The default /etc/sddm.conf config file provides a section called [XDisplay] (of course this is commented, but one might uncomment if adding something to that section). Such section doesn't exist (probably has changed over the releases), and is now called [X11], as shown by the command sddm --example-config. I provide a revised sddm.conf to be added to the package.
Created attachment 8551 [details] revised sddm.conf revised sddm.conf to be in par with current sddm version.
CC: (none) => marja11Assignee: bugsquad => kde
Keywords: (none) => PATCH
Another issue Giuseppe found is that sddm is using its own Xsetup script instead of /etc/X11/xdm/Xsetup_0, so this would be a good time to fix that as well.
New sddm file added
Status: NEW => RESOLVEDCC: (none) => mageiaResolution: (none) => FIXED
Created attachment 8561 [details] patch for sddm.spec for using /etc/X11/xdm/Xsetup_0
Here is the patch as diff from my local mgarepo for using /etc/X11/xdm/Xsetup_0.
Created attachment 8562 [details] patch for using /etc/X11/xdm/Xsetup_0 Here is the patch as diff from my local mgarepo for using /etc/X11/xdm/Xsetup_0.
Attachment 8561 is obsolete: 0 => 1
Instead of trying to change all the default values why not make the change in the the replacement Xsession we include as Source4. -------------------------- #!/bin/bash -login exec /etc/X11/Xsession $* # Xsession ends here -------------------------- why not just make the changes to it -------------------------- #!/bin/bash -login exec /etc/X11/xdm/Xsetup_0 $* # Xsession ends here -------------------------- We also build and ship it with a modified sddm.conf (Source6). Any changes to the defaults we decide to make can be done in this file just as is currently being done to make these changes from /etc/sddm.conf.rpmnew #### Mageia-specific configuration [Users] MinimumUid=500 # hide system users # system users using real shells and hence cannot be hidden via HideShells HideUsers=mysql,apache,mldonkey HideShells=/sbin/nologin,/bin/false,/usr/sbin/nologin,/bin/true [Theme] # use our new custom theme without a userlist Current=mga-coffee # use our custom theme based on Maui but with default Mageia background # Current=mga-maui # maui is the default theme, when none is specified #Current=maui #Current=maldives #Current=elarun #Current=numix #Current=circles # allow display of user icons from a central system location # requires accountsservice to be installed which is not the default # FacesDir=/var/lib/AccountsService/icons/
CC: (none) => cae
Well, I thought it would be more polished to have it configurable in Cmake and then eventually later one can customize the /etc/sddm.conf. Or there could be some utility which might need to it, such as "mageia-prime" package for using the nvidia prime (to which I'm working on). Apart this IMHO Xsession is right to be executed there as it points already to exec /etc/X11/Xsession "*" (maybe one can use $@ instead of $*, but doesn't hurt). An alternative would be to add in the sddm.conf file BTW, there is still something to fix, as I was getting dbus errors, with that patch, I've to revise the paths probably or /etc/X11/Xsession is not good...
I mean that Xsetup_0 shouldn't be executed as replacement of Xsession, but both.
This is weird: changing Xsession from /usr/share/sddm/scripts/Xsession, which just does a exec /etc/X11/Xsession to directly calling /etc/X11/Xsession, would result in a dbus error at startup. (i.e. by either changing in the CMAKE building commandline OR in sddm.conf, using: [X11] SessionCommand=/etc/X11/Xsession what's wrong? The missed "bash -login?"
It 's possible that it's the missing "bash -login?" Since you are already screwing with your system what happens if, in the custom sddm.conf you set [X11] SessionCommand=/usr/share/sddm/scripts/Xsession DisplayCommand=/usr/share/X11/xdm/Xsetup_0
Ok, with [X11] SessionCommand=/usr/share/sddm/scripts/Xsession DisplayCommand=/usr/share/X11/xdm/Xsetup_0 works, so probably is the login shell which causes some extra /etc/profile.d/* script to be executed?
Created attachment 8572 [details] patch for using /etc/X11/xdm/Xsetup_0 This patch works better, and uses /usr/share/sddm/scripts/Xsession for SessionCommand and /usr/share/X11/xdm/Xsetup_0 for DisplayCommand.
Attachment 8562 is obsolete: 0 => 1
If you patch it in that manner it means that sddm MUST require xdm. My preference, and I think a better way, would be to include a copy of the file Xsetup_0, renamed to Xsetup, as Source5, and to install it just as is being done with Xsession --- sddm.spec~ 2016-10-18 14:36:56.000000000 -0400 +++ sddm.spec 2016-10-18 14:45:12.000000000 -0400 @@ -15,6 +15,8 @@ Source3: 11sddm.conf # Xsession script Source4: Xsession +# Xsetup script stolen from xdm's Xsetup_0 +Source5: Xsetup # default /etc/sddm.conf, created from man sddm.conf # similar can be obtained via sddm --example-config # show users with UID >= 500 and hide system users @@ -82,6 +84,8 @@ # replace upstream Xsession script install -Dpm755 %{_sourcedir}/Xsession data/scripts/Xsession +# replace upstream Xsetup script +install -Dpm755 %{_sourcedir}/Xsetup data/scripts/Xsetup %build # set UID_MIN and UID_MAX here as autodetection from /etc/login.defs is not ------------------------------------------------------------------------------ No patch is needed, no xdm require is needed, and no sddm.conf defaults are changed.
AFAIK Xsetup_0 is part of xinitrc package, which is the same package providing Xsession and is already in Requires for current sddm. Isn't better to have something which works with common xinitrc? BTW, I also noticed sddm has a support fo Xephyr, which is not in Requires. Though I've never used Xephyr. G.
(In reply to Charles Edwards from comment #14) > If you patch it in that manner it means that sddm MUST require xdm. Too much xdm on the mind file is of course provided by xinitrc
Yep, too much scripts back and forth, that it's difficult to disentangle... It would be fine to have a map (maybe graphic) of what is called when X starts, from the systemd launching prefdm to the desktop starting, for the various desktop and login managers. Maybe prefdm could be add a debug which calls the display mananger under strace and then save the trace of any open/access/etc.; or is there something more graceful?
I did a build removing the Xsession Source4 and using links instead. Even tested it and it works well for me and again all upstream default paths remain the same. --- sddm.spec~ 2016-10-18 14:36:56.000000000 -0400 +++ sddm.spec 2016-10-18 16:36:29.000000000 -0400 @@ -12,9 +12,7 @@ Source1: sddm.pam Source2: sddm-autologin.pam # Adds sddm to drakedm -Source3: 11sddm.conf -# Xsession script -Source4: Xsession +Source3: 11sddm.conf # default /etc/sddm.conf, created from man sddm.conf # similar can be obtained via sddm --example-config # show users with UID >= 500 and hide system users @@ -80,8 +78,10 @@ # sed -i -e 's,\(^background=\).*,\1%{_datadir}/mga/backgrounds/default.jpg,' data/themes/*/theme.conf -# replace upstream Xsession script -install -Dpm755 %{_sourcedir}/Xsession data/scripts/Xsession +# replace upstream Xsession and Xsetup scripts +rm -f data/scripts/{Xsession, Xsetup} +ln -sf /usr/share/X11/xdm/Xsession data/scripts/Xsession +ln -sf /usr/share/X11/xdm/Xsetup_0 data/scripts/Xsetup %build # set UID_MIN and UID_MAX here as autodetection from /etc/login.defs is not ----------------------------------------------------------------------------
seems good.
I agree with the solution, but if you're going to replace regular files with symlinks, you need a %pretrans in the package to delete the old regular files, otherwise you'll get file conflicts when upgrading.
CC: (none) => luigiwalser
Like this? --- sddm.spec (revision 1063332) +++ sddm.spec (working copy) @@ -164,6 +164,15 @@ %_preun_service sddm %endif +%pretrans +if [ -L %{_datadir}/sddm/scripts/Xsetup ]; then + %{__rm} -f %{_datadir}/sddm/scripts/Xsetup +fi + +if [ -L %{_datadir}/sddm/scripts/XSession ]; then + %{__rm} -f %{_datadir}/sddm/Xsession ] +fi + %files %attr(700,sddm,sddm) %{_localstatedir}/lib/%{name}/ %config(noreplace) %{_sysconfdir}/sddm.conf
almost, it'd be if [ ! -L
Created attachment 8589 [details] add use of %pretrans for potential problems during upgrades
(In reply to David Walser from comment #20) > I agree with the solution, but if you're going to replace regular files with > symlinks, you need a %pretrans in the package to delete the old regular > files, otherwise you'll get file conflicts when upgrading. There is no conflict! The files are being replaced in the upstream source directory. The files list included in the rpm Remains The Same.
Well, that's wrong then. The symlinks should be installed in the buildroot, not the source directory. We don't want to be installing *copies* of the Xsetup and Xsession files that could get out of sync with the system ones.
Read and understand the sddm.spec The Xsession and Xsetup files in the build dir data/scripts/ are being replaced by links named the same that point to the Xsession and Xsetup_0 belonging to xinitrc. Within the sddm rpm there is no conflict and no pretrans needed as the file names remain the same and they will always point to the installed up-to-date version in xinitrc.
Charles, please quite talking in circles. It isn't clear from the SPEC what's happening, and without reading the installation scripts in the package source, it isn't evident whether it's installing the symlinks that are created in the BUILD dir (in which case the %pretrans is needed) or if it's following the symlinks and installing copies of the scripts, which would be wrong.
To make the SPEC file more robust, we could move the linking of those scripts from the %build to the at the %install stage, towards the ends; in this way should the installer be more weak with copying symlinks, we won't break the package in future releases, like this: --- sddm.spec (revision 1063332) +++ sddm.spec (working copy) @@ -1,4 +1,4 @@ -%define rel 9 +%define rel 10 Name: sddm Version: 0.14.0 @@ -79,10 +79,6 @@ # instead, a separate Mageia theme is created further below and used by default # sed -i -e 's,\(^background=\).*,\1%{_datadir}/mga/backgrounds/default.jpg,' data/themes/*/theme.conf -# replace upstream Xsession and Xsetup scripts with the same links from the xinitrc package. -rm -f data/scripts/{Xsession,Xsetup} -ln -sf /usr/share/X11/xdm/Xsession data/scripts/Xsession -ln -sf /usr/share/X11/xdm/Xsetup_0 data/scripts/Xsetup %build # set UID_MIN and UID_MAX here as autodetection from /etc/login.defs is not @@ -147,6 +143,11 @@ #### %endif +# replace upstream Xsession and Xsetup scripts with the same links from the xinitrc package. +rm -f %{buildroot}/%{_datadir}/sddm/scripts/{Xsession,Xsetup} +ln -sf ../../../../%{_datadir}/X11/xdm/Xsession %{buildroot}%{_datadir}/sddm/scripts/Xsession +ln -sf ../../../../%{_datadir}/X11/xdm/Xsetup_0 %{buildroot}%{_datadir}/sddm/scripts/Xsetup + # install default sddm.conf install -Dpm 644 %{_sourcedir}/sddm.conf %{buildroot}%{_sysconfdir}/
(In reply to David Walser from comment #27) > Charles, please quite talking in circles. It isn't clear from the SPEC > what's happening, and without reading the installation scripts in the > package source, it isn't evident whether it's installing the symlinks that > are created in the BUILD dir (in which case the %pretrans is needed) or if > it's following the symlinks and installing copies of the scripts, which > would be wrong. I am not speaking in circles. You are saying that file symlinks must be handled in the same manner as directory symlinks. %pretrans Are always needed when|if you add|change directory symlinks to prevent 'cpio: rename' errors and failed installation. They Are Not needed if you are adding|changing links to a file. These will install|update normally.
No Charles, that's incorrect. Any file type mismatch, be it regular file, symlink, or directory, will cause rpm errors. Giuseppe, yes, fixing it in %install with symlinks installed in the buildroot, with the %pretrans, is the correct solution.
(In reply to Giuseppe Ghibò from comment #28) > To make the SPEC file more robust, we could move the linking of those > scripts from the %build to the at the %install stage, towards the ends; in > this way should the installer be more weak with copying symlinks, we won't > break the package in future releases, like this: Even moved it to after %install they still dangling links. You are the packager so it is your choice. My position to doing it as a %pretrans has already stated.
Indeed I think that I've a better solution, move the soft link from the build section to the %install section and installing in %{buildroot}, and in this patch. In this way we bypass the "Makefile install" process, which could either copy the links or maybe copy the content of the link (i.e. following/expanding) and thus producing a "copy" of the content. Indeed should the "Makefile install" follows the symlinks, would probably produce an error, because "xinitrc" is in Requires: but not in BuildRequires:, so the chroot/iurt/mock shouldn't have the xinitrc package installed at the time of building and then can't expand the content of the link. What remain ambiguous is the position of %pretrans; i.e. the files in /usr/share/sddm/scripts/{Xsetup,Xsession} are not marked as %config, so they can't be moved by any %pre or %post scripts, they can be only be deleted or upgraded. Because according to this also xinitrc which is for instance using symlinks in the same manner from /etc/X11/xdm/<scripts> to /usr/share/x11/xdm/<scripts> (though they are all internal to te package and not dangling) and thus should have a %pretrans. In other words, once we are sure that the links are in the %buildroot, which kind of conflicts we should get on upgrading? Is there a test case?
Created attachment 8590 [details] move the symlinks to the %install sections
Created attachment 8591 [details] move the symlinks to the %install section and add %pretrans
(In reply to David Walser from comment #30) > No Charles, that's incorrect. Any file type mismatch, be it regular file, > symlink, or directory, will cause rpm errors. Would you be so kind as to point me to 2 other rpm specs where this is done|required because of a file symlink.
Giuseppe, the issue is that the file type is changing from regular files in the older version of the package, to symlinks in the newer one, so you need a %pretrans scriptlet to remove the regular files.
I attached the two versions, one with %pretrans and one without. The %pretrans would run only once, at the time of the "transition" between files and soft links, as in the future, once the links are already translated to links, the "if [ ! -L ...]" would prevent future removing of the links, unless those made by the rpm %files section itself.
s/once the links are already translated to links/once the files are already translated to links/
Created attachment 8599 [details] preserve original sddm Xsession scripts I think it would be worthwhile to preserve also the original sddm scripts, they can be used as last resource for instance adding: [X11] SessionCommand=/usr/share/sddm/scripts/Xsession.sddm otherwise files remain there and won't interfere with current startup process. OK, that customizing sddm.conf like that would bypass a lot of our xinitrc initialization but is very useful for debugging purpose against upstream sddm (for instance for bug https://bugs.mageia.org/show_bug.cgi?id=18199). WDYT?
I'm beginning to question why we stopped simply using the upstream scripts. I rebuilt and installed sddm that uses the upstream Xsession and Xsetup and Not those provided in xinitrc. I saw no issues with it starting or with launching the desired WM. The login menu list all installed WMs, and that means nearly All WMs. Did not specificly try them all but did easily login to plasma, all 3 gnomes, both cinnamons, mate, and lxde.
Indeed apparently the proper sddm internal scripts works but also may bypass some stuff that were added (over the years) in the xinitrc scripts. I also found the origin of the bug #18199, it's due to the way the first argument is passed (or the ambiguity), and the use or the ambiguity of the $DESKTOP env var in /etc/X11/Xsession. I've a fix/hack/workaround for that. BTW, I also found another bug common to ALL the init scripts, and is the usage of the xrdb -merge; such option would not "merge" the entries to the xrdb, rather they discards. I'll provide a test case. Indeed this is not important as "fixing" in the right way might produce some side effect that now there isn't with the bugged version.
Anyway that's the reason why I suggested to have the sddm's classic Xsession, dormiant, renamed to Xsession.sddm. For the bug https://bugs.mageia.org/show_bug.cgi?id=18199 I attached there the fixes, actually it works with GNOME, GNOME-classic, Plasma, LXDE, OpenBox, WindowMaker. I noticed also that the original sddm's Xsession execute scripts in /etc/X11/xinit/xinitrc.d/* (and this is part of systemd), while Mageia's Xsession in /etc/X11/xinit.d/* (and is part of xinitrc).