Re: jigdo 0.6.0 - testing
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/
Reply to: