Regenerated and uploaded the new jigdoes, old ones renamed with a trailing '_'. CentOS-5.0-i386-bin-1of6.jigdo CentOS-5.0-i386-bin-1of6.template CentOS-5.0-i386-bin-DVD.jigdo CentOS-5.0-i386-bin-DVD.template CentOS-5.0-x86_64-bin-1of7.jigdo CentOS-5.0-x86_64-bin-1of7.template CentOS-5.0-x86_64-bin-DVD.jigdo CentOS-5.0-x86_64-bin-DVD.template md5sum.txt sha1sum.txt (basically both the first CD and the DVD contain the release notes, so they all needed a rebuild, I verified all the others didn't change/still work (at least on my local mirror)). > They shouldn't. These seem to have changed because of the charset fuckup > with the release notes on the ISOs. Hmm. Well, in the future we should either not make such changes (I'm assuming we want to keep valid jigdoes around) or we'll have to regenerate the jigdo/template files in such a situation. I think sticking the new fixed files under a different name would also be a valid solution (you can add new files, what you can't do is you can't change existing files required by jigdo). We could also possibly run jigdo with a minimum file size requirement closer to 200KB which would allow changes to the smaller (ie. text) files. However I would vote for keeping the os tree totally frozen from the point of release. Although increasing the min file size would possibly also with only a slight template file size increase reduce the number of files needing downloading... Here's a list of the current number of external (ie. in mirror) files in each jigdo/template: CentOS-4.4-SRPMS-src1of4.jigdo: 204 CentOS-4.4-SRPMS-src2of4.jigdo: 205 CentOS-4.4-SRPMS-src3of4.jigdo: 208 CentOS-4.4-SRPMS-src4of4.jigdo: 208 CentOS-4.4-i386-ServerCD.jigdo: 606 CentOS-4.4-i386-bin1of4.jigdo: 2138 CentOS-4.4-i386-bin2of4.jigdo: 255 CentOS-4.4-i386-bin3of4.jigdo: 381 CentOS-4.4-i386-bin4of4.jigdo: 340 CentOS-4.4-i386-binDVD.jigdo: 3104 CentOS-4.4-x86_64-bin1of4.jigdo: 2368 CentOS-4.4-x86_64-bin2of4.jigdo: 256 CentOS-4.4-x86_64-bin3of4.jigdo: 411 CentOS-4.4-x86_64-bin4of4.jigdo: 474 CentOS-4.4-x86_64-binDVD.jigdo: 3508 CentOS-5.0-i386-bin-1of6.jigdo: 559 CentOS-5.0-i386-bin-2of6.jigdo: 418 CentOS-5.0-i386-bin-3of6.jigdo: 421 CentOS-5.0-i386-bin-4of6.jigdo: 357 CentOS-5.0-i386-bin-5of6.jigdo: 422 CentOS-5.0-i386-bin-6of6.jigdo: 214 CentOS-5.0-i386-bin-DVD.jigdo: 2386 CentOS-5.0-x86_64-bin-1of7.jigdo: 575 CentOS-5.0-x86_64-bin-2of7.jigdo: 555 CentOS-5.0-x86_64-bin-3of7.jigdo: 520 CentOS-5.0-x86_64-bin-4of7.jigdo: 398 CentOS-5.0-x86_64-bin-5of7.jigdo: 492 CentOS-5.0-x86_64-bin-6of7.jigdo: 348 CentOS-5.0-x86_64-bin-7of7.jigdo: 219 CentOS-5.0-x86_64-bin-DVD.jigdo: 3100 To me it doesn't look to bad, seems average file size is easily above 1MB, so the number of required files (ie. connection establishment/handshake/etc) shouldn't drastically impact performance. (ie. downloading via jigdo shouldn't be much slower than downloading the iso directly - assuming you're downloading from the same mirror). Jigdo also has the added benefit of reducing the amount of data mirrors need to sync, and allowing us to release stuff like rolled up update cds with almost no mirror space/bandwidth overhead (same thing for anything else that uses in-tree files, live ServerCD's, but not LiveCD's [which are totally recompressed and thus have no common parts to the os tree]. > On another note: I was able to rebuild all other x86_64 CD isos and they > do have the same checksums as the ISOs on the mirrors. Yes :) I did verify this at home. > And I asked dag to rebuild jigdo-0.7.3 for rpmforge, so it will be > available for CentOS 5 also. Cool. > More testing from me in the next few days, I have to go through the > documentation first and that needs a little time. What we need to figure out is a better way to specify the source mirror, possibly hack around in the jigdo-lite script. It might also make sense to see if we can improve (parallelize) jigdo-lite download performance to make it work better on bigger pipes (and possibly not require quite so much temporary space).