Bug#762194: On automatic init system switching on upgrade
Hi, I would like to see an end to open questions on systemd in Jessie. So, given that the GR is over and no technical proposals for not switching init systems on upgrade to Jessie have been made, is it possible to draw a conclusion to this issue now? I'm not sure there is much to gain from waiting longer... 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/546c9240.8010...@debian.org
Resignation
I am resigning from the Technical Committee with immediate effect. While it is important that the views of the 30-40% of the project who agree with me should continue to be represented on the TC, I myself am clearly too controversial a figure at this point to do so. I should step aside to try to reduce the extent to which conversations about the project's governance are personalised. And, speaking personally, I am exhausted. The majority of the project have voted to say that it was wrong of me to bring this GR at this time. Despite everything that's happened, I respectfully disagree. I hope that the next time a controversial issue arises, someone will step forward to advance what might be a minority view. Thanks to everyone who has served with me on the TC. I wish those who remain on the TC the best for the future and I hope that you'll find colleagues who are as good to work with as you have been to me. I now hope to spend more of my free software time doing programming. dgit is at the top of my Debian queue, but some of my GNU and SGO projects could do with attention too. 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/21612.38477.245453.248...@chiark.greenend.org.uk
Thank you for your work, Ian
Ian Jackson wrote: > I now hope to spend more of my free software time doing programming. > dgit is at the top of my Debian queue, but some of my GNU and SGO > projects could do with attention too. Hi Ian, I've been quite impressed with your technical contributions to Debian, particularly dgit, and I'm glad to hear that you plan to continue that work. I would have been quite sad if this had been a resignation from the project rather than the TC. For anyone who has not yet seen dgit, I recommend taking a look at it; it's an impressive bit of wizardry that lets you pretend the entire Debian repository all lives in git. - Josh Triplett -- 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/20141119192100.GA4590@jtriplet-mobl1
Re: Resigning from the Technical Committee
Hey. On Sun, 2014-11-16 at 17:34 -0800, Russ Allbery wrote: > I resign from the Debian Technical Committee, effective immediately. What a shame :-( Thanks for your many years of excellent work. I think this is a very big loss for the TC and Debian, since you showed great wisdom and technical knowledge as well as commitment to work yourself into an issue brought up to the TC, and all its background. Of course one has to respect your decision, especially in the light of personal burden that the work for the TC put upon you, but I guess I'd be more than happy if someone would nominate you again. They recent "developments" around the TC and all the political parties and agendas involved, make it even more regretful that you felt you'd have to resign now. > I'm also not comfortable being part of the governance process when I'm not > deeply involved in the work. Actually I think the opposite is the case. Making a good decision should only require technical, scientific and long-term political knowledge - which you undoubtedly all have. Being to deeply involved in one of the parts one have to decide upon, usually leads to political questions (biased?) and a less neutral decision. Debian is a do-ocracy, which has practical advantages but also disadvantages: In the long term it may very well mean that it destroys the basis for minorities and for diversity. In that light it seems even more bad that especially you resigned. Also the plans for a maximum term on the TC membership seems not really compelling to me - it just means that it will become even more easy to put political pressure on the TC or to have people becoming member, which are deeply involved in one of the matters brought up before the TC. Thanks anyway, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Thank you for your work, Ian
Hey. On Wed, 2014-11-19 at 13:08 +, Ian Jackson wrote: >I am resigning from the Technical Committee with immediate effect. Again, what a shame :-( Thanks for all your work, I'd say the same what I've just written about Russ applies to you as well. You far-sight and technical knowledge will be deeply missed. I can fully understand that you feel very exhausted, especially since you've seemed to have become the direct target for many accusations and political issues. But especially since you "represent" the views of quite a number of DDs and also users of Debian, your resignation at this point is even more regretful. While personally I think systemd should be the default in Debian (well at least if it would be used in a way not just to rebuild sysvinit in systemd - but to use its full potential), and while I think that legacy systems should migrate to it on upgrade (unless people opt-out), I fully agree with your opinions about init-system-coupling, etc.. In the long term, the majority may simply destroy the basis of minority and of diversity. Likely we've already seen first signs of this with what's happening to kfreebsd. When a majority (or at least a larger group) has a strong technical and/or political agenda, others (whose wishes and technical views aren't less valid or important) often have to suffer and diversity dies. I don't want to imply that groups like GNOME would do this intentionally or in bad faith, not at all,... it simply happens as a side effect of being a big group, powerful or even the majority. GNOME seems to largely focus on desktop/single user models and to fully focus on systemd - so in the long term other projects will have to follow that or be less supported, or suffer show-stopper issues. This doesn't mean GNOME=evil, it just means the consequences of their decisions may very well affect others to a great deal and especially have a negative impact on diversity. Right now of course, all this seems to be a rather political and uncertain issue (which is also among the reasons why the TC and you were so heavily attacked) - but it can very well be, that the political questions of today, become the technical problems of tomorrow - only that it's likely to late then. In real world politics, there are laws to protect minorities - Debian apparently is to frightened of making such "laws" at the moment :-( I'd guess in the long-term this will mean a big loss for Debian and for FLOSS at large. > I myself am > clearly too controversial a figure at this point to do so. Mhh to me it seems that you were made that controversial figure largely for political reasons. Actually, such actions seemed to have become more common (on all sides) recently: - people threatening to fork Debian - people threatening to leave it - people abusing CoC other other things to silence others > The majority of the project The majority of those who took part in voting! > I now hope to spend more of my free software time doing programming. > dgit is at the top of my Debian queue, but some of my GNU and SGO > projects could do with attention too. Good to not see you leaving Debian :) Thanks as well for all your efforts, especially for fighting for your "controversial" beliefs, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Bug#762194: On automatic init system switching on upgrade
On Wed, 2014-11-19 at 13:51 +0100, Ansgar Burchardt wrote: > Hi, > > I would like to see an end to open questions on systemd in Jessie. > > So, given that the GR is over and no technical proposals for not > switching init systems on upgrade to Jessie have been made, is it > possible to draw a conclusion to this issue now? I'm not sure there is > much to gain from waiting longer... Hi Ansgar and especially the ctte members, Now when the GR outome is know it is time for the ctte to resolve the bug report first issued by me in #747535, then issued by Ian in #762194 to the ctte, and then by me to the ctte in #765803. According to the ctte announcement https://lists.debian.org/debian-devel-announce/2014/11/msg0.html the important parts of that text is: 3. We do not want to prejudge, interfere with, or contradict, the General Resolution process on init systems which is currently ongoing. Some of the GR options imply that automatic switching (both during upgrades, and during leaf package installations) will be necessary in at least some circumstances. The GR is now resolved: No GR required. 4. For the moment, we invite concrete proposals for technical changes which would arrange that 1. new jessie installations using Linux would get systemd but 2. existing installations retain their existing init system so far as possible. Solutions exists or are in the works for solving this. 5. After the result of the General Resolution is known, we intend to formally resolve the question of automatic switching of init systems. Our decision on that question will of course be consistent with the successful General Resolution option, whatever that may be. This issue is not resolved, and since the GR did not give any answer on the above problem, this question now bounces back to the ctte! Now with three less members, down to five :( Or can the resigning members still be part of deciding on this issue? Note also that the bug about automatic switching of init systems was issued in March this year by me, and brought to the ctte in September by Ian and me in October. Ian is/was was in the ctte, but I'm not, so the question about if a ctte member can issue an issue to the ctte, and vote at the same time does not apply in this case. (in case somebody questions the involvement by Ian (as has been done)). Bug #746578 is now resolved by the ctte in https://lists.debian.org/debian-devel-announce/2014/11/msg00010.html about the order of systemd-shim and systemd-sysv, but the above bugs still have to be resolved by the ctte. So Ansgar, this has to be dragged on for still some while. Thank you for your attention. -- 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/1416436750.11764.125.ca...@g3620.my.own.domain
Bug#765803: Bug#762194: On automatic init system switching on upgrade
On Wed, 19 Nov 2014, Svante Signell wrote: > 4. For the moment, we invite concrete proposals for technical changes >which would arrange that 1. new jessie installations using Linux >would get systemd but 2. existing installations retain their >existing init system so far as possible. > > Solutions exists or are in the works for solving this. As far as I know, these concrete proposals have not been discussed with the relevant teams or presented to the CTTE. Presumably, they would involve specific changes to the init package. Speaking personally, without specific patches which have been discussed with the maintainers of the init package and well tested, I'm unlikely to vote any resolution on this issue above FD. -- Don Armstrong http://www.donarmstrong.com Live and learn or die and teach by example -- a softer world #625 http://www.asofterworld.com/index.php?id=625 -- 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/20141119235422.gd4...@teltox.donarmstrong.com
Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On Tue, 28 Oct 2014, Helmut Grohne wrote: > I have to admit that the code is not exactly lightweight. I do > understand the desire to get rid it and asked that a ctte ruling does > not apply beyond jessie for that reason. Are people who are doing cross-building like this actually using the code which will be in jessie? I (perhaps naïvely) would expect them to be primarily using the code in unstable, and maybe at a late stage of bring-up rebuilding all of stable. -- Don Armstrong http://www.donarmstrong.com "There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself." -- Bach -- 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/20141120004149.gg4...@teltox.donarmstrong.com
Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On Wed, Nov 19, 2014 at 4:41 PM, Don Armstrong wrote: > Are people who are doing cross-building like this actually using the > code which will be in jessie? I (perhaps naïvely) would expect them to > be primarily using the code in unstable, and maybe at a late stage of > bring-up rebuilding all of stable. Important use case that people seem to be ignored: cross-building source code but *not* using Debian infrastructure. This still matters to Debian because it affects how much support both upstream and the package maintainers can give without having access to actual hardware. If cross-compilers are available in the exact same version (which, depending on where the bug is found, may be in the stable release or not), it is *much* easier for the people with more intimate knowledge of the package to directly support it. The code I work on isn't packaged for Debian yet, but without having cross-compilers to play with, I will *never* be able to support anything other than x86-*. I was using secretsauce builds for a while on my dev machine (when I think to test them), but that's not suitable for running my buildbot. I got excited that it was landing in time for Jessie, but because of this maintainer turf war it looks like I'll be another 3 years (i.e. until 'Stretch' is stable) without CI for non-x86 arches. I expect that my code will be ready to be packaged for Stretch, but who is going to take responsibility for finding and fixing the non-x86 bugs, given that the gcc maintainer is going out of his way to make things difficult? Honestly, disabling cross-compilers sounds like saying "x86-* are the only arches that matter" and negating the entire selling point of multiarch. I can't seriously believe the argument against cross-compilers is "you need to enable multiarch repos" - where else are you going to get all your library dependencies - bring back an entire set of ia32-libs packages, but for *every* arch? This is ludicrous, but it sounds like what the gcc maintainer is recommending. -- 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/ca+xnfzmwhiqtbdsl9e9qovnnzdk2rerbq0xshu2v9elawy-...@mail.gmail.com
Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On Wed, 19 Nov 2014, Ben Longbons wrote: > The code I work on isn't packaged for Debian yet, but without having > cross-compilers to play with, I will *never* be able to support > anything other than x86-*. Which suite are you currently using? I'm asking, because I want to know whether actually just doing this for jessie is enough, or whether doing this for unstable is enough, or whether we have to do it for jessie and unstable and then get a complete, tested, multiarch procedure which works in Debian which is acceptable to both porters and the gcc maintainers. > This is ludicrous, but it sounds like what the gcc maintainer is > recommending. Please try not to use language which escalates; calling something ludicrous isn't helpful. -- Don Armstrong http://www.donarmstrong.com The game of science is, in principle, without end. He who decides one day that scientific statements do not call for any further test, and that they can be regarded as finally verified, retires from the game. -- Sir Karl Popper _The Logic of Scientific Discovery_ §11 -- 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/20141120020535.gh4...@teltox.donarmstrong.com
Bug#762194: On automatic init system switching on upgrade
Svante Signell writes: > 4. For the moment, we invite concrete proposals for technical changes >which would arrange that 1. new jessie installations using Linux >would get systemd but 2. existing installations retain their >existing init system so far as possible. > > Solutions exists or are in the works for solving this. I'm aware that people are actively working on this. When a concrete proposal is ready, we'll be able to consider it. Any resolution before that would be clouded by uncertainty. Future software is always bug-free and runs in O(1) time... -- keith.pack...@intel.com signature.asc Description: PGP signature
Re: [CTTE #746578] libpam-systemd to switch alternate dependency ordering
Anthony Towns writes: > The tech ctte could've addressed this issue by providing policy guidance > or by just offering advice, and assuming that the systemd maintainers would > act on the advice or policy in good faith. Choosing to override the > systemd maintainers was far from the most friendly available option. If you go back and read the discussion, the participants came to a well researched and reasoned conclusion that the proposed change was the correct one in this case. Here's a paragraph from Josh Triplett's last message before the vote was taken. Josh is a proponent of systemd, but not a member of the Debian systemd team. I don't see any obvious further steps that need to occur other than flipping the dependency around. (It might be a good idea for the libpam-systemd dependency to bump its versioned dependency on systemd-shim to (>= 8-4), but that's up to the libpam-systemd maintainers.) I sent a note offering my apologies to the systemd team and to Tollef in particular for our rash application of an override before we'd given them a chance to read, review and respond to the conclusions reached by the discussion participants. -- keith.pack...@intel.com signature.asc Description: PGP signature
Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On Wed, Nov 19, 2014 at 6:05 PM, Don Armstrong wrote: > On Wed, 19 Nov 2014, Ben Longbons wrote: >> The code I work on isn't packaged for Debian yet, but without having >> cross-compilers to play with, I will *never* be able to support >> anything other than x86-*. > > Which suite are you currently using? I'm asking, because I want to know > whether actually just doing this for jessie is enough, or whether doing > this for unstable is enough, or whether we have to do it for jessie and > unstable and then get a complete, tested, multiarch procedure which > works in Debian which is acceptable to both porters and the gcc > maintainers. Our production server runs stable (i.e. Wheezy now, but we plan to upgrade not long after Jessie is released), and by sanity the CI server runs the same as production (and currently does x86-* builds only since there are no cross tools in Wheezy). My dev machine runs testing (Jessie), but it is *very* common for CI to catch errors that I can't, due to tiny differences between versions (gcc-4.7 4.7.2 in Wheezy has a frustrating bug with arrays of string literals but gcc-4.7 4.7.3 in Jessie was fine; the Debian-specific packaging bugs in libstdc++-dbg that have regressed in *every* new gcc release; several subtle between gdb versions (e.g. printing null pointers as '0' instead of '0x0' and breaking my script that checks gdb output) and of course the catastrophic bug #748711 (at least there's a migration plan for Stretch now (gdb-python2 package in experimental))). So, if you want upstream and Debian maintainers to support a package in $suite, you need the full set of cross tools and multiarch libs in $suite, not just in unstable. I've proven with the cross tools in unstable that my program *should* work on non-x86-* platforms, but real-world reports indicate that it does *not* on stable (Wheezy), on at least one architecture. If the cross tools miss jessie and go in jessie-backports, that will require a significant amount of knowledge and discipline on the part of all the package maintainers involved, to make sure that they always have matching versions despite being in different repos or they will not be useful for package developers. If they are treated as one package and go in one repo, everybody is happy. -Ben -- 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/ca+xnfzoyze6itmau2hgzrrst6pgl+ge+6vfc6yikfznkasp...@mail.gmail.com
Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
Hi Don, On Wed, Nov 19, 2014 at 04:41:49PM -0800, Don Armstrong wrote: > Are people who are doing cross-building like this actually using the > code which will be in jessie? I (perhaps naïvely) would expect them to > be primarily using the code in unstable, and maybe at a late stage of > bring-up rebuilding all of stable. Thanks for asking this. Let me give two answers to this question: 1) No. The continuous integration happened in sid and people bootstrapping new architectures tend to use sid plus patches. However the method of bootstrapping that was known working two weeks before the freeze no longer works. Whatever method is going to be used now, it requires changing packages. Since these changes tend to not fall under the freeze policy, they are practically not mergeable. So in this answer, jessie is to be understood as a time frame: Keep things working that worked before until we are allowed to fix things. 2) Yes. People repeatedly ask for cross toolchains on stable systems. This is the very reason why Wookey tried to package them for jessie. Ultimately, they ended being late, so people will try to build them on their own and for the popular targets (mostly armhf, armel) this actually worked. Helmut -- 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/20141120075120.ga4...@alf.mars
