this may be less of a bug and more a question of expected behavior.
up2date_client/up2date.py's checkRpmMd5 takes one of 2 routes - if it can,
rpm.checksig(fileName, rpm.RPMTAG_SIGMD5) otherwise /bin/rpm -Kv --nopgp
if you apply this patch:
to up2date you see that they don't return the same thing - specifically, rpm
-Kv does return "MD5 sum OK" (and hence returns 0 for checkRpmMd5) but
rpm.checksig(fileName, rpm.RPMTAG_SIGMD5) is returning 1 which is breaking
Checking rpm-4.0.4/python/rpmmodule.c, we just call through to rpmCheckSig
with the appropriate flags set. Then checking rpm-4.0.4/lib/rpmchecksig.c it
*looks* like (hard to tell for sure) that it should return 0 if the md5 on the
file is fine (and the md5 flag was passed)
So the question is: is rpm.checksig returning 1 expected behavior for an rpm
with a good md5sum? And if not, any idea what's going on (flag translation is
all that makes sense as a guess given the rpm -Kv works)
Getting headers for available packages...
rpm.checksig returns 1 on file /var/spool/up2date/zip-2.3-12.i386.rpm
rpm -Kv returns 0 on file /var/spool/up2date/zip-2.3-12.i386.rpm
You should do
as opposed to SIGTAG_MD5 and SIGTAG_GPG
1) the flag was rpm.RPMTAG_SIGMD5 - what is SIGTAG_MD5? is that the equiv once
it gets into C space?
2) sounds like you're saying that up2date.py's not using the right flag, so I'm
reopening this as an up2date bug
ugh - i had hoped the bug owner would shift along with component, but here's
step 2 to get this over to adrian
jeremy told me you've already got this fixed in cvs, adrian, so either
close/dup this on whatever or use it to lemme know when the fix makes it
out ;) Kinda funny since this is all orthogonal once you switched to file size
instead of md5 checks in bug 53583
yeah, fixed in cvs, around 2.7.77 or so
It's not completely orthogonal since I use the md5 sum
when reading stuff off local disk cache to see if the files
are complete, and if not I download them again.
Thats what was causing the "skipjack always downloads
the packages" bug.