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