On Wednesday 15 February 2006 11:08, William L. Maltby wrote:
On Wed, 2006-02-15 at 09:44 +0100, Peter Kjellström wrote:
On Tuesday 14 February 2006 22:14, William L. Maltby wrote:
Sorry to reply to myself, but ...
On Tue, 2006-02-14 at 13:45 -0500, William L. Maltby wrote:
On Tue, 2006-02-14 at 10:55 -0500, Jim Perrin wrote:
<snip>
Try running 'yum clean all' then 'yum update' and see what you get. rpmforge should include all of dag's packages anyway so there shouldn't be a problem. All I can tell you is it "WorksForMe".
All the other's updated fine. I'm going to ribit and do a forced fsck to make sure I'm not getting victimized by a creeping calamitous failure on my HD. Then I'll try some manual junk.
Ummm... I'd try some manual junk if I had any idea where to start. I did the reboot, fsck, and even tried a yum update while in single user mode. ImageMagick updated ok, but the two files here failed again.
nmap-frontend.i386 2:4.01-1.2.el4.rf nmap.i386 2:4.01-1.2.el4.rf
Since I'm under the aegis of WFM now, if someone could give a starting point for me to follow and resolve, I'd appreciate it and stop pestering you all. I can't figure why only this one should be a problem only for my installation. *sigh*.
FWIW, I see the exact same problem here with all of my centos-4 machines that have nmap from rpmforge.net. I consider it a broken rpm package (but havn't looked into it yet. I dropped dag a line about it.
Peter, thanks for taking the time. I see several other posts report the problem now, so apparently the "WorksForMe" poster has a better setup. Anyway, Johnny Hughes replied (in thread Re: [CentOS] DAG Repository) that there is a known and on-going problem of this type with that mirror that is so persistent that Dag made a form for dealing with it. It is here
http://dag.wieers.com/home-made/apt/FAQ.php#C1You can allways update and, for the time, ignore nmap like this: yum --exclude=nmap update
Yes, I did that. In resolution of another problem a couple weeks back, I re-read completely the oft cited YUM documents. Combined with suggestions like yours above that I had seen on the lists before, that one stuck in my mind and allowed me to proceed regardless of the one bad file.
/Peter
<snip diag listing I sent>
What I'm thinking now is that there is probably some way to override the checksum/gpg checking from the command line. If so, and if I can find out what the real check sum is supposed to be, I could check the file and install it by turning off the checking (at the command line hopefully, instead of temp modification of the config file).
The bigger ones yum config, the more servers you depend upon for sanity in order to get 100% success rate on yum update type commands :-/
I feel sorry for the rpmforge guys because they've had a lot of problems with their mirrors (and as such with users running yum). They do a great job and fantasic packages. The rpmforge-release package is a very good idea, it takes care of adding the relevant parts to your yum conf and as such reduces risks associated with the human factor.
As I wrote in the other sub thread, if yum and/or rpm barfs on the file it's probably not a good candidate for installing. Don't fall down to fedora levels of package checking ;-). If a package fails it's rpm sums, then it's broken and the user should wait for a fixed one.
/Peter
So a little reading again of the YUM docs (I hope I don't have to do it so often that I no longer need to read it! =:-O ) and effort to get the right "numbers" and I shiould be able to get it done withb waiting for the habitually broken mirror folks to habitually fix it habitually temporarily again.
Again, thanks for the reply.
Bill