Description of Problem: I tried to update everything available on Monday. up2date stopped (at 98% done!) with an error (auth required?) for one package; now I'm trying again, most of the packages are already downloaded, but no account is being taken of them, and up2date is complaining about lack of free space. I don't really want to download them all again, because it's a waste of time and bandwidth. Version-Release number of selected component (if applicable): up2date-2.7.0-7.x.1
yep, downloaded packages are not removed from list.
*** This bug has been marked as a duplicate of 5316 ***
yup, will take a look at fixing this for the next release of up2date.
Looks like this was marked as a duplicate of the wrong bug? 5316 was an install problem, I guess a digit is missing (should be 53xxx).
FWIW up2date worked very well for me today, although it took a while to download the updates. Where would I log an enhancement request for the RHN web interface, by the way? I need to delete two of the three profiles my work desktop has on the server - one each for 7.1, some hybrid Roswell / Raw Hide version and now 7.2 :o)
doh, typo... meant bug 53216 *** This bug has been marked as a duplicate of 53216 ***
*** Bug 62708 has been marked as a duplicate of this bug. ***
Created attachment 52404 [details] patch against up2date-2.7.51-7.x.3
ugh - sorry, wrong patch got uploaded - I'm tracking down a "problem" with rpm.checksig now - either there's something quirky about it or we're interpreting its result wrong. The gist of it is that if I force the legacy 3.0.x behavior (so we spawn rpm -Kv) then the md5 check happens fine - if instead it does the rpm.checksig, it says it's invalid. Since the rpm binary says it's fine, something's screwy... so, ignore this patch while I clarify what the rpm.checksig problem is.
UGH - if I edit up2date.py's checkRpmMd5 to comment out the if, else, and "return ret" lines (so we run both rpm.checksig *and* rpm -Kv for the file) then add some prints to spit it out: 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 any ideas why checksig says it's wrong with -Kv is fine with it? existing known bug?
Created attachment 52424 [details] simple hack to do both md5 methods and show the diff - just for testing
Created attachment 52425 [details] patch against up2date-2.7.65-7.x.3 - works once checkRpmMd5 acts right :)
patch looks good. thanks. not sure I follow the issue with rpmcheckMd5...? I'll test it out and see whats up
I'll see if I can get the gui code handling this case as well, and hopefully in the next version
Created attachment 52484 [details] better version - don't do the cached checks (hits fs) unless we need that extra space in the check
better version of patch avail, please apply that instead - it'll behave nicer in the typical case and just hit if(cached) if we need that extra space in the check The checkRpmMd5 problems with rpm.checksig are covered pretty well in bug 62802 which I think Jeff is ignoring because he doesn't like me :) If anyone else knows rpm.checksig expected behavior, I'm all for it :)
Created attachment 52485 [details] *sigh* yeah - zero out the sum var before re-calc'ing a sum - dammit
I kind of like the first one better (minus s/filename/fileName). Since with the first one, the totalSize value is always going to be accurate, not just in cases where it matters. Since I display that value in the gui, I would like it to be accurate, and if I can get there the same way in the cli, all the better. I'm not too worried about the performance hit of doing the md5 check.
ah, ok - forgot the gui would display that. Neat :) The one thing I don't like is that we're not caching (although arguably that's better) the md5 check so we do it twice with this patch - once at size check and another at getPackage time. But, if the md5 I/O traffic's not a big deal (should still be largely cached from the first time through) we're probably still ok.
looks like doing the md5 for every package in the gui is too slow.... Probabaly going to try something like the patch you suggest... unless I can find a way to keep a accurate total and not be slow as dirt... perhaps checking to see if the file sizes match, instead of doing the md5 (since I do that later anyway...)
yup, doing a size check seems to work. I do the md5check later when I do the package fetch path (I changed it back to not use isPackageCached, since it no longer validates md5s) gui/cli/action seems to like the changes. Should be fixed in version 2.7.88 or higher
works, I'm closing bug.