Installing python-ipython breaks Gnome on Fedora.

I am currently running Guix on top of Fedora 26, which comes with Gnome 3.24.2

As recommended(1), I source *~/.guix-profile/etc/profile* in *~/.bash_profile*

to make all the exported variables recognized by login shell.

After installing python-ipython with guix, guix exported the following

variables:

GUIX_GTK3_PATH

PKG_CONFIG_PATH

The next time I login, Gnome was broken, displaying nothing but a black screen,

except for Owncloud client(which is based on Qt). And all the key bindings

are gone.

So, I used tty to move the `source` command from *.bash_profile* to *.bashrc*.

After that, Gnome came back and functions as usual.

$: guix --version

guix (GNU Guix) d9a38cc255d853b2694a01b5704c1daedbb56742

[1]: https://lists.gnu.org/archive/html/help-guix/2017-05/msg00072.html

I tried to find out which environment variable is responsible for breaking

the gnome shell by disabling them in ~/.guix-profile/etc/profile one at a time.

It turns out to be the *GI_TYPELIB_PATH*. After commenting it out in the profile

file my system works as usual.

But then, this variable is not exported by installing ipython(otherwise it will

let me know in the prompt after installation right?), so my guess would be

installing ipython brings in typelib of Gtk, then gnome used the wrong .typelib

file and crashed.

Fis Trivial <ybbs.daans@hotmail.com> writes:

This sounds similar to the following bug:

It has been known for a while that certain environment variables might

cause problems like this if they are not configured "correctly" on a

foreign distribution. What is "correct" depends on the distro, it

seems.

For more discussion about this kind of issue in general, you might be

interested in the following threads:

By the way, I found those threads by searching for the bug number 26202

on the email list archives:

The examples above were specific to Ubuntu and Trisquel (an Ubuntu

derivative), I think. Perhaps you have discovered a new example of this

kind of problem on Fedora. I wonder what Fedora is doing with

GI_TYPELIB_PATH that causes this problem to occur for you?

--

Chris

Maybe we can Maybe we can divide those environment variables into two types:

1. Needed directly by human. For example the *PATH* environment, we use it

to start whatever program from the shell.

2. Environment variables only needed by programs. For examples, the

*PYTHONPATH*, or in this case *GI_TYPELIB_PATH*.

For _type 2_, we can try to wrap every program with a simple script, and

propagate all the needed environment variables from its dependencies to that

wrapping script. This should eliminate the need to put any of those environment

variables into ~/.guix-profile/etc/profile, guaranteeing the safety of these

variables.

But this method won't solve all the problems. For examples *XDG_DATA_DIRS* will

be classified as one of variables that needed by human because we need to use

it to find GUI programs with GUI shell, and it's also needed by some programs

(a script in this case):

To mitigate the problem in above link, which is the problem introduced by

_type 1_ variables, maybe we can treat these environment variables differently.

When guix is updating it to a new value due to change of profile, it should

explicitly append the original value to the upgraded definition (explicitly

means writing it down in expanded form, like "/home/fis/.bin", not $HOME/.bin or

$VARIABLE_NAME). In the above bug, there is no way guix can define the

*XDG_DATA_DIRS* earlier than the distro. (You have to run the distro then

install guix, right?). It's not perfect, but it seems to work.

I don't have any better idea for now. Does anybody know what kind of approaches

are employed by Flatpak and Snap?

Please know that introducing wrapper script might cause problems like this one:

Fis Trivial <ybbs.daans@hotmail.com> writes:

I'm not sure this will help. As you just pointed out, the

classification doesn't really match reality, which limits its

usefulness.

It sounds like you're suggesting that when Guix builds the new profile,

it should take into consideration current value of the user's

environment variables when building the profile. This is not

permissible in the purely functional software deployment model that Guix

follows. The work-around suggested in Bug 26202 is a specific, "impure"

work-around for a specific problem on a specific foreign distribution,

which requires a user to modify their environment outside the scope of

Guix's purely functional model. In general, for any given foreign

distribution, there may be other problems that occur because the

environment variables set by Guix are not formed or used in precisely

the way that the foreign distribution expects. These problems may

require changes that are, in general, impossible for Guix to predict or

(if the solution requires changes that depend impurely on the

environment) impossible for Guix to make without violating the purely

functional model.

I suspect that this class of problem won't be easy to fix generically

from within Guix. Instead, I suspect it's more realistic to look for

solutions on a case-by-case basis. For example, the work-around for Bug

26202 is currently a reasonable solution for that particular issue on

that particular foreign distribution. Even if we might be able to solve

a particular problem like that one by introducing impurities into the

build, I'm not convinced it would fix this class of problems in general.

In any case, I'm afraid that the fact that it would require us to

introduce impurities into the build probably makes it a non-starter for

the reasons I mentioned above.

Of course, if there is a way to solve this class of problem more

generally without introducing impurities, that'd be great. I just can't

think of one at this time.

--

Chris

Chris Marusich <cmmarusich@gmail.com> writes:

There is existing code in Guix that puts things into the store which

depend on things outside of the store. The specific examples I know of

are:

- When Guix downloads source files from the Internet and puts them into

the store.

- When Guix finds Guile modules in the GUILE_LOAD_PATH and puts them in

the store, as a result of using 'with-imported-modules' with a

G-Expression.

- Other code that exists explicitly to add files to the store, such as

the 'local-file' procedure.

In these cases, what winds up in the store ultimately comes from the

outside world. I'm not 100% sure, but I think that when something from

"outside" is put into the store in this way, it's done outside the scope

of a derivation, since derivations should only be able to access files

that exist in the store.

Anyway, this means that technically, we probably could come up with a

solution that takes the current value of an environment variable and

ultimately incorporates it into a build that creates the new profile

generation. However, it doesn't change the fact that this class of

problem will probably continue to occur on foreign distributions, so I

still think it might be best to deal with the problems on a case by case

basis.

--

Chris

I tried to find out what would Fedora set *GI_TYPELIB_PATH* if guix didn't.

It turns out, nothing. If I comment out the line containing *GI_TYPELIB_PATH*

in ~/.guix-profile/etc/profile, the variable won't be exist.

Is there any suggestion for what I can do, to let guix have this variable, while

Fedora wouldn't see it?

severity 30093 important

Hello,

Fis Trivial <ybbs.daans@hotmail.com> writes:

I think a bold, but definitive approach at fixing this problem would be

to never use known environment variables in Guix search paths

specifications.

Instead, we should introduce custom Guix-specific flavors of the same

variables, e.g. GUIX_GI_TYPELIB_PATH. That's more work (need to write

and maintain patches that add those Guix-specific variables along their

regular flavor), but that'd mean we can set all the variables we want

not worrying about breaking a foreign distribution.

What do you think?

Maxim

Hello,

I see people mentioning here that there doesn't seem to be a general solution to be included in Guix for this, but I als do not understand what the particular solution (for my machine, for example) is supposed to be.

I'm a new user to Guix and also not technically very experienced with Linux OS's, so feel free to point me out something obvious I have missed.

I currently have Guix on top of Ubuntu 20.04, and I have this exact problem with XDG_DATA_DIRS being exported on startup of Gnome and breaking it, and i happend when this variable is added to ~/.guix-profile/etc/profile when installing certain packages; the ones detected so far where python-ipython, python-ipykernel and python-notebook.

As far as I unedrstand, when Ubuntu starts up, it runs /etc/profile, which in turn reads through all scripts inside /etc/profile.d. In that dir, we have guix.sh, which I will paste here:

# _GUIX_PROFILE: `guix pull` profile

_GUIX_PROFILE="$HOME/.config/guix/current"

export PATH="$_GUIX_PROFILE/bin${PATH:+:}$PATH"

# Export INFOPATH so that the updated info pages can be found

# and read by both /usr/bin/info and/or $GUIX_PROFILE/bin/info

# When INFOPATH is unset, add a trailing colon so that Emacs

# searches 'Info-default-directory-list'.

export INFOPATH="$_GUIX_PROFILE/share/info:$INFOPATH"

# GUIX_PROFILE: User's default profile

GUIX_PROFILE="$HOME/.guix-profile"

[ -L $GUIX_PROFILE ] || return

GUIX_LOCPATH="$GUIX_PROFILE/lib/locale"

export GUIX_PROFILE GUIX_LOCPATH

[ -f "$GUIX_PROFILE/etc/profile" ] && . "$GUIX_PROFILE/etc/profile"

# set XDG_DATA_DIRS to include Guix installations

export XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"

The culprit in this case seems to be [ -f "$GUIX_PROFILE/etc/profile" ] && . "$GUIX_PROFILE/etc/profile", and this is because it is getting the following two lines from $GUIX_PROFILE/etc/profile which are introduced by installing python-ipython (for example):

export GI_TYPELIB_PATH="${GUIX_PROFILE:-/gnu/store/22lc31mr4h00x5swzk73293pm2xpaahi-profile}/lib/girepository-1.0${GI_TYPELIB_PATH:+:}$GI_TYPELIB_PATH"

export XDG_DATA_DIRS="${GUIX_PROFILE:-/gnu/store/22lc31mr4h00x5swzk73293pm2xpaahi-profile}/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"

In fact, when this happens, the last line in guix.sh is only duplicating what the line inside .guix-profile/etc/profile had already exported:

export XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"

What is the workaround that can be used here?

I only see two possible solutions, which are unsatisfactory to me: * Refrain from installing packages that alter this variable; * Comment all lines inside guix.sh and add . "$GUIX_PROFILE/etc/profile to my .bash_rc file, focing me to open a terminal everytime I want to launch guix installed packages.Is there another alternative for this?

Eagerly awating for feedback on this, as it's completely destroying my workflow; I am never sure when  will install a package that wll break Ubuntu.

Thanks,

Tomás

Hi Tomás,

I'm not certain what your problem is, but I've run into problems

with XDG_DATA_DIRS in the past, and I've added these lines in my

profile script *before* sourcing any Guix profiles:

# 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 see you have this line in your profile script:

but you call this *after* sourcing the Guix profiles, which means

if Guix sets XDG_DATA_DIRS then the fallback case (i.e. including

/usr/local/share and /usr/share) won't have any effect, and the

default paths (which Ubuntu expects) won't end up in the path.

I'm not as familiar with GI_TYPELIB_PATH, but I think it might

need something similar with a default value of

/usr/lib/girepository-1.0 (that's mostly a guess, based on a quick

search of the internet and my local Ubuntu machine).

I hope that helps!

Carlo

Hi Carlo,

Thank you for your answer, but unfortunately I wasn't yet able to solve the situation with your advice, maybe I'm misinterpreting something.

A small clarification first: the "/etc/profile.d/guix.sh" script  installed by the Guix installation script; what I shared in my previous email is exactly as it was installed, so it wasn't myself who modified guix.sh or created those lines.

With the vanilla "/etc/profile.d/guix.sh" script (the one I shared), and after installing ipython with guix, here is the result of echoing my XDG_DATA_DIRS after a reboot, when I log in through a tty (since Gnome breaks and I can't log in there, as discussed):

/home/tomplaa/.guix-profile/share:/home/tomplaa/.guix-profile/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktopNotice that "/home/tomplaa/.guix-profile/share" is repeated, and this is the reason why I previously had written that the last lines in "/etc/profile.d/guix.sh" seemed superfluous to me, because they were appending something that was already there after sourcing the guix profile.

Regarding your suggestion, I tried the following things, all unsuccessful: * modified "/etc/profile.d/guix.sh" with your suggested lines as the beginning of the script; * modified "/etc/profile" with your suggested lines at the beginning of the script; * created a new script "/etc/profile.d/a0.sh" with those lines, so that it would be the first script to be read by the iteration routine called inside "/etc/profile".Is there anything else I should be trying here?

Thanks!

Tomás

Hi,

tomas.almeida@astrolabium.io <tomas.almeida@astrolabium.io> writes:

That's been fixed in guix-install.sh with

23aafc800c9e678662766440916449ec5bbce830 from Philip McGrath (thanks!):

"etc/guix-install.sh: Initialize XDG base directories."

I've confirmed it fixes the original problem, which was that installing

'python-ipython' would break a GDM login to GNOME on Fedora, by

installing the latest Guix via guix-install.sh on a Fedora 33 VM I had

laying around, then 'guix install python-ipython', logout, then re-login

without an issue.

Closing!

--

Thanks,

Maxim