Debian Bug report logs - #726763
gnome-settings-daemon: no suspend on close lid, action not configurable, key missing

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Johannes Rohr <jorohr@gmail.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: gnome-settings-daemon: no suspend on close lid, action not configurable, key missing

Date: Fri, 18 Oct 2013 21:40:57 +0200

Package: gnome-settings-daemon
Version: 3.8.5-2
Severity: normal

Gnome-settings-daemon 3.8.5 does not suspend the laptop when I close the lid while running on battery 

The respective action is not configurable in gnome-control-center.

Running gsettings set org.gnome.settings-daemon.plugins.power lid-close-battery-action suspend returns an error:

No such key 'lid-close-battery-action'

According to https://help.gnome.org/users/gnome-help/3.5/power-closelid.html.en this would be the key to use.

Also, 

inspecting the contents of /org/gnome/settings-daemon/plugins/power/ in dconf-editor shows that no keys for configuring what happens when the lid is being closed are available.

So, something appears to be missing.

Thanks,

Johannes


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (450, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnome-settings-daemon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.16.1-1
ii  gsettings-desktop-schemas                    3.8.2-2
ii  libc6                                        2.17-93
ii  libcairo2                                    1.12.16-2
ii  libcanberra-gtk3-0                           0.30-2
ii  libcanberra0                                 0.30-2
ii  libcolord1                                   1.0.2-1
ii  libcups2                                     1.6.3-1
ii  libfontconfig1                               2.10.2-2
ii  libgdk-pixbuf2.0-0                           2.28.2-1
ii  libglib2.0-0                                 2.36.4-1
ii  libgnome-desktop-3-7                         3.8.4-2
ii  libgtk-3-0                                   3.8.4-1
ii  libgudev-1.0-0                               204-5
ii  libibus-1.0-5                                1.5.3-7
ii  liblcms2-2                                   2.2+git20110628-2.3
ii  libnotify4                                   0.7.6-1
ii  libpackagekit-glib2-16                       0.8.10-2
ii  libpango-1.0-0                               1.32.5-5+b1
ii  libpulse-mainloop-glib0                      4.0-6+b1
ii  libpulse0                                    4.0-6+b1
ii  librsvg2-2                                   2.36.4-2
ii  libupower-glib1                              0.9.21-3
ii  libwacom2                                    0.8-1
ii  libx11-6                                     2:1.6.2-1
ii  libxfixes3                                   1:5.0.1-1
ii  libxi6                                       2:1.7.2-1
ii  libxkbfile1                                  1:1.0.8-1
ii  libxtst6                                     2:1.2.2-1
ii  nautilus-data                                3.8.2-2
ii  systemd                                      204-5

Versions of packages gnome-settings-daemon recommends:
ii  pulseaudio  4.0-6+b1

Versions of packages gnome-settings-daemon suggests:
ii  gnome-screensaver            3.6.1-1
ii  icewm [x-window-manager]     1.3.7-5
ii  metacity [x-window-manager]  1:2.34.13-1
ii  twm [x-window-manager]       1:1.0.6-1
ii  x11-xserver-utils            7.7+1

-- no debconf information

Message #10 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Johannes Rohr <jorohr@gmail.com>, 726763@bugs.debian.org

Subject: Re: Bug#726763: gnome-settings-daemon: no suspend on close lid, action not configurable, key missing

Date: Fri, 18 Oct 2013 22:07:49 +0200

[Message part 1 (text/plain, inline)]

Am 18.10.2013 21:40, schrieb Johannes Rohr:
> Package: gnome-settings-daemon
> Version: 3.8.5-2
> Severity: normal
> 
> Gnome-settings-daemon 3.8.5 does not suspend the laptop when I close the lid while running on battery 
> 
> The respective action is not configurable in gnome-control-center.
> 
> Running gsettings set org.gnome.settings-daemon.plugins.power lid-close-battery-action suspend returns an error:
> 
> No such key 'lid-close-battery-action'
> 
> According to https://help.gnome.org/users/gnome-help/3.5/power-closelid.html.en this would be the key to use.
> 
> Also, 
> 
> inspecting the contents of /org/gnome/settings-daemon/plugins/power/ in dconf-editor shows that no keys for configuring what happens when the lid is being closed are available.
> 
> So, something appears to be missing.


Working suspend/resume requires systemd to be PID 1 [1].
Boot with init=/bin/systemd for that.

I'll probably add a small notification on first login with instructions
how to do that.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #15 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Johannes Rohr <jorohr@gmail.com>

To: Michael Biebl <biebl@debian.org>

Cc: 726763@bugs.debian.org

Subject: Re: Bug#726763: gnome-settings-daemon: no suspend on close lid, action not configurable, key missing

Date: Sat, 19 Oct 2013 08:17:12 +0200

[Message part 1 (text/plain, inline)]

On Fri, Oct 18, 2013 at 10:07:49PM +0200, Michael Biebl wrote:

[...]

> 
> Working suspend/resume requires systemd to be PID 1 [1].
> Boot with init=/bin/systemd for that.
> 
> I'll probably add a small notification on first login with instructions
> how to do that.

Thanks for the quick response & your instructions! However, using this
method, the screen is not locked on resume, which obviously is a
security issue. Is there any trick to work around this as well? (lock
screen settings appear to have disappeared from GNOME altogether)

Thanks,

Johannes



-- 
infoe - Institut für Ökologie und Aktions-Ethnologie e.V.
Melchiorstr. 3, 50670 Köln, +49-221-739 28 71
http://www.infoe.de/ Fax: +49-221-922 97 60

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Michael Biebl <biebl@debian.org>

Cc: Johannes Rohr <jorohr@gmail.com>, 726763@bugs.debian.org

Subject: Bug#726763: Gnome depends on systemd being PID 1

Date: Sun, 08 Dec 2013 21:05:05 +0100

Hi,

in the last week there have been three bug reports (#731426, #731602, 
#731686) concerning the same problem as described in this bug: Gnome 
depends on systemd being PID 1 for suspend/hibernate/reboot/poweroff to 
fully work in all menus.
Each of these bug reports was against a different package, so the 
reporters did not find an existing report on the issue.

I think that the gnome package in its current state should at least 
recommend systemd-sysv, since this package (or the boot parameter 
'init=/bin/systemd') "would be found together with this one in all but 
unusual installations" [0].

The problem with this is that systemd-sysv replaces sysvinit, which is 
an essential Debian package, thus systemd-sysv cannot be a dependency, 
at least until the technical committee has decided on the init system 
issue (#727708).

On Fri, Oct 18, 2013 at 10:07:49PM +0200, Michael Biebl wrote:
> Working suspend/resume requires systemd to be PID 1 [1].
> Boot with init=/bin/systemd for that.
>
> I'll probably add a small notification on first login with instructions
> how to do that.

It seems that this notification is either not yet added, or normal users 
do not find it, as they are still confused and report bugs about the 
issue. So please add this notification in a prominent place to avoid 
countless duplicates of this bug report.

Best regards,
Andreas


0: 
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

Message #25 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Vincent Lefevre <vincent@vinc17.net>

Cc: Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>

Subject: Re: Bug#729576: duplicate of bug #726763

Date: Sun, 22 Dec 2013 17:47:42 +0100

Control: reassign 726763 gnome-shell

Hi Vincent,

On 22.12.2013 17:38, Vincent Lefevre wrote:
> Bug #726763 is assigned to gnome-settings-daemon, while #729576
> occurs without it installed. But perhaps #726763 is assigned to
> the wrong package...
Yeah, that is probably assigned to the wrong package, but it is not so 
clear, what the correct package is. I'm reassigning this to gnome-shell, 
as I'm sure that gnome-shell at least depends on systemd being PID 1.

> If #726763 occurs with GNOME and without lightdm, and is the same
> problem as #729576, then this could confirm that it is a systemd
> bug.
This is no bug in systemd, but rather a missing dependency of 
gnome-shell and probably also gdm3 on systemd-sysv. But this dependency 
cannot be added, because systemd-sysv conflicts with the essential 
sysvinit package. Thus a resolution of this has to wait until after the 
technical committee has decided on the init system issue (Bug #727708).

Have you tried using systemd as PID 1?

Best regards,
Andreas

Message #36 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>

Subject: Re: Bug#729576: duplicate of bug #726763

Date: Sun, 22 Dec 2013 20:41:55 +0100

On 2013-12-22 17:47:42 +0100, Andreas Cadhalpun wrote:
> On 22.12.2013 17:38, Vincent Lefevre wrote:
> > If #726763 occurs with GNOME and without lightdm, and is the same
> > problem as #729576, then this could confirm that it is a systemd
> > bug.
> This is no bug in systemd,

Sorry, I mixed up two bugs related to systemd and with similar bug
number (the other one is 732623, where the installation of systemd
breaks some lightdm features).

> but rather a missing dependency of gnome-shell and probably also
> gdm3 on systemd-sysv.

Perhaps. This would mean that gnome-shell / gdm3 would be completely
tied to systemd, and concerning gdm3, admins who don't want to use
systemd for init would have to use a different DM. A better solution
for gdm3 could be to use the traditional shutdown/restart/... method
as a fallback, which doesn't need systemd at all; then systemd-sysv
could just be recommended. But that's up to the gdm3 developers to
decide.

> But this dependency cannot be added, because systemd-sysv conflicts
> with the essential sysvinit package.

If GNOME developers want to require systemd as the init system,
I don't see this as a reason not to add the dependency. Users
are not forced to install GNOME packages. And if they want GNOME,
they would have to accept the consequences about the init system.

> Have you tried using systemd as PID 1?

No, I don't want to do such kind of risky test. Since I was not
using the GNOME desktop environment, but just gdm3 and some GNOME
apps, I decided to drop those that depend on systemd. For me,
this meant:
  * gdm3 -> lightdm (but systemd must *not* be installed due to
    bug 732623),
  * gnome-control-center (to set up the volume) -> pavucontrol
    (though it is inferior).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #41 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Vincent Lefevre <vincent@vinc17.net>

Cc: Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <732623@bugs.debian.org>

Subject: Re: Bug#729576: duplicate of bug #726763

Date: Sun, 22 Dec 2013 21:20:18 +0100

Hi,

On 22.12.2013 20:41, Vincent Lefevre wrote:
> Sorry, I mixed up two bugs related to systemd and with similar bug
> number (the other one is 732623, where the installation of systemd
> breaks some lightdm features).
I have lightdm installed parallel to gdm3 and just switched to lightdm. 
I cannot reproduce the issue described in bug 732623, i.e. for me all 
the four menu entries are there, independent of how often I login/logout.

> If GNOME developers want to require systemd as the init system,
> I don't see this as a reason not to add the dependency. Users
> are not forced to install GNOME packages. And if they want GNOME,
> they would have to accept the consequences about the init system.
The problem is the policy [1]:
"Essential is defined as the minimal set of functionality that must be 
available and usable on the system at all times"
So removing an essential package is not really allowed by the policy.

>> Have you tried using systemd as PID 1?
>
> No, I don't want to do such kind of risky test. Since I was not
> using the GNOME desktop environment, but just gdm3 and some GNOME
> apps, I decided to drop those that depend on systemd. For me,
> this meant:
>    * gdm3 -> lightdm (but systemd must *not* be installed due to
>      bug 732623),
Since this problem does not occur for me and I am using systemd as it 
was meant to be used, i.e. as PID 1, perhaps you may want to reconsider 
trying systemd as PID 1?
By the way, that is not 'risky' in any way: You can just edit the boot 
entry in grub (or whatever boot loader you use) by appending 
'init=\bin\systemd' (with the package systemd installed). With this, you 
can try booting with systemd just for one session, without changing any 
configuration on your hard disk.

Best regards,
Andreas

1: http://www.debian.org/doc/debian-policy/ch-binary.html#s3.8

Message #46 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <732623@bugs.debian.org>

Subject: Re: Bug#729576: duplicate of bug #726763

Date: Sun, 22 Dec 2013 22:33:47 +0100

Hi,

On 2013-12-22 21:20:18 +0100, Andreas Cadhalpun wrote:
> On 22.12.2013 20:41, Vincent Lefevre wrote:
> >Sorry, I mixed up two bugs related to systemd and with similar bug
> >number (the other one is 732623, where the installation of systemd
> >breaks some lightdm features).
> I have lightdm installed parallel to gdm3 and just switched to lightdm.

I had the same problem with both installed.

> I cannot reproduce the issue described in bug 732623, i.e. for me
> all the four menu entries are there, independent of how often I
> login/logout.

Did you try with twm?

Now, without logs from systemd, it's hard to tell the cause of
the difference.

> >If GNOME developers want to require systemd as the init system,
> >I don't see this as a reason not to add the dependency. Users
> >are not forced to install GNOME packages. And if they want GNOME,
> >they would have to accept the consequences about the init system.
> The problem is the policy [1]:
> "Essential is defined as the minimal set of functionality that must be
> available and usable on the system at all times"
> So removing an essential package is not really allowed by the policy.

There's the same problem with systemd-sysv itself. So, I don't think
it is against the policy. This point is more for tools handling
package installation and removal, and also to avoid two essential
packages conflicting each other.

> >>Have you tried using systemd as PID 1?
> >
> >No, I don't want to do such kind of risky test. Since I was not
> >using the GNOME desktop environment, but just gdm3 and some GNOME
> >apps, I decided to drop those that depend on systemd. For me,
> >this meant:
> >   * gdm3 -> lightdm (but systemd must *not* be installed due to
> >     bug 732623),
> Since this problem does not occur for me and I am using systemd as it was
> meant to be used, i.e. as PID 1, perhaps you may want to reconsider trying
> systemd as PID 1?
> By the way, that is not 'risky' in any way: You can just edit the boot entry
> in grub (or whatever boot loader you use) by appending 'init=\bin\systemd'
> (with the package systemd installed). With this, you can try booting with
> systemd just for one session, without changing any configuration on your
> hard disk.

I'll have to think to try that on my desktop machine (which is much
faster to do various tests than my old laptop).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #51 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Vincent Lefevre <vincent@vinc17.net>

Cc: Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <732623@bugs.debian.org>

Subject: Re: Bug#729576: duplicate of bug #726763

Date: Sun, 22 Dec 2013 23:30:21 +0100

Hi,

On 22.12.2013 22:33, Vincent Lefevre wrote:
> On 2013-12-22 21:20:18 +0100, Andreas Cadhalpun wrote:
>> I have lightdm installed parallel to gdm3 and just switched to lightdm.
>
> I had the same problem with both installed.
The problem is probably, that systemd is not PID 1.

>> I cannot reproduce the issue described in bug 732623, i.e. for me
>> all the four menu entries are there, independent of how often I
>> login/logout.
>
> Did you try with twm?
I just tried twm, but twm just hangs and gives many of the following errors:
console-kit-daemon[2535]: (process:2928): GLib-CRITICAL **: 
g_slice_set_config: assertion `sys_page_size == 0' failed

This same message comes (but only 6x) when using gnome-shell, but 
gnome-shell starts.

> Now, without logs from systemd, it's hard to tell the cause of
> the difference.
What logs would you like to see?

>>> If GNOME developers want to require systemd as the init system,
>>> I don't see this as a reason not to add the dependency. Users
>>> are not forced to install GNOME packages. And if they want GNOME,
>>> they would have to accept the consequences about the init system.
>> The problem is the policy [1]:
>> "Essential is defined as the minimal set of functionality that must be
>> available and usable on the system at all times"
>> So removing an essential package is not really allowed by the policy.
>
> There's the same problem with systemd-sysv itself. So, I don't think
> it is against the policy. This point is more for tools handling
> package installation and removal, and also to avoid two essential
> packages conflicting each other.
I think it is not acceptable that the default Debian installer (for a 
desktop system) does not install an essential package, which would be 
the case, if gnome depended on systemd-sysv. Currently I think there is 
no package that depends on systemd-sysv without alternative and 
systemd-sysv is a package that actually does nothing else (as far as I 
can tell), but replace sysvinit with a link to systemd.

Best regards,
Andreas

Message #56 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <732623@bugs.debian.org>

Subject: Re: Bug#729576: duplicate of bug #726763

Date: Mon, 23 Dec 2013 03:20:46 +0100

On 2013-12-22 23:30:21 +0100, Andreas Cadhalpun wrote:
> >Now, without logs from systemd, it's hard to tell the cause of
> >the difference.
> What logs would you like to see?

The result of the tests CanSuspend, CanHibernate, CanReboot and
CanPowerOff, and possibly the cause of the result when it isn't
"yes". I can't see them in D-Bus monitoring. Or perhaps I'm doing
something wrong.

There could be a debug mode in the conf files, just like what
gdm3 has, e.g. from /etc/gdm3/daemon.conf:

[debug]
# More verbose logs
# Additionally lets the X server dump core if it crashes
Enable = true

After some new tests, it appears that libpam-systemd is needed too to
make the bug appear with lightdm. But to make it disappear, removing
libpam-systemd only is not sufficient: I also need to remove systemd
(but rebooting might be another solution, I haven't tried). Note that
even after removing systemd, /lib/systemd/systemd-logind is still
running.

With libpam-systemd installed, using

  gdbus monitor --system --dest org.freedesktop.login1

I can see org.freedesktop.login1.Manager.SessionNew lines, but the
sessions are removed only when I log in again. So, when I log out,
there's always a session active. Here's how it looks like:

/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionNew ('6', objectpath '/org/freedesktop/login1/session/_36')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions', 'ActiveSession'])
/org/freedesktop/login1/user/1000: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionNew ('c9', objectpath '/org/freedesktop/login1/session/c9')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions', 'ActiveSession'])
/org/freedesktop/login1/user/124: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionRemoved ('6', objectpath '/org/freedesktop/login1/session/_36')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/user/1000: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionRemoved ('c7', objectpath '/org/freedesktop/login1/session/c7')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/user/124: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionNew ('7', objectpath '/org/freedesktop/login1/session/_37')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions', 'ActiveSession'])
/org/freedesktop/login1/user/1000: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionNew ('c10', objectpath '/org/freedesktop/login1/session/c10')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions', 'ActiveSession'])
/org/freedesktop/login1/user/124: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionRemoved ('7', objectpath '/org/freedesktop/login1/session/_37')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/user/1000: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionRemoved ('c9', objectpath '/org/freedesktop/login1/session/c9')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/user/124: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionNew ('8', objectpath '/org/freedesktop/login1/session/_38')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions', 'ActiveSession'])
/org/freedesktop/login1/user/1000: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionNew ('c11', objectpath '/org/freedesktop/login1/session/c11')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions', 'ActiveSession'])
/org/freedesktop/login1/user/124: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionRemoved ('8', objectpath '/org/freedesktop/login1/session/_38')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/user/1000: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionRemoved ('c10', objectpath '/org/freedesktop/login1/session/c10')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', @a{sv} {}, ['Sessions'])
/org/freedesktop/login1/user/124: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', @a{sv} {}, ['Sessions'])

When I remove systemd, though logind is still running, I no longer
get SessionNew and SessionRemoved lines. That's probably why the bug
disappears.

This leaves 2 questions:

1. Why isn't the session removed when I log out?
   Something related to /etc/X11/Xsession* configuration?
   Note that I have the default.
   /etc/X11/Xsession is run via session-wrapper=/etc/X11/Xsession
   in /usr/share/lightdm/lightdm.conf.d/01_debian.conf

2. Why, apparently due to this session problem, only 2 menu items
   over the 4 ones disappear?

> >>>If GNOME developers want to require systemd as the init system,
> >>>I don't see this as a reason not to add the dependency. Users
> >>>are not forced to install GNOME packages. And if they want GNOME,
> >>>they would have to accept the consequences about the init system.
> >>The problem is the policy [1]:
> >>"Essential is defined as the minimal set of functionality that must be
> >>available and usable on the system at all times"
> >>So removing an essential package is not really allowed by the policy.
> >
> >There's the same problem with systemd-sysv itself. So, I don't think
> >it is against the policy. This point is more for tools handling
> >package installation and removal, and also to avoid two essential
> >packages conflicting each other.
> I think it is not acceptable that the default Debian installer (for a
> desktop system) does not install an essential package, which would be the
> case, if gnome depended on systemd-sysv.

I agree, but the Debian installer would have to be changed to drop
GNOME entirely (anyway, if GNOME breaks without systemd-sysv, this
will happen).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #61 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>

Subject: Re: Bug#729576: duplicate of bug #726763

Date: Sat, 28 Dec 2013 02:07:22 +0100

On 2013-12-22 23:30:21 +0100, Andreas Cadhalpun wrote:
> >>>If GNOME developers want to require systemd as the init system,
> >>>I don't see this as a reason not to add the dependency. Users
> >>>are not forced to install GNOME packages. And if they want GNOME,
> >>>they would have to accept the consequences about the init system.
> >>The problem is the policy [1]:
> >>"Essential is defined as the minimal set of functionality that must be
> >>available and usable on the system at all times"
> >>So removing an essential package is not really allowed by the policy.
> >
> >There's the same problem with systemd-sysv itself. So, I don't think
> >it is against the policy. This point is more for tools handling
> >package installation and removal, and also to avoid two essential
> >packages conflicting each other.
> I think it is not acceptable that the default Debian installer (for a
> desktop system) does not install an essential package, which would be the
> case, if gnome depended on systemd-sysv. Currently I think there is no
> package that depends on systemd-sysv without alternative and systemd-sysv is
> a package that actually does nothing else (as far as I can tell), but
> replace sysvinit with a link to systemd.

The latest change of sysvinit should solve this conflict issue,
once systemd-sysv no longer conflicts with sysvinit, but with
sysvinit-core:

sysvinit (2.88dsf-44) unstable; urgency=low
[...]
  [ Steve Langasek ]
  * Move sysvinit functionality into a new binary package, sysvinit-core,
    and have sysvinit depend on an ORed list of the available
    implementations of /sbin/init.  Since sysvinit is an Essential: yes
    package, this is the only away to allow users to cleanly switch between
    init systems without having to go through a multi-release-cycle
    transition.  Closes: #728566.

 -- Steve Langasek <vorlon@debian.org>  Thu, 26 Dec 2013 11:09:49 -0800

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #66 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Vincent Lefevre <vincent@vinc17.net>

Cc: Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <733240@bugs.debian.org>, Debian Bug Tracking System <645540@bugs.debian.org>

Subject: Re: Bug#729576: duplicate of bug #726763

Date: Sat, 28 Dec 2013 19:31:46 +0100

Hi,

On 28.12.2013 02:07, Vincent Lefevre wrote:
> On 2013-12-22 23:30:21 +0100, Andreas Cadhalpun wrote:
>>>>> If GNOME developers want to require systemd as the init system,
>>>>> I don't see this as a reason not to add the dependency. Users
>>>>> are not forced to install GNOME packages. And if they want GNOME,
>>>>> they would have to accept the consequences about the init system.
>>>> The problem is the policy [1]:
>>>> "Essential is defined as the minimal set of functionality that must be
>>>> available and usable on the system at all times"
>>>> So removing an essential package is not really allowed by the policy.
>>> There's the same problem with systemd-sysv itself. So, I don't think
>>> it is against the policy. This point is more for tools handling
>>> package installation and removal, and also to avoid two essential
>>> packages conflicting each other.
>> I think it is not acceptable that the default Debian installer (for a
>> desktop system) does not install an essential package, which would be the
>> case, if gnome depended on systemd-sysv. Currently I think there is no
>> package that depends on systemd-sysv without alternative and systemd-sysv is
>> a package that actually does nothing else (as far as I can tell), but
>> replace sysvinit with a link to systemd.
>
> The latest change of sysvinit should solve this conflict issue,
> once systemd-sysv no longer conflicts with sysvinit, but with
> sysvinit-core:
>
> sysvinit (2.88dsf-44) unstable; urgency=low
> [...]
>    [ Steve Langasek ]
>    * Move sysvinit functionality into a new binary package, sysvinit-core,
>      and have sysvinit depend on an ORed list of the available
>      implementations of /sbin/init.  Since sysvinit is an Essential: yes
>      package, this is the only away to allow users to cleanly switch between
>      init systems without having to go through a multi-release-cycle
>      transition.  Closes: #728566.
>
>   -- Steve Langasek <vorlon@debian.org>  Thu, 26 Dec 2013 11:09:49 -0800

The package systemd-sysv should only break/replace sysvinit-core and not 
sysvinit (see bug #733240), which would solve bug #645540 as well.

After that gnome-shell and gdm3 should add a recommendation for 
systemd-sysv, since most people will want to use the functionality like 
suspend from menus, that needs systemd as PID 1, but occasionally some 
people may prefer to use sysvinit-core or upstart.

Best regards,
Andreas

Message #71 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>, 645540@bugs.debian.org

Cc: Vincent Lefevre <vincent@vinc17.net>, Debian Bug Tracking System <733240@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: [Pkg-sysvinit-devel] Bug#645540: Bug#729576: duplicate of bug #726763

Date: Sat, 28 Dec 2013 11:32:10 -0800

On Sat, Dec 28, 2013 at 07:31:46PM +0100, Andreas Cadhalpun wrote:

> After that gnome-shell and gdm3 should add a recommendation for
> systemd-sysv, since most people will want to use the functionality
> like suspend from menus, that needs systemd as PID 1, but
> occasionally some people may prefer to use sysvinit-core or upstart.

Absolutely not.  The desktop functionality is related to a set of dbus
services, which can be provided perfectly well on top of other init systems. 
We need a proper solution here, not the GNOME packages forcing an init
system selection on all users.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Message #76 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Steve Langasek <vorlon@debian.org>

Cc: 645540@bugs.debian.org, Vincent Lefevre <vincent@vinc17.net>, Debian Bug Tracking System <733240@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: [Pkg-sysvinit-devel] Bug#645540: Bug#729576: duplicate of bug #726763

Date: Sat, 28 Dec 2013 20:51:58 +0100

Hi Steve,

On 28.12.2013 20:32, Steve Langasek wrote:
> On Sat, Dec 28, 2013 at 07:31:46PM +0100, Andreas Cadhalpun wrote:
>
>> After that gnome-shell and gdm3 should add a recommendation for
>> systemd-sysv, since most people will want to use the functionality
>> like suspend from menus, that needs systemd as PID 1, but
>> occasionally some people may prefer to use sysvinit-core or upstart.
>
> Absolutely not.  The desktop functionality is related to a set of dbus
> services, which can be provided perfectly well on top of other init systems.
> We need a proper solution here, not the GNOME packages forcing an init
> system selection on all users.

As it is, GNOME upstream decided to depend on systemd being PID 1. While 
I don't really like it, I do not know of any alternative that exists 
now, but, of course, you are invited to create one.
Until that has happened, gdm3 and gnome-shell should recommend 
systemd-sysv to ensure that they work properly. You might not be aware 
of it, but this missing dependency has annoyed users (myself included) 
already, and there have been many bug reports about it (#726763, 
#729576, #731426, #731602, #731686).

Best regards,
Andreas

Message #81 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: 645540@bugs.debian.org, Vincent Lefevre <vincent@vinc17.net>, Debian Bug Tracking System <733240@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: [Pkg-sysvinit-devel] Bug#645540: Bug#729576: duplicate of bug #726763

Date: Sat, 28 Dec 2013 11:56:24 -0800

[Message part 1 (text/plain, inline)]

On Sat, Dec 28, 2013 at 08:51:58PM +0100, Andreas Cadhalpun wrote:
> On 28.12.2013 20:32, Steve Langasek wrote:
> >On Sat, Dec 28, 2013 at 07:31:46PM +0100, Andreas Cadhalpun wrote:

> >>After that gnome-shell and gdm3 should add a recommendation for
> >>systemd-sysv, since most people will want to use the functionality
> >>like suspend from menus, that needs systemd as PID 1, but
> >>occasionally some people may prefer to use sysvinit-core or upstart.

> >Absolutely not.  The desktop functionality is related to a set of dbus
> >services, which can be provided perfectly well on top of other init systems.
> >We need a proper solution here, not the GNOME packages forcing an init
> >system selection on all users.

> As it is, GNOME upstream decided to depend on systemd being PID 1.

No, they decided to depend on *a set of dbus services*.

> While I don't really like it, I do not know of any alternative that
> exists now, but, of course, you are invited to create one.

It exists, it's called systemd-shim and it's available in Ubuntu.  I will be
uploading it to Debian shortly.  Unconditionally recommending systemd-sysv
is absolutely the wrong thing to do here.

> Until that has happened, gdm3 and gnome-shell should recommend
> systemd-sysv to ensure that they work properly. You might not be
> aware of it, but this missing dependency has annoyed users (myself
> included) already, and there have been many bug reports about it
> (#726763, #729576, #731426, #731602, #731686).

I'm sure I'm more aware of the details of the situation than you are.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #86 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Steve Langasek <vorlon@debian.org>

Cc: 645540@bugs.debian.org, Vincent Lefevre <vincent@vinc17.net>, Debian Bug Tracking System <733240@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: [Pkg-sysvinit-devel] Bug#645540: Bug#729576: duplicate of bug #726763

Date: Sat, 28 Dec 2013 21:02:05 +0100

On 28.12.2013 20:56, Steve Langasek wrote:
> On Sat, Dec 28, 2013 at 08:51:58PM +0100, Andreas Cadhalpun wrote:
>> While I don't really like it, I do not know of any alternative that
>> exists now, but, of course, you are invited to create one.
>
> It exists, it's called systemd-shim and it's available in Ubuntu.  I will be
> uploading it to Debian shortly.

This is great. Thanks for your work for Debian.

Message #91 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 726763@bugs.debian.org, 729576@bugs.debian.org

Cc: 727708@bugs.debian.org, systemd@packages.debian.org

Subject: systemd-shim uploaded to NEW

Date: Sat, 28 Dec 2013 19:50:11 -0800

[Message part 1 (text/plain, inline)]

Control: affects 726763 systemd

I've just uploaded the systemd-shim package to the NEW queue.  This provides
an implementation of the org.freedesktop.systemd1 dbus service which is
compatible with non-systemd-using systems.  I have verified this service
works with gdm3 in unstable, at least to the point of enabling shutdown from
the GUI menu.

There are, however, some remaining problems to sort out before systemd-shim
will solve the hard dependency of GNOME on systemd in unstable.  The systemd
maintainers have rejected my request to split the systemd binary package
between the init system and the dbus services.  This is problematic, because
systemd-shim provides an independent implementation of some, but not all, of
the systemd dbus services: to be precise, it provides only
org.freedesktop.systemd1.service, not any of
org.freedesktop.hostname1.service, org.freedesktop.locale1.service,
org.freedesktop.login1.service, and org.freedesktop.timedate1.service.  It
does not provide these services because the existing implementations from
systemd are perfectly usable on a stand-alone basis without pid1==systemd.
As a result, systemd-shim has a Conflict with systemd (which is correct),
but GNOME needs to be able to depend on all of the above dbus services
installable together.

So I repeat here my request that the systemd maintainers make a suitable
split of the systemd binary package, so that systemd-shim will be
coinstallable with the systemd-provided implementations of the other dbus
services.  The only alternative I see is for systemd-shim to declare a
Replaces: against systemd without a Conflicts, which would have the known
problematic effect that anyone removing the systemd-shim package again
(perhaps because they are choosing to switch to systemd) will be left
without the Replaced files on disk.  I would prefer users not to be
subjected to such poor integration, on top of the problems they've already
been made to endure as a result of the GNOME packages gaining an
ill-coordinated dependency on an init system; but of the available choices,
this seems to be the lesser evil if the systemd maintainers continue to
insist on a monolithic binary package.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #98 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Paul Tagliamonte <paultag@debian.org>

To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org

Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Sun, 29 Dec 2013 01:00:10 -0500

[Message part 1 (text/plain, inline)]

On Sat, Dec 28, 2013 at 07:50:11PM -0800, Steve Langasek wrote:
> I've just uploaded the systemd-shim package to the NEW queue.

This package has been marked for ACCEPT. Please feel free to test it
once dinstall runs and it gets sync'd to your local friendly mirror.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte <paultag@debian.org>  |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `-     http://people.debian.org/~paultag/conduct-statement.txt

[signature.asc (application/pgp-signature, inline)]

Message #103 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org

Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Mon, 30 Dec 2013 18:29:10 +0000

Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
> So I repeat here my request that the systemd maintainers make a suitable
> split of the systemd binary package, so that systemd-shim will be
> coinstallable with the systemd-provided implementations of the other dbus
> services.

Is there a summary of the systemd maintainers' response to this
request ?  I glanced #726763 and #729576 but they were very long and
if the answer is in there I probably wouldn't have found it.

>  The only alternative I see is for systemd-shim to declare a
> Replaces: against systemd without a Conflicts,

This would be quite wrong; Replaces is not supposed to be used like
that (but you apparently know that).

How do the systemd maintainers think this problem should be solved ?

Ian.

Message #108 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Raphael Hertzog <hertzog@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 727708@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>, 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Mon, 30 Dec 2013 19:42:58 +0100

On Mon, 30 Dec 2013, Ian Jackson wrote:
> >  The only alternative I see is for systemd-shim to declare a
> > Replaces: against systemd without a Conflicts,
> 
> This would be quite wrong; Replaces is not supposed to be used like
> that (but you apparently know that).
> 
> How do the systemd maintainers think this problem should be solved ?

I don't know the specifics of systemd-shim, but dpkg-divert is the usual
answer when you need/want to replace something without the consent of the
other side.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Message #113 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org, 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Mon, 30 Dec 2013 13:03:48 -0800

[Message part 1 (text/plain, inline)]

On Mon, Dec 30, 2013 at 06:29:10PM +0000, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
> > So I repeat here my request that the systemd maintainers make a suitable
> > split of the systemd binary package, so that systemd-shim will be
> > coinstallable with the systemd-provided implementations of the other dbus
> > services.

> Is there a summary of the systemd maintainers' response to this
> request ?  I glanced #726763 and #729576 but they were very long and
> if the answer is in there I probably wouldn't have found it.

The relevant discussion on debian-devel is here:

http://lists.debian.org/msgid-search/20131024012751.GA7604@virgil.dodds.net
http://lists.debian.org/msgid-search/87bo2fyruk.fsf_-_@qurzaw.varnish-software.com

> >  The only alternative I see is for systemd-shim to declare a
> > Replaces: against systemd without a Conflicts,

> This would be quite wrong; Replaces is not supposed to be used like
> that (but you apparently know that).

Yes.  Raphaël rightly points out that dpkg-divert can be used for this; if
necessary, that's what I'll do.

But I still think the right thing here is for the systemd package to be
split.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #118 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Tollef Fog Heen <tfheen@err.no>

To: 727708@bugs.debian.org

Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Mon, 30 Dec 2013 21:52:37 +0100

]] Ian Jackson 

> Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
> > So I repeat here my request that the systemd maintainers make a suitable
> > split of the systemd binary package, so that systemd-shim will be
> > coinstallable with the systemd-provided implementations of the other dbus
> > services.
> 
> Is there a summary of the systemd maintainers' response to this
> request ?  I glanced #726763 and #729576 but they were very long and
> if the answer is in there I probably wouldn't have found it.

I see no point in doing that, in particular not in the middle of when
the ctte is choosing a new default init system.  If anything, I think
it's pretty rude of Steve to upload systemd-shim and asking the systemd
maintainers to solve the problem for him.

> >  The only alternative I see is for systemd-shim to declare a
> > Replaces: against systemd without a Conflicts,
> 
> This would be quite wrong; Replaces is not supposed to be used like
> that (but you apparently know that).
> 
> How do the systemd maintainers think this problem should be solved ?

Initially, by waiting for the ctte to come to a conclusion.  If that is
that systemd should be the default init system I think we should solve
the problem by not solving it.  If the decision is that another init
system should be solved, I'm probably going to solve it by removing the
init functionality from the systemd package at which point the bug
solves itself, AIUI.

If the systemd-shim maintainers want to solve it in the meantime, going
with Raphael's suggestion seems reasonable enough.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Message #123 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Ian Jackson <ijackson@chiark.greenend.org.uk>

Cc: 727708@bugs.debian.org, 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org, Tollef Fog Heen <tfheen@err.no>

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Mon, 30 Dec 2013 15:46:51 -0800

[Message part 1 (text/plain, inline)]

On Mon, Dec 30, 2013 at 01:03:48PM -0800, Steve Langasek wrote:
> > This would be quite wrong; Replaces is not supposed to be used like
> > that (but you apparently know that).

> Yes.  Raphaël rightly points out that dpkg-divert can be used for this; if
> necessary, that's what I'll do.

> But I still think the right thing here is for the systemd package to be
> split.

Looking more closely, I find that one of the conflicting files is a conffile
(/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).  diversions and
conffiles still don't mix, AFAIK (and according to current policy).  So that
seems to still leave us without a proper solution that doesn't involve
splitting the systemd binary package.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #128 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Michael Stapelberg <stapelberg@debian.org>

To: Tollef Fog Heen <tfheen@err.no>

Cc: systemd@packages.debian.org, 729576@bugs.debian.org, 726763@bugs.debian.org

Subject: Re: [Pkg-systemd-maintainers] Bug#727708: systemd-shim uploaded to NEW

Date: Tue, 31 Dec 2013 07:22:14 +0100

Hi,

Tollef Fog Heen <tfheen@err.no> writes:

> ]] Ian Jackson 
>
>> Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
>> > So I repeat here my request that the systemd maintainers make a suitable
>> > split of the systemd binary package, so that systemd-shim will be
>> > coinstallable with the systemd-provided implementations of the other dbus
>> > services.
>> 
>> Is there a summary of the systemd maintainers' response to this
>> request ?  I glanced #726763 and #729576 but they were very long and
>> if the answer is in there I probably wouldn't have found it.
>
> I see no point in doing that, in particular not in the middle of when
> the ctte is choosing a new default init system.  If anything, I think
> it's pretty rude of Steve to upload systemd-shim and asking the systemd
> maintainers to solve the problem for him.
FWIW, as one of the other systemd maintainers, I entirely agree with
Tollef here.

-- 
Best regards,
Michael

Message #133 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 727708@bugs.debian.org

Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Tue, 31 Dec 2013 00:38:49 -0800

[Message part 1 (text/plain, inline)]

On Mon, Dec 30, 2013 at 09:52:37PM +0100, Tollef Fog Heen wrote:
> ]] Ian Jackson 

> > Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
> > > So I repeat here my request that the systemd maintainers make a suitable
> > > split of the systemd binary package, so that systemd-shim will be
> > > coinstallable with the systemd-provided implementations of the other dbus
> > > services.

> > Is there a summary of the systemd maintainers' response to this
> > request ?  I glanced #726763 and #729576 but they were very long and
> > if the answer is in there I probably wouldn't have found it.

> I see no point in doing that, in particular not in the middle of when
> the ctte is choosing a new default init system.  If anything, I think
> it's pretty rude of Steve to upload systemd-shim and asking the systemd
> maintainers to solve the problem for him.

Conversely, I think it's rude of everyone involved in having created this
bug to be pointing fingers at each other and disclaiming all responsibility
for fixing it, while in the meantime users of unstable are being left with
silently broken desktops on upgrades.  Even if Debian ultimately decides for
systemd, that doesn't do the least bit of good for users who suddenly find
suspend not working on their systems right now.

> > >  The only alternative I see is for systemd-shim to declare a
> > > Replaces: against systemd without a Conflicts,

> > This would be quite wrong; Replaces is not supposed to be used like
> > that (but you apparently know that).

> > How do the systemd maintainers think this problem should be solved ?

> Initially, by waiting for the ctte to come to a conclusion.  If that is
> that systemd should be the default init system I think we should solve
> the problem by not solving it.  If the decision is that another init
> system should be solved, I'm probably going to solve it by removing the
> init functionality from the systemd package at which point the bug
> solves itself, AIUI.

> If the systemd-shim maintainers want to solve it in the meantime, going
> with Raphael's suggestion seems reasonable enough.

So given that dpkg-divert can't be used for the conffile, is this still your
position?  This means that divert+Replaces is the only other option, which
will result in the conffile being removed if systemd-shim is installed and
then purged.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #138 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: debian-ctte@lists.debian.org, 727708@bugs.debian.org, 726763@bugs.debian.org, 729576@bugs.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Tue, 31 Dec 2013 01:16:32 -0800

Steve Langasek wrote:
> Looking more closely, I find that one of the conflicting files is a conffile
> (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).  diversions and
> conffiles still don't mix, AFAIK (and according to current policy).  So that
> seems to still leave us without a proper solution that doesn't involve
> splitting the systemd binary package.

Files in /etc/dbus-1/system.d/ need not have names that match the
interface they control; see, for instance, gdm.conf or
nm-dhcp-client.conf.  Why not simply install a systemd-shim.conf with
the contents you need?  To the best of my knowledge, I see nothing in
org.freedesktop.systemd1.conf that should interfere with you.

(That said, personally I'd prefer to see systemd-shim continue to
conflict with systemd, and work with a hypothetical
forked-systemd-logind package instead, which would also conflict with
systemd.  That would then, for instance, unblock systemd's ability to
upgrade past version 204.)

- Josh Triplett

Message #141 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Jakub Wilk <jwilk@debian.org>

To: 727708@bugs.debian.org

Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Tue, 31 Dec 2013 13:02:49 +0100

* Raphael Hertzog <hertzog@debian.org>, 2013-12-30, 19:42:
>dpkg-divert is the usual answer when you need/want to replace something 
>without the consent of the other side.

FWIW, Policy §3.9 reads: 
“You should not use ‘dpkg-divert’ on a file belonging to another package 
without consulting the maintainer of that package first.”

-- 
Jakub Wilk

Message #146 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>

To: Steve Langasek <vorlon@debian.org>, 727708@bugs.debian.org

Cc: 726763@bugs.debian.org, 729576@bugs.debian.org, systemd@packages.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Tue, 31 Dec 2013 16:50:43 +0000

Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
> On Mon, Dec 30, 2013 at 06:29:10PM +0000, Ian Jackson wrote:
> > This would be quite wrong; Replaces is not supposed to be used like
> > that (but you apparently know that).
> 
> Yes.  Raphaël rightly points out that dpkg-divert can be used for this; if
> necessary, that's what I'll do.

Right.  I think it would be best if you did that for now.  I'm right
in thinking that that would get you (and non-systemd-users) unblocked ?

> But I still think the right thing here is for the systemd package to be
> split.

I agree, but I think it would be best to postpone the resolution of
this dispute until after the main conclusions in this TC thread.

(One argument for delaying is that if the TC decides that systemd is
not only default, but mandatory, for jessie, this becomes irrelevant.)

Ian.

Message #151 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Josh Triplett <josh@joshtriplett.org>, 727708@bugs.debian.org

Cc: debian-ctte@lists.debian.org, 726763@bugs.debian.org, 729576@bugs.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Tue, 31 Dec 2013 13:07:22 -0800

[Message part 1 (text/plain, inline)]

On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote:
> Steve Langasek wrote:
> > Looking more closely, I find that one of the conflicting files is a conffile
> > (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).  diversions and
> > conffiles still don't mix, AFAIK (and according to current policy).  So that
> > seems to still leave us without a proper solution that doesn't involve
> > splitting the systemd binary package.

> Files in /etc/dbus-1/system.d/ need not have names that match the
> interface they control; see, for instance, gdm.conf or
> nm-dhcp-client.conf.  Why not simply install a systemd-shim.conf with
> the contents you need?  To the best of my knowledge, I see nothing in
> org.freedesktop.systemd1.conf that should interfere with you.

I hadn't considered that, but yes, I see that it's true that we could
install the conffile under a different name.

Given that the two config files apply policy to the same dbus name, this
means that a removed-but-not-purged systemd-shim package may impact
systemd's own dbus security policy.  It's already the case that the
systemd-shim and systemd policies are different.

So, which is the lesser evil here - that a removed-but-not-purged
systemd-shim package will interfere with the dbus policy of systemd itself,
or that an installed-then-purged systemd-shim package will remove the
systemd dbus policy altogether?

> (That said, personally I'd prefer to see systemd-shim continue to
> conflict with systemd, and work with a hypothetical
> forked-systemd-logind package instead, which would also conflict with
> systemd.  That would then, for instance, unblock systemd's ability to
> upgrade past version 204.)

For the record, logind is not the only issue here.  It's logind, timedated,
hostnamed, localed which are needed by GNOME.  This doesn't actually change
the work involved in forking the package; but I think it would be ridiculous
to have two systemd source packages in the archive, with all the resulting
coordination costs to both maintainers, instead of working out a correct
binary split of the one package that meets the needs of all Debian's users.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #156 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andrew Shadura <andrew@shadura.me>

To: 727708@bugs.debian.org

Cc: debian-ctte@lists.debian.org, 726763@bugs.debian.org, 729576@bugs.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Tue, 31 Dec 2013 22:30:56 +0100

[Message part 1 (text/plain, inline)]

Hello,

On Tue, 31 Dec 2013 13:07:22 -0800
Steve Langasek <vorlon@debian.org> wrote:

> For the record, logind is not the only issue here.  It's logind,
> timedated, hostnamed, localed which are needed by GNOME.  This
> doesn't actually change the work involved in forking the package; but
> I think it would be ridiculous to have two systemd source packages in
> the archive, with all the resulting coordination costs to both
> maintainers, instead of working out a correct binary split of the one
> package that meets the needs of all Debian's users.

Speaking of hostnamed... I wonder what's wrong with xdg-hostnamed[1],
why did systemd have chosen to reimplement it from scratch?

[1] http://cgit.freedesktop.org/~david/xdg-hostname/

-- 
Cheers,
  Andrew

[signature.asc (application/pgp-signature, attachment)]

Message #161 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: Steve Langasek <vorlon@debian.org>

Cc: 727708@bugs.debian.org, debian-ctte@lists.debian.org, 726763@bugs.debian.org, 729576@bugs.debian.org

Subject: Re: Bug#727708: systemd-shim uploaded to NEW

Date: Tue, 31 Dec 2013 13:50:15 -0800

On Tue, Dec 31, 2013 at 01:07:22PM -0800, Steve Langasek wrote:
> On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote:
> > Steve Langasek wrote:
> > > Looking more closely, I find that one of the conflicting files is a conffile
> > > (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf).  diversions and
> > > conffiles still don't mix, AFAIK (and according to current policy).  So that
> > > seems to still leave us without a proper solution that doesn't involve
> > > splitting the systemd binary package.
> 
> > Files in /etc/dbus-1/system.d/ need not have names that match the
> > interface they control; see, for instance, gdm.conf or
> > nm-dhcp-client.conf.  Why not simply install a systemd-shim.conf with
> > the contents you need?  To the best of my knowledge, I see nothing in
> > org.freedesktop.systemd1.conf that should interfere with you.
> 
> I hadn't considered that, but yes, I see that it's true that we could
> install the conffile under a different name.
> 
> Given that the two config files apply policy to the same dbus name, this
> means that a removed-but-not-purged systemd-shim package may impact
> systemd's own dbus security policy.  It's already the case that the
> systemd-shim and systemd policies are different.

Interesting; why are those policies different?  systemd's policy is, as
far as I can tell, "root can do as it likes, root can receive activation
requests, anyone else can send specific requests".  Is systemd-shim's
policy more lax or more strict?

> So, which is the lesser evil here - that a removed-but-not-purged
> systemd-shim package will interfere with the dbus policy of systemd itself,
> or that an installed-then-purged systemd-shim package will remove the
> systemd dbus policy altogether?

The latter, quite clearly.  Both would be bugs in systemd-shim, but
removing the configuration entirely would break systemd with the
systemd-shim package *not* installed, while interfering with the
configuration would break systemd with the systemd-shim package
*installed*, which seems less egregious and less surprising.

> > (That said, personally I'd prefer to see systemd-shim continue to
> > conflict with systemd, and work with a hypothetical
> > forked-systemd-logind package instead, which would also conflict with
> > systemd.  That would then, for instance, unblock systemd's ability to
> > upgrade past version 204.)
> 
> For the record, logind is not the only issue here.  It's logind, timedated,
> hostnamed, localed which are needed by GNOME.  This doesn't actually change
> the work involved in forking the package; but I think it would be ridiculous
> to have two systemd source packages in the archive, with all the resulting
> coordination costs to both maintainers, instead of working out a correct
> binary split of the one package that meets the needs of all Debian's users.

The key phrase is "both maintainers".  Having two packages that
permanently conflict with each other hardly seems like a major
coordination effort.  (The only annoyance I can think of is that I don't
know of any way to conflict with a package such that even having it
removed-but-not-purged would prevent installation of the conflicting
package.)

The problem is not the binary split, it's the ongoing maintenance burden
of making components of systemd run without systemd.  I would like to
see the forked-systemd source package maintained by folks willing to do
that work, and in the meantime, I'd like to see an *un*-forked systemd
package usable by people who want and use systemd.  (I'd be quite
willing to help with the latter, especially if the systemd maintainers
find themselves shorthanded due to demotivation caused by an upcoming
tech-ctte decision.)  In particular, I'd like to see new versions of
systemd available in Debian as soon as they're available upstream, and
that seems highly unlikely to happen with a forked systemd.  I'd also
like to avoid a situation in which the only package of systemd in the
archive is maintained as a permanent fork by people who don't actually
use it as their init systemd; that would not bode well for people trying
to run it and have their systems depend on it.

- Josh Triplett

Message #166 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <729576@bugs.debian.org>

Cc: Steve Langasek <vorlon@debian.org>

Subject: Bug#726763: gnome should depend on systemd-shim | systemd-sysv

Date: Sat, 04 Jan 2014 17:02:23 +0100

Control: reassign 726763 gnome-settings-daemon 3.8.5-2
Control: severity 726763 important

Hi,

I tested systemd-shim and, using it, suspend etc. from GNOME menus work 
agin with sysvinit/upstart.

So to resolve this bug, GNOME should depend on:
systemd-shim | systemd-sysv

This ordering ensures that installing GNOME does not switch the init 
system, but since it works with systemd as PID 1, the dependency can 
also be satisfied by systemd-sysv.

The best place to add this new dependency seems the 
gnome-settings-daemon, since it directly depends on systemd, which is 
not enough to provide the necessary working dbus interfaces.
Since gdm3 depends on gnome-settings-daemon, this will solve the issue 
in gdm3 menus as well.

I think that according to policy [1] systemd-shim should be Priority: 
optional and not extra, because gnome-settings-daemon is optional and 
packages must not depend on packages with lower priority.

Furthermore I changed the severity to important as I think this bug has 
a 'major effect on the usability' [2].

Best regards,
Andreas

1: http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
2: http://www.debian.org/Bugs/Developer.html

Message #179 received at 726763@bugs.debian.org (full text, mbox, reply):

From: iiNET <darren.w@iinet.net.au>

To: 731602@bugs.debian.org, 726763@bugs.debian.org, 731426@bugs.debian.org, 731686@bugs.debian.org

Subject: Lid close and power button suspend not working

Date: Thu, 16 Jan 2014 21:33:01 +1100

Hi All

Just installed a new laptop with Jessie testing and found that suspend 
events do not trigger suspend action.

Looking through the threads of the included bugs reports there seems to 
be a bit of an overlap so I've CC'ed you all in.

System Information
        Manufacturer: Dell Inc.
        Product Name: Latitude E7240
        amd64

Related Packages
gnome-power-manager                   3.8.2-1
acpi-support-base 0.141-2
acpid                                 1:2.0.20-1
systemd                               204-6
pm-utils                              1.4.1-13
upower                                0.9.23-2+b1

A bit of investigation found that the acpi-support-base scripts have a 
small problem, With the 'su' is in place a call to CheckPolicy from a 
non root account prompts for a password. The following patch fixed the 
password prompt and allowed suspend to initiate.

--- /usr/share/acpi-support/policy-funcs.orig    2014-01-16 
19:24:48.828610060 +1100
+++ /usr/share/acpi-support/policy-funcs    2014-01-16 
19:25:31.169186162 +1100
@@ -44,7 +44,7 @@
         test -r /proc/$p/environ || continue
         DBUS_SESS=$(grep -a -z "DBUS_SESSION_BUS_ADDRESS=" 
/proc/$p/environ || :)
         test "$DBUS_SESS" != "" || continue
-        su $(ps -o user= $p) -s /bin/sh -c "$DBUS_SESS dbus-send 
--print-reply --dest='$DEST' '$DBUS_PATH' '$METHOD'"
+        $DBUS_SESS dbus-send --print-reply --dest='$DEST' '$DBUS_PATH' 
'$METHOD'
     done
 }

The pacth allows the lid to initiate and complete a suspend, the problem 
now is the power button issues a shutdown. gnome-tweak-tool suggests 
that the power button is set to suspend ( this could be a problem with 
my gnome profile though ).

Darren

Message #184 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: darren.w@computer.org, 726763@bugs.debian.org

Cc: iiNET <darren.w@iinet.net.au>, 731602@bugs.debian.org, 731426@bugs.debian.org

Subject: Re: Bug#726763: Lid close and power button suspend not working

Date: Thu, 16 Jan 2014 20:29:49 +0100

Hi,

On 16.01.2014 11:33, iiNET wrote:
> Just installed a new laptop with Jessie testing and found that suspend
> events do not trigger suspend action.
>
> Looking through the threads of the included bugs reports there seems
> to be a bit of an overlap so I've CC'ed you all in.

Have you tried installing systemd-shim or systemd-sysv?

> A bit of investigation found that the acpi-support-base scripts have a
> small problem, With the 'su' is in place a call to CheckPolicy from a
> non root account prompts for a password. The following patch fixed the
> password prompt and allowed suspend to initiate.
>
> --- /usr/share/acpi-support/policy-funcs.orig    2014-01-16
> 19:24:48.828610060 +1100
> +++ /usr/share/acpi-support/policy-funcs    2014-01-16
> 19:25:31.169186162 +1100
> @@ -44,7 +44,7 @@
>           test -r /proc/$p/environ || continue
>           DBUS_SESS=$(grep -a -z "DBUS_SESSION_BUS_ADDRESS="
> /proc/$p/environ || :)
>           test "$DBUS_SESS" != "" || continue
> -        su $(ps -o user= $p) -s /bin/sh -c "$DBUS_SESS dbus-send
> --print-reply --dest='$DEST' '$DBUS_PATH' '$METHOD'"
> +        $DBUS_SESS dbus-send --print-reply --dest='$DEST' '$DBUS_PATH'
> '$METHOD'
>       done
>   }
>
> The pacth allows the lid to initiate and complete a suspend, the problem
> now is the power button issues a shutdown. gnome-tweak-tool suggests
> that the power button is set to suspend ( this could be a problem with
> my gnome profile though ).

This patch does not change anything for me. Suspend on lid close works 
with systemd-shim | systemd-sysv and does not work without one of those 
installed.

Best regards,
Andreas

Message #189 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Z <bugs@theloosespoke.org.uk>, Michael Biebl <biebl@debian.org>

Cc: Debian Bug Tracking System <735591@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <735593@bugs.debian.org>

Subject: Re: Bug#735591: gnome-shell: doesn't suspend on keyboard shortcut

Date: Thu, 16 Jan 2014 20:42:31 +0100

Hi,

On 16.01.2014 19:08, Z wrote:
> This is a problem that only started in jessie testing with gnome 3.8, not in
> wheezy. The keyboard shortcut for suspend
> (fn+esc on my laptop) does not work, and instead locks the screen. It also
> doesn't suspend when closing the lid any-more, but I suspect this is a design
> feature.

This is no feature, but rather a missing dependency of 
gnome-settings-daemon on systemd-shim | systemd-sysv, see [1].
So you can either install systemd-shim or switch your init system to 
systemd, which can be achieved by installing systemd-sysv or adding the 
boot parameter 'init=/bin/systemd'.

> When I have done this and wish to suspend, I have to unlock the screen
> and do it manually through the menu, which does work. I found the same issue on
> someone else’s laptop (different manufacturer) running debian jessie,
> originally KDE, with gnome installed as well. It may be connected to a
> hibernating bug which I also found on both, and will file separately.

The hibernate issue [2] should also be fixed by this dependency.
If you want a suspend/hibernate in the gnome-menu, you can use the 
'Alternative status menu' extension from the package gnome-shell-extensions.

Michael, it would be great if you could add the appropriate dependency 
on systemd-shim | systemd-sysv to gnome-settings-daemon.

Best regards,
Andreas


1: http://bugs.debian.org/726763
2: http://bugs.debian.org/735593

Message #194 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Darren Williams <darren.w@computer.org>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: 726763@bugs.debian.org, 731602@bugs.debian.org, 731426@bugs.debian.org

Subject: Re: Bug#726763: Lid close and power button suspend not working

Date: Fri, 17 Jan 2014 09:20:35 +1100

On 17/01/14 06:29, Andreas Cadhalpun wrote:
> Hi,
>
> On 16.01.2014 11:33, iiNET wrote:
>> Just installed a new laptop with Jessie testing and found that suspend
>> events do not trigger suspend action.
>>
>> Looking through the threads of the included bugs reports there seems
>> to be a bit of an overlap so I've CC'ed you all in.
>
> Have you tried installing systemd-shim or systemd-sysv?
>
>> A bit of investigation found that the acpi-support-base scripts have a
>> small problem, With the 'su' is in place a call to CheckPolicy from a
>> non root account prompts for a password. The following patch fixed the
>> password prompt and allowed suspend to initiate.
>>
>> --- /usr/share/acpi-support/policy-funcs.orig    2014-01-16
>> 19:24:48.828610060 +1100
>> +++ /usr/share/acpi-support/policy-funcs    2014-01-16
>> 19:25:31.169186162 +1100
>> @@ -44,7 +44,7 @@
>>           test -r /proc/$p/environ || continue
>>           DBUS_SESS=$(grep -a -z "DBUS_SESSION_BUS_ADDRESS="
>> /proc/$p/environ || :)
>>           test "$DBUS_SESS" != "" || continue
>> -        su $(ps -o user= $p) -s /bin/sh -c "$DBUS_SESS dbus-send
>> --print-reply --dest='$DEST' '$DBUS_PATH' '$METHOD'"
>> +        $DBUS_SESS dbus-send --print-reply --dest='$DEST' '$DBUS_PATH'
>> '$METHOD'
>>       done
>>   }
>>
>> The pacth allows the lid to initiate and complete a suspend, the problem
>> now is the power button issues a shutdown. gnome-tweak-tool suggests
>> that the power button is set to suspend ( this could be a problem with
>> my gnome profile though ).
>
> This patch does not change anything for me. Suspend on lid close works with systemd-shim | systemd-sysv and does not work without one of those installed.
I'm guessing that sysvinit and systemd-sysv, have a side effect of setting up a difference power management paths.

Installing systemd-sysv, fixes lid and power button suspend. However when the machine boots, the root file system is mounted read only thus gdm3 does not start. Running 'mount / -o remount,rw' allows the startup to continue and gdm3 will start.

Installing upstart, hangs the boot process consistently at "Starting acpi_fakekey...done."

Installing systemd-shim, seems to of given the best result. Lid and power button suspend/resume working, and system boots:)
>
> Best regards,
> Andreas
>
>
I think there needs to be some decisions made by the sysvinit package maintainers on what the preferred init path is.

My install was a vanilla install using the daily disk builds at:
http://d-i.debian.org/daily-images/amd64/daily/netboot/debian-installer/amd64/

From the the install logs the sysvinit package prefers sysvinit-core:

Jan 15 03:35:33 debootstrap:  sysvinit pre-depends on sysvinit-core | upstart | systemd-sysv
Jan 15 03:35:33 debootstrap: dpkg: regarding .../sysvinit_2.88dsf-45_amd64.deb containing sysvinit, pre-dependency problem:
Jan 15 03:35:33 debootstrap:  sysvinit pre-depends on sysvinit-core | upstart | systemd-sysv
Jan 15 03:35:33 debootstrap:   sysvinit-core is not installed.
Jan 15 03:35:33 debootstrap:   upstart is not installed.
Jan 15 03:35:33 debootstrap:   systemd-sysv is not installed.
Jan 15 03:35:33 debootstrap:
Jan 15 03:35:33 debootstrap: dpkg: warning: ignoring pre-dependency problem!
Jan 15 03:35:33 debootstrap: Preparing to unpack .../sysvinit_2.88dsf-45_amd64.deb ...
Jan 15 03:35:33 debootstrap: Unpacking sysvinit (2.88dsf-45) ...
Jan 15 03:35:33 debootstrap: Selecting previously unselected package sysvinit-core.
Jan 15 03:35:33 debootstrap: Preparing to unpack .../sysvinit-core_2.88dsf-45_amd64.deb ...
Jan 15 03:35:33 debootstrap: Unpacking sysvinit-core (2.88dsf-45) ...
Jan 15 03:35:33 debootstrap: Selecting previously unselected package sysvinit-utils.
Jan 15 03:35:33 debootstrap: Preparing to unpack .../sysvinit-utils_2.88dsf-45_amd64.deb ...
Jan 15 03:35:33 debootstrap: Unpacking sysvinit-utils (2.88dsf-45) ...


Hope this helps,
Darren

Message #199 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Darren Williams <darren.w@computer.org>

Cc: 726763@bugs.debian.org, 731602@bugs.debian.org, 731426@bugs.debian.org

Subject: Re: Bug#726763: Lid close and power button suspend not working

Date: Fri, 17 Jan 2014 00:07:04 +0100

Hi,

On 16.01.2014 23:20, Darren Williams wrote:
> I'm guessing that sysvinit and systemd-sysv, have a side effect of
> setting up a difference power management paths.

As far as I understand it, systemd-sysv provides a certain set of dbus 
services for power management, that sysvinit has not, but that can be 
provided by systemd-shim on top of sysvinit (or upstart).

> Installing systemd-sysv, fixes lid and power button suspend. However
> when the machine boots, the root file system is mounted read only thus
> gdm3 does not start. Running 'mount / -o remount,rw' allows the startup
> to continue and gdm3 will start.

This seems to be broken on your system. I don't have such issues using 
systemd-sysv.

> Installing upstart, hangs the boot process consistently at "Starting
> acpi_fakekey...done."

Again it seems something on your machine is badly broken. I switched 
often between sysvinit-core/systemd-sysv/upstart and did not experience 
these problems.

Could you provide some logs (e.g. /var/log/syslog), or even better, a 
way to reproduce this on a fresh install?

> Installing systemd-shim, seems to of given the best result. Lid and
> power button suspend/resume working, and system boots:)

At least this works for you. :)

> I think there needs to be some decisions made by the sysvinit package
> maintainers on what the preferred init path is.

Do you mean that Debian needs to decide what the default init system 
should be? This is currently discussed as bug #727708 [1].

Best regards,
Andreas


1: http://bugs.debian.org/727708

Message #204 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Adrian Immanuel Kiess <adrian@kiess.at>

Cc: Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Fri, 17 Jan 2014 12:04:11 +0100

Hi Adrian,

On 17.01.2014 05:09, Adrian Immanuel Kiess wrote:
>     * What led up to the situation?
>       Trying to restart system via GDM
>     * What exactly did you do (or not do) that was effective (or
>       ineffective)?
>       Clicking {Restart} button
>     * What was the outcome of this action?
>       None
>     * What outcome did you expect instead?
>       System restarting
>
> currently in Debian/testing GDM does not restart the system after clicking
> {Restart}.

This is due to a missing dependency on systemd-shim | systemd-sysv, see [1].
So you can either install systemd-shim or switch your init system to
systemd, which can be achieved by installing systemd-sysv or adding
the boot parameter 'init=/bin/systemd'.

> The root password is asked thou, but no action is taken afterwards.

The strange asking for a root password is tracked in Bug#731882 [2].

> Thank you for your efforts.

Thanks for reporting bugs.

Best regards,
Andreas

1: http://bugs.debian.org/726763
2: http://bugs.debian.org/731882

Message #209 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Adrian Immanuel Kieß <adrian@immanuelk.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Sun, 19 Jan 2014 06:35:53 +0100

[Message part 1 (text/plain, inline)]

Dear Andreas,

installing systemd-shim helped fine.

I'd like to note that GDM3 in Debian/testing now takes a great time to
load and that the console output is not shown right when GDM3 leaves X
mode.

Additionally; I've read on http://www.phoronix.com/ that Debian now
possibly likes to switch to systemd. Is it recommended now to switch to
systemd and install systemd-sysv?

Thank you very much.

With many greetings,

Adrian


On Fri, 2014-01-17 at 12:04 +0100, Andreas Cadhalpun wrote: 
> Hi Adrian,
> 
> On 17.01.2014 05:09, Adrian Immanuel Kiess wrote:
> >     * What led up to the situation?
> >       Trying to restart system via GDM
> >     * What exactly did you do (or not do) that was effective (or
> >       ineffective)?
> >       Clicking {Restart} button
> >     * What was the outcome of this action?
> >       None
> >     * What outcome did you expect instead?
> >       System restarting
> >
> > currently in Debian/testing GDM does not restart the system after clicking
> > {Restart}.
> 
> This is due to a missing dependency on systemd-shim | systemd-sysv, see [1].
> So you can either install systemd-shim or switch your init system to
> systemd, which can be achieved by installing systemd-sysv or adding
> the boot parameter 'init=/bin/systemd'.
> 
> > The root password is asked thou, but no action is taken afterwards.
> 
> The strange asking for a root password is tracked in Bug#731882 [2].
> 
> > Thank you for your efforts.
> 
> Thanks for reporting bugs.
> 
> Best regards,
> Andreas
> 
> 1: http://bugs.debian.org/726763
> 2: http://bugs.debian.org/731882
> 

-- 
With greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Administrator & programmer
Unix / Perl / LaTeX

mail: <adrian (at) kiess.at>
www: http://www.kiess.at

[signature.asc (application/pgp-signature, inline)]

Message #214 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: adrian@kiess.at

Cc: Adrian Immanuel Kieß <adrian@immanuelk.net>, Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Sun, 19 Jan 2014 17:12:54 +0100

Hi Adrian,

On 19.01.2014 06:35, Adrian Immanuel Kieß wrote:
> installing systemd-shim helped fine.

That's great.

> I'd like to note that GDM3 in Debian/testing now takes a great time to
> load and that the console output is not shown right when GDM3 leaves X
> mode.

How long is 'a great time'? Can you make a picture of how the console 
output is wrong?

> Additionally; I've read on http://www.phoronix.com/ that Debian now
> possibly likes to switch to systemd. Is it recommended now to switch to
> systemd and install systemd-sysv?

Currently the answer to this question probably depends strongly on who 
you ask. This will hopefully change soon, when the technical committee 
has made it's decision. [1]
If you don't feel curious about modern init systems, it is possible to 
stay with sysvinit for jessie.
But since GNOME upstream decided to use features provided by systemd 
that only afterwards were available on other init systems via 
systemd-shim, you might want to try out systemd-sysv, as similiar 
upstream changes might happen again. (And a modern init system is an 
improvement over the old sysvinit.)
I hope that helps you.

Best regards,
Andreas


1: http://bugs.debian.org/727708

Message #219 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Darren Williams <darren.w@computer.org>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: 726763@bugs.debian.org, 731602@bugs.debian.org, 731426@bugs.debian.org

Subject: Re: Bug#726763: Lid close and power button suspend not working

Date: Mon, 20 Jan 2014 09:57:53 +1100

Andreas

I just re-installed an older Dell E6400 laptop which results in similar suspend issue. Installing systemd-sysv on the old laptop fixes suspend.

Read below for the solution to the mount problem reported earlier, seems to be an issue with me trying to preserve my home directory.

Let me know if there is any testing you would like me to do.

On 17/01/14 10:07, Andreas Cadhalpun wrote:
> Hi,
>
> On 16.01.2014 23:20, Darren Williams wrote:
>> I'm guessing that sysvinit and systemd-sysv, have a side effect of
>> setting up a difference power management paths.
>
> As far as I understand it, systemd-sysv provides a certain set of dbus services for power management, that sysvinit has not, but that can be provided by systemd-shim on top of sysvinit (or upstart).
>
>> Installing systemd-sysv, fixes lid and power button suspend. However
>> when the machine boots, the root file system is mounted read only thus
>> gdm3 does not start. Running 'mount / -o remount,rw' allows the startup
>> to continue and gdm3 will start.
>
> This seems to be broken on your system. I don't have such issues using systemd-sysv.
>
>> Installing upstart, hangs the boot process consistently at "Starting
>> acpi_fakekey...done."
>
> Again it seems something on your machine is badly broken. I switched often between sysvinit-core/systemd-sysv/upstart and did not experience these problems.
Found the error here, fstab did not have any mount lines only the single line:

# UNCONFIGURED FSTAB FOR BASE SYSTEM

this could be a side effect of me trying to preserve my home dir which sits on the root partition. During the install I delete all the files and directories except for home (Yeah, I know, one should partition better). After adding the appropriate fstab mount entires systemd-sysv boots and also fixes Lid and power button suspend/resume.

>
> Could you provide some logs (e.g. /var/log/syslog), or even better, a way to reproduce this on a fresh install?
>
>> Installing systemd-shim, seems to of given the best result. Lid and
>> power button suspend/resume working, and system boots:)
>
> At least this works for you. :)
>
>> I think there needs to be some decisions made by the sysvinit package
>> maintainers on what the preferred init path is.
>
> Do you mean that Debian needs to decide what the default init system should be? This is currently discussed as bug #727708 [1].
Exactly, at least they are discussing the issue.

>
> Best regards,
> Andreas
>
>
> 1: http://bugs.debian.org/727708
>
Thanks for your help
Darren

Message #224 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Adrian Immanuel Kieß <adrian@immanuelk.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Mon, 20 Jan 2014 04:42:08 +0100

[Message part 1 (text/plain, inline)]

Dear Andreas,

following to your suggestion I installed systemd-sysv and it is really
nice; the system boots much quicker.

As a side note, I had to apt-get purge portmap to make nfs-kernel-server
working again with systemd; but not all of the console output is shown
again while booting up, because of GDM is loading and takes the console
output away.

Installing systemd now fixed the missing console output while shutting
the system down.

Thanks for your help.

With many greetings,

Adrian

On Sun, 2014-01-19 at 17:12 +0100, Andreas Cadhalpun wrote: 
> Hi Adrian,
> 
> On 19.01.2014 06:35, Adrian Immanuel Kieß wrote:
> > installing systemd-shim helped fine.
> 
> That's great.
> 
> > I'd like to note that GDM3 in Debian/testing now takes a great time to
> > load and that the console output is not shown right when GDM3 leaves X
> > mode.
> 
> How long is 'a great time'? Can you make a picture of how the console 
> output is wrong?
> 
> > Additionally; I've read on http://www.phoronix.com/ that Debian now
> > possibly likes to switch to systemd. Is it recommended now to switch to
> > systemd and install systemd-sysv?
> 
> Currently the answer to this question probably depends strongly on who 
> you ask. This will hopefully change soon, when the technical committee 
> has made it's decision. [1]
> If you don't feel curious about modern init systems, it is possible to 
> stay with sysvinit for jessie.
> But since GNOME upstream decided to use features provided by systemd 
> that only afterwards were available on other init systems via 
> systemd-shim, you might want to try out systemd-sysv, as similiar 
> upstream changes might happen again. (And a modern init system is an 
> improvement over the old sysvinit.)
> I hope that helps you.
> 
> Best regards,
> Andreas
> 
> 
> 1: http://bugs.debian.org/727708

-- 
With greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Administrator & programmer
Unix / Perl / LaTeX

mail: <adrian (at) kiess.at>
www: http://www.kiess.at

[signature.asc (application/pgp-signature, inline)]

Message #229 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Darren Williams <darren.w@computer.org>

Cc: 726763@bugs.debian.org, 731602@bugs.debian.org, 731426@bugs.debian.org

Subject: Re: Bug#726763: Lid close and power button suspend not working

Date: Mon, 20 Jan 2014 15:35:32 +0100

Hi Darren,

On 19.01.2014 23:57, Darren Williams wrote:
> I just re-installed an older Dell E6400 laptop which results in similar
> suspend issue. Installing systemd-sysv on the old laptop fixes suspend.

That's good.

> Read below for the solution to the mount problem reported earlier, seems
> to be an issue with me trying to preserve my home directory.
>
> Let me know if there is any testing you would like me to do.

If this works for you now, no further information is needed.

> Found the error here, fstab did not have any mount lines only the single
> line:
>
> # UNCONFIGURED FSTAB FOR BASE SYSTEM

This indeed doesn't look good...

> this could be a side effect of me trying to preserve my home dir which
> sits on the root partition. During the install I delete all the files
> and directories except for home (Yeah, I know, one should partition
> better). After adding the appropriate fstab mount entires systemd-sysv
> boots and also fixes Lid and power button suspend/resume.

I'm glad you could fix it.

Best regards,
Andreas

Message #234 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: adrian@kiess.at

Cc: Adrian Immanuel Kieß <adrian@immanuelk.net>, Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Mon, 20 Jan 2014 16:17:55 +0100

Hi Adrian,

On 20.01.2014 04:42, Adrian Immanuel Kieß wrote:
> following to your suggestion I installed systemd-sysv and it is really
> nice; the system boots much quicker.

;)

> As a side note, I had to apt-get purge portmap to make nfs-kernel-server
> working again with systemd;

This is not really surprising, considering that portmap is only 
available in oldstable...

> but not all of the console output is shown
> again while booting up, because of GDM is loading and takes the console
> output away.

Can you specify which output is missing, e.g. by copying the relevant 
part from /var/log/syslog?

> Installing systemd now fixed the missing console output while shutting
> the system down.

That's strange...
So this seems like a bug in sysvinit-core.

Best regards,
Andreas

Message #239 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Adrian Immanuel Kieß <adrian@immanuelk.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Tue, 21 Jan 2014 09:11:47 +0100

[Message part 1 (text/plain, inline)]

Dear Andreas,

I can't find the missing part in /var/log/syslog. The console output
seem mostly to stop at "Starting fancontrol...".

Regarding to portmap; that's true, but it was not obvious for me at
first that I have to delete the old portmap configuration files to make
rpcbind working again. :-)

I have another small question; Can you tell me how I can set the banner
text in GDM v3.8? I tried with dconf and the configuration files
under /etc/gdm3 but nothing seems to work.

I attached my greetings.gsettings file. It now seems to be ignored by
GDM 3.8.

With many greetings,

Adrian

On Mon, 2014-01-20 at 16:17 +0100, Andreas Cadhalpun wrote: 
> Hi Adrian,
> 
> On 20.01.2014 04:42, Adrian Immanuel Kieß wrote:
> > following to your suggestion I installed systemd-sysv and it is really
> > nice; the system boots much quicker.
> 
> ;)
> 
> > As a side note, I had to apt-get purge portmap to make nfs-kernel-server
> > working again with systemd;
> 
> This is not really surprising, considering that portmap is only 
> available in oldstable...
> 
> > but not all of the console output is shown
> > again while booting up, because of GDM is loading and takes the console
> > output away.
> 
> Can you specify which output is missing, e.g. by copying the relevant 
> part from /var/log/syslog?
> 
> > Installing systemd now fixed the missing console output while shutting
> > the system down.
> 
> That's strange...
> So this seems like a bug in sysvinit-core.
> 
> Best regards,
> Andreas

-- 
With greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Administrator & programmer
Unix / Perl / LaTeX

mail: <adrian (at) kiess.at>
www: http://www.kiess.at

[greeter.gsettings (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #244 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: adrian@kiess.at

Cc: Adrian Immanuel Kieß <adrian@immanuelk.net>, Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Tue, 21 Jan 2014 19:50:44 +0100

Hi Adrian,

On 21.01.2014 09:11, Adrian Immanuel Kieß wrote:
> I can't find the missing part in /var/log/syslog. The console output
> seem mostly to stop at "Starting fancontrol...".

Then you can probably find them in /var/log/boot.log.

> Regarding to portmap; that's true, but it was not obvious for me at
> first that I have to delete the old portmap configuration files to make
> rpcbind working again. :-)

To prevent such problems, I prefer to purge outdated packages as soon as 
they aren't available anymore.

> I have another small question; Can you tell me how I can set the banner
> text in GDM v3.8? I tried with dconf and the configuration files
> under /etc/gdm3 but nothing seems to work.
>
> I attached my greetings.gsettings file. It now seems to be ignored by
> GDM 3.8.

Your greetings.gsettings file looks fine, but you have to reboot for 
changes to take effect.

Best regards,
Andreas

Message #249 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Adrian Immanuel Kieß <adrian@immanuelk.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Wed, 22 Jan 2014 01:24:21 +0100

[Message part 1 (text/plain, inline)]

Dear Andreas,

the missing part is then:

Starting Enable support for additional executable binary formats...
76          Starting LSB: Start acpi_fakekey daemon...
77          Starting LSB: Bluetooth monitoring daemon...
78          Starting LSB: OpenBSD Secure Shell server...
79          Starting LSB: Fetch LDAP SSL public key from the server...
80          Starting Initialize hardware monitoring sensors...
81          Starting /etc/rc.local Compatibility...
82          Starting System Logging Service...
83          Starting Permit User Sessions...
84 [^[[32m  OK  ^[[0m] Listening on Virtual machine lock manager socket.
85 [^[[32m  OK  ^[[0m] Listening on Avahi mDNS/DNS-SD Stack Activation
Socket.
86 [^[[32m  OK  ^[[0m] Listening on GPS (Global Positioning System)
Daemon Sockets.
87 [^[[32m  OK  ^[[0m] Listening on PC/SC Smart Card Daemon Activation
Socket.
88 [^[[32m  OK  ^[[0m] Listening on ACPID Listen Socket.
89 [^[[32m  OK  ^[[0m] Listening on D-Bus System Message Bus Socket.
90          Starting Avahi mDNS/DNS-SD Stack...
91          Starting Login Service...
92          Starting Accounts Service...
93          Starting D-Bus System Message Bus...
94 [^[[32m  OK  ^[[0m] Started D-Bus System Message Bus.
95          Starting LSB: network connection manager...
96          Starting LSB: Light Display Manager...
97          Starting Virtualization daemon...

(taken from /var/log/boot.log)

I'd like to note when I boot with plymouth and I am not exiting plymouth
with [Home] then even the screen suspends and wents off while GDM is
starting up.

I have a lot of problems with the window display managers in
Debian/testing lateley. With XDM I can't even login with any user and
all the other display managers won't execute enlightenment_start and
refuse to open a E17 session.

I did reboot but GDM won't show the banner or the background image set
in greeter.gsettings.

Thank you for your reply,

Adrian


On Tue, 2014-01-21 at 19:50 +0100, Andreas Cadhalpun wrote: 
> Hi Adrian,
> 
> On 21.01.2014 09:11, Adrian Immanuel Kieß wrote:
> > I can't find the missing part in /var/log/syslog. The console output
> > seem mostly to stop at "Starting fancontrol...".
> 
> Then you can probably find them in /var/log/boot.log.
> 
> > Regarding to portmap; that's true, but it was not obvious for me at
> > first that I have to delete the old portmap configuration files to make
> > rpcbind working again. :-)
> 
> To prevent such problems, I prefer to purge outdated packages as soon as 
> they aren't available anymore.
> 
> > I have another small question; Can you tell me how I can set the banner
> > text in GDM v3.8? I tried with dconf and the configuration files
> > under /etc/gdm3 but nothing seems to work.
> >
> > I attached my greetings.gsettings file. It now seems to be ignored by
> > GDM 3.8.
> 
> Your greetings.gsettings file looks fine, but you have to reboot for 
> changes to take effect.
> 
> Best regards,
> Andreas
> 

-- 
With greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Administrator & programmer
Unix / Perl / LaTeX

mail: <adrian (at) kiess.at>
www: http://www.kiess.at

[signature.asc (application/pgp-signature, inline)]

Message #254 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: adrian@kiess.at

Cc: Adrian Immanuel Kieß <adrian@immanuelk.net>, Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Wed, 22 Jan 2014 03:03:48 +0100

Hi Adrian,

On 22.01.2014 01:24, Adrian Immanuel Kieß wrote:
> the missing part is then:
>
> Starting Enable support for additional executable binary formats...
> 76          Starting LSB: Start acpi_fakekey daemon...
> 77          Starting LSB: Bluetooth monitoring daemon...
> 78          Starting LSB: OpenBSD Secure Shell server...
> 79          Starting LSB: Fetch LDAP SSL public key from the server...
> 80          Starting Initialize hardware monitoring sensors...
> 81          Starting /etc/rc.local Compatibility...
> 82          Starting System Logging Service...
> 83          Starting Permit User Sessions...
> 84 [^[[32m  OK  ^[[0m] Listening on Virtual machine lock manager socket.
> 85 [^[[32m  OK  ^[[0m] Listening on Avahi mDNS/DNS-SD Stack Activation
> Socket.
> 86 [^[[32m  OK  ^[[0m] Listening on GPS (Global Positioning System)
> Daemon Sockets.
> 87 [^[[32m  OK  ^[[0m] Listening on PC/SC Smart Card Daemon Activation
> Socket.
> 88 [^[[32m  OK  ^[[0m] Listening on ACPID Listen Socket.
> 89 [^[[32m  OK  ^[[0m] Listening on D-Bus System Message Bus Socket.
> 90          Starting Avahi mDNS/DNS-SD Stack...
> 91          Starting Login Service...
> 92          Starting Accounts Service...
> 93          Starting D-Bus System Message Bus...
> 94 [^[[32m  OK  ^[[0m] Started D-Bus System Message Bus.
> 95          Starting LSB: network connection manager...
> 96          Starting LSB: Light Display Manager...
> 97          Starting Virtualization daemon...
>
> (taken from /var/log/boot.log)

Strange, I can see (using plymouth exited with <Esc>) lines like:
Starting Initialize hardware monitoring sensors...
or
Starting LSB: network connection manager...

> I'd like to note when I boot with plymouth and I am not exiting
> plymouth with [Home] then even the screen suspends and wents off while
> GDM is starting up.

For me the screen goes black (but still is on) for a moment just before 
GDM comes up. Does it really turn off for you?

> I have a lot of problems with the window display managers in
> Debian/testing lateley. With XDM I can't even login with any user and
> all the other display managers won't execute enlightenment_start and
> refuse to open a E17 session.

:(

> I did reboot but GDM won't show the banner or the background image set
> in greeter.gsettings.

I don't understand this. The banner works for me.

Best regards,
Andreas

Message #259 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Adrian Immanuel Kieß <adrian@immanuelk.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Wed, 22 Jan 2014 14:40:40 +0100

[Message part 1 (text/plain, inline)]

Dear Andreas,

yes the screen does indeed turn off for a while while GDM is loading
when I dont't exit plymouth.

Maybe should I purge GDM3 and try over again? I have no clue why GDM
does only works so sluggish for me.

As noted in my last mail, with XDM, KDM and lightdm I can't even start
my xinitrc session, since they refuse to exec enlightenment_start.

I really have no clue where this all comes from, this is why I am asking
on the bugreport list. :-)

To note, my installation is a Debian 5 installation, upgraded to
Debian/testing and running on so far.

I already reported other sometimes strange bugs happening for me, for
example gkrellm seqfaulting when I type an umlaut; I use xmodmap by the
way.

Maybe you have an idea how to make GDM run smoothly again.

Thank you very much,

Adrian


On Wed, 2014-01-22 at 03:03 +0100, Andreas Cadhalpun wrote: 
> Hi Adrian,
> 
> On 22.01.2014 01:24, Adrian Immanuel Kieß wrote:
> > the missing part is then:
> >
> > Starting Enable support for additional executable binary formats...
> > 76          Starting LSB: Start acpi_fakekey daemon...
> > 77          Starting LSB: Bluetooth monitoring daemon...
> > 78          Starting LSB: OpenBSD Secure Shell server...
> > 79          Starting LSB: Fetch LDAP SSL public key from the server...
> > 80          Starting Initialize hardware monitoring sensors...
> > 81          Starting /etc/rc.local Compatibility...
> > 82          Starting System Logging Service...
> > 83          Starting Permit User Sessions...
> > 84 [^[[32m  OK  ^[[0m] Listening on Virtual machine lock manager socket.
> > 85 [^[[32m  OK  ^[[0m] Listening on Avahi mDNS/DNS-SD Stack Activation
> > Socket.
> > 86 [^[[32m  OK  ^[[0m] Listening on GPS (Global Positioning System)
> > Daemon Sockets.
> > 87 [^[[32m  OK  ^[[0m] Listening on PC/SC Smart Card Daemon Activation
> > Socket.
> > 88 [^[[32m  OK  ^[[0m] Listening on ACPID Listen Socket.
> > 89 [^[[32m  OK  ^[[0m] Listening on D-Bus System Message Bus Socket.
> > 90          Starting Avahi mDNS/DNS-SD Stack...
> > 91          Starting Login Service...
> > 92          Starting Accounts Service...
> > 93          Starting D-Bus System Message Bus...
> > 94 [^[[32m  OK  ^[[0m] Started D-Bus System Message Bus.
> > 95          Starting LSB: network connection manager...
> > 96          Starting LSB: Light Display Manager...
> > 97          Starting Virtualization daemon...
> >
> > (taken from /var/log/boot.log)
> 
> Strange, I can see (using plymouth exited with <Esc>) lines like:
> Starting Initialize hardware monitoring sensors...
> or
> Starting LSB: network connection manager...
> 
>  > I'd like to note when I boot with plymouth and I am not exiting
> > plymouth with [Home] then even the screen suspends and wents off while
> > GDM is starting up.
> 
> For me the screen goes black (but still is on) for a moment just before 
> GDM comes up. Does it really turn off for you?
> 
> > I have a lot of problems with the window display managers in
> > Debian/testing lateley. With XDM I can't even login with any user and
> > all the other display managers won't execute enlightenment_start and
> > refuse to open a E17 session.
> 
> :(
> 
> > I did reboot but GDM won't show the banner or the background image set
> > in greeter.gsettings.
> 
> I don't understand this. The banner works for me.
> 
> Best regards,
> Andreas

-- 
With greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Administrator & programmer
Unix / Perl / LaTeX

mail: <adrian (at) kiess.at>
www: http://www.kiess.at

[signature.asc (application/pgp-signature, inline)]

Message #264 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: adrian@kiess.at

Cc: Adrian Immanuel Kieß <adrian@immanuelk.net>, Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Wed, 22 Jan 2014 15:49:39 +0100

Hi Adrian,

On 22.01.2014 14:40, Adrian Immanuel Kieß wrote:
> yes the screen does indeed turn off for a while while GDM is loading
> when I dont't exit plymouth.

Strange.

> Maybe should I purge GDM3 and try over again? I have no clue why GDM
> does only works so sluggish for me.

This may help - at least I think this can't make things worse...

> As noted in my last mail, with XDM, KDM and lightdm I can't even start
> my xinitrc session, since they refuse to exec enlightenment_start.

I just installed lightdm and e17 and started e17 from lightdm. This 
worked for me (although e17 segfaulted shortly after that).

> I really have no clue where this all comes from, this is why I am asking
> on the bugreport list. :-)
>
> To note, my installation is a Debian 5 installation, upgraded to
> Debian/testing and running on so far.
>
> I already reported other sometimes strange bugs happening for me, for
> example gkrellm seqfaulting when I type an umlaut; I use xmodmap by the
> way.
>
> Maybe you have an idea how to make GDM run smoothly again.

If you have free hard disk space, I would recommend you to create a 
fresh jessie installation and see, whether these problems happen there 
as well.
If yes, you know how to reproduce the problem in a fresh installation, 
which might help solving it.
If no, you should think about migrating to the fresh installation.

Best regards,
Andreas

Message #269 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Adrian Immanuel Kieß <adrian@immanuelk.net>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

Cc: Debian Bug Tracking System <735628@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>

Subject: Re: Bug#735628: gdm3: Does not restart system when clicking {Restart}

Date: Sat, 25 Jan 2014 05:42:00 +0100

[Message part 1 (text/plain, inline)]

Dear Andreas,

I guess a fresh installation is not yet an option right now, since it
would make to much effort.

I guess I'll wait until GDM 3.10 hits Debian/testing.

The only thing, if I find some time, I could do is set up a new virtual
installation of Debian/testing.

But you see, you also run into a bug with the display managers. :-)

I hope that an Xorg or DM update will fix things for me.

Also can't await to see E18 in Debian. Maybe your E17 crashes because of
the by default enabled composite manager, I also have to disable the
module for E17.3 because with it enabled things get very slow and
sluggish.

With many greetings,

Adrian

On Wed, 2014-01-22 at 15:49 +0100, Andreas Cadhalpun wrote: 
> Hi Adrian,
> 
> On 22.01.2014 14:40, Adrian Immanuel Kieß wrote:
> > yes the screen does indeed turn off for a while while GDM is loading
> > when I dont't exit plymouth.
> 
> Strange.
> 
> > Maybe should I purge GDM3 and try over again? I have no clue why GDM
> > does only works so sluggish for me.
> 
> This may help - at least I think this can't make things worse...
> 
> > As noted in my last mail, with XDM, KDM and lightdm I can't even start
> > my xinitrc session, since they refuse to exec enlightenment_start.
> 
> I just installed lightdm and e17 and started e17 from lightdm. This 
> worked for me (although e17 segfaulted shortly after that).
> 
> > I really have no clue where this all comes from, this is why I am asking
> > on the bugreport list. :-)
> >
> > To note, my installation is a Debian 5 installation, upgraded to
> > Debian/testing and running on so far.
> >
> > I already reported other sometimes strange bugs happening for me, for
> > example gkrellm seqfaulting when I type an umlaut; I use xmodmap by the
> > way.
> >
> > Maybe you have an idea how to make GDM run smoothly again.
> 
> If you have free hard disk space, I would recommend you to create a 
> fresh jessie installation and see, whether these problems happen there 
> as well.
> If yes, you know how to reproduce the problem in a fresh installation, 
> which might help solving it.
> If no, you should think about migrating to the fresh installation.
> 
> Best regards,
> Andreas

-- 
With greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Administrator & programmer
Unix / Perl / LaTeX

mail: <adrian (at) kiess.at>
www: http://www.kiess.at

[signature.asc (application/pgp-signature, inline)]

Message #276 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: Steve Langasek <vorlon@debian.org>

Cc: debian-ctte@lists.debian.org, pkg-gnome-maintainers@lists.alioth.debian.org, 726763@bugs.debian.org, 727708@bugs.debian.org

Subject: Re: Processed: block 726763 with 727708

Date: Sat, 1 Feb 2014 13:42:23 -0800

On Sat, Feb 01, 2014 at 03:24:47PM -0500, Steve Langasek wrote:
> On Sat, Feb 01, 2014 at 08:09:24PM +0000, Debian Bug Tracking System wrote:
> > Processing commands for control@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 who
> have been arguing against codifying a requirement to support multiple init
> systems in the TC resolution have said they want maintainers to work
> together to provide reasonable support for init systems other than the
> default.
> 
> 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; but as you're not
> a maintainer of the package, that doesn't seem relevant here.

I'm going to attempt to ignore the confrontational tone of your mail, on
the assumption that you can't possibly be proposing that nobody other
than a package maintainer should ever do bug triage for fear of stepping
on the maintainer's toes.  I've done such triage on numerous bugs in the
past, including adjustment of blocks, severity (including RC
severities), and so on, always on the assumption that the maintainer
will agree with the change; that assumption generally holds true.  Bug
metadata is trivially changed or reverted, and we already have informal
policies regarding such metadata, notably the general presumption that
the maintainer can always change it if they disagree, and that they have
the final say.  Thus, implicit in the block added above is the
assumption that the maintainer can trivially change it if they disagree;
if they did so, I certainly would not change it back and play BTS
tennis.

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 reality of the current situation: you explicitly stated in
the bug log of 726763 that systemd-shim was not ready to serve as an
alternative to GNOME (though with different assumptions about how to
resolve that), and you furthermore objected to the suggestion of
resolving the situation by adding a recommends on systemd-sysv.  Thus, I
don't see any obvious action the gnome-settings-daemon maintainer could
take at this point to resolve 726763 without drawing ire.

I would furthermore object strongly to your claim that the block is "an
assertion that you [sic] have no intention of accepting patches from
maintainers of non-default init systems to provide compatibility unless
forced to do so by the TC".  Metadata is a dynamic thing reflecting the
current reality as it stands, and there are no such patches currently on
offer.  Patches that the maintainers find acceptable would certainly be
cause to remove the block (and add the patch tag).

See also Russ's very clear response, which I agree with wholeheartedly;
thank you, Russ.

- Josh Triplett

Message #281 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Josh Triplett <josh@joshtriplett.org>

Cc: debian-ctte@lists.debian.org, pkg-gnome-maintainers@lists.alioth.debian.org, 726763@bugs.debian.org, 727708@bugs.debian.org

Subject: Re: Processed: block 726763 with 727708

Date: Sat, 1 Feb 2014 15:24:54 -0800

[Message part 1 (text/plain, inline)]

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 reality of the current situation: you explicitly stated in
> the bug log of 726763 that systemd-shim was not ready to serve as an
> alternative to GNOME (though with different assumptions about how to
> resolve that), and you furthermore objected to the suggestion of
> resolving the situation by adding a recommends on systemd-sysv.  Thus, I
> don't see any obvious action the gnome-settings-daemon maintainer could
> take at this point to resolve 726763 without drawing ire.

Ok, it seems that wherever I sent my previous note about how I thought this
should be fixed, it didn't actually manage to go to the bug log.  Sorry
about that.

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 addressed by having gnome-settings-daemon Depends: systemd,
systemd-shim | systemd-sysv.

Would the GNOME maintainers be willing to upload such a change?  Or would
they be ok with me NMUing gnome-settings-daemon for it?

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #286 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Josh Triplett <josh@joshtriplett.org>

To: debian-ctte@lists.debian.org, pkg-gnome-maintainers@lists.alioth.debian.org, 726763@bugs.debian.org, 727708@bugs.debian.org

Subject: Re: Processed: block 726763 with 727708

Date: Sat, 1 Feb 2014 16:03:00 -0800

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 before making any drastic changes.  Furthermore, it
> > reflects the reality of the current situation: you explicitly stated in
> > the bug log of 726763 that systemd-shim was not ready to serve as an
> > alternative to GNOME (though with different assumptions about how to
> > resolve that), and you furthermore objected to the suggestion of
> > resolving the situation by adding a recommends on systemd-sysv.  Thus, I
> > don't see any obvious action the gnome-settings-daemon maintainer could
> > take at this point to resolve 726763 without drawing ire.
> 
> Ok, it seems that wherever I sent my previous note about how I thought this
> should be fixed, it didn't actually manage to go to the bug log.  Sorry
> about that.

Thanks for that clarification.  That would explain why I hadn't seen
that mail when I reviewed the full bug log.

> 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 addressed by having gnome-settings-daemon Depends: systemd,
> systemd-shim | systemd-sysv.

While that would DTRT for users with systemd-sysv installed, it will not
work for a majority of current systemd users in Debian, who use systemd
via just the "systemd" package and having init=/bin/systemd on the
kernel command line.  For such users, this change would attempt to
install systemd-shim, which should not happen on systems running
systemd.

Do you have a suggestion for how to solve that, given the constraints
of:

- not having systemd-shim conflict with systemd (since you've stated
  that you'd like to avoid that),
- not causing breakage in the systemd package, and
- not requiring systemd users to install systemd-sysv?

I can think of a few, but none that would be particularly simple to
implement or apply.

Adding "systemd-shim" as an alternative to the current dependency on
systemd could partially work, with the caveat that users who have
systemd installed but are not currently booted into it would experience
breakage.

As an aside, what is the list of interfaces systemd-shim provides?  I
previously had the impression that systemd-shim just provided the
systemd DBus interfaces that logind depended on, but did not provide
org.freedesktop.login1 directly, counting on a forked logind to provide
that on top of systemd-shim.  Are you saying systemd-shim provides
logind's interface directly, and thus satisfies GNOME's full dependency
needs already?

I'd also point out that there's no reason, other than the common issue
of init=/bin/systemd systems (which applies to both orderings) and the
current cloud of uncertainty surrounding init systems in Debian, that
that dependency couldn't also be written "systemd-sysv | systemd-shim".
Bug 727708 blocks one of the two alternatives but not the other, and I
see no reason not to consider both alternatives equally.

- Josh Triplett

Message #291 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Steve Langasek <vorlon@debian.org>, pkg-gnome-maintainers@lists.alioth.debian.org, 726763@bugs.debian.org, 727708@bugs.debian.org, Russ Allbery <rra@debian.org>, Josh Triplett <josh@joshtriplett.org>

Subject: Re: Bug#727708: Processed: block 726763 with 727708

Date: Thu, 06 Feb 2014 18:53:06 +0100

Sorry to add more noise to #727708, but I feel the need to clarify some
accusations that have been made before.

First of all, there's been no malice from our side as you have accused us of in
this thread. As an example, if you look at the last gdm3 and gnome-shell 3.8.x
uploads and their bug reports, you'll see that I tried hard to fix GNOME not
starting on sysvinit and other cases (e.g. custom kernels with different options
to Debian's).

I believe that I got things working for most users (I tested with both systemd
and sysvinit, with and without libpam-systemd...), though it still looks like
some people are having issues. Unfortunately, the bad atmosphere and the various
accusations here and on debian-devel didn't really motivate me to keep working
on that (or other Debian stuff tbh). Thus I've been holding on until the init
system decision is resolved, however that goes.

Now as for your direct question:

On 02/02/14 00:24, Steve Langasek wrote:
> Would the GNOME maintainers be willing to upload such a change?  Or would
> they be ok with me NMUing gnome-settings-daemon for it?

(These are my own thoughts.) I want to see how the TC decides on the init system
question first. Then I'll think about how to move forward on this and other
(related) issues. In any case I'll try to support the default init system, as
well as other inits, provided the TC decides that that is desired and the work
needed and the patches involved are not too invasive (and I may require changes
to be sent upstream first, but that is not different to what I already do in
many cases when I consider it appropriate). This may depend on whether fallback
paths are provided and maintained, on whether alternative implementations of the
required dbus interfaces are provided, and on other technicalities that we will
have to think through...

Looking forward to a final decision on the subject at hand,
Emilio

Message #296 received at 726763@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Vincent Lefevre <vincent@vinc17.net>

Cc: Debian Bug Tracking System <729576@bugs.debian.org>, Debian Bug Tracking System <736880@bugs.debian.org>, Debian Bug Tracking System <726763@bugs.debian.org>, Debian Bug Tracking System <731426@bugs.debian.org>, Debian Bug Tracking System <731602@bugs.debian.org>, Debian Bug Tracking System <731686@bugs.debian.org>, control@bugs.debian.org

Subject: Re: Bug#729576: duplicate of bug #726763

Date: Tue, 06 May 2014 16:44:35 +0200

reassign 736880 libpam-systemd 204-5
reassign 726763 libpam-systemd 204-5
reassign 731426 libpam-systemd 204-5
reassign 731602 libpam-systemd 204-5
reassign 735591 libpam-systemd 204-5
reassign 735593 libpam-systemd 204-5
reassign 735628 libpam-systemd 204-5
forcemerge 729576 736880 726763 731426 731602 735591 735593 735628
thanks

Hi,

On 05.05.2014 14:31, Vincent Lefevre wrote:
> On 2013-12-22 17:38:53 +0100, Vincent Lefevre wrote:
>> But perhaps #726763 is assigned to the wrong package...
>>
>> If #726763 occurs with GNOME and without lightdm, and is the same
>> problem as #729576, then this could confirm that it is a systemd
>> bug.
>
> Now I don't know the current status of #726763, but #729576 seems
> to have been fixed with systemd-shim automatic installation. So,
> retroactively, I suppose that this could have be regarded as a
> bug in libpam-systemd, fixed by the new dependency on
> systemd-sysv | systemd-shim (in libpam-systemd 204-9).

Indeed that fixes #726763 and all the other bugs due to missing 
systemd-sysv or systemd-shim, because gnome-settings-daemon depends on 
systemd and systemd recommends libpam-systemd.

> So, I'm reassigning the bug to libpam-systemd (204-5 was its version
> when I reported the bug). I'll close it in a second time, once the
> reassign has been done.

I'm now merging the other bugs with Bug #729576.

Best regards,
Andreas

Send a report that this bug log contains spam.