Op woensdag 16 januari 2013 21:22:22 schreef Colin Guthrie: > 'Twas brillig, and AL13N at 16/01/13 20:22 did gyre and gimble: > > 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... > > Interesting idea. Never thought about using two mirrors in the config. > > I fought with urpmi-proxy today for a while. No matter what I tried, > when downloading a synthesis via the proxy it always ended up too small > and with md5sum failures. Requesting the same file direct from the > mirrors worked every time. I noticed that the file never ended up in the > cache tree, just in the tmp dir. Time wasn't on my side, so I didn't > debug further... one to fight another day. > > (this is with urpmi-proxy-0.3.2-1.mga2 on mga2 FWIW) > > > Col
so, either a partial file, or out of disk space? better make sure the cache tree is the same partition as the tmp dir it uses. in any case, using multiple mirrors isn't supported... (yet) i'm just trying them out this way. i had alot of troubles with cauldron due to mismatches with MD5SUM and the synthesis files, because the MD5SUM doesn't match the synthesis files but, sometimes, i do have some oddness in files (i think maybe i need better error-checking) like if you get a partial result, it doesn't get removed from cache. so if it does fail, i delete the file from the cache tree for now. don't forget to do that in all your cascading urpmi-proxy's... i actually have tested 3 cascading urpmi-proxy's. in normal usage, i have an urpmi-proxy at my local lan. one at my desktop itself, and then once i tested urpmi-proxy in a VM on my desktop. the one on my desktop has an "extra" repository (and changes which ones are default), and the one on the server has now 2 sources (http mirrors), with very small timeouts (i may have used 3 or 5 seconds) since i have an urpmi-proxy at work, my work-laptop had always 2 sources which i uncommented constantly, but perhaps i should actually set them both, with very small timeouts... maybe with a 3rd slow one? /me continues to ponder
