Hi, David Kalnischkies <da...@kalnischkies.de> (2014-10-15): > On Wed, Oct 15, 2014 at 11:47:44AM +0200, Cyril Brulebois wrote: > > [ X-D-Cc: debian-boot@, please keep it in the loop when replying. ] > > [Done, although I don't see the header… (bad mutt, bad).]
IIRC it's munged when the submitted report is processed, that's why I'm mentioning this every time I use this header. > > we received several bug reports about weekly installation images being > > unable to find a kernel package to install on the freshly debootstrapped > > system. I've been able to replicate this issue with apt 1.9.0.2. Various > > Is the "apt-get update" call from which you have included the output > a recent addition or was it 'always' there? > > I am asking as 'apt-cdrom add' actually does the work of copying the > indexes to disk, which (should) mean that 'apt-get update' is a no-op, > making the call useless if cdroms are really the only possible source in > that stage. > > That 'update' isn't really supposed to be called here is reinforced by > the ugly warnings/errors you showcase and which existed since ever. Our > only testcase covering apt-cdrom also doesn't include such a call… > > Why that is the case, I have no idea, as I would expect at least some > people to have multiple sources, including cdrom, which would call for > an update, so that should really work without being scary (= assuming > warnings from apt are regarded as scary…). > > The irony is that the suspected bad-boy 80174528 actually fixes this > longstanding problem as the regression was that apt exited nonzero, not > that it printed warnings (so much for scary). > > The problematic commit is b0f4b486 (and therefore not a regression in > a security fix – everyone rejoice): While fine by itself, merged with > the suspected bad-boy we still have no warnings and a successful exit, > but our helpful list-cleanup kicks in removing files from the lists/ > directory which seem to be orphaned given that it is looking e.g. for > a Packages.gz file and not for Packages as the part fixing up the > filename is skipped if a cdrom source is encountered. You can pretend I don't know anything about d-i vs. apt, except for running git log in apt.git and looking for cdrom-related changes; you won't be far from reality. > The attached patch should merge both in a better working way, at least > that is what the testcase is promising me – which I have extended a bit > to cover a bit more ground, too. Nothing near proper testing though, so > someone giving it a proper testspin would be nice, but if that is too > hard I guess Michael could just upload it and let the world test it for > us (now that he doesn't have to fear another security upload). ;) I've tweaked bits and pieces locally to use apt 1.0.9.3 at the appropriate time and I can confirm that the easy/usual one-CD case is fixed, thanks! It'd be nice to see what happens with several CDs but that's not going to be me today. Some notes: - apt.git is missing at least one commit and the tag. - I think you wanted to close #764442, rather than #76442. I'm tempted to make apt migrate to testing soon, possibly today, because bug reports are piling up. From your maintainer point of view, is there anything speaking against such a move? Thanks again for the swift fix. Mraw, KiBi.
signature.asc
Description: Digital signature
