Natty alpha2 source jigdo's fail - 1500 files missing, don't match binaries

Bug #713876 reported by John Gilmore on 2011-02-06
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu CD Images

Bug Description

I tried to download the three source DVDs from the Natty alpha2 release candidate from here:

I was able to get the jigdo and template files, but when I run jigdo-lite on them, it is only able to
download some of the thousands of files required from the Ubuntu repositories.

In natty-src-1, 883 files are missing. Examples include:

In natty-src-2, 500 files are missing. Examples include:

In natty-src-3, 161 files are missing. Examples include:

I tried chasing down one of these packages (xserver-xorg-video-intel). The Ubuntu packages site:

says that the Natty version is 2.14, not 2.13.901, and lists these source file locations:

Those files exist and I was able to download each of them.

Now the question is: which *binary* was included in alpha-2? I downloaded (via its torrent) and mounted the Natty desktop ISO image:

Inside the image, /casper/filesystem.manifest and /casper/filesystem.manifest-desktop both list:

  xserver-xorg-video-intel 2:2.14.0-1ubuntu5

Inside the squashfs in the desktop iso, /usr/doc/xserver-xorg-video-intel has an entry for version 2:2.14.0-1ubuntu5, and
the README file mentions "Release 2.14.0 (2011-01-07)".

The natty-src-3.jigdo file includes the line:


It looks like the binary ISO shipped version 2:2.14.0-1ubuntu5, but the source jigdo's tried to ship something else, thus causing the jigdo problem.

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
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

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

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

Changed in ubuntu-cdimage:
importance: Undecided → Low
status: New → Triaged
John Gilmore (gnu-gilmore) wrote :

It's not just the jigdo's that are wrong -- the "natty-src-3.iso" file that I downloaded from the web also includes the wrong source code (xserver-xorg-video-intel_2.13.901 rather than version 2.14).

It appears that Ubuntu is intentionally violating the GPL every time it cuts an alpha or beta release, by releasing binary CD/DVDs without matching sources. And marking this "importance: Low"? I don't think releasing matching sources for your binaries is optional, whether or not "Unfortunately, this is extremely hard to fix." If you can't fix it, you can't ship those binaries. Any GPL copyright holder could sue you over it, today, and shut down your release process.

It also seems bizarre that Ubuntu can manage to build complete binary releases but can't build matching source releases. In every other shop I've ever dealt with, the source release is built first, THEN the binaries are built from the sources. Why can't Ubuntu make releases in the normal way, which would guarantee the ability to produce matching sources and binaries?

All versions of our source packages are available on Launchpad,
distributed by us. True, they aren't on the same server, but we do
distribute them for at least the lifetime required by the GPL - in fact,
I'm not aware that we've ever deleted any library copies of source
packages since we started using Launchpad for our archive.

I marked this as Importance: low because it's a CD assembly issue, not a
failure to provide source code (which would certainly be of much higher

Individual Ubuntu packages are obviously built as you say: source is
uploaded first, then binaries are built from that. However, we do not
rebuild the binaries from source every time we build a CD set - it would
be prohibitively slow. The difference from your analogy with other
shops is that CD images are assembled, not compiled: they're built from
pre-existing binaries taken from the Ubuntu archive. Since different CD
images are built at different times, there's version skew. We have thus
the following choices:

  1) Build individual source images for each binary image.

     This is what we used to do. However, the space cost is prohibitive
     because there's so much duplication, and for the same reason it's
     not convenient for users trying to keep a source archive. We
     therefore switched to ...

  2) Build a single set of source images during the binary image set

     This mostly works, but there's unfortunate skew.

  3) Once we've built binary images, retroactively construct a set of
     source images with the union of all the versions found therein.

     This is probably what we need to do.

Colin Watson (cjwatson) wrote :

I've added a note now to the HTML index files for natty alpha-2 and all future source image builds, giving directions for getting source packages from Launchpad in the event of version skew. I realise this doesn't meet ideal archiving requirements for source images, but I think it should make it clear that we're meeting our legal obligations.

If you still believe that we're failing to meet our obligations under the GPL, of course you're welcome to contact Canonical's legal department - they will no doubt send a rocket my way if that's so.

Colin Watson (cjwatson) wrote :

(I mean, if you don't feel you're getting satisfaction from me.)

Dimitri John Ledkov (xnox) wrote :$FILENAME is an automatic redirector. I guess if either I get my going it will be generic "archive" that has all versions of .dsc & .debs (well anything that launchpadlibrarian still has) I guess we can teach to become an "ubuntu mirror" e.g. accept normal archive like urls and redirect them to launchpad librarian as per above.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers