bug#30093: Installing python-ipython breaks Gnome on Fedora.

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

* Environment
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.

* Issue
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.


* Version
$: guix --version
guix (GNU Guix) d9a38cc255d853b2694a01b5704c1daedbb56742


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

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

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.

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

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

> 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.

This sounds similar to the following bug:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202

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:

https://lists.gnu.org/archive/html/help-guix/2017-11/msg00031.html
https://lists.gnu.org/archive/html/help-guix/2017-05/msg00161.html

By the way, I found those threads by searching for the bug number 26202
on the email list archives:

https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=26202&submit=Search%21&idxname=help-guix&max=20&result=normal&sort=score

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

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):

> This sounds similar to the following bug:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202
>
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?

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

Please know that introducing wrapper script might cause problems like this one:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29824

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 3736 bytes --]

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

> 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):

I'm not sure this will help.  As you just pointed out, the
classification doesn't really match reality, which limits its
usefulness.

>> This sounds similar to the following bug:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202
>>
> 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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

Chris Marusich <cmmarusich@gmail.com> writes:

> 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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Fis Trivial]

>
> so I
> still think it might be best to deal with the problems on a case by case
> basis.
>

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?

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Maxim Cournoyer]

Hello,

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

>>
>> so I
>> still think it might be best to deal with the problems on a case by case
>> basis.
>>
>
> 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?

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

bug#30093: what manual workaround?

[tomas.almeida]

[-- Attachment #1: Type: text/plain, Size: 3071 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 3410 bytes --]

bug#30093: what manual workaround?

[Carlo Zancanaro]

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:

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

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

bug#30093: what manual workaround?

[tomas.almeida]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 1667 bytes --]

bug#30093: Installing python-ipython breaks Gnome on Fedora.

[Maxim Cournoyer]

Hi,

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

> 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.

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