Cannot log in to GNOME on foreign distro with Guix

  • Open
  • quality assurance status badge
Details
4 participants
  • Carlo Zancanaro
  • Evan Straw
  • Nicolas Goaziou
  • Ricardo Wurmus
Owner
unassigned
Submitted by
Evan Straw
Severity
normal
E
E
Evan Straw wrote on 22 Dec 2020 06:38
(address . bug-guix@gnu.org)
87v9cu4cyg.fsf@gmail.com
Hello,

I'm running Ubuntu 20.04.1 LTS with Guix installed on top as a package
manager.

Toggle snippet (13 lines)
evan@navi:~$ guix describe
Generation 30 Dec 21 2020 13:21:53 (current)
guix f00e68a
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: f00e68ace070fd5240a4b5874e61c26f6e909b6c
personal bd255b1
repository URL: https://git.sr.ht/~estraw/guix-channel
branch: master
commit: bd255b10b22e612971bd8daf9c2ab3d3014a0b7c


One day, I went to log in after rebooting my PC (I had performed a `guix
pull` the same day) and upon entering my password, I was just brought
immediately back to the login screen. Checking the system journal, I
found that gnome-session is outputting several errors like

Toggle snippet (34 lines)
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.A11ySettings'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Color'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.A11ySettings'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Color'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Datetime'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Datetime'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Housekeeping'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Housekeeping'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Keyboard'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Keyboard'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.MediaKeys'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.MediaKeys'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Power'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Power'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.PrintNotifications'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Rfkill'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.ScreensaverProxy'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.PrintNotifications'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Rfkill'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.ScreensaverProxy'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Sharing'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Sharing'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Smartcard'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Smartcard'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Sound'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Sound'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Wacom'
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Wacom'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.XSettings'
Dec 17 22:27:14 navi gnome-session[24407]: gnome-session-binary[24407]: CRITICAL: We failed, but the fail whale is dead. Sorry....
Dec 17 22:27:14 navi gnome-session-binary[24407]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.XSettings'
Dec 17 22:27:14 navi gnome-session-binary[24407]: CRITICAL: We failed, but the fail whale is dead. Sorry....

When I disable the shell script in /etc/profile.d/ that exports
necessary environment variables for Guix, the problem disappears, and I
am able to log in again, which makes me suspect that maybe some of the
environment variables that Guix sets are confusing GNOME somehow. I'm
not sure if it is caused by one of the packages I have installed from
Guix, but I know that when I limit my profile to only Emacs and the
Emacs packages I have installed from Guix, I am able to log in
again. When I add a package (like stumpwm) that needs to set
XDG_DATA_DIRS, the problem seems to reappear. I also was able to
reproduce the problem on another machine I have that runs the same
operating system and also has Guix.

Is this a bug, or is it possible I've just misconfigured something?
Please let me know if I'm missing any needed information and I'll do my
best to provide it.

-- Evan Straw <evan.straw99@gmail.com>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE6f/SZXb4DLdwy+VR9TDDtKKp8G0FAl/hhmcACgkQ9TDDtKKp
8G0dHRAAyKwsWVQKQQqCrcqwBi3TYuAPQPsImGEXwuhaRwN6zQ0DK3RajXlGBptj
EwlUl7Zypgi9NxGIM3gPZ3jYltEwzvawziiWNK2sZNQAoszU3WZO7mWiius9pskq
yfuymF+BOO4P3Pe8bZW/nAfdbo11sUjjTKqcYd5CxhQZEJt4MpFRJ4dDJGNtRc6k
t3pG/ee3CBHfc+88DqjfBDPtBS8tlmwaX+tdw1YiBsyPRXbqtvXExQghTCXidO7+
u48XrIQ4cipYNXr/BersfM3gql4EwDON24RZ2IlCSQU3Vc+WJJrwXQuGFNqvn133
Zy1eRRTw0HerDHmStbK8FMy80DfzZRCyz/Gz4NWgDeldOHLgNF6tCCn821WkKb3U
X5cqTNC5srWpgzU1h1+gyoZDuI3pQZJgWXRvs2/rJyjnfz2m4yYuIAJRVudMV1C6
IpVvmDxGU2rKRwX52sFxawxJBjlsrXfK9u+Qk9JNLsO/l42Se7bWm81o2Ixl4Vxd
rYvvYVJeSWw2nTjJYyJ5ocJH+xC/XVEoFRlmB3RlLqoMIKYXXFskdiptYjysc3ny
h1Z0FP7k7nl2wZvtTjIQ0SpwbmYBengPCLwc/utUrXWqJB/CUf5vEZpQpfiBplT5
dUiWtRVkhowz/75FlTPQ+rKfclQxwZ2lsLJd8O7lmVDuqh7Ccgk=
=Lcpl
-----END PGP SIGNATURE-----

C
C
Carlo Zancanaro wrote on 22 Dec 2020 12:42
(name . Evan Straw)(address . evan.straw99@gmail.com)(address . 45360@debbugs.gnu.org)
87tuseoyn2.fsf@zancanaro.id.au
Hi Evan!

On Tue, Dec 22 2020, Evan Straw wrote:
Toggle quote (3 lines)
> ... When I add a package (like stumpwm) that needs to set
> XDG_DATA_DIRS, the problem seems to reappear. ...

I think I've had this problem in the past. I'm currently running
on a foreign distribution, and I have this in my ~/.profile file:

# XDG_DATA_DIRS often starts off empty, but an empty value is
# interpreted as this value. Loading a profile can set it,
though,
# which effectively ignores the default value. We want it to
# instead add to the default, so we set it here to the default
# value.
if [ -z "$XDG_DATA_DIRS" ]; then
export XDG_DATA_DIRS="/usr/local/share/:/usr/share/"
fi

I think I took the default value from
where it says:

If $XDG_DATA_DIRS is either not set or empty, a value equal to
/usr/local/share/:/usr/share/ should be used.

I hope that helps!

Toggle quote (3 lines)
> Is this a bug, or is it possible I've just misconfigured
> something?

We should consider this a bug, because Guix's attempt to add to
the XDG_DATA_DIRS environment variable clobbers the default value
that foreign distributions are relying on.

We should at least document this in the manual, maybe in "(guix)
Application Setup".

Carlo
R
R
Ricardo Wurmus wrote on 22 Dec 2020 13:34
(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)
87blemnho1.fsf@elephly.net
Carlo Zancanaro <carlo@zancanaro.id.au> writes:

Toggle quote (6 lines)
>> Is this a bug, or is it possible I've just misconfigured something?
>
> We should consider this a bug, because Guix's attempt to add to the
> XDG_DATA_DIRS environment variable clobbers the default value that
> foreign distributions are relying on.

Is this something we can avoid by patching … something to use a
Guix-specific variable? This variable can cause a lot of trouble when
using Guix on foreign distros, but I don’t know how we can prevent
system software from loading stuff from XDG_DATA_DIRS for Guix and vice
versa without renaming the variables.

A related question: should Guix software ignore XDG_DATA_DIRS when set
by the system? Or is it enough to make it respect an *additional*
variable like GUIX_XDG_DATA_DIRS, which we would have Guix set?

Toggle quote (3 lines)
> We should at least document this in the manual, maybe in "(guix)
> Application Setup".

If it’s an easy workaround: yes. But if it’s a bug we can actually fix
I’d rather see it fixed :)

--
Ricardo
N
N
Nicolas Goaziou wrote on 22 Dec 2020 14:40
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87v9cuez7y.fsf@nicolasgoaziou.fr
Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

Toggle quote (22 lines)
> Carlo Zancanaro <carlo@zancanaro.id.au> writes:

>> We should consider this a bug, because Guix's attempt to add to the
>> XDG_DATA_DIRS environment variable clobbers the default value that
>> foreign distributions are relying on.
>
> Is this something we can avoid by patching … something to use a
> Guix-specific variable? This variable can cause a lot of trouble when
> using Guix on foreign distros, but I don’t know how we can prevent
> system software from loading stuff from XDG_DATA_DIRS for Guix and vice
> versa without renaming the variables.
>
> A related question: should Guix software ignore XDG_DATA_DIRS when set
> by the system? Or is it enough to make it respect an *additional*
> variable like GUIX_XDG_DATA_DIRS, which we would have Guix set?
>
>> We should at least document this in the manual, maybe in "(guix)
>> Application Setup".
>
> If it’s an easy workaround: yes. But if it’s a bug we can actually fix
> I’d rather see it fixed :)

I don't think this would be a sufficient workaround anyway. It seems
related to bug 35308 (http://issues.guix.info/35308) where
GI_TYPELIB_PATH is also involved.

Regards,
--
Nicolas Goaziou
E
E
Evan Straw wrote on 30 Dec 2020 03:29
(address . 45360@debbugs.gnu.org)
87ft3okove.fsf@gmail.com
Hello,

I have more information on this bug. Apologies for the delay. I've been
able to narrow the problem down to a single package - when I install
sbcl, I am unable to log in, and when I uninstall sbcl, the problem
disappears, and I am able to log in normally. Even using a profile with
only the sbcl package, the problem occurs. I checked out the package
definition for sbcl and it seems to set both XDG_CONFIG_DIRS and
XDG_DATA_DIRS, so maybe that's where the problem is? I'm not really sure
what causes this, however; that's just a guess.

Hope this helps narrow it down more. If I can provide any more
information please let me know.

-- Evan
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE6f/SZXb4DLdwy+VR9TDDtKKp8G0FAl/r5hUACgkQ9TDDtKKp
8G0WMw/+L5jXNdI85pEagDWKnu1yRDot/N3wTZ0YzpqOpK0+LhOK2T2G/iy4L792
GU72jK5xOI/jlavGEonIJ3XAM7iZx+VZ65198tZGWL/XMAuaiXGcSu3i9smxghPc
aCJaMiF0T2Fd/UE0XfA/RAg8pcNux1XanOXn14EOh4HilCHm2KGIraz4OMsc4IHg
Q/wgDw2v2BC626TAoivmLwTEzhlJHKk2/n0bjKwQA/iGqrw91Cd0lBkPqm066L3x
QDjnV1+hLzGKcuiLwe8h2wjjE33VzTfKQu6TryFZ2B8be3GQViDpci029Sr2enwu
QYuSgv+EyUAv7YVBkmSf5QH6C49UZJJCvA6s3XRyOY87n+IcXfGW5FLlCiti/HTP
M6ISbJGMa3Oj7hmyXh+grBw2+bkKKu52wBgR/SPwETEra27qC10scIAkgh1gPs6b
o1stfP5ogMtKPJ4A60rH6qw6khA8Rg+/xaYC9tfUYATu28QfTg6uc/OQ6k+D+Vq9
TfjCNS4qppLpreCRm12TqRCDQbYWy/aXU0Pibs7NCPvLIhbVMqCrgwfnqGVgd82d
l8Hdd/3bKd3jIJCOZv9UAlwH56eudagix5hPRHwiKFp4evqBo9zFek1BHIV24ZeC
NbUy0W4qnpz4vxckw4clrVBAwb10T5+2gao8tCfWBCAvU8wNaAY=
=soa9
-----END PGP SIGNATURE-----

?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 45360@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 45360
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch