Natty alpha2 source jigdo's fail - 1500 files missing, don't match binaries
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu CD Images |
Triaged
|
Low
|
Unassigned |
Bug Description
I tried to download the three source DVDs from the Natty alpha2 release candidate from here:
http://
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:
http://
libimobiledev
php5_
kdegames_
grantlee_
meta-
base-
kdevelop_
lapack_
In natty-src-2, 500 files are missing. Examples include:
http://
packagekit_
partman-
python-
telepathy-
nvidia-
pkgsel_
libselinux_
vlc_1.
qt4-perl_
In natty-src-3, 161 files are missing. Examples include:
http://
xserver-
xserver-
ubufox_
xulrunner-
xserver-
xserver-
ispell.
xfwm4_
I tried chasing down one of these packages (xserver-
http://
says that the Natty version is 2.14, not 2.13.901, and lists these source file locations:
http://
http://
http://
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:
http://
Inside the image, /casper/
xserver-
Inside the squashfs in the desktop iso, /usr/doc/
the README file mentions "Release 2.14.0 (2011-01-07)".
The natty-src-3.jigdo file includes the line:
BHe5tCtOFkP-
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 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