Bug#727708: TC resolution revised draft

2014-02-01 Thread Ian Jackson
Sébastien Villemot writes (Bug#727708: TC resolution revised draft): P1: DT UT DL UL P2: DL UL DT UT P3: UT UL DL DT P4: UT UL DL DT This is a nice example which actually demonstrates why these questions need to be voted on in a single ballot. If one votes on T-vs-L before

Bug#727708: TC resolution revised draft

2014-02-01 Thread Uoti Urpala
On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote: Sébastien Villemot writes (Bug#727708: TC resolution revised draft): P1: DT UT DL UL P2: DL UL DT UT P3: UT UL DL DT P4: UT UL DL DT This is a nice example which actually demonstrates why these questions need to be

Re: Bug#727708: On diversity

2014-02-01 Thread Steve Langasek
On Mon, Jan 20, 2014 at 08:27:47AM +0100, Tollef Fog Heen wrote: GNOME certainly uses these interfaces already. Whether they should be considered a dependency or not is probably something that should be left to the maintainers' discretion. But I think they should certainly be handled the

Bug#727708: call for votes on default Linux init system for jessie

2014-02-01 Thread Steve Langasek
On Tue, Jan 28, 2014 at 09:23:11AM -0800, Keith Packard wrote: Bdale Garbee bd...@gag.com writes: Thus, I believe the only acceptable option for Q2 from among your set is requiring a specific init is permitted even if it is not the default one. But I would prefer to vote a ballot that

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Steve Langasek
On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote: No, Josselin was making the technical claim that GNOME 3.10 would need a working logind even for basic functionality. So if it is possible to get the basic functionality of GNOME 3.10 without a working logind, his claim is just

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Ian Jackson
Steve Langasek writes (Bug#727708: multiple init systems - formal resolution proposal): [stuff] Thanks for that, which I mostly agree with. On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote: Thus, for me, all of the T variants in Ian's latest draft

Processed: block 726763 with 727708

2014-02-01 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org: block 726763 with 727708 Bug #726763 [gnome-settings-daemon] gnome-settings-daemon: no suspend on close lid, action not configurable, key missing 726763 was not blocked by any bugs. 726763 was not blocking any bugs. Added blocking bug(s) of

Bug#727708: call for votes on default Linux init system for jessie

2014-02-01 Thread Josh Triplett
Steve Langasek wrote: On Tue, Jan 28, 2014 at 09:23:11AM -0800, Keith Packard wrote: Bdale Garbee bd...@gag.com writes: Thus, I believe the only acceptable option for Q2 from among your set is requiring a specific init is permitted even if it is not the default one. But I would

Re: Processed: block 726763 with 727708

2014-02-01 Thread Steve Langasek
On Sat, Feb 01, 2014 at 08:09:24PM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: block 726763 with 727708 On whose behalf are you setting such a block? You are not listed as a maintainer of gnome-settings-daemon, and even those members of the TC

Re: Processed: block 726763 with 727708

2014-02-01 Thread Russ Allbery
Steve Langasek vor...@debian.org writes: The above 'block' would be tantamount to an assertion that you have no intention of accepting patches from maintainers of non-default init systems to provide compatibility unless forced to do so by the TC; Wouldn't it be more reasonable to assume that

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Steve Langasek
On Sat, Feb 01, 2014 at 07:28:49PM +, Ian Jackson wrote: Steve Langasek writes (Bug#727708: multiple init systems - formal resolution proposal): Thus, for me, all of the T variants in Ian's latest draft (21226.41292.366504.997...@chiark.greenend.org.uk) rank below FD. In my mail

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Russ Allbery
Steve Langasek vor...@debian.org writes: Where would this ballot option rank vis-à-vis FD, for those TC members who are opposed to the loose coupling option? == dependencies rider version S (split-the-init) == This decision is limited to selecting a default initsystem; we continue to

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Josh Triplett
Russ Allbery wrote: Steve Langasek vor...@debian.org writes: And so I am greatly dismayed by the position Russ and Bdale have taken in this discussion with respect to packages being allowed to depend on a specific init system. Both have expressed the opinion that Debian should remain

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Russ Allbery
Josh Triplett j...@joshtriplett.org writes: It should be completely trivial to introduce a virtual org-freedesktop-login1 package (modulo any complexities introduced by interface versioning for new methods added to that interface). However, it also seems pointless until there's a prospective

Re: Processed: block 726763 with 727708

2014-02-01 Thread Josh Triplett
On Sat, Feb 01, 2014 at 03:24:47PM -0500, Steve Langasek wrote: On Sat, Feb 01, 2014 at 08:09:24PM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: block 726763 with 727708 On whose behalf are you setting such a block? You are not listed as a

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Josh Triplett
On Sat, Feb 01, 2014 at 01:21:19PM -0800, Russ Allbery wrote: Josh Triplett j...@joshtriplett.org writes: It should be completely trivial to introduce a virtual org-freedesktop-login1 package (modulo any complexities introduced by interface versioning for new methods added to that

Bug#727708: TC resolution revised draft

2014-02-01 Thread Anthony Towns
On 2 February 2014 04:05, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote: Sébastien Villemot writes (Bug#727708: TC resolution revised draft): P1: DT UT DL UL So his example was one where the D/U and L/T choices were independent for every

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Steve Langasek
On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote: In particular, in the case of GNOME, I don't see any package in the archive yet for a fork of logind that depends on systemd-shim instead of systemd, so there's no alternative available for GNOME to depend on. There is no fork of

Re: Processed: block 726763 with 727708

2014-02-01 Thread Steve Langasek
On Sat, Feb 01, 2014 at 12:34:19PM -0800, Russ Allbery wrote: Steve Langasek vor...@debian.org writes: The above 'block' would be tantamount to an assertion that you have no intention of accepting patches from maintainers of non-default init systems to provide compatibility unless forced

Re: Processed: block 726763 with 727708

2014-02-01 Thread Ian Jackson
Steve Langasek writes (Re: Processed: block 726763 with 727708): In other words: I think the technically correct thing here is obvious and simple and invariant with respect to any decision the TC is going to make; (Disclaimer: I have had some wine and am tired. This may make no sense or be

Re: Processed: block 726763 with 727708

2014-02-01 Thread Russ Allbery
Steve Langasek vor...@debian.org writes: I don't think it's reasonable to leave testing and unstable users of our default desktop environment without working suspend and resume for more than a month (systemd-shim was accepted into unstable on Dec 28, and this was mentioned on the bug) when a

Re: Processed: block 726763 with 727708

2014-02-01 Thread Steve Langasek
On Sat, Feb 01, 2014 at 01:42:23PM -0800, Josh Triplett wrote: The block added above simply reflects the many comments from GNOME folks (and systemd folks for that matter) saying that they're waiting for the fallout to clear before making any drastic changes. Furthermore, it reflects the

Re: Bug#727708: On diversity

2014-02-01 Thread Tollef Fog Heen
]] Steve Langasek On Mon, Jan 20, 2014 at 08:27:47AM +0100, Tollef Fog Heen wrote: GNOME certainly uses these interfaces already. Whether they should be considered a dependency or not is probably something that should be left to the maintainers' discretion. But I think they should

Re: Processed: block 726763 with 727708

2014-02-01 Thread Tollef Fog Heen
]] Steve Langasek While I think the Depends: systemd should be dropped (via a split of the systemd package), While you keep asking for this, I think I've quite clearly said I'm not interested in that. You're of course free to suggest it to the CTTE that the systemd maintainers should be

Re: Processed: block 726763 with 727708

2014-02-01 Thread Josh Triplett
On Sat, Feb 01, 2014 at 03:24:54PM -0800, Steve Langasek wrote: On Sat, Feb 01, 2014 at 01:42:23PM -0800, Josh Triplett wrote: The block added above simply reflects the many comments from GNOME folks (and systemd folks for that matter) saying that they're waiting for the fallout to clear

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Josh Triplett
On Sat, Feb 01, 2014 at 05:23:11PM -0500, Steve Langasek wrote: On Sat, Feb 01, 2014 at 01:12:34PM -0800, Josh Triplett wrote: In particular, in the case of GNOME, I don't see any package in the archive yet for a fork of logind that depends on systemd-shim instead of systemd, so there's no

Bug#727708: Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use one that does.

2014-02-01 Thread Thilos Rich
Init should be simple, secure, and get out of the way. It should not take over the system. We should not be forced to use an init that does. This man said it best: wizardofbits.tumblr.com/post/45232318557/systemd-more-like-shit-stemd Init has one other job, which is to keep the process tables

Bug#727708: Processed: block 726763 with 727708

2014-02-01 Thread Cameron Norman
On Sat, Feb 1, 2014 at 3:48 PM, Uoti Urpala uoti.urp...@pp1.inet.fi wrote: On Sat, 2014-02-01 at 15:24 -0800, Steve Langasek wrote: While I think the Depends: systemd should be dropped (via a split of the systemd package), that's not required for fixing the present problem. That can be

Bug#727708: Processed: block 726763 with 727708

2014-02-01 Thread Russ Allbery
Cameron Norman camerontnor...@gmail.com writes: I think there is a huge problem with recommending that systemd be installed by the user changing the init line in grub: a package can not depend on an init system being PID 1. Can a package be made that changes the init line to systemd? I think

Bug#727708: Processed: block 726763 with 727708

2014-02-01 Thread Bdale Garbee
Russ Allbery r...@debian.org writes: I *like* systemd, and I would still be very unhappy if a routine aptitude upgrade (or even a dist-upgrade) of a system currently running sysvinit suddenly resulted in running systemd without some sort of critical debconf question or the like. Indeed.

Bug#727708: package to change init systems [was: Bug#727708: Processed: block 726763 with 727708]

2014-02-01 Thread Chris Knadle
On Saturday, February 01, 2014 19:14:21 Cameron Norman wrote: On Sat, Feb 1, 2014 at 6:35 PM, Russ Allbery r...@debian.org wrote: I *like* systemd, and I would still be very unhappy if a routine aptitude upgrade (or even a dist-upgrade) of a system currently running sysvinit suddenly

Bug#727708: multiple init systems - formal resolution proposal

2014-02-01 Thread Michael Gilbert
On Sat, Feb 1, 2014 at 11:25 AM, Steve Langasek wrote: On Wed, Jan 29, 2014 at 10:13:25PM +0200, Adrian Bunk wrote: And that does matter a lot, since such claims seem to be the basis of all these GNOME in jessie needs systemd or with multiple init systems, GNOME will need a dependency on

Bug#727708: package to change init systems

2014-02-01 Thread Russ Allbery
Cameron Norman camerontnor...@gmail.com writes: This is not really what I was interested in. I want a package for each init system (init-systemd, init-upstart, etc.) that uses something like init-select (under the hood) to prompt the user to change the init system. This will allow packages