On Thu 22 Nov, Richard Atterer wrote: > On Thu, Nov 22, 2001 at 07:35:24PM +0000, Wookey wrote: > > On Thu 22 Nov, Richard Atterer wrote: > > > > > So, did it work? :) > > > > As I explained to richard offlist > > Er, who was that mail for? Feel free to quote me on the mailing list > or elsewhere. :)
That coment was just to explain to other readers who might have noticed that they had missed part of the conversation (I couldn't be bothered typing all the info I sent to you in again just to keep the list informed :-) > > the answer is 'not quite' - it goes round and round in circles > > downloading and then saying it can't find 2 files (one of ehich is > > the 4Mb debian-keyring, which is a bit tedious. > > It really should be able to give an error saying that the MD5 sum does > not match. Unfortunately, that's very difficult because jigdo-file > *never* looks at filenames, it just scans everything and uses whatever > matches a part of the image. Ah - OK. That explains why when I point it at my debian archive to see if it can find the files it needs from there it scans the _whole damn thing_, which takes quite a while :-) - I had foolishly assumed that it would only look at the files it needed, as listed in the .jigdo file. > jigdo-file is really only designed to be > used for *generating* template/jigdo files - I'm abusing it a bit for > recreating images... > > #include <jigdo-gui-app-will-do-this-properly.h> fair enough :-) > Well, I think I'll just change the "Aargh, this should not happen" > message to one that says "If it all downloaded OK and you still got > here, this means the original files are no longer on the FTP server." So what happens to the unlucky CD-creator at this point? The rsync approach will still work in this case. Jigdo is knackered. And all the files in an official release _should_ still be on the server. Do the 2.2r4 jigdo files need recreating to match the true state of affairs? Anyway I've gone back to using PIK+a script to download the missing bits to update my archive+PIK+rsync to get some finished CDs as I need them for the w/e. > > I.... notice that in scanning every file that is > > larger than 127K is listed as 127K/<realsize> with an appropriate > > percentage. > > This had me wondering for a while... :-) > What happens is: > - jigdo-file starts scanning file, prints first percentage info after > 128k. Because the name is too long, an LF takes place and the 128k > line stays visible (which is a bug; will fix). > - jigdo-file scans through rest of file. It is intelligent enough > *not* to print the filename again - to reduce flicker, it only > overwrites the percentage. Thus, no further unwanted LFs happen. > - jigdo-file starts scanning next file. The first percentage for that > file will *overwrite* the "100%" of the previous one. yep - that makes sense. I agree this is the explanation. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]