On Sat, Mar 08, 2014 at 01:37:22AM +0100, Cyril Brulebois wrote: > Gabriele Giacone <1o5g4r8o@gmail.com> (2014-03-04): > > On hurd, "apt-cdrom ident" started requesting to insert cdrom even if cdrom is > > already mounted. > > That breaks debian-installer given it's called by load-install-cd. > > Recent debian-installer builds get stuck at "Configuring apt - Scanning the > > CD-ROM". > > See https://bugs.debian.org/728153 > > Weekly installation image builds are indeed broken; this is slightly > annoying since I was aiming at releasing an alpha 1 image for jessie > soon, so that we can perform regression tests against it. Sorry about that. I am not really able to test cdrom stuff at the moment and had hoped that this was actually tested with d-i as the buglog indicated this to me (yes I know, silly me). John, as the author of the patch, can you shine some light on with what you have tested this (out of my interest). One of your mails suggested to me it was useful for d-i, but now that I read it again I seem to have overlooked a "possibly". (btw: I had shortly looked at the bug before, but couldn't find anything with a "non-udev codepath" POV, so that cluebat here really helped) > And more precisely: > | Author: John Ogness <john.ogness@linutronix.de> > | Date: Fri Dec 13 20:59:31 2013 +0100 > | > | apt-cdrom should succeed if any drive succeeds > | > | If there are multiple CD-ROM drives, `apt-cdrom add` will abort with an > | error if any of the drives do not contain a Debian CD which is against > | the documentation we have saying "a CD-ROM" and also scripts do not > | expect it this way. > | > | This patch modifies apt-cdrom to return success if any of the drives > | succeeded. If failures occur, apt-cdrom will still continue trying all > | the drives and report the last failure (if none of them succeeded). > | > | The 'ident' command was also changed to match the new 'add' behavior. > | > | Closes: 728153 > > I'm pretty sure making "apt-cdrom ident" hang wasn't part of the plan, > and that's what's happening nonetheless when called from apt-setup's > generators/40cdrom script. Mhh, I see. Me and my "lets reduce code duplication" stricking again. I guess you can give apt-cdrom ident /dev/null as stdin as you do for add to hotfix that for the moment (but not tested). Will have to do some code-staring to find out what is really messed up as I see this "Please insert a Disc in the drive and press enter" in the new output of the add command only, but the code for it is in the old one as well. And my impression is that it shouldn't be in any. Fishy. At least it reminds me that I have to find a way to make a testcase which doesn't use --no-mount as this is of course hiding the issue… Sidenote: Why are you allowing apt-cdrom to do the mounting by itself here if you have mounted it already and remount it after the run? > [ Also, if you're going to change semantics, it probably would be nice > to warn your users (e.g. -boot@ in that particular case); heads-up on > topics with possible big consequences are always appreciated. ] It wasn't supposed to change semantics - at least not in a negative way. If you have one drive nothing changes (at least that was the idea) and if you have two apt-cdrom will not fail if it looks at the empty drive first - which sounds like a good idea and should be fine for d-i (and even fix some issues as mentioned in the buglog with it) if it would work as intended. Beside: I have to admit that I don't know who is using apt and how. I get a remote idea of what is using apt and how each time we "break" something (like description fieldname in 'apt-cache show' for cdrom creation scripts), but as much as I would like to, I can't remember them all and especially can't test them all. And I am pretty sure you don't want to be cc'ed on all changes in apt just because I have no idea what could possibly break if I change anything (as the fieldname example shows, I can't assume anything in general). So sorry again for the trouble caused, but please don't assume bad faith here… Sidenote: The manpage says 'ident' is "a debugging tool". You will hopefully understand that even if I had anticipated that the commit would cause trouble I would have assumed nobody would use it. (I see now that apt-setup is using it and why, and while the information is in the add output as well it is probably a bit harder to get it from there, point taken, but that this is easy to say after the fact) Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature