Cannot log in to GNOME on foreign distro with Guix

Hello,

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

manager.

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

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>

Hi Evan!

On Tue, Dec 22 2020, Evan Straw wrote:

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!

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

Carlo Zancanaro <carlo@zancanaro.id.au> writes:

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?

If it’s an easy workaround: yes. But if it’s a bug we can actually fix

I’d rather see it fixed :)

--

Ricardo

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

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

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

Hi, folks! I can see that the last comment is back in 2020.

Is there anyone involved in related development that still considers this bug? Today, in 2024, four years later, I can see the bug is not fixed.

Yesterday, I &nbsp;ran guix install gcl sbcl. After a logout, I was unable to login. First, I thought I messed up something by accident so I used timeshift to roll back my machine. After the fix I installed gcl and sbcl again, then when I started my machine, the same problem occured! It took my more than 5 reboots to found out that it is the sbcl installed via guix that broke gnome somehow. After guix remove sbcl, the problem is gone!&nbsp;

does anyone have some idea about a fix or walkaround? This is absolutely a bug, and since gnome is popular fossware, I would regard it as an urgent bug that forces people not to use sbcl via guix.&nbsp;

If the bug is not easily fixable in the near future, a note in the package description is needed, warning people not to use the package if they are using gnome.

--Jack