Ubuntu CD Images

Bug #713876
Comment #1

Comment 1 for bug 713876

Revision history for this message

Colin Watson (cjwatson) wrote on 2011-02-08: Re: [Bug 713876] [NEW] Natty alpha2 source jigdo's fail - 1500 files missing, don't match binaries

The missing files have always been a problem with milestone (i.e.
pre-release) builds. Unfortunately, this is extremely hard to fix. We
don't have a snapshot archive that corresponds to the point at which the
jigdo files were built, and files are expired from archive.ubuntu.com
once they've been superseded by newer versions in the same release for a
while (about a day, I think). This is not a problem for the final
release because everything in the final release is kept around.

My usual suggestion is to use jigdo to download everything it can, and
then use rsync to fix up any remaining differences, although I agree
that this is not well documented.

While bug 187864 requests that Launchpad provide snapshot archives, and
this would gain something in terms of avoiding confusing UI, it wouldn't
gain anything in terms of the primary purpose of jigdo, i.e.
transferring some of the ISO image download cost to a local mirror,
because any such snapshot archive would likely be extremely poorly
mirrored.

As for the source/binary desync, well, this is partly because I switched
to a single aggregated source ISO image as the simplest resolution to
your previous comments on source images, and that image is built from
whatever the current versions are at the time when it was built. If the
archive skewed between the binary image builds then the source image
only gets to contain one of them. (There are of course theoretical
workarounds for this - scan all binary images, pick out required
versions, calculate union of all those versions, construct archive of
any versions no longer in the archive by downloading directly from
Launchpad, build source image based on that archive - but unfortunately
debian-cd doesn't support this kind of thing very well, to put it
mildly.)

I suspect that this was compounded because our release managers have to
remember to rebuild the source image towards the end of the milestone
release process, and it looks like that may not have happened in this
case. We could probably use some process improvement here.

status triaged
importance low

The missing files have always been a problem with milestone (i.e.
pre-release) builds.  Unfortunately, this is extremely hard to fix.  We
don't have a snapshot archive that corresponds to the point at which the
jigdo files were built, and files are expired from archive.ubuntu.com
once they've been superseded by newer versions in the same release for a
while (about a day, I think).  This is not a problem for the final
release because everything in the final release is kept around.

My usual suggestion is to use jigdo to download everything it can, and
then use rsync to fix up any remaining differences, although I agree
that this is not well documented.

As for the source/binary desync, well, this is partly because I switched
to a single aggregated source ISO image as the simplest resolution to
your previous comments on source images, and that image is built from
whatever the current versions are at the time when it was built.  If the
archive skewed between the binary image builds then the source image
only gets to contain one of them.  (There are of course theoretical
workarounds for this - scan all binary images, pick out required
versions, calculate union of all those versions, construct archive of
any versions no longer in the archive by downloading directly from
Launchpad, build source image based on that archive - but unfortunately
debian-cd doesn't support this kind of thing very well, to put it
mildly.)

I suspect that this was compounded because our release managers have to
remember to rebuild the source image towards the end of the milestone
release process, and it looks like that may not have happened in this
case.  We could probably use some process improvement here.

status triaged
 importance low