Trying to build an "oldstable" ("jessie") tarball fails trying to download "gstreamer1.0-libav" (which nothing depends on and shouldn't be pulled in at all) #41
Comments
|
Just verified |
|
It's confirmed!!!! #37 is the culprit. Apparently APT in Jessie cannot actually handle that (so we'll need to update that to be Stretch and later instead). |
|
Also confirmed that |
|
(Thinking of adding |
|
Trying to help narrow this down, I've walked backwards to + debuerreotype-apt-get rootfs dist-upgrade -yqq
E: Failed to fetch http://snapshot.debian.org/archive/debian-security/20180301T000000Z/pool/updates/main/libr/libreoffice/libreoffice-core_4.3.3-2+deb8u10_amd64.deb Size mismatch
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?(We definitely don't ever install anything that might pull in |
|
So, I'm starting to think this probably isn't something that changed in a package, but probably more likely something where one of the To recap: I'm able to reproduce by doing the following in a $ sed -i '/CompressionTypes/d' /etc/apt/apt.conf.d/docker-gzip-indexes
$ apt-get update
$ apt-get dist-upgrade # not sure this step is necessary
$ apt-get install --no-install-recommends build-essential fakerootHere's the results of my rough binary search to narrow down further exactly when things changed enough to cause this behavior: (doing
So, something changed between |
|
Here's the request logs of the Interesting that it does a |
|
One major change between 2018-02-17 and 2018-02-18 is that we got a security update to (Looking at a |
|
As expected, http://snapshot.debian.org/archive/debian/20180217T000000Z/dists/oldstable/main/binary-amd64/Packages.xz and http://snapshot.debian.org/archive/debian/20180218T000000Z/dists/oldstable/main/binary-amd64/Packages.xz are identical (which is good). Ditto with http://snapshot.debian.org/archive/debian/20180217T000000Z/dists/oldstable-updates/main/binary-amd64/Packages.xz and http://snapshot.debian.org/archive/debian/20180218T000000Z/dists/oldstable-updates/main/binary-amd64/Packages.xz. That $ diff -u <(curl -fsSL 'http://snapshot.debian.org/archive/debian-security/20180217T000000Z/dists/oldstable/updates/main/binary-amd64/Packages.bz2' | bzcat) <(curl -fsSL 'http://snapshot.debian.org/archive/debian-security/20180218T000000Z/dists/oldstable/updates/main/binary-amd64/Packages.bz2' | bzcat) | grep 'Source:' | sort -u
+Source: gcc-4.9
+Source: gcc-4.9 (4.9.2-10+deb8u1)
Source: gdk-pixbuf |
|
Giving up on digging further to figure out the root cause; filed #42 to patch around the issue instead (especially since Jessie transitions to LTS this weekend). |
Somewhere between 20180426 and today, something has changed such that the following failure is 100% reproducible while trying to do something like
./build.sh --codename-copy output oldstable 'today'(wheretodaycan be replaced by any recent timestamp).I've tried a number of things such as #39 which I thought would help because the error looks like a download failure so I was hoping my Squignix hack could help paper over the failure, but looking into it it's much more nefarious than that (see tianon/squignix#2 for where I initially filed a note about this). Here's the failure output with a bunch of context that I'll explain following:
If you're more in-tune than I was the first 20 or so times I looked at this output, you might notice that not only is
gstreamer1.0-libavnot one of the 39 packages APT tried to download, it's also not listed as a dependency of anything being installed (and this is happening in a pretty standard/faithfulminbasechroot -- basically justdebuerreotype-init,dist-upgrade, followed bydebuerreotype-minimizing-config), so uh, what??I've tried re-ordering the lines in
debuerreotype-gen-sources-listto match the order of https://salsa.debian.org/installer-team/apt-setup/tree/master/generators instead of https://wiki.debian.org/SourcesList#Example_sources.list (silly, but figure it was an easy change to rule out right off).I've tried reproducing by using the current
debian:jessie-slimDocker image and updating itssources.listto use the same exactsnapshot.debian.orglinks (identicalsources.listcontent), no avail.I've tried removing the
tmpfsthat we build the rootfs on top of (just in case), no avail.This is 100% reproducible at this point on several AWS hosts and my local machine, so I don't think it's environmental either.
My next attempt is going to be essentially doing a binary search of snapshot.debian.org timestamps to try and narrow down what's changed in the archive between the known-good and current timestamps to try and glean more clues. 😞
The text was updated successfully, but these errors were encountered: