Bug#746715: the foreseeable outcome of the TC vote on init systems
Ian Jackson writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): I do think there is still something for the TC to do here. As Andi writes, the TC failed to clarify that we expect people to continue to support multiple init systems. Evidently this was a mistake. It is not too late to rectify it. ... A maintainer recently peremptorily removed support for upstart from one of their packages. The Technical Committee thanks Steve Langasek for bringing this matter to our attention. We are pleased that the maintainer has agreed to revert the disputed change. For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. I deliberately don't name or criticise the maintainer. I'm open to suggestions for improvements to the wording, but I think what I have in the final paragraph should be uncontroversial within the TC. Apparently it is controversial within the TC to say even (some) uncontroversial things. Nevertheless, I intend to press for a resolution along these lines. Unless someone comes up with some wording which I consider an improvement I will formally propose the above, and eventually take it to a vote. I'll give a period of at least 72h for opponents to propose amendments. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21374.4406.635164.674...@chiark.greenend.org.uk
Bug#746715: the foreseeable outcome of the TC vote on init systems
Ian Jackson wrote: Ian Jackson writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): I do think there is still something for the TC to do here. As Andi writes, the TC failed to clarify that we expect people to continue to support multiple init systems. Evidently this was a mistake. It is not too late to rectify it. ... A maintainer recently peremptorily removed support for upstart from one of their packages. The Technical Committee thanks Steve Langasek for bringing this matter to our attention. We are pleased that the maintainer has agreed to revert the disputed change. For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. I deliberately don't name or criticise the maintainer. I'm open to suggestions for improvements to the wording, but I think what I have in the final paragraph should be uncontroversial within the TC. Apparently it is controversial within the TC to say even (some) uncontroversial things. From what I can see in the thread, it seems like folks viewed a statement as unnecessary given how rapidly the situation that prompted this got resolved without the need for TC action. It also seems completely understandable, in light of Ubuntu's in-progress migration from upstart to systemd, that a Debian maintainer could see upstart support as unlikely to remain useful. In that regard, I think it would help greatly if the upstart maintainers in Debian (rather than the TC) could post an announcement regarding the long-term plans for upstart in Debian in light of Ubuntu's stated long-term plans. Also, the last paragraph of the statement proposed above does in fact seem controversial; expects maintainers to continue to support is a much stronger statement than expecting maintainers to merge reasonable contributions and not drop such contributions without reason. The latter seems completely reasonable, albeit a somewhat redundant statement of how package maintenance normally works in Debian. The former, expects maintainers to continue to support, assumes such support already exists in all cases, and seems to inherently disregard and disparage packages that specifically make use of the features of one or more init systems and depend on those init systems. Nothing forces a maintainer to add support for any particular init system; it seems reasonable to expect a maintainer to incorporate reasonable changes for another init system, and not intentionally break or drop those changes if they have a reasonable maintenance burden (which holds especially true if those changes have an active maintainer), but the proposed statement as written could easily be used as a hammer against maintainers of packages that support one init system and have received no reasonable contributions to support others. Nevertheless, I intend to press for a resolution along these lines. Unless someone comes up with some wording which I consider an improvement I will formally propose the above, and eventually take it to a vote. I'll give a period of at least 72h for opponents to propose amendments. Not a member of the TC, but nonetheless suggesting the following, in the hopes that a TC member will second it: First, one change that I'd like to see accepted as an amendment to the above, since it doesn't change the stated intent of causing the TC to make a statement in support of multiple init systems: - Dropping the first two paragraphs that make this statement come across as reactionary to a non-specific incident, and instead tweak the third paragraph more along the lines of the statements Ian proposed as part of the previous TC decision on init systems. Posting a reactionary statement in response to an incident that got successfully resolved via normal processes seems like a poor way of encouraging those normal processes. Second, a change I don't expect to see accepted as an amendment, since it tones down the statement in support of multiple init systems to just a reminder about how our existing maintenance processes *already* work for any non-required feature people care about: - Adjusting the last paragraph to be more precise about expectations (and non-expectations) from package maintainers: The TC expects package maintainers to accept and maintain reasonable contributions adding support for multiple init systems, both default and non-default. Packages that already have functional support for multiple init systems should not drop that support without a compelling reason. Finally, in the interests of having an alternative to the current proposal other than FD, to distinguish between we should discuss this further and there's nothing that needs further discussion here, there should be an option on the resulting
Bug#746715: the foreseeable outcome of the TC vote on init systems
Cameron Norman camerontnor...@gmail.com writes: From your other message I was under the impression that you thought it was ok to remove Upstart support, but now you agree that if there was interest, then it should be kept (as long as it does not cause issues). Under the circumstances, I don't think we should be *surprised* that someone thought dropping upstart support was ok. That does not mean that *I* think it is ok, and I'm very happy that the support for upstart was restored. Would you mind clarifying a little? I think anyone interested in a new or alternative feature in Debian always has to be prepared to do work themselves to get what they want. Because we strive to be inclusive, the normal behavior in Debian has always been to accept patches that enable new features, new architectures, etc, as long as the patches make sense and don't break something else. Support for alternative init systems should be no different. Bdale pgpIVwQ0qQGCf.pgp Description: PGP signature
Bug#746715: the foreseeable outcome of the TC vote on init systems
On 05/06/2014 11:11 AM, Raphael Hertzog wrote: For instance, to date, we still don't have a newer syslinux in unstable while he was eager to push syslinux 5 in unstable during the former freeze 1. syslinux 6 prior 6.02 was not usable because the efi things caused regressions in the non-efi bootloaders (e.g. pxelinux was broken for a very long time; see #syslinux and syslinux@l.s.o). 2. due to required changes in the debian packaging, the package had to go through new (twice; the last time it rottet there for ~6 weeks, the previous one was iirc in NEW even longer). 3. you very well know that even if 1. and 2. wouldn't be a problem, i couldn't upload syslinux 6 directly to unstable without first getting the packages depending on syslinux 4 behaviour adjusted (syslinux upstream changed incompatible between version 4 and 5, see https://lists.debian.org/debian-release/2014/05/msg00016.html). so, while you where holding the 'speedy' upload of syslinux 5 to unstable against me, at the same time you're now holding the causious upload of syslinux 6 to unstable against me as well? i seem to never be able to do it right for you, no matter what. (and I still don't agree with his migration plan given in #742836 that he closed twice without trying to see whether I agreed and whether I would not have additional advice...) as usual, i'm open for anything constructive. you might want to read my second message to the bug carefully to understand the whole issue though. let me know if you have any questions left. The lxc package was severly out of date ever since the wheezy release up to a few weeks ago. Etc. lxc changed incompatible with almost any in-between release until they settled for their stable 1.x series (well, between 1.0.0 and 1.0.3 which are supposed to be stable releases, they changed significantly again, but that's another story). thus not having a sane upgrade path, and having to refactor the debian additions due to the request from Lucas, it was imho the better way to handle it that way and only provide a stable LXC to unstable when ready, rather than to break users machines with almost every update. ymmv. Regards, Daniel -- 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536a8b4c.1000...@progress-technologies.net
Bug#746715: the foreseeable outcome of the TC vote on init systems
Daniel Baumann writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): 1. syslinux [etc.] lxc [etc] Daniel, I appreciate that you feel the need to rebut the criticisms that have been made of you. I don't think that's unreasonable. But, I think we should draw a line under this now. So can everyone please let this be the last word on these questions in this TC bug ? (And if someone does respond further, please just let it stand, or reply by private email.) Thanks, Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21354.36470.577005.405...@chiark.greenend.org.uk
Bug#746715: the foreseeable outcome of the TC vote on init systems
Le 2014-05-06 13:06, Thomas Goirand a écrit : I believe he is unfriendly with unfriendly people, and I don't think you count as one of his friend, given the way you've interacted with him in the past. Well, Raphael is not Daniel's friend... fine. But, actually, who cares? The maintainer should go over those details and simply does his job. What raphael is trying to explain is that he failed in his mission as a maintainer. (Not taking any side, just re-explaining and putting things in the right context). Regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/b39d45d9dd00c63078dbefda3fce1...@dogguy.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
Mehdi Dogguy writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): Well, Raphael is not Daniel's friend... fine. But, actually, who cares? The maintainer should go over those details and simply does his job. What raphael is trying to explain is that he failed in his mission as a maintainer. Can we stop the general commentary on Daniel Baumann's performance as maintainer ? I don't think it's helpful or relevant to the discussion about tftp-hpa and upstart. If someone has more general concerns about the maintenance of some package, and after failing to resolve these concerns *they would like to take over the package*, that would best be dealt with separately. Probably emailing the TC private list, or a TC member privately, to seek advice, would be the right place to start. Likewise if there are general concerns about a DD or DM, the right team to contact would be new-maintainer. Persistently making negative comments about a fellow contributor, in inappropriate forums, does not help. It makes Debian less fun without addressing the underlying problems - indeed, often, it exacerbates the problems. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21352.63774.819977.93...@chiark.greenend.org.uk
Bug#746715: the foreseeable outcome of the TC vote on init systems
Thanks Ian, this is exactly what I think as well, and you expressed it a way better than I would have. Thomas -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53691267.5000...@debian.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
Hi, Ian Jackson ijack...@chiark.greenend.org.uk writes: Can we stop the general commentary on Daniel Baumann's performance as maintainer ? I don't think it's helpful or relevant to the discussion about tftp-hpa and upstart. Is there still anything left to discuss on tftp-hpa/upstart or could this issue be closed? The last upload restored support for upstart[1]. [1] http://packages.qa.debian.org/t/tftp-hpa/news/20140504T133456Z.html Ansgar -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvkmhe69@deep-thought.43-1.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
Ansgar Burchardt writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): Is there still anything left to discuss on tftp-hpa/upstart or could this issue be closed? The last upload restored support for upstart[1]. [1] http://packages.qa.debian.org/t/tftp-hpa/news/20140504T133456Z.html Excellent. I do think there is still something for the TC to do here. As Andi writes, the TC failed to clarify that we expect people to continue to support multiple init systems. Evidently this was a mistake. It is not too late to rectify it. This is why I informally suggested this wording for a TC resolution: A maintainer recently peremptorily removed support for upstart from one of their packages. The Technical Committee thanks Steve Langasek for bringing this matter to our attention. We are pleased that the maintainer has agreed to revert the disputed change. For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. I deliberately don't name or criticise the maintainer. I'm open to suggestions for improvements to the wording, but I think what I have in the final paragraph should be uncontroversial within the TC. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21353.17140.863810.280...@chiark.greenend.org.uk
Bug#746715: the foreseeable outcome of the TC vote on init systems
Ian Jackson ijack...@chiark.greenend.org.uk writes: I do think there is still something for the TC to do here. As Andi writes, the TC failed to clarify that we expect people to continue to support multiple init systems. Evidently this was a mistake. On what grounds do you think it was a mistake? As soon as someone talked to the maintainer in question and asked them to re-add support, support was almost immediately re-added. Sounds to me like our normal processes worked properly as soon as they were attempted, which is exactly the rationale that Keith presented originally for not over-dictating to the project how to go about its work. We have a long tradition of not making formal rulings on things that resolved themselves before we could get around to putting together a ballot, for much the same reasons that courts usually do the same. I think that tradition serves us well and that we should stick with it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87tx92wp40@windlord.stanford.edu
Bug#746715: the foreseeable outcome of the TC vote on init systems
On Tue, May 06, 2014 at 09:15:48PM +0100, Ian Jackson wrote: Ansgar Burchardt writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): Is there still anything left to discuss on tftp-hpa/upstart or could this issue be closed? The last upload restored support for upstart[1]. [1] http://packages.qa.debian.org/t/tftp-hpa/news/20140504T133456Z.html Excellent. I do think there is still something for the TC to do here. As Andi On the contrary - this has been resolved without needing any TC involvement. You risk being accused of being big brother with a heavy hand if you persist in insisting on micro-managing volunteers. Regards -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140506222657.gm1...@wacka.mjr.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
On 05/06/14 23:15, Ian Jackson wrote: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. Considering: - The technical committee has decided that Jessie is going to have a default init system and that would be systemd, - Testing a package's support for an alternative init systems is a complicated manual process that requires non-trivial modifications, such as switching init systems and rebooting or maintaining VMs, - Upstart has a popcon install count of 99, - Debian maintainers are not required to care about derivatives, - Even for those of us that do care about Ubuntu, upstart's future in Ubuntu (and in general) is unclear given Mark Shuttleworth's blog post[1] that was posted immediately after tech-ctte's systemd decision, - Unlike, say, openrc or sysvinit, there are no Debian release architectures that would specifically benefit from upstart in the jessie timeframe. - Upstart's failure mode for a package's lack of an upstart job is to execute the corresponding SysV init script and hence is not a regression, ...I'm having a hard time convincing myself to treat potential upstart bugs as anything but very low priority wishlist bugs. I haven't gotten any such bug reports, so this is still theoretical, but I think I'd simply reject anything more complicated than simply adding a debian/foo.upstart file to the tree, including adding (and maintaining) hacks or modifying existing SysV init scripts. I certainly won't work on adding an upstart job to my packages myself. If the committee feels differently about this, I think it'd be useful to express this in a more clarified manner and possibly incorporate this into policy. For what it's worth, the current wording of contin[uing] to support, merging reasonable contributions and without a compelling reason leaves a lot of room for interpretation and changes nothing for me compared to the previous resolution or the status quo before it. Regards, Faidon 1: http://www.markshuttleworth.com/archives/1316 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507020042.ga14...@tty.gr
Bug#746715: the foreseeable outcome of the TC vote on init systems
Faidon Liambotis parav...@debian.org writes: I haven't gotten any such bug reports, so this is still theoretical, but I think I'd simply reject anything more complicated than simply adding a debian/foo.upstart file to the tree, including adding (and maintaining) hacks or modifying existing SysV init scripts. I certainly won't work on adding an upstart job to my packages myself. The hacks we're talking about here are pretty minimal: just three lines in the init script that we're mentioning. I think it's pretty straightforward and think that maintainers should just add that support. I can see your point that the future of upstart is possibly unclear, but my feeling is that if anyone filed a bug against a package requesting upstart support, that's sufficient indication of interest to merge upstart support patches, including this sort of minor modification of the init script. If the committee feels differently about this, I think it'd be useful to express this in a more clarified manner and possibly incorporate this into policy. Wouldn't it be better to just do this directly via Policy? I don't think that the TC is needed or adds value right now. Doing this via Policy had been my intention, which has been interrupted by my day job becoming absolutely awful over the past nine months or so (four reorgs in eight months, most of them entirely unjustified). I still think that's the best route forward, and am sorry that I've not been able to drive that work. I had intended to be well into it by now. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uqes3hx@windlord.stanford.edu
Bug#746715: the foreseeable outcome of the TC vote on init systems
El Tue, 6 de May 2014 a las 7:54 PM, Russ Allbery r...@debian.org escribió: Faidon Liambotis parav...@debian.org writes: I haven't gotten any such bug reports, so this is still theoretical, but I think I'd simply reject anything more complicated than simply adding a debian/foo.upstart file to the tree, including adding (and maintaining) hacks or modifying existing SysV init scripts. I certainly won't work on adding an upstart job to my packages myself. The hacks we're talking about here are pretty minimal: just three lines in the init script that we're mentioning. I think it's pretty straightforward and think that maintainers should just add that support. In addition, as has been mentioned, they will soon be unnecessary, as Dimitri Ledkov is working to put the functionality into a init-functions.d hook. [snippity snip] 3 Hope that stuff clears up! Stress is very stressful, and that is never good. I do not know your taste in music, but maybe you will like this: https://www.youtube.com/watch?v=tNygDLi9gb4. Top of the day, -- Cameron Norman
Bug#746715: the foreseeable outcome of the TC vote on init systems
Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): On what grounds do you think it was a mistake? As soon as someone talked to the maintainer in question and asked them to re-add support, support was almost immediately re-added. If the TC had said something earlier, to set the right expectations, the problem would probably have never been introduced in the first place. That's not clear to me at all. Given the broad perception based on http://www.markshuttleworth.com/archives/1316 that upstart's future prospects are now quite limited, I would have been surprised if someone didn't eventually drop upstart-specific support in a package. To assume this portends broad abandonment of alternative init systems seems like a *huge* stretch... Bdale pgpd24cyF6NkM.pgp Description: PGP signature
Bug#746715: the foreseeable outcome of the TC vote on init systems
Russ Allbery r...@debian.org writes: I can see your point that the future of upstart is possibly unclear, but my feeling is that if anyone filed a bug against a package requesting upstart support, that's sufficient indication of interest to merge upstart support patches, including this sort of minor modification of the init script. I agree. Bdale pgpxGmcaz1UoI.pgp Description: PGP signature
Bug#746715: the foreseeable outcome of the TC vote on init systems
El Tue, 6 de May 2014 a las 8:41 PM, Bdale Garbee bd...@gag.com escribió: Russ Allbery r...@debian.org writes: I can see your point that the future of upstart is possibly unclear, but my feeling is that if anyone filed a bug against a package requesting upstart support, that's sufficient indication of interest to merge upstart support patches, including this sort of minor modification of the init script. I agree. From your other message I was under the impression that you thought it was ok to remove Upstart support, but now you agree that if there was interest, then it should be kept (as long as it does not cause issues). Is the maintainer supposed to accept the support then remove it a few months later :) ? Are those interested in Upstart support supposed to hawk over packages and never get a wink of sleep? I do not think that is what you want, but the wording of your other message (that you would not be surprised if upstart support was removed) seems like it is. Would you mind clarifying a little? Thanks y buenos noches, -- Cameron Norman
Bug#746715: the foreseeable outcome of the TC vote on init systems
Steve, first of all: why haven't you just talked to me? you know more then well that i've kindly and quickly responded to all your bug reports, on and offline. #746715 sounds like shooting with a nuclear weapon on little glitch. seccond, if you feel that deeply about that particular patch[1] and want to still add see upstart support in tftpd-hpa for jessie, i'm happy to re-include it. to the allegations made in this bug report: upstart support has been only *temporarily* be present in experimental. it has never been in unstable, technically there was never any upstart support. Regards, Daniel [1] http://daniel-baumann.ch/gitweb/?p=debian/packages/tftp-hpa.git;a=commitdiff;h=0ec85b4d4fcd3d4bbd7fa97e81c35fd301ac7060 -- 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5364a96a.5040...@progress-technologies.net
Bug#746715: the foreseeable outcome of the TC vote on init systems
* Bdale Garbee (bd...@gag.com) [140503 01:54]: Steve Langasek vor...@debian.org writes: Package: tech-ctte An Ubuntu developer just brought the following Debian changelog entry to my attention: tftp-hpa (5.2-17) experimental; urgency=low * Removing upstart hacks, they are ugly and upstart is dead now. Since various members of the Technical Committee argued that choosing a default would not prevent Debian from supporting other init systems, I would like to hear from those members how they think this should be addressed. In general, pulling upstart support while upstart still exists in Debian feels wrong. However, since this is in experimental, and not in a released tree or release candidate, this particular case is hard for me to get worked up about. There are two different thoughts in my mind: 1. This shows in a very wrong direction. Upstart support might not be useful for long, but it is now, and dropping a useful feature should only happen if there is a cause for. 2. There are things I worry more about with this particular maintainer than that. So if we think about overruling him, there might be better uses for. Andi -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140503080546.gz20...@mails.so.argh.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
Bdale Garbee bd...@gag.com (2014-05-02): However, since this is in experimental, and not in a released tree or release candidate, this particular case is hard for me to get worked up about. http://packages.qa.debian.org/t/tftp-hpa.html has the timeline for the last few dozens uploads. Last items are: [2014-04-11] tftp-hpa 5.2-18 MIGRATED to testing [2014-03-31] Accepted 5.2-18 in unstable (low) [2014-02-18] Accepted 5.2-17 in experimental (low) ... meaning upstart support is completely gone, not only in experimental. Mraw, KiBi. signature.asc Description: Digital signature
Bug#746715: the foreseeable outcome of the TC vote on init systems
Ian Jackson ijack...@chiark.greenend.org.uk: I have CC'd the packages@address for the package. jftr, you haven't (tftpa-...@packages.debian.org != tftp-...@packages.debian.org). but i have seen the bug by chance today when checking the ctte mailing list in my inbox, so i guess no harm done/time lost. -- 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5364bc05.7050...@progress-technologies.net
Bug#746715: the foreseeable outcome of the TC vote on init systems
On 05/03/2014 10:05 AM, Andreas Barth wrote: if we think about overruling him, there might be better uses for. such as? i'm not aware of anything that would displease you in my packages, let alone anything that would require to 'overrule' me. in the absence of any bug report from you against any of my packages, please let me know of any issues you're having and i'll look into fixing them. -- 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-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5364bdaa.40...@progress-technologies.net
Bug#746715: the foreseeable outcome of the TC vote on init systems
On 3 May 2014 09:31, Daniel Baumann daniel.baum...@progress-technologies.net wrote: Steve, first of all: why haven't you just talked to me? you know more then well that i've kindly and quickly responded to all your bug reports, on and offline. #746715 sounds like shooting with a nuclear weapon on little glitch. seccond, if you feel that deeply about that particular patch[1] and want to still add see upstart support in tftpd-hpa for jessie, i'm happy to re-include it. As part of https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1273462 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712763 I'm working on a patch to add a hook into lsb-initfunctions.d (which init.d script in your package sources) that way no changes to the init script would be required / nor exit codes added / nor dependency on higher (debian specific) functions from sysv-init package. In essence this brings back upstart-job symlinks, but via lsb initfunctions hook, thus the following would happen if one invokes init.d script: # /etc/init.d/ssh restart ssh stop/waiting ssh start/running, process 6946 This is more in-spirit with previous (ubuntu-only) implementation of sysv-init migration which made /etc/inid./ssh a symlink to an upstart-job script that called into initctl commands. This is also similar to what systemd integration on Debian/Ubuntu does. I believe adding above lsb hook is compliant with Debian Policy §9.11.1 in a sense that init.d scripts avoid running in favor of the native upstart job. It's just in common case it's done on behalf of the maintainers / users. to the allegations made in this bug report: upstart support has been only *temporarily* be present in experimental. it has never been in unstable, technically there was never any upstart support. There is, however, support for upstart in ubuntu for that package and a developer of that derivative had to spend extra work rebasing/reintroducing the support back as part of regular merge work to keep up to date with changes introduced in Debian. Thus slightly more development time was used up on this issue/bug collectively across debian derivative distributions. [1] http://daniel-baumann.ch/gitweb/?p=debian/packages/tftp-hpa.git;a=commitdiff;h=0ec85b4d4fcd3d4bbd7fa97e81c35fd301ac7060 -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhlugaiyc-wfjm7ebmdnmgfsllsms_oji1lpsh2da424y...@mail.gmail.com
Bug#746715: the foreseeable outcome of the TC vote on init systems
Le samedi 03 mai 2014 à 10:31 +0200, Daniel Baumann a écrit : first of all: why haven't you just talked to me? you know more then well that i've kindly and quickly responded to all your bug reports, on and offline. #746715 sounds like shooting with a nuclear weapon on little glitch. Wild guess: because the Technical Committee is being treated as a personal playground by a couple developers. Maybe they should read the Constitution, especially §6.3.6. Ironically enough, this advice applies most to the person who originally wrote it. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1399135724.7081.6.ca...@kagura.malsain.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
Package: tech-ctte An Ubuntu developer just brought the following Debian changelog entry to my attention: tftp-hpa (5.2-17) experimental; urgency=low * Removing upstart hacks, they are ugly and upstart is dead now. Since various members of the Technical Committee argued that choosing a default would not prevent Debian from supporting other init systems, I would like to hear from those members how they think this should be addressed. -- 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#746715: the foreseeable outcome of the TC vote on init systems
Steve Langasek vor...@debian.org writes: An Ubuntu developer just brought the following Debian changelog entry to my attention: tftp-hpa (5.2-17) experimental; urgency=low * Removing upstart hacks, they are ugly and upstart is dead now. Since various members of the Technical Committee argued that choosing a default would not prevent Debian from supporting other init systems, I would like to hear from those members how they think this should be addressed. Well, one, in the abstract this seems like a bad idea. I certainly don't intend to remove upstart support in my packages, any more than I would reintroduce a bunch of PATH_MAX expressions and intentionally drop Hurd support. In terms of what to do about it, I think we need more details, specifically around why the maintainer felt that the upstart support was ugly and involved hacks. Removing half-implemented or poorly-implemented code may be appropriate in some circumstances even for things that we do want to support, and may involve some degree of judgement call (although I'd hope the maintainer would accept cleanups instead of removal). Do you know why the maintainer felt that way about the upstart changes? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvkrj4o4@windlord.stanford.edu
Bug#746715: the foreseeable outcome of the TC vote on init systems
Russ Allbery writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): Steve Langasek vor...@debian.org writes: An Ubuntu developer just brought the following Debian changelog entry to my attention: tftp-hpa (5.2-17) experimental; urgency=low * Removing upstart hacks, they are ugly and upstart is dead now. Since various members of the Technical Committee argued that choosing a default would not prevent Debian from supporting other init systems, I would like to hear from those members how they think this should be addressed. Well, one, in the abstract this seems like a bad idea. I certainly don't intend to remove upstart support in my packages, any more than I would reintroduce a bunch of PATH_MAX expressions and intentionally drop Hurd support. The removed change is presumably what was added here: tftp-hpa (5.2-9) experimental; urgency=low * Adding upstart exit codes in initscript. * Adding slightly modified upstart script from Steve Langasek steve.langa...@canonical.com (Closes: #708851). -- Daniel Baumann m...@daniel-baumann.ch Mon, 03 Jun 2013 06:50:31 +0200 (It appears that archive.debian.org doesn't keep snapshots of experimental so it isn't easy to see exactly what was done.) In terms of what to do about it, I think we need more details, specifically around why the maintainer felt that the upstart support was ugly and involved hacks. Removing half-implemented or poorly-implemented code may be appropriate in some circumstances even for things that we do want to support, and may involve some degree of judgement call (although I'd hope the maintainer would accept cleanups instead of removal). Do you know why the maintainer felt that way about the upstart changes? #708851 does not disclose any concerns from the maintainer about the version of these changes that were previously applied. Obviously the patches as they were were tolerable, so it seems unlikely that there's a compelling reason for removing them now. In the absence of a reasonable explanation, the TC should overrule the maintainer. We should do so promptly. I have CC'd the packages@ address for the package. Ian. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21348.5554.300057.342...@chiark.greenend.org.uk
Bug#746715: the foreseeable outcome of the TC vote on init systems
Ian Jackson ijack...@chiark.greenend.org.uk (2014-05-02):
(It appears that archive.debian.org doesn't keep snapshots of
experimental so it isn't easy to see exactly what was done.)
You probably want:
http://snapshot.debian.org/package/tftp-hpa/
Packages are easily downloaded this way:
debsnap -d . tftp-hpa 5.2-8
debsnap -d . tftp-hpa 5.2-9
debdiff tftp-hpa_5.2*dsc
Source debdiff attached for your convenience.
Mraw,
KiBi.
diff -Nru tftp-hpa-5.2/debian/changelog tftp-hpa-5.2/debian/changelog
--- tftp-hpa-5.2/debian/changelog 2013-03-31 16:54:13.0 +0200
+++ tftp-hpa-5.2/debian/changelog 2013-06-03 06:50:33.0 +0200
@@ -1,3 +1,11 @@
+tftp-hpa (5.2-9) experimental; urgency=low
+
+ * Adding upstart exit codes in initscript.
+ * Adding slightly modified upstart script from Steve Langasek
+steve.langa...@canonical.com (Closes: #708851).
+
+ -- Daniel Baumann m...@daniel-baumann.ch Mon, 03 Jun 2013 06:50:31 +0200
+
tftp-hpa (5.2-8) experimental; urgency=low
* Adding Slovak debconf translations from Slavko sla...@slavino.sk
diff -Nru tftp-hpa-5.2/debian/tftpd-hpa.init tftp-hpa-5.2/debian/tftpd-hpa.init
--- tftp-hpa-5.2/debian/tftpd-hpa.init 2013-03-31 16:53:41.0 +0200
+++ tftp-hpa-5.2/debian/tftpd-hpa.init 2013-06-03 06:31:51.0 +0200
@@ -31,6 +31,13 @@
. /lib/lsb/init-functions
+if init_is_upstart /dev/null 21
+then
+ _INITSYSTEM=upstart
+else
+ _INITSYSTEM=sysvinit
+fi
+
do_start()
{
# Ensure --secure and multiple server directories are not used at the
@@ -70,18 +77,24 @@
case ${1} in
start)
+ [ ${_INITSYSTEM} = upstart ] exit 1
+
log_daemon_msg Starting ${DESC} ${NAME}
do_start
log_end_msg ${?}
;;
stop)
+ [ ${_INITSYSTEM} = upstart ] exit 0
+
log_daemon_msg Stopping ${DESC} ${NAME}
do_stop
log_end_msg ${?}
;;
restart|force-reload)
+ [ ${_INITSYSTEM} = upstart ] exit 1
+
log_daemon_msg Restarting ${DESC} ${NAME}
do_stop
sleep 1
diff -Nru tftp-hpa-5.2/debian/tftpd-hpa.upstart tftp-hpa-5.2/debian/tftpd-hpa.upstart
--- tftp-hpa-5.2/debian/tftpd-hpa.upstart 1970-01-01 01:00:00.0 +0100
+++ tftp-hpa-5.2/debian/tftpd-hpa.upstart 2013-06-03 06:31:42.0 +0200
@@ -0,0 +1,51 @@
+description tftp-hpa server
+
+start on runlevel [2345]
+stop on runlevel [!2345]
+
+expect fork
+respawn
+
+env DEFAULTS=/etc/default/tftpd-hpa
+env PIDFILE=/var/run/tftpd-hpa.pid
+
+pre-start script
+ if [ -f ${DEFAULTS} ]
+ then
+ . ${DEFAULTS}
+ fi
+
+ # Ensure --secure and multiple server directories are not used at the
+ # same time
+ if [ $(echo ${TFTP_DIRECTORY} | wc -w) -ge 2 ] echo ${TFTP_OPTIONS} | grep -qs secure
+ then
+ echo
+ echo When --secure is specified, exactly one directory can be specified.
+ echo Please correct your /etc/default/tftpd-hpa.
+
+ stop
+ exit 0
+ fi
+
+ # Ensure server directories are existing
+ for _DIRECTORY in ${TFTP_DIRECTORY}
+ do
+ if [ ! -d ${_DIRECTORY} ]
+ then
+ echo ${_DIRECTORY} missing, aborting.
+
+ stop
+ exit 0
+ fi
+ done
+
+end script
+
+script
+ if [ -f ${DEFAULTS} ]
+ then
+ . ${DEFAULTS}
+ fi
+
+ exec /usr/sbin/in.tftpd --listen --user ${TFTP_USERNAME} --address ${TFTP_ADDRESS} ${TFTP_OPTIONS} ${TFTP_DIRECTORY}
+end script
signature.asc
Description: Digital signature
Bug#746715: the foreseeable outcome of the TC vote on init systems
El Fri, 2 de May 2014 a las 3:01 PM, Ian Jackson ijack...@chiark.greenend.org.uk escribió: Russ Allbery writes (Bug#746715: the foreseeable outcome of the TC vote on init systems): Steve Langasek vor...@debian.org writes: An Ubuntu developer just brought the following Debian changelog entry to my attention: tftp-hpa (5.2-17) experimental; urgency=low * Removing upstart hacks, they are ugly and upstart is dead now. Since various members of the Technical Committee argued that choosing a default would not prevent Debian from supporting other init systems, I would like to hear from those members how they think this should be addressed. Well, one, in the abstract this seems like a bad idea. I certainly don't intend to remove upstart support in my packages, any more than I would reintroduce a bunch of PATH_MAX expressions and intentionally drop Hurd support. The removed change is presumably what was added here: tftp-hpa (5.2-9) experimental; urgency=low * Adding upstart exit codes in initscript. There we go! As somebody who likes Upstart, _this is an ugly hack_. It is mandated by Debian policy [0], as most of you may know, though. Perhaps the simplest solution to the immediate problem is to perform the actions suggested by Dimitri Ledkov in BTS #712763 [1]. That said, there is obviously a bigger question here for the TC to address. [0] https://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712763 Best regards, -- Cameron Norman
Bug#746715: the foreseeable outcome of the TC vote on init systems
Steve Langasek vor...@debian.org writes: Package: tech-ctte An Ubuntu developer just brought the following Debian changelog entry to my attention: tftp-hpa (5.2-17) experimental; urgency=low * Removing upstart hacks, they are ugly and upstart is dead now. Since various members of the Technical Committee argued that choosing a default would not prevent Debian from supporting other init systems, I would like to hear from those members how they think this should be addressed. In general, pulling upstart support while upstart still exists in Debian feels wrong. However, since this is in experimental, and not in a released tree or release candidate, this particular case is hard for me to get worked up about. Bdale pgpCQQUyNU4Ct.pgp Description: PGP signature
Bug#746715: the foreseeable outcome of the TC vote on init systems
On Fri, May 02, 2014 at 04:50:51PM -0700, Bdale Garbee wrote: Steve Langasek vor...@debian.org writes: Package: tech-ctte An Ubuntu developer just brought the following Debian changelog entry to my attention: tftp-hpa (5.2-17) experimental; urgency=low * Removing upstart hacks, they are ugly and upstart is dead now. Since various members of the Technical Committee argued that choosing a default would not prevent Debian from supporting other init systems, I would like to hear from those members how they think this should be addressed. In general, pulling upstart support while upstart still exists in Debian feels wrong. However, since this is in experimental, and not in a released tree or release candidate, this particular case is hard for me to get worked up about. The changelog entry was for experimental. The change in question is included in unstable now. In point of fact, the upstart support was never included in unstable at all, because the maintainer had closed the bug in an upload to experimental instead of uploading it to unstable where it belonged; but that's a separate issue. And it doesn't change the situation that the maintainer has decided to block upstart support for this package without discussion. -- 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
