Hi folks, I'm seeing a similar problem on a chroot that doesn't have bzip2, combined with a mirror that only offers the bzip2 version (with and without .bz2 extension).
I can reproduce this on my regular system by adding this sources.list
line,
deb http://ftp.ch.debian.org/debian/ wheezy main
uninstalling the bzip2 pacakge,
sudo dpkg -r --force-depends bzip2
and then running "apt-get update":
matthijs@grubby:~$ sudo apt-get update
[sudo] password for matthijs:
Hit http://ftp.ch.debian.org wheezy InRelease
Hit http://ftp.ch.debian.org wheezy/main amd64 Packages/DiffIndex
Hit http://ftp.ch.debian.org wheezy/main TranslationIndex
Get:1 http://ftp.ch.debian.org wheezy/main Translation-en [3699 kB]
Fetched 1 B in 1s (1 B/s)
W: Failed to fetch
copy:/var/lib/apt/lists/partial/ftp.ch.debian.org_debian_dists_wheezy_main_i18n_Translation-en
Encountered a section with no Package: header
E: Some index files failed to download. They have been ignored, or old
ones used instead.
This downloads the following file:
matthijs@grubby:~$ wget -O /dev/null --server-response
http://ftp.ch.debian.org/mirror/debian/dists/wheezy/main/i18n/Translation-en
--2012-01-25 18:42:48--
http://ftp.ch.debian.org/mirror/debian/dists/wheezy/main/i18n/Translation-en
Resolving ftp.ch.debian.org (ftp.ch.debian.org)... 129.132.86.210
Connecting to ftp.ch.debian.org (ftp.ch.debian.org)|129.132.86.210|:80...
connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Wed, 25 Jan 2012 17:42:48 GMT
Server: Apache/2.2.16 (Debian)
Content-Location: Translation-en.bz2
Vary: negotiate
TCN: choice
Last-Modified: Wed, 25 Jan 2012 14:02:21 GMT
ETag: "3c6c19d-387179-4b75ab657f540;4b75ab657f540"
Accept-Ranges: bytes
Content-Length: 3699065
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/x-bzip2
Length: 3699065 (3.5M) [application/x-bzip2]
as suggested before, this response really returns the .bz2 version, which apt
does not currently handle.
I'm not really sure how apt should handle this: By the time it gets to try the
uncompressed version, it has already tried all supported compressions, so it
probably can't handle the file, even if it would try to find out the type. I
can imagine apt looking at the Content-Type, and simply rejecting the
file if it's not what it expects, but that sounds a bit harsh to me.
Also, it could cause problems with mirrors that don't set the correct
Content-Type, but I guess those mirrors need fixing...
Alternatively, apt could just drop anything that has a Content-Location
in its response, but that sounds even harsher...
I also tried to prevent the "negatiation" from happening by passing
"Accept-Encoding: identity" in the HTTP request using wget, but that
didn't help (which makes sense, since Accept-Encoding is about
negotiating Content-Encoding, not Content-Type). However, I'm not sure
if you can actually negotiate over the Content-Type, since the server is
really just sending a different resource instead...
Anyway, just my observations,
Gr.
Matthijs
signature.asc
Description: Digital signature
