Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Daniel Baumann daniel.baum...@progress-technologies.net (07/02/2013): On 02/07/2013 08:12 AM, Michael Biebl wrote: This list is getting longer with each email. Seeing that syslinux 5 has been in sid for less then 10 days, I'm worried what other issues might show up. apart from the two obvious things (debian-installer and debian-cd) that do need to be updated to copy in the additionally required c32 modules when using vesamenu.c32, there's only vbox broken. So obvious that you didn't submit any patches against the reverse build-dependencies you broke unilaterally, without any prior notice? I always thought of Debian as something which included “team work” and people interacting with each others to build a nice operating system. Apparently I was wrong all along. while i can see that one is inclined to jump to the conclusion that now each and every package in debian needs an update, it really isn't so. no package is directly interacting with a bootloader, except those that create images (debian-installer, debian-cd), or boot images *and* have bugs fixed-upstream-long-time-ago-but-not-in-debian (vbox). That's nowhere like anything which could qualify with something starting with “no package except […]”. again, note that any other virtualization software, be it in wheezy directly (qemu, kvm) or otherwise (parallels, vmware) which i've tested with, has no bugs with syslinux 5. it's an isolated thing that vbox still has that bug in debian. That's called a showstopper. Last I checked, we have nothing to gain with syslinux 5 apart losing accumulated testing, having to include patches you can't even come up with a full list of, hitting known-and-unfixed regressions, and having to bother tech-ctte instead of just releasing a new d-i. Thank you so much. Not. KiBi. signature.asc Description: Digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Hi, On Wed, 06 Feb 2013, Bdale Garbee wrote: two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! Sure seems like d-i is something we should build using the components of the release it will be contained in and not unstable... but I haven't tried to think hard about what that might imply that's problematic. And I certainly don't think this is something we should even consider changing at this late date in for wheezy release cycle! Technically d-i point release updates are built in stable-proposed-updates and build dependencies are satisfied in stable (+ s-p-u maybe). Similarly it should be possible to build d-i for wheezy in testing-proposed-updates right now (and have build-deps satisfied in wheezy). t-p-u is frowned upon for normal packages because the release team like the testing packages get in unstable, but in the case of d-i the only thing that needs to be tested are the installer images which end up on the mirror and not in the package repository (the installer directories are shared between wheezy and sid). That said this was never done yet and we're not sure what dak would do with the by-hand archive containing the installer images. Maybe some ftpmasters could answer on this point? I discussed this with Cyril and Julien and they were (rightfully IMO) not keen on trying this at this point of the release. That said this whole discussion is interesting and might even help up in the long term but the real problem is that Daniel is just actively working against the release team wishes and this is unacceptable to me. We all know the limitations of our processes, any help to improve them is welcome, but working against them is not acceptable. But judging the social behaviour of a developer is not really in the realm of the tech-ctte and the best technical outcome might not be in line with the release team's plans. Thus I would subject to word a resolution along the line of The tech-ctte suggests the release team to try out this because bar, but if the release team doesn't wish to try it out, then the release team has the right to upload an older version of syslinux to unstable (given that the maintainer deliberately ignored recommendations of the release team).. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
i'm not commenting on unfair accusations, so only to the relevant part: On 02/07/2013 09:00 AM, Cyril Brulebois wrote: again, note that any other virtualization software, be it in wheezy directly (qemu, kvm) or otherwise (parallels, vmware) which i've tested with, has no bugs with syslinux 5. it's an isolated thing that vbox still has that bug in debian. That's called a showstopper. you're aware that regardless of syslinux version in sid, the current vbox version in wheezy will not be able to boot any post-wheezy image at all? so, again, the vbox bug is entirely unrelated to what version of syslinux is in sid now and probably should be fixed anyway, even in wheezy. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Daniel Baumann daniel.baum...@progress-technologies.net (07/02/2013): i'm not commenting on unfair accusations, so only to the relevant part: On 02/07/2013 09:00 AM, Cyril Brulebois wrote: again, note that any other virtualization software, be it in wheezy directly (qemu, kvm) or otherwise (parallels, vmware) which i've tested with, has no bugs with syslinux 5. it's an isolated thing that vbox still has that bug in debian. That's called a showstopper. you're aware that regardless of syslinux version in sid, the current vbox version in wheezy will not be able to boot any post-wheezy image at all? so, again, the vbox bug is entirely unrelated to what version of syslinux is in sid now and probably should be fixed anyway, even in wheezy. I don't disagree. Having a fixed virtualbox would be nice. That doesn't mean we should be keeping syslinux 5 in sid in the meanwhile, especially since that's preventing us from releasing d-i wheezy rc1. KiBi. signature.asc Description: Digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 09:59 AM, Cyril Brulebois wrote: That doesn't mean we should be keeping syslinux 5 in sid in the meanwhile, especially since that's preventing us from releasing d-i wheezy rc1. (ftr) which is where i disagree, with the mentioned patch against d-i and debian-cd, you can release d-i wheezy rc1, even with syslinux 5.x in sid. even more so: since steve uses a local copy of syslinux anyway (judging from debian-cd sources as unfortunately the setup of debian-cd on the buildhost is not documented) when invoking debian-cd, it doesn't matter at all what version of syslinux is in sid. therefore, right now, even without any patches, the only actually affected things are the images within the debian-installer-images tarball built by src:debian-installer, which i believe should be possible to fix without too much of a hassle. let me know if you want me to come up with a patch for that too. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 07.02.2013 08:31, Raphael Hertzog wrote: Technically d-i point release updates are built in stable-proposed-updates and build dependencies are satisfied in stable (+ s-p-u maybe). Similarly it should be possible to build d-i for wheezy in testing-proposed-updates right now (and have build-deps satisfied in wheezy). For reference, it would also require an otherwise no-op upload of the debian-installer package to unstable, to ensure that testing = unstable. t-p-u is frowned upon for normal packages because the release team like the testing packages get in unstable, but in the case of d-i the only thing that needs to be tested are the installer images which end up on the mirror and not in the package repository (the installer directories are shared between wheezy and sid). I believe they once were shared; that's no longer the case - to the extent that there's a dak copy-installer command to migrate the non-package elements. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, 07 Feb 2013, Raphael Hertzog wrote: on the mirror and not in the package repository (the installer directories are shared between wheezy and sid). Cyril pointed out to me that this specific point is wrong, while wheezy/main/installer-* and unstable/main/installer-* have the same content right now, they are not the same (and thus not shared). There's a dak copy-installer involved to copy the installer from unstable to wheezy. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Daniel Baumann daniel.baum...@progress-technologies.net (07/02/2013): (ftr) which is where i disagree, with the mentioned patch against d-i and debian-cd, you can release d-i wheezy rc1, even with syslinux 5.x in sid. even more so: since steve uses a local copy of syslinux anyway (judging from debian-cd sources as unfortunately the setup of debian-cd on the buildhost is not documented) when invoking debian-cd, it doesn't matter at all what version of syslinux is in sid. That means at least broken mini.iso, which is totally unacceptable. therefore, right now, even without any patches, the only actually affected things are the images within the debian-installer-images (wrong) tarball built by src:debian-installer, which i believe should be possible to fix without too much of a hassle. let me know if you want me to come up with a patch for that too. We're not going to patch various things to cope with syslinux 5 “just because”. Especially when the list of said things is growing over time. It's time to realize that we had working things, and that you broke athem. Patching reverse dependencies isn't what is going to happen here. KiBi. signature.asc Description: Digital signature
Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 10:27 AM, Cyril Brulebois wrote: That means at least broken mini.iso, which is totally unacceptable. broken without the patch i send for debian-installer, yes. therefore, right now, even without any patches, the only actually affected things are the images within the debian-installer-images (wrong) hm? We're not going to patch various things to cope with syslinux 5 “just because”. Especially when the list of said things is growing over time. i already commented on 'growing' and why that's wrong. It's time to realize that we had working things, and that you broke athem. Patching reverse dependencies isn't what is going to happen here. as elaborated, i disagree. to repeat, again, at minimum, it needs one (confirming working[0]) patch (to d-i), and steve using the wheezy local-copy of syslinux on the cdbuilder for debian-cd. not more, not less. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 07:52:13AM +0100, Daniel Baumann wrote: consider such a misfeature to be in critical need of a fix (iirc steve puts a local copy of the 'to be used' syslinux version to be used by debian-cd for release images manually on the local fs; not sure about the same that ends up in the final release copy of debian-installer-images, will check later on)). Correcting - that used to be the case several years ago, but debian-cd now explicitly extracts files from the syslinux(-common) package in the main archive at CD build time, using the same suite as used in d-i for consistency. -- Steve McIntyre, Cambridge, UK.st...@einval.com Every time you use Tcl, God kills a kitten. -- Malcolm Ray -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Daniel Baumann daniel.baum...@progress-technologies.net (07/02/2013): On 02/07/2013 10:27 AM, Cyril Brulebois wrote: That means at least broken mini.iso, which is totally unacceptable. broken without the patch i send for debian-installer, yes. If that can't be used with virtualbox (and we already established that, thanks to Michael's testing), that means it's broken with your patch too. i already commented on 'growing' and why that's wrong. That… It's time to realize that we had working things, and that you broke athem. Patching reverse dependencies isn't what is going to happen here. as elaborated, i disagree. to repeat, again, at minimum, it needs and “at minimum” doesn't exactly play along very well. one (confirming working[0]) patch (to d-i), and steve using the wheezy local-copy of syslinux on the cdbuilder for debian-cd. not more, not less. I'm going to repeat it again for you: - that's already too much - that would still mean known regressions (which you'll try to blame on virtualbox, but not going to syslinux 5 means no problem, so just let's just not use that) - and above all: that wouldn't gain us anything at all. KiBi. signature.asc Description: Digital signature
Bug#699742: Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 10:15:42AM +0100, Daniel Baumann wrote: On 02/07/2013 09:59 AM, Cyril Brulebois wrote: That doesn't mean we should be keeping syslinux 5 in sid in the meanwhile, especially since that's preventing us from releasing d-i wheezy rc1. (ftr) which is where i disagree, with the mentioned patch against d-i and debian-cd, you can release d-i wheezy rc1, even with syslinux 5.x in sid. even more so: since steve uses a local copy of syslinux anyway (judging from debian-cd sources as unfortunately the setup of debian-cd on the buildhost is not documented) when invoking debian-cd, it doesn't matter at all what version of syslinux is in sid. Already corrected elsewhere (repeating for clarity for people who may not read all of the thread here) - debian-cd uses syslinux from the archive at build time. -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 10:53 AM, Cyril Brulebois wrote: If that can't be used with virtualbox (and we already established that, thanks to Michael's testing), that means it's broken with your patch too. as already elaborated, the bug in vbox needs to be fixed anyway, regardless what version of syslinux is in the archive.. and if you wait until the end of the day, that problem is gone anyway. - and above all: that wouldn't gain us anything at all. which is not an argument.. any package that i don't use/care about doesn't give any benefits to me when it get any upload. with that in mind, from my point of view, for any package that i don't use, they should be never ever touched at all to prevent bringing any (potential) bug that could affect me indirectly. i'm argueing for either an explicit unfrozen sid or an explicit frozen sid. since it's neither right now, and you intend to overwrite the maintainers decision via CTTE to upload newer syslinux to sid, you need to argue against it, not 'doesn't gain anything'. i've already made the case why i want newer syslinux in sid, and have provided patches for the two packages that needs an update for that (plus the third and only remaining one, vbox, is in the works). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Daniel Baumann, le Thu 07 Feb 2013 11:08:55 +0100, a écrit : i've already made the case why i want newer syslinux in sid, I must have missed that, and I can't find it on either bug #699382, 699742 or 699808. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 11:17 AM, Samuel Thibault wrote: I must have missed that, and I can't find it on either bug #699382, 699742 or 699808. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699808#10 -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 11:08:55AM +0100, Daniel Baumann wrote: i'm argueing for either an explicit unfrozen sid or an explicit frozen sid. since it's neither right now, and you intend to overwrite the maintainers decision via CTTE to upload newer syslinux to sid, you need to argue against it, not 'doesn't gain anything'. Daniel, I don't think this is the place for such a broad discussion. I believe we would all agree that a frozen distro development (no matter the suite where it happens) is a PITA that we could all live without. But at present, this is what our release processes and technologies offer. Like it or not. It would be very nice to improve them, and I've high hopes that dak based personal package archives would help a lot with that, but this is not the time for this kind of changes. More importantly, it is arguably false that sid is not explicitly frozen. The freeze policy [1], which has been repeatedly announced on d-d-a, reads: Please also note that since many updates (hopefully, the vast majority) will still be going in through unstable, major changes in unstable right now can disrupt efforts to get RC bugs fixed. We don't ask you not to make changes in unstable, but we do ask that you be aware of the effects your changes can have -- especially if you maintain a library. Please continue to keep disruptive changes out of unstable and continue making use of experimental where appropriate. Note that you can stage NEW uploads in experimental to avoid disruption in unstable. [1]: http://release.debian.org/wheezy/freeze_policy.html by evidence, your change to unstable has been disruptive. I understand (better, I trust your claim on that, but I haven't checked) that experimental is not a viable path for syslinux development. But that is no justification for getting in the way of a release, going explicitly against the freeze policy. Please put back in sid the syslinux version that the release team wants to see in there. Ideally, it wouldn't be for long, and an action of that kind will avoid burning cycles of all the people participating in this thread. I'm pretty sure we can all use those cycles to the betterment of Wheezy instead. As soon as Wheezy is out of the door, please re-raise this topic in a project-wide place, where we can work on solutions to avoid this kind of frustrating long freezes. That would be the appropriate time and place for this kind of discussions. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#699742: Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Steve McIntyre wrote: On Thu, Feb 07, 2013 at 07:52:13AM +0100, Daniel Baumann wrote: consider such a misfeature to be in critical need of a fix (iirc steve puts a local copy of the 'to be used' syslinux version to be used by debian-cd for release images manually on the local fs; not sure about the same that ends up in the final release copy of debian-installer-images, will check later on)). Correcting - that used to be the case several years ago, but debian-cd now explicitly extracts files from the syslinux(-common) package in the main archive at CD build time, using the same suite as used in d-i for consistency. Howver, that is not the only image provided by Debian that uses syslinux. The d-i mini.iso is another one, which uses the syslinux provided by d-i's Build-Depedency, ie the one from unstable. -- see shy jo signature.asc Description: Digital signature
Bug#699742: Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 02:14 PM, Joey Hess wrote: Howver, that is not the only image provided by Debian that uses syslinux. The d-i mini.iso is another one, which uses the syslinux provided by d-i's Build-Depedency, ie the one from unstable. that has already been discussed in earlier messages. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 01:55:11AM +0100, Cyril Brulebois wrote: On a personal note, I'm unsure how we came up with a situation where a single maintainer can *actively* stall a release… Not caring about the release process put into place years ago is a thing. Stopping people from fixing problems created by such carelessness is another one… Speaking as an ex-RM, I think the answer here is that it used to be that when a maintainer made such an upload (and it did happen), we would revert it without hesitation and without apology. I'm having a hard time deciding, with my TC member hat on, if I think this is actually an ok thing to do. But whether or not it's ok, I do think I would still do it today if I were in your position on the grounds that it's easier to ask forgiveness than to ask permission, and asking explicit permission from every maintainer who is in a position to become a critical blocker for the release is a good way to make sure releases don't happen. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 05.02.2013 23:55, Don Armstrong wrote: On Wed, 06 Feb 2013, Cyril Brulebois wrote: Daniel Baumann daniel.baum...@progress-technologies.net (05/02/2013): or: * apply the following tested and working patch from #699742 in debian-installer, […] Except that this “tested and working patch” doesn't fix anything. Same issue, as seen by Michael and myself. Is it the intention of the Release Managers not to accept a newer version of syslinux into wheezy? [That is, if the CTTE were to decide to require some fix to d-i, we'd also have to override the RMs?] Given that the syslinux packages in sid are a different major upstream version from those in wheezy, with a raw diffstat of 621 files changed, 36622 insertions(+), 15023 deletions(-) and that upstream version has been in unstable for a little over a week in total, I'm certainly uncomfortable that accepting the new version at this point would be in the best interest of the release. We've already said no to changes in other packages which were significantly smaller and didn't carry the possibility of affecting something as key as the installer. Shipping an installer that was built with a differing version of syslinux than we eventually ship also causes me concern, since the first update to d-i in a point release will obviously be rebuilt against wheezy's syslinux. This introduces a situation that we can't reasonably test beforehand, as we could no longer be confident that the released version of the wheezy installer could be correctly booted on all of our architectures. (tl,dr; right now, yes, we believe the changes are too potentially disruptive.) Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/06/2013 12:55 AM, Don Armstrong wrote: Is it the intention of the Release Managers not to accept a newer version of syslinux into wheezy? [That is, if the CTTE were to decide to require some fix to d-i, we'd also have to override the RMs?] jftr, i never did nor intended to ask for having syslinux 5 in wheezy. what i care about is having it in unstable (for reasons said earlier). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/06/2013 10:38 AM, Daniel Baumann wrote: On 02/06/2013 12:55 AM, Don Armstrong wrote: Is it the intention of the Release Managers not to accept a newer version of syslinux into wheezy? [That is, if the CTTE were to decide to require some fix to d-i, we'd also have to override the RMs?] jftr, i never did nor intended to ask for having syslinux 5 in wheezy. what i care about is having it in unstable (for reasons said earlier). Well, the d-i development is happening in sid. Therefore, this upload disrupted the development process of syslinux dependent d-i components that have to end up, but are not yet in wheezy. Milan signature.asc Description: OpenPGP digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Tue, 05 Feb 2013, Julien Cristau wrote: - the latest of these uploads breaks the installer, making it impossible to build and upload the planned wheezy release candidate, since build-dependencies are fetched from unstable - when asked to revert this change, the syslinux maintainer refused, and said disagreements should be referred to the technical committee Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? [I can understand a bit of wariness of having d-i built with a version of syslinux that isn't being distributed in wheezy, but I think that might need to be discussed and a technical solution fleshed out elsewhere, and probably isn't ripe for a CTTE decision.] Don Armstrong 0: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#30 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#40 -- [Panama, 1989. The U.S. government called it Operation Just Cause.] I think they misspelled this. Shouldn't it be Operation Just 'Cause? -- TekPolitik http://slashdot.org/comments.pl?sid=59669cid=5664907 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Don Armstrong d...@debian.org writes: Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? Earlier in this thread, there had been a couple of reports that fix didn't work. I haven't looked further, though. [I can understand a bit of wariness of having d-i built with a version of syslinux that isn't being distributed in wheezy, but I think that might need to be discussed and a technical solution fleshed out elsewhere, and probably isn't ripe for a CTTE decision.] In practice, at least for the last couple of release cycles, we freeze unstable for non-leaf packages during the release freeze because otherwise it's too difficult with our current infrastructure to finish the release. I believe this has even been made explicit in release-team updates, although I haven't gone back and checked the exact wording. I concur with Daniel and with Anthony that it does feel like a deficiency in our tools that we don't have a way to distinguish wheezy-targeted packages from post-wheezy development and build wheezy-targeted packages with the build dependencies that will be released with wheezy. If we had such a thing, I think it would save the release team some time, since it would limit the problems caused by uncoordinated library transitions during the release freeze. I also concur with Daniel that it can make development during the release freeze rather annoying when there are multiple branches of upstream that one wants to follow, since we only have one other archive available for packages that aren't eligible for release. But, well, that's the architecture we have right now and we're clearly not going to fix it immediately. Given that, I think it makes sense to, as Daniel mentioned, make it rather explicit that, yes, unstable is frozen for non-leaf packages until we complete the release. And, in this specific case, to revert the syslinux update in unstable (and hopefully upload to experimental) so that we're not building d-i against a package that isn't part of the release. That does take over experimental for that purpose, but, well, there's always personal repositories; that's what I sometimes do when there are more branches of development to juggle than there is space in Debian. It's annoying, and we need better tools, but it's possible. In the longer term, I think it would be interesting to provide some more metadata and automation around the whole release request/unblock/build process than we have right now. For example, I could see some use in a system where one has to explicitly tag a package as being targeted for the next release or not targeted for the next release, which could be communicated to the buildds in some fashion so that they would build release-targeted packages against only the release-targeted packages, and new uploads of release-targeted packages would be automatically diffed and brought to the release team's attention. There could even be a convention for including the justification for the change. (I can see a lot of complexity here in how one would have to set up the archive suites, since you can't just point the buildds at testing since there would be no way to stage library transitions that *are* going into the release, so let me note that this is not a well-thought-out proposal, just the sketch of an idea.) But that's all outside the scope of tech-ctte deliberation, since that's technical design, and regardless isn't something that we would do right now. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Wed, 06 Feb 2013, Russ Allbery wrote: Don Armstrong d...@debian.org writes: Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? Earlier in this thread, there had been a couple of reports that fix didn't work. I haven't looked further, though. Yeah, that was for the first incomplete patch. I was referring to the second one. Don Armstrong -- Let us chat together a moment, my friend. There are still several hours until dawn, and I have the whole day to sleep. -- Count Orlock in _Nosferatu (1922)_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Russ Allbery r...@debian.org writes: In practice, at least for the last couple of release cycles, we freeze unstable for non-leaf packages during the release freeze because otherwise it's too difficult with our current infrastructure to finish the release. I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! Sure seems like d-i is something we should build using the components of the release it will be contained in and not unstable... but I haven't tried to think hard about what that might imply that's problematic. And I certainly don't think this is something we should even consider changing at this late date in for wheezy release cycle! Given that, I think it makes sense to, as Daniel mentioned, make it rather explicit that, yes, unstable is frozen for non-leaf packages until we complete the release. And, in this specific case, to revert the syslinux update in unstable (and hopefully upload to experimental) so that we're not building d-i against a package that isn't part of the release. I agree that we need to bring this current situation to closure quickly so that the RC1 build of d-i for wheezy can proceed. We seem to have three options: patch d-i to build successfully against the syslinux in sid wiggle the d-i build processing to fetch syslinux from testing (re-)upload the previous syslinux version with a new epoch The first requires a patch that actually works, and there is at least one assertion that the patch Daniel pointed to does not. The second I can't speak to the complexity of since the last time I looked at d-i was just before the last stable release. The third is easy to accomplish but requires agreement from the maintainer or a TC vote to overrule him. I'm relatively unavailable for the next 24 hours. Hopefully by then further investigation and/or discussion will help make it clear which of the above options we should pursue. Bdale pgpzDhVGTtsEk.pgp Description: PGP signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Bdale Garbee bd...@gag.com writes: I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! Sure seems like d-i is something we should build using the components of the release it will be contained in and not unstable... but I haven't tried to think hard about what that might imply that's problematic. And I certainly don't think this is something we should even consider changing at this late date in for wheezy release cycle! Yes. This is pretty much exactly how I feel. And I suspect it's a general feeling by a lot of people: we freeze for too long, and we don't like a lot of the implications of that, but we don't know how to do better and get releases out faster because there's a truly intimidating amount of work that has to get done to do the release and all the alternatives seem to make the work even worse. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 06.02.2013 23:22, Don Armstrong wrote: On Wed, 06 Feb 2013, Russ Allbery wrote: Don Armstrong d...@debian.org writes: Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? Earlier in this thread, there had been a couple of reports that fix didn't work. I haven't looked further, though. Yeah, that was for the first incomplete patch. I was referring to the second one. Unfortunately the second patch doesn't work either. See [1]. Cheers, Michael [1] https://lists.debian.org/debian-boot/2013/02/msg00115.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Bdale Garbee bd...@gag.com (06/02/2013): I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! How is that different from e.g. refraining to upload new libraries to unstable, so that a package needing an upload (say, we need RC bugfixes) doesn't pick new dependencies (on libraries not in testing)? That's how testing works; and it's been this way for years/releases now (since testing replaced frozen, I think). Sure seems like d-i is something we should build using the components of the release it will be contained in and not unstable... Why should that source package be special? Yes, it's cumbersome, it needs many uploads, if only because we need kernel fixes and improvements, along with fixes for its 100+ components. I'm happy to consider improvements to the process when we have time for that, meaning not 8 months into the freeze, but I'd be happy to receive an answer to the above question. And I certainly don't think this is something we should even consider changing at this late date in for wheezy release cycle! I concur. I agree that we need to bring this current situation to closure quickly so that the RC1 build of d-i for wheezy can proceed. We seem to have three options: patch d-i to build successfully against the syslinux in sid And chase all regressions between syslinux 4 and 5? I'd rather not do that, especially given how tested and working patches are failing to deliver. Over the last few months on the d-i front, we've had 1 alpha, 4 betas; we would be throwing away the testing efforts of those 5 releases! wiggle the d-i build processing to fetch syslinux from testing See above question, why should we special-case this build-dependency? (re-)upload the previous syslinux version with a new epoch I don't see a better solution than this one. On a personal note, I'm unsure how we came up with a situation where a single maintainer can *actively* stall a release… Not caring about the release process put into place years ago is a thing. Stopping people from fixing problems created by such carelessness is another one… Mraw, KiBi. signature.asc Description: Digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Cyril Brulebois k...@debian.org writes: Bdale Garbee bd...@gag.com (06/02/2013): I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! How is that different from e.g. refraining to upload new libraries to unstable, so that a package needing an upload (say, we need RC bugfixes) doesn't pick new dependencies (on libraries not in testing)? I personally think it's exactly the same problem. I think the situation with libraries is regrettable as well. (Note that, and I'm guessing I speak for Bdale here too, regrettable is not intended to assign any sort of blame! This is the best solution that we've been able to come up with to date as a project. It's just still has some problems.) That's how testing works; and it's been this way for years/releases now (since testing replaced frozen, I think). Yes. It's always a source of some tension, since there are always people who would prefer to have a place to continue to do development in an unstable context even during the release process. (Cue the standard debate over the usability of experimental for this purpose -- I'm sure nearly everyone reading this can fill it in from memory. *grin*) If we could find a way to release some of that tension, that would be great, but it's a hard problem, and there's no way that we're going to come up with a solution to it right now in the middle of the wheezy freeze. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/06/2013 11:48 PM, Michael Biebl wrote: Unfortunately the second patch doesn't work either. See [1]. that is incorrect; the patch works, it's just the old vbox version in current debian testing/sid which has a bug (try the image on real hardware or any other virtualization and it works). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
07.02.2013 10:30, Daniel Baumann wrote: On 02/06/2013 11:48 PM, Michael Biebl wrote: Unfortunately the second patch doesn't work either. See [1]. that is incorrect; the patch works, it's just the old vbox version in current debian testing/sid which has a bug (try the image on real hardware or any other virtualization and it works). This makes me wonder what other components are also buggy somehow and needs to be updated? How many (old) hardware machines has something similar too? And how much more testing we need to declare that everything we use is compatible? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 07.02.2013 07:30, Daniel Baumann wrote: On 02/06/2013 11:48 PM, Michael Biebl wrote: Unfortunately the second patch doesn't work either. See [1]. that is incorrect; the patch works, it's just the old vbox version in current debian testing/sid which has a bug (try the image on real hardware or any other virtualization and it works). Well, VBOX is pretty popular, so shipping an installer which doesn't work for such an environment is certainly a no-go. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 07:35 AM, Michael Tokarev wrote: This makes me wonder what other components are also buggy somehow and needs to be updated? first, this is a specific bug in vbox that was fixed some time ago but didn't make it into debian yet (because it lags a significant amount of upstream releases behind; and yes, i should and will fill a bug about it at some later point). How many (old) hardware machines has something similar too? And how much more testing we need to declare that everything we use is compatible? second, if you follow the bug, it's affecting sid and doesn't affect wheezy release images - they will have the same tested and working syslinux version that has proven to be stable during d-i alpha/beta images (unless i'm missing something and d-i *release* images are built with sid packages as well, in which case i personally would consider such a misfeature to be in critical need of a fix (iirc steve puts a local copy of the 'to be used' syslinux version to be used by debian-cd for release images manually on the local fs; not sure about the same that ends up in the final release copy of debian-installer-images, will check later on)). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 07:45 AM, Michael Biebl wrote: Well, VBOX is pretty popular, so shipping an installer which doesn't work for such an environment is certainly a no-go. again, the syslinux in sid would not be in wheezy. making it a *temporary* problem until vbox has been fixed in debian (which i'm happy to NMU again, will look to cherry-pick the required patch later today). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 07.02.2013 07:58, Daniel Baumann wrote: On 02/07/2013 07:45 AM, Michael Biebl wrote: Well, VBOX is pretty popular, so shipping an installer which doesn't work for such an environment is certainly a no-go. again, the syslinux in sid would not be in wheezy. making it a *temporary* problem until vbox has been fixed in debian (which i'm happy to NMU again, will look to cherry-pick the required patch later today). I think it is obvious by now that reverting to syslinux 4 from wheezy is the only sensible way forward at this point in the release. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 07:55 AM, Michael Biebl wrote: I think it is obvious by now that reverting to syslinux 4 from wheezy is the only sensible way forward at this point in the release. 'obvious'? it requires two straight forward things, that, again, as said, are required to be applied for jessie anyway, and are wherey much desired to be applied on the wheezy source (to build images with syslinux backports): * patch applied against debian-installer to include the additionally required .c32 modules when using vesamenu.c32 * patch applied against debian-cd to include the additionally required .c32 modules when using vesamenu.c32 and fixing one temporary breakage in vbox for convenience: * cherry-pick upstream commit to fix a bug in vbox not more, not less. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
sorry, forgot to put in the links to the patches.. On 02/07/2013 08:06 AM, Daniel Baumann wrote: * patch applied against debian-installer to include the additionally required .c32 modules when using vesamenu.c32 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#30 * patch applied against debian-cd to include the additionally required .c32 modules when using vesamenu.c32 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699884#20 -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 07.02.2013 08:06, Daniel Baumann wrote: On 02/07/2013 07:55 AM, Michael Biebl wrote: I think it is obvious by now that reverting to syslinux 4 from wheezy is the only sensible way forward at this point in the release. 'obvious'? Imho, yes. But then, it's not up to me to decide. * patch applied against debian-installer to include the additionally required .c32 modules when using vesamenu.c32 * patch applied against debian-cd to include the additionally required .c32 modules when using vesamenu.c32 * cherry-pick upstream commit to fix a bug in vbox This list is getting longer with each email. Seeing that syslinux 5 has been in sid for less then 10 days, I'm worried what other issues might show up. While I can understand (from personal experience) that freeze-time is sometimes frustrating, delaying the release even further doesn't help anyone. If we want to improve our procedures, how we handle d-i, freeze etc, now is not the time to discuss/work on this. Just my 2¢ Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 08:12 AM, Michael Biebl wrote: This list is getting longer with each email. Seeing that syslinux 5 has been in sid for less then 10 days, I'm worried what other issues might show up. apart from the two obvious things (debian-installer and debian-cd) that do need to be updated to copy in the additionally required c32 modules when using vesamenu.c32, there's only vbox broken. while i can see that one is inclined to jump to the conclusion that now each and every package in debian needs an update, it really isn't so. no package is directly interacting with a bootloader, except those that create images (debian-installer, debian-cd), or boot images *and* have bugs fixed-upstream-long-time-ago-but-not-in-debian (vbox). again, note that any other virtualization software, be it in wheezy directly (qemu, kvm) or otherwise (parallels, vmware) which i've tested with, has no bugs with syslinux 5. it's an isolated thing that vbox still has that bug in debian. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Daniel Baumann daniel.baum...@progress-technologies.net (05/02/2013): or: * apply the following tested and working patch from #699742 in debian-installer, […] Except that this “tested and working patch” doesn't fix anything. Same issue, as seen by Michael and myself. KiBi. signature.asc Description: Digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Wed, 06 Feb 2013, Cyril Brulebois wrote: Daniel Baumann daniel.baum...@progress-technologies.net (05/02/2013): or: * apply the following tested and working patch from #699742 in debian-installer, […] Except that this “tested and working patch” doesn't fix anything. Same issue, as seen by Michael and myself. Is it the intention of the Release Managers not to accept a newer version of syslinux into wheezy? [That is, if the CTTE were to decide to require some fix to d-i, we'd also have to override the RMs?] Don Armstrong -- I now know how retro SCOs OSes are. Riotous, riotous stuff. How they had the ya-yas to declare Linux an infant OS in need of their IP is beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over TCP. The 80's called, they want their features back. -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org