Op dinsdag 15 januari 2013 12:32:27 schreef Johnny A. Solbu: > On Tuesday 15. January 2013 11.43, Colin Guthrie wrote: > > Sounds like one of your media couldn't be updated or something. Not > > directly related to urpmi-proxy per-se but it could certainly confuse > > the issue :) > > Just for good measure, I ran «urpmi.upfdate -a» just now, and the count > didnt change. No media where unable to update, and I only have one repo > configured. (http://ftp-stud.hs-esslingen.de/pub/Mirrors)
just mentioning, that the disadvantage to urpmi-proxy, is that it hides connection errors to repositories, since it will use cache if it fails. you can look at the logfile if it mentions HIT_AFTER_FAIL (which means it gets you cache after it failed) lately, i've been testing with 2 repositories and changing the timeout value to very low values (5s) as first repos, i choose one that is fast, and as second repos, i use what is always up2date. considering MD5SUM would be asked for both repositories (it's a specially configured file for that), it would get you always up2date results, since the first would fail to have the file and the second one would be asked for it. for me, this gave alot better results especially for cauldron during the mass rebuild...
