Control: tag -1 confirmed On Tue, Feb 09, 2016 at 11:42:59PM -0500, James McCoy wrote: > On Fri, Feb 05, 2016 at 12:35:11AM +0100, Julian Andres Klode wrote: > > On 4 February 2016 at 23:44, Guillem Jover <guil...@debian.org> wrote: > > > On Thu, 2016-02-04 at 08:39:30 -0500, James McCoy wrote: > > >> On Thu, Feb 04, 2016 at 12:56:53AM +0100, Guillem Jover wrote: > > >> > Just to make sure, if you have the > > >> > libjpeg62-turbo_1%3a1.4.2-2_amd64.deb > > >> > around could you check that it really contains the libjpec62-turbo > > >> > package inside with say dpkg-deb, or manually with ar+tar? > > After some discussion with Julian on IRC about some of the issues I've > been seing lately, and his suggestion that a parse change might be > related, I'm thinking that's more likely. > > Just as a recap, yesterday I was hitting #813000 (corrupt package index, > can't find Filename:). I mentioned that it happened even after I > removed the Packages file and re-ran "apt update", so it's not PDiff > related. > > Today, after an update, I tried to install the same package I was trying > to install last night and ran into the "Writing more data than expected" > error while downloading the deb. The interesting part is that apt > reported it got that error while trying to download a deb that it > shouldn't have been downloading: > > └[jamessan@freya] 0 % sudo apt install abi-dumper > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following additional packages will be installed: > elfutils libasm1 vtable-dumper > The following NEW packages will be installed: > abi-dumper elfutils libasm1 vtable-dumper > 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. > Need to get 353 kB of archives. > After this operation, 1,155 kB of additional disk space will be used. > Do you want to continue? [Y/n] > Get:1 http://httpredir.debian.org/debian sid/main amd64 libasm1 amd64 > 0.165-3 [27.6 kB] > Get:2 http://httpredir.debian.org/debian sid/main amd64 elfutils amd64 > 0.165-3 [293 kB] > Get:3 http://httpredir.debian.org/debian sid/main amd64 vtable-dumper > amd64 1.1-1 [6,870 B] > Err:3 http://httpredir.debian.org/debian sid/main amd64 vtable-dumper > amd64 1.1-1 > Writing more data than expected (27304 > 25526) > Get:4 http://httpredir.debian.org/debian sid/main i386 abi-dumper all > 0.99.12-1 [25.5 kB] > Fetched 346 kB in 1s (228 kB/s) > E: Failed to fetch > http://httpredir.debian.org/debian/pool/main/r/r-cran-teachingdemos/r-cran-teachingdemos_2.9-1_all.deb > Writing more data than expected (27304 > 25526) > > E: Unable to fetch some archives, maybe run apt-get update or try with > --fix-missing? > > Apt is supposed to be downloading abi-dumper, but it then reports it > failed to fetch r-cran-teachingdemos. > > Seeing that reminded me of this email, so I checked > /var/cache/apt/archives/partial: > > └[jamessan@freya] 0 % sudo dpkg-deb -I > /var/cache/apt/archives/partial/vtable-dumper_1.1-1_amd64.deb.FAILED > new debian package, version 2.0. > size 65536 bytes: control archive=1338 bytes. > 608 bytes, 14 lines control > 2223 bytes, 26 lines md5sums > Package: r-cran-teachingdemos > Version: 2.9-1 > Architecture: all > Maintainer: Debian Science Team > <debian-science-maintain...@lists.alioth.debian.org> > Installed-Size: 1741 > Depends: r-base-core (>= 3.0.1-1) > Recommends: r-cran-misc3d, r-recommended, r-cran-mapproj > Section: gnu-r > Priority: optional > Homepage: http://cran.r-project.org/web/packages/TeachingDemos/ > Description: GNU R Demonstrations for teaching and learning > This package is a set of demonstration functions that can be used in a > classroom to demonstrate statistical concepts, or on your own to better > understand the concepts or the programming. > > After another dinstall run, I still can't install abi-dumper, but now > apt is downloading r-cran-surveillance instead of r-cran-teachingdemos. > > I've made the two Packages files available at: > https://people.debian.org/~jamessan/tmp/r-cran-teachingdemos-amd64_Packages.lz4 > https://people.debian.org/~jamessan/tmp/r-cran-surveillance-amd64_Packages.lz4 > > > On IRC it was mentioned that bug #813000 mentions that the update can > > generate Packages files in the APT dir with messed up contents. > > From at least visual inspection, it isn't corrupted. Also, given that > both a PDiff generated and downloaded Packages file show this issue, it > seems to be something in apt's parsing. > > > I'm > > not entirely sure it's related, but maybe it is. That must be a very > > unlikely incarnation of that bug though (two packages would need their > > Filename and various hash sum fields replaced by that of another > > package). > > A quick check of the file doesn't show anything as obvious as that. > > > We cannot reproduce that one yet, but I'm working on it (running apt > > update manually now, and backing up lists before update).
Bisecting gives me: b0f4b486e6850c5f98520ccf19da71d0ed748ae4 is the first bad commit commit b0f4b486e6850c5f98520ccf19da71d0ed748ae4 Author: Michael Vogt <m...@debian.org> Date: Sun Sep 21 10:18:03 2014 +0200 generalize Acquire::GzipIndex -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. When replying, only quote what is necessary, and write each reply directly below the part(s) it pertains to (`inline'). Thank you.