[Mageia-dev] Missign rebuilds tagged mga1

Wed Jan 16 23:06:18 CET 2013

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
+