Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2020-02-03 Thread Michael Biebl 
Am 03.02.20 um 08:18 schrieb Yves-Alexis Perez:

> So, if I do that, lightdm.service is not installed at all (it comes from
> debian/, not the upstream sources).

You can install debian/lightdm.service via debian/lightdm.install.



signature.asc
Description: OpenPGP digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2020-02-02 Thread Yves-Alexis Perez 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2020-02-02 at 21:08 +0100, Yves-Alexis Perez wrote:
> > An empty
> > override_dh_installsystemd:
> > 
> > is probably better suited in this case.
> > 
> > Not sure if this fixes the issue you are seeing, just something I
> > noticed while quickly glancing at it.
> 
> I can surely try, at least.

So, if I do that, lightdm.service is not installed at all (it comes from
debian/, not the upstream sources).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl43ySwACgkQ3rYcyPpX
RFtS/ggAiKk4n0acU9JFeB9tJb2IfOVG6wsxFlWfEHDkeyFw2B6Vb8cg3SE4cuUc
aeDyraoJuS5rq2MRU592arHaOaISuWiNRf+cKR6YB+6qZmqvBR4dGxwAuGeMinu0
ZwGrPiElCYb40HknsDQr5f27l812QOqLIpi2VKZxPOvols2MzwC92JHlqNxnCKOU
WPT71s6y+kEKvqiEFV08aQJp9n6RbYT6qM6Xxrqft1ZPiKBgdzdOClDtXsPHgC95
mw+ioLdDBMiLkOosNpHMSCML8xlSESfkTM3yp5NalWdihUR3dKKSyKNP/Vn6MW68
t1Ny9sU5WtTaO69X6rc0eM5lt0odJg==
=YrkR
-END PGP SIGNATURE-

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2020-02-02 Thread Michael Biebl 
Am 02.02.20 um 21:08 schrieb Yves-Alexis Perez:
> On Sun, 2020-02-02 at 21:03 +0100, Michael Biebl wrote:
>> I had a very superficial look at debian/rules
> 
>> override_dh_installsystemd:
>>dh_installsystemd -plightdm --no-start -r lightdm.service
> 
>> I suppose you don't want that.
> 
> To be honest, I think I always followed what other where telling me to do
> here, in order to coordinate with other DM for the shared display-
> manager.service stuff.

Nod. It would probably not be the worst idea if we created a wiki page
with some best practices for how to handle the display-manager.service
symlink in Debian.





signature.asc
Description: OpenPGP digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2020-02-02 Thread Yves-Alexis Perez 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2020-02-02 at 21:03 +0100, Michael Biebl wrote:
> I had a very superficial look at debian/rules
> 
> override_dh_installsystemd:
>dh_installsystemd -plightdm --no-start -r lightdm.service
> 
> I suppose you don't want that.

To be honest, I think I always followed what other where telling me to do
here, in order to coordinate with other DM for the shared display-
manager.service stuff.

> For one, it would unconditionally enable the service, not respecting the
> debconf choice.
> It would also unconditionally remove the display-manager.service symlink
> on purge.
> 
> An empty
> override_dh_installsystemd:
> 
> is probably better suited in this case.
> 
> Not sure if this fixes the issue you are seeing, just something I
> noticed while quickly glancing at it.

I can surely try, at least.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl43LCcACgkQ3rYcyPpX
RFsnEAf9FVMdypIHlJTeizHUypwi0Uh7oR08o7At7RpChSVCoDARL13F6b0nad4s
sA8VeElf+WsFDs4jYTs+8ycIwIKGYxpwRVduQEH4zNFRWdNlfN3t3kS67UncX5cc
uQFu3kuMc2ftYFvF4JsSc2qMSyt1fdv2d6joFUd0ybO/BsMoiv5AEI9aJihUvkP0
Pb5UCNnGjuTYMgie1HQEDer8V3yvRR3msUWxDKTm/DkXZEI8ACLum7+bUIPePOMB
L1Zt+cXkhdn+QU+LZYD80ENpWFolL+2a7gEqFkZmuPijCO7TF/jCjtfufu6A3z+5
LcsToz1N5/FhJ5SpgsmmRHC5pDp8HQ==
=RmX2
-END PGP SIGNATURE-

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2020-02-02 Thread Michael Biebl 
Am 02.02.20 um 20:45 schrieb Michael Biebl:
> Am 02.02.20 um 16:13 schrieb Yves-Alexis Perez:
>> On Sat, 2020-02-01 at 03:21 +0100, Michael Biebl wrote:
>>> They should also add a
>>
>>> [Install]
>>> Alias=display-manager.service
>>
>>> section
>>
>>> to their service file. Which will make sure that if you run
>>> "systemctl enable foo.service", display-manager.service will point at
>>> the desired display manager.
>>
>> Hi Michael, I tried that, but it seems that it has the side effect of making
>> lightdm restart when upgrading, which is not really a good idea when you're
>> actually in a X session.
>>
>> Any idea how to prevent that?
> 
> Can you show me the (complete) postinst code?
> 

I had a very superficial look at debian/rules

override_dh_installsystemd:
   dh_installsystemd -plightdm --no-start -r lightdm.service

I suppose you don't want that.
For one, it would unconditionally enable the service, not respecting the
debconf choice.
It would also unconditionally remove the display-manager.service symlink
on purge.

An empty
override_dh_installsystemd:

is probably better suited in this case.

Not sure if this fixes the issue you are seeing, just something I
noticed while quickly glancing at it.



signature.asc
Description: OpenPGP digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2020-02-02 Thread Michael Biebl 
Am 02.02.20 um 20:45 schrieb Michael Biebl:
> Am 02.02.20 um 16:13 schrieb Yves-Alexis Perez:
>> On Sat, 2020-02-01 at 03:21 +0100, Michael Biebl wrote:
>>> They should also add a
>>
>>> [Install]
>>> Alias=display-manager.service
>>
>>> section
>>
>>> to their service file. Which will make sure that if you run
>>> "systemctl enable foo.service", display-manager.service will point at
>>> the desired display manager.
>>
>> Hi Michael, I tried that, but it seems that it has the side effect of making
>> lightdm restart when upgrading, which is not really a good idea when you're
>> actually in a X session.
>>
>> Any idea how to prevent that?
> 
> Can you show me the (complete) postinst code?
> 

before and after



signature.asc
Description: OpenPGP digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2020-02-02 Thread Michael Biebl 
Am 02.02.20 um 16:13 schrieb Yves-Alexis Perez:
> On Sat, 2020-02-01 at 03:21 +0100, Michael Biebl wrote:
>> They should also add a
> 
>> [Install]
>> Alias=display-manager.service
> 
>> section
> 
>> to their service file. Which will make sure that if you run
>> "systemctl enable foo.service", display-manager.service will point at
>> the desired display manager.
> 
> Hi Michael, I tried that, but it seems that it has the side effect of making
> lightdm restart when upgrading, which is not really a good idea when you're
> actually in a X session.
> 
> Any idea how to prevent that?

Can you show me the (complete) postinst code?



signature.asc
Description: OpenPGP digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2020-02-02 Thread Yves-Alexis Perez 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2020-02-01 at 03:21 +0100, Michael Biebl wrote:
> They should also add a
> 
> [Install]
> Alias=display-manager.service
> 
> section
> 
> to their service file. Which will make sure that if you run
> "systemctl enable foo.service", display-manager.service will point at
> the desired display manager.

Hi Michael, I tried that, but it seems that it has the side effect of making
lightdm restart when upgrading, which is not really a good idea when you're
actually in a X session.

Any idea how to prevent that?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl425xsACgkQ3rYcyPpX
RFvAMwf/Tk4n/O+Do2BtvKCyGlURo4xlofmHtZNlBISDVV+dxAN5jNxwcnjf2D3t
T+65JIJ6sDHWg1DjWSu0Ug6Y0KF3ei3ka7M4di50iMwtn2ULglHg0Z3Prjuyq4bH
CH4JfLXfCIsa62XPSn1tSbUW4KAj+SO1j7CGBhVUf7eixF0anMLP1QC/z+W52z78
CAa4Tf2ODrUip9n4iad10W+pHMD9x8uEIrTAF8Grgro916xcAcyyI9c6BDYRKIAS
Hxj9ZrDen3n5EjN1gXEzFt3hX8o+X6NRoMNRWNCZNGJSo+4s/Y41vwD0a2x1KmUj
mJaXI6l+30ipwGPsWfN0nVBNePA/2Q==
=3gP4
-END PGP SIGNATURE-

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2020-01-31 Thread Michael Biebl 
Control: retitle -1 Improve handling of display-manager.service symlink
Control: clone -1 -2 -3 -4 -5 -6 -7
Control: reassign -1 gdm3
Control: reassign -2 lightdm
Control: reassign -3 sddm
Control: reassign -4 lxdm
Control: reassign -5 xdm
Control: reassign -6 slim
Control: reassign -7 wdm



On Thu, 09 Oct 2014 17:55:18 +0300 Andrei POPESCU
 wrote:
> Package: systemd
> Version: 215-5+b1
> Severity: normal
> 
> Hi,
> 
> # systemctl disable lightdm
> Synchronizing state for lightdm.service with sysvinit using update-rc.d...
> Executing /usr/sbin/update-rc.d lightdm defaults
> Executing /usr/sbin/update-rc.d lightdm disable
> insserv: warning: current start runlevel(s) (empty) of script `lightdm' 
> overrides LSB defaults (2 3 4 5).
> insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
> `lightdm' overrides LSB defaults (0 1 6).
> Removed symlink /etc/systemd/system/display-manager.service.
> # systemctl enable lightdm
> Synchronizing state for lightdm.service with sysvinit using update-rc.d...
> Executing /usr/sbin/update-rc.d lightdm defaults
> insserv: warning: current start runlevel(s) (empty) of script `lightdm' 
> overrides LSB defaults (2 3 4 5).
> insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
> `lightdm' overrides LSB defaults (0 1 6).
> Executing /usr/sbin/update-rc.d lightdm enable
> The unit files have no [Install] section. They are not meant to be enabled
> using systemctl.
> Possible reasons for having this kind of units are:
> 1) A unit may be statically enabled by being symlinked from another unit's
>.wants/ or .requires/ directory.
> 2) A unit's purpose may be to act as a helper for some other unit which has
>a requirement dependency on it.
> 3) A unit may be started when needed via activation (socket, path, timer,
>D-Bus, udev, scripted systemctl call, ...).
> 
> 
> I have to run 'dpkg-reconfigure lightdm' to have lightdm's postinst 
> recreate the display-manager.service symlink, which is not obvious.


I think, the proper solution is, that gdm, lightdm etc
drop this bit from their service file (in case they have added this
previously)

ExecStartPre=/bin/sh -c '[ "$(cat /etc/X11/default-display-manager
2>/dev/null)" = "/usr/sbin/lightdm" ]'

This is not longer necessary, as all relevant x-display-managers ship a
.service file nowadays.

They should also add a

[Install]
Alias=display-manager.service

section

to their service file. Which will make sure that if you run
"systemctl enable foo.service", display-manager.service will point at
the desired display manager.

Cloning, reassigning this bug report.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2017-02-20 Thread Maximiliano Curia 

¡Hola!

El 2014-11-24 a las 13:37 +0100, Didier Roche escribió:
-DEFAULT_SERVICE=/etc/systemd/system/display-manager.service 
+DEFAULT_SERVICE=display-manager.service 
+SERVICE=$(basename $(cat "$DEFAULT_DISPLAY_MANAGER_FILE")).service 
# set default-display-manager systemd service link according to our config 
-if [ "$1" = configure ] && [ -d /etc/systemd/system/ ]; then 
-  if [ -e "$DEFAULT_DISPLAY_MANAGER_FILE" ]; then 
-SERVICE=/lib/systemd/system/$(basename $(cat "$DEFAULT_DISPLAY_MANAGER_FILE")).service 
-if [ -h "$DEFAULT_SERVICE" ] && [ $(readlink "$DEFAULT_SERVICE") = /dev/null ]; then 
-  echo "Display manager service is masked" >&2 
-elif [ -e "$SERVICE" ]; then 
-  ln -sf "$SERVICE" "$DEFAULT_SERVICE" 
-else 
-  echo "WARNING: $SERVICE is the selected default display manager but does not exist" >&2 
-  rm -f "$DEFAULT_SERVICE" 
-fi 
+if [ "$1" = configure ] && [ -x /bin/systemctl ]; then 
+  if [ $(systemctl is-enabled "$DEFAULT_SERVICE") = masked ]; then 
+echo "Display manager service is masked" >&2 
  else 
-rm -f "$DEFAULT_SERVICE" 
+[ -d /run/systemd/system ] && systemctl daemon-reload 
+if [ ! `systemctl enable --force $SERVICE 2>/dev/null` ]; then


This should be written as:
if ! systemctl enable --force $SERVICE 2>/dev/null;

As written it should always fail.

Please note that this snippet only works on systems that have a running 
systemd, thus it may fail when installing it in using debbootstrap, the 
debian installer, using a chroot, etc.


If possible, please tells us what have you tested. I'm also unsure of what 
would systemd do if you are replacing a running display-manager.service, we 
don't systemd to stop the running display-manager (as that's probably being 
used).



+  echo "WARNING: $SERVICE is the selected default display manager but does not have a 
systemd service" >&2


I see that the set of strings used by gdm sddm and lightdm are different. We 
should also sync those.


Happy hacking,
--
"It is practically impossible to teach good programming to students that have
had a prior exposure to BASIC: as potential programmers they are mentally
mutilated beyond hope of regeneration."
-- Edsger W. Dijkstra
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2015-09-30 Thread Michael Biebl 
On Mon, 24 Nov 2014 09:23:22 +0100 Didier Roche  wrote:
> Le 22/11/2014 21:28, Andrei POPESCU a écrit :
> >
> > 2b. Each display manager must add a Conflicts=[all other DMs]
> 
> You don't really need to maintain a long list of Conflicts (which will 
> never be kept up to date). I suggested last wek to the gdm maintainers 
> that we start using the Alias. That enables to have only one DM enable 
> at a time, having systemctl creating the symlink and conflicting when 
> needed. Finally, the postinst maintainer script is easier. Then, you 
> don't really need WantedBy=graphical.target I guess.
> 
> 
> I didn't hear from the gdm3-pkg team yet, let me paste my suggestions:
> 
> ---
> We discussed a little bit today with Martin on providing other display 
> managers like xdm with systemd services.
> 
> I looked at the existing postinst of lightdm and I think we can leverage 
> systemd Alias to keep the exact same functionality, but removing the 
> internal systemd knowledge from the postinst scripts. The end result on 
> disk would be exactly the same than the existing implementation, we just 
> remove the manual handling of symlinks.
> 
> The idea is to add:
> [Install]
> Alias=display-manager.service
> 

Right, this is not a bug in systemd, but in the involved display managers.

They should use dh-systemd --no-enable and add the [Install] section
Didier posted.

Anyone up for checking the existing display manager service file and
file bug reports accordingly.?


Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2014-11-24 Thread Didier Roche 

Le 22/11/2014 21:28, Andrei POPESCU a écrit :


2b. Each display manager must add a Conflicts=[all other DMs]


You don't really need to maintain a long list of Conflicts (which will 
never be kept up to date). I suggested last wek to the gdm maintainers 
that we start using the Alias. That enables to have only one DM enable 
at a time, having systemctl creating the symlink and conflicting when 
needed. Finally, the postinst maintainer script is easier. Then, you 
don't really need WantedBy=graphical.target I guess.



I didn't hear from the gdm3-pkg team yet, let me paste my suggestions:

---
We discussed a little bit today with Martin on providing other display 
managers like xdm with systemd services.


I looked at the existing postinst of lightdm and I think we can leverage 
systemd Alias to keep the exact same functionality, but removing the 
internal systemd knowledge from the postinst scripts. The end result on 
disk would be exactly the same than the existing implementation, we just 
remove the manual handling of symlinks.


The idea is to add:
[Install]
Alias=display-manager.service

to the service unit, and then, replacing the existing postinst symlinks 
dance with only systemctl commands. Here is the commit for lightdm: 
http://bazaar.launchpad.net/~didrocks/lightdm/systemd-alias/revision/2099, 
resulting in a simpler postinst: 
http://bazaar.launchpad.net/~didrocks/lightdm/systemd-alias/view/head:/debian/lightdm.postinst#L72 



Martin agrees that this approach is more decouple from systemd internals 
and I'm here to reach your feedback about it. As the result on disk is 
the same in the end, we don't have to migrate all DMs at the same time 
if you agree with that idea.


I've prepared in case you are in favor of this change a gdm3 debdiif 
(attached), I saw that upstream was shipping for gdm the Alias section, 
so modified the patch + postinst for it.


-

Does it make sense to you?
diff -Nru gdm3-3.14.1/debian/changelog gdm3-3.14.1/debian/changelog
--- gdm3-3.14.1/debian/changelog2014-11-09 18:16:03.0 +0100
+++ gdm3-3.14.1/debian/changelog2014-11-20 09:44:14.0 +0100
@@ -1,3 +1,10 @@
+gdm3 (3.14.1-4) UNRELEASED; urgency=medium
+
+  * debian/patches/92_systemd_unit.patch, debian/gdm3.postinst:
+- Using Alias and systemctl to handle systemd unit alternatives.
+
+ -- Didier Roche didro...@ubuntu.com  Thu, 20 Nov 2014 09:40:25 +0100
+
 gdm3 (3.14.1-3) unstable; urgency=medium
 
   * 18_all_displays_transient.patch: fix autologin for the initial 
diff -Nru gdm3-3.14.1/debian/gdm3.postinst gdm3-3.14.1/debian/gdm3.postinst
--- gdm3-3.14.1/debian/gdm3.postinst2014-04-27 15:07:16.0 +0200
+++ gdm3-3.14.1/debian/gdm3.postinst2014-11-20 09:45:01.0 +0100
@@ -40,21 +40,18 @@
   fi
 fi
 
-DEFAULT_SERVICE=/etc/systemd/system/display-manager.service
+DEFAULT_SERVICE=display-manager.service
+SERVICE=$(basename $(cat $DEFAULT_DISPLAY_MANAGER_FILE)).service
 # set default-display-manager systemd service link according to our config
-if [ $1 = configure ]  [ -d /etc/systemd/system/ ]; then
-  if [ -e $DEFAULT_DISPLAY_MANAGER_FILE ]; then
-SERVICE=/lib/systemd/system/$(basename $(cat 
$DEFAULT_DISPLAY_MANAGER_FILE)).service
-if [ -h $DEFAULT_SERVICE ]  [ $(readlink $DEFAULT_SERVICE) = 
/dev/null ]; then
-  echo Display manager service is masked 2
-elif [ -e $SERVICE ]; then
-  ln -sf $SERVICE $DEFAULT_SERVICE
-else
-  echo WARNING: $SERVICE is the selected default display manager but does 
not exist 2
-  rm -f $DEFAULT_SERVICE
-fi
+if [ $1 = configure ]  [ -x /bin/systemctl ]; then
+  if [ $(systemctl is-enabled $DEFAULT_SERVICE) = masked ]; then
+echo Display manager service is masked 2
   else
-rm -f $DEFAULT_SERVICE
+[ -d /run/systemd/system ]  systemctl daemon-reload
+systemctl enable --force $SERVICE 2/dev/null || true
+if [ $? != 0 ]; then
+  echo WARNING: $SERVICE is the selected default display manager but does 
not have a systemd service 2
+fi
   fi
 fi
 
diff -Nru gdm3-3.14.1/debian/patches/92_systemd_unit.patch 
gdm3-3.14.1/debian/patches/92_systemd_unit.patch
--- gdm3-3.14.1/debian/patches/92_systemd_unit.patch2014-04-27 
14:44:32.0 +0200
+++ gdm3-3.14.1/debian/patches/92_systemd_unit.patch2014-11-20 
09:43:34.0 +0100
@@ -1,8 +1,8 @@
-Index: gdm3-3.12.1/data/gdm.service.in
+Index: gdm3-3.14.1/data/gdm.service.in
 ===
 gdm3-3.12.1.orig/data/gdm.service.in   2014-04-27 14:40:14.210580120 
+0200
-+++ gdm3-3.12.1/data/gdm.service.in2014-04-27 14:43:22.350149176 +0200
-@@ -4,12 +4,15 @@ Conflicts=getty@tty@GDM_INITIAL_VT@.serv
+--- gdm3-3.14.1.orig/data/gdm.service.in
 gdm3-3.14.1/data/gdm.service.in
+@@ -4,10 +4,16 @@ Conflicts=getty@tty@GDM_INITIAL_VT@.serv
  After=systemd-user-sessions.service getty@tty@GDM_INITIAL_VT@.service 
plymouth-quit.service

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2014-11-24 Thread Didier Roche 
Here is an updated version of the patch (ensuring we echo a warning if 
systemctl enable fails) after discussing with Laurent.


There seems to be one case failing due to the autogenerated gdm3 service 
script from the LSB version which is making systemctl enable --force 
gdm3 failing, investigating.


Cheers,
Didier
diff -Nru gdm3-3.14.1/debian/changelog gdm3-3.14.1/debian/changelog
--- gdm3-3.14.1/debian/changelog2014-11-09 18:16:03.0 +0100
+++ gdm3-3.14.1/debian/changelog2014-11-20 09:44:14.0 +0100
@@ -1,3 +1,11 @@
+gdm3 (3.14.1-4) UNRELEASED; urgency=medium
+
+  * debian/patches/92_systemd_unit.patch, debian/gdm3.postinst:
+- Using Alias and systemctl to handle systemd unit alternatives.
+  Closes: #764607
+
+ -- Didier Roche didro...@ubuntu.com  Thu, 20 Nov 2014 09:40:25 +0100
+
 gdm3 (3.14.1-3) unstable; urgency=medium
 
   * 18_all_displays_transient.patch: fix autologin for the initial 
diff -Nru gdm3-3.14.1/debian/gdm3.postinst gdm3-3.14.1/debian/gdm3.postinst
--- gdm3-3.14.1/debian/gdm3.postinst2014-04-27 15:07:16.0 +0200
+++ gdm3-3.14.1/debian/gdm3.postinst2014-11-20 09:45:01.0 +0100
@@ -40,21 +40,17 @@
   fi
 fi
 
-DEFAULT_SERVICE=/etc/systemd/system/display-manager.service
+DEFAULT_SERVICE=display-manager.service
+SERVICE=$(basename $(cat $DEFAULT_DISPLAY_MANAGER_FILE)).service
 # set default-display-manager systemd service link according to our config
-if [ $1 = configure ]  [ -d /etc/systemd/system/ ]; then
-  if [ -e $DEFAULT_DISPLAY_MANAGER_FILE ]; then
-SERVICE=/lib/systemd/system/$(basename $(cat 
$DEFAULT_DISPLAY_MANAGER_FILE)).service
-if [ -h $DEFAULT_SERVICE ]  [ $(readlink $DEFAULT_SERVICE) = 
/dev/null ]; then
-  echo Display manager service is masked 2
-elif [ -e $SERVICE ]; then
-  ln -sf $SERVICE $DEFAULT_SERVICE
-else
-  echo WARNING: $SERVICE is the selected default display manager but does 
not exist 2
-  rm -f $DEFAULT_SERVICE
-fi
+if [ $1 = configure ]  [ -x /bin/systemctl ]; then
+  if [ $(systemctl is-enabled $DEFAULT_SERVICE) = masked ]; then
+echo Display manager service is masked 2
   else
-rm -f $DEFAULT_SERVICE
+[ -d /run/systemd/system ]  systemctl daemon-reload
+if [ ! `systemctl enable --force $SERVICE 2/dev/null` ]; then
+  echo WARNING: $SERVICE is the selected default display manager but does 
not have a systemd service 2
+fi
   fi
 fi
 
diff -Nru gdm3-3.14.1/debian/patches/92_systemd_unit.patch 
gdm3-3.14.1/debian/patches/92_systemd_unit.patch
--- gdm3-3.14.1/debian/patches/92_systemd_unit.patch2014-04-27 
14:44:32.0 +0200
+++ gdm3-3.14.1/debian/patches/92_systemd_unit.patch2014-11-20 
09:43:34.0 +0100
@@ -1,8 +1,8 @@
-Index: gdm3-3.12.1/data/gdm.service.in
+Index: gdm3-3.14.1/data/gdm.service.in
 ===
 gdm3-3.12.1.orig/data/gdm.service.in   2014-04-27 14:40:14.210580120 
+0200
-+++ gdm3-3.12.1/data/gdm.service.in2014-04-27 14:43:22.350149176 +0200
-@@ -4,12 +4,15 @@ Conflicts=getty@tty@GDM_INITIAL_VT@.serv
+--- gdm3-3.14.1.orig/data/gdm.service.in
 gdm3-3.14.1/data/gdm.service.in
+@@ -4,10 +4,16 @@ Conflicts=getty@tty@GDM_INITIAL_VT@.serv
  After=systemd-user-sessions.service getty@tty@GDM_INITIAL_VT@.service 
plymouth-quit.service
  
  [Service]
@@ -20,6 +20,4 @@
 +#BusName=org.gnome.DisplayManager
  StandardOutput=syslog
  StandardError=inherit
--
--[Install]
--Alias=display-manager.service
+

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2014-11-22 Thread Andrei POPESCU 
On Vi, 10 oct 14, 00:10:18, Andrei POPESCU wrote:
 On Jo, 09 oct 14, 17:55:18, Andrei POPESCU wrote:
  
  I have to run 'dpkg-reconfigure lightdm' to have lightdm's postinst 
  recreate the display-manager.service symlink, which is not obvious.
 
 Actually that wasn't enough to re-enable lightdm, in the end I had to 
 resorte to 'dpkg --purge --force-depends' and then install again.

Given also the recent lxdm bug I've been giving this issue more thought 
and here's what I came up with:

1. Keep the current ExecStartPre= hack until systemd has better support 
for this use case[*].

2a. Each display manager must add a WantedBy=graphical.target

2b. Each display manager must add a Conflicts=[all other DMs]

If I'm not mistaken this will ensure that at least one display manager 
is started (because of the WantedBy=), and only one can run at any given 
time (because of the Conflicts=). Which one would actually start would 
still be controlled via /etc/X11/default-display-manager, same as 
before.

systemctl/update-rc.d enable/disable should then Just Work(tm).

If you think the above makes sense I can start testing it with all 
display managers currently handling the display-manager.service symlink.

[*] See #770633 for a possible implementation of this use case

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2014-10-09 Thread Andrei POPESCU 
Package: systemd
Version: 215-5+b1
Severity: normal

Hi,

# systemctl disable lightdm
Synchronizing state for lightdm.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d lightdm defaults
Executing /usr/sbin/update-rc.d lightdm disable
insserv: warning: current start runlevel(s) (empty) of script `lightdm' 
overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `lightdm' 
overrides LSB defaults (0 1 6).
Removed symlink /etc/systemd/system/display-manager.service.
# systemctl enable lightdm
Synchronizing state for lightdm.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d lightdm defaults
insserv: warning: current start runlevel(s) (empty) of script `lightdm' 
overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `lightdm' 
overrides LSB defaults (0 1 6).
Executing /usr/sbin/update-rc.d lightdm enable
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).


I have to run 'dpkg-reconfigure lightdm' to have lightdm's postinst 
recreate the display-manager.service symlink, which is not obvious.


Kind regards,
Andrei


-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: i386 (x86_64)

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

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-53.4
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1
ii  libblkid1   2.25.1-3
ii  libc6   2.19-11
ii  libcap2 1:2.24-6
ii  libcap2-bin 1:2.24-6
ii  libcryptsetup4  2:1.6.6-2
ii  libgcrypt20 1.6.2-4
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsystemd0 215-5+b1
ii  sysv-rc 2.88dsf-53.4
ii  udev215-5+b1
ii  util-linux  2.25.1-3

Versions of packages systemd recommends:
ii  dbus1.8.8-2
ii  libpam-systemd  215-5+b1

Versions of packages systemd suggests:
pn  systemd-ui  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764607: systemd: systemctl does not re-create display-manager.service symlink

2014-10-09 Thread Andrei POPESCU 
On Jo, 09 oct 14, 17:55:18, Andrei POPESCU wrote:
 
 I have to run 'dpkg-reconfigure lightdm' to have lightdm's postinst 
 recreate the display-manager.service symlink, which is not obvious.

Actually that wasn't enough to re-enable lightdm, in the end I had to 
resorte to 'dpkg --purge --force-depends' and then install again.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature