Installing python-ipython breaks Gnome on Fedora.

  • Done
  • quality assurance status badge
Details
6 participants
  • Carlo Zancanaro
  • Chris Marusich
  • Ludovic Courtès
  • Maxim Cournoyer
  • tomas.almeida@astrolabium.io
  • Fis Trivial
Owner
unassigned
Submitted by
Fis Trivial
Severity
important
F
F
Fis Trivial wrote on 12 Jan 2018 22:32
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
DM5PR16MB00596FB3BFDAA834B8F84EC692170@DM5PR16MB0059.namprd16.prod.outlook.com
* 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
F
F
Fis Trivial wrote on 13 Jan 2018 22:39
(name . 30093@debbugs.gnu.org)(address . 30093@debbugs.gnu.org)
MWHPR16MB0063CDD625964B3F1D8F044092140@MWHPR16MB0063.namprd16.prod.outlook.com
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.
C
C
Chris Marusich wrote on 14 Jan 2018 01:36
(name . Fis Trivial)(address . ybbs.daans@hotmail.com)(name . 30093@debbugs.gnu.org)(address . 30093@debbugs.gnu.org)
871sitcm4j.fsf@gmail.com
Fis Trivial <ybbs.daans@hotmail.com> writes:

Toggle quote (11 lines)
> 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:


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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlpapfwACgkQ3UCaFdgi
Rp0RGRAAxAkHygHeQLfH4MrhH4elKI3tUJvDeo7uQIh+0M9h5cAWUQquMGGSoDFl
13jaXDZF8yxKNUyZ+CbCDlqHVxNXLJmpPUZR8ufiBA4wMm4WlcCsjQ+FULoCXQr7
mUdaQKxA94zg1m7BSQMuAtgNBNEai2CvkxvVL3VaQQKqBHIPWQ2zU4N6PUTOAdi+
VGxvL49oBwqV9YMUr5PI35VO9VDLVBHjNgjenNwVD9IBlWGA+/8QGbCkM47unv9m
BGHbX1EoHHpLHexPHdf06i7SKUl7O4lCUIzqDEPnDylc0z7OB5NNaX8X00BHJVlb
AI3WpupeBVm+29ZCtFROcsObCEwcAOfhc7/MAjteW1Q27exQS1IZ/m9y5xE6Qw02
5kjvLEbMhLCevLpThaSzPxmflwsNIupzlDxCyV0jpYBiPDyUbBbxIAiX5dY4MxD1
V9u/myiGit7/UqaWmP/r5gr1bscC57lyE5PTJQAicEiqxA+5pJgMuBUFHCcaKuRZ
SoOUTVm+3bfLPAuszQhrC4KYqdprpITioeDxQ2MIbi3dMmMmpk2uUcKPDcf6oEY8
s8OHNN3BFh5emUJz/bN6N2Ow/vT9M61emGIcw52RZiKcNznZe5tKt8Ph2wXNG79C
2aNvftCKYW230iIZxB8liJZwUGAdthzCB2QVllj6H6YI9Es2hNw=
=D/rW
-----END PGP SIGNATURE-----

F
F
Fis Trivial wrote on 14 Jan 2018 19:31
(name . Chris Marusich)(address . cmmarusich@gmail.com)(name . 30093@debbugs.gnu.org)(address . 30093@debbugs.gnu.org)
MWHPR16MB006339CA06E01E82683F357092150@MWHPR16MB0063.namprd16.prod.outlook.com
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):
Toggle quote (4 lines)
> 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?
F
F
Fis Trivial wrote on 14 Jan 2018 20:01
(name . Chris Marusich)(address . cmmarusich@gmail.com)(name . 30093@debbugs.gnu.org)(address . 30093@debbugs.gnu.org)
MWHPR16MB006392318D89AA21F0196EAD92150@MWHPR16MB0063.namprd16.prod.outlook.com
Please know that introducing wrapper script might cause problems like this one:
C
C
Chris Marusich wrote on 14 Jan 2018 23:25
(name . Fis Trivial)(address . ybbs.daans@hotmail.com)(name . 30093@debbugs.gnu.org)(address . 30093@debbugs.gnu.org)
876084dqmr.fsf@gmail.com
Fis Trivial <ybbs.daans@hotmail.com> writes:

Toggle quote (17 lines)
> 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.

Toggle quote (13 lines)
>> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlpb2OwACgkQ3UCaFdgi
Rp1ATBAAwAui9DKp4jXn8RUerVeQs5hedbLYXe/atup4fuoqqYfqwnXvHyUfuqEv
uAOK/N80dk8V+H2qUQmsri6JxE4OnHaOh932KBLDY2Bx4DOX2oxfo9bDMXnxxmHy
7RpvxrI5p4xHprUxtnlKJ4vgkKRo846tqxllw2HnagARb03H1tWwCdNazK2CIQF9
1IePWIHFhmWIod1FwAQZZ4l1FRNJwD738NqsZfVysWL8Urg1wfbrtgRuGckuBfhz
REE4NvdBCYeeONdvlDdjac+edzwMYedE/kHGNe5eKWv+O/TCf+BiBkHsr2C56lst
mJBZZhAB9Jc9BVBK0KIthuq7ehbNLZi6//Hnm4Y0D0gh9AaNUx/jIXprFMjnjr/q
hgu+zvFRghnUqxZVj6yJl63Mt7QJuDnjXKvn11aCCg+dtfdAM30vRp19L/PaCvHA
KHl1lng5irjsBPZDXGxu6YG8gtpAuI0b4gvhC+tu9TReQ7IWofFByXg0+Tp/EqCg
f9n1S8GTLq8xLrxvFTviwP19h1dTJPnPKL4lquLmzgfovAwQ2cVXZYNrqrXHykH/
uh4TzalrtGUk+IwjL3TkadyuNpG/wDn54dFcChYGjNkx+LtH2DuPKp9Y75nEsoGD
kVgE+pMZcNH/uRMxkM9DQ7yBoE5pPIvAl5B09ZxSw8JeiLyTJgE=
=4KLO
-----END PGP SIGNATURE-----

C
C
Chris Marusich wrote on 15 Jan 2018 01:45
(name . Fis Trivial)(address . ybbs.daans@hotmail.com)(address . 30093@debbugs.gnu.org)
87po6cc5ma.fsf@gmail.com
Chris Marusich <cmmarusich@gmail.com> writes:

Toggle quote (4 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlpb+Y0ACgkQ3UCaFdgi
Rp2zMRAAqtUktuf0qFunNaHkm7nu9USD0ggnjKmgcjFW/Fj1PBdkPT178tFBKDao
jiRzzDhMLfxprSjwcHyyPRofqV30EI2lYHd50tq0A4pQhNjz0uv8tRJdghXWVvbM
hA3rtlSZlY2GmRZBE4S4PCW15OtCysi5faBsX37+J9M4OU0DPYgKwPdCdkjmK1wd
l8FLK3akhuLrji+YGtSbt54JuxwLynaHPXCiVxPuMtmIkZQQSHPWAobfbWQb9dMU
L/Uu3C6pSuLfk+7ya1ngyIvYCwLdzh0CgirY//4qL587FZ49UUiqz60XdhLgXaps
mm0z66tFipvkpfb774N/4WMbrLksjmsY0CWamdoUzKLFqjuXfFKOktGmH+xBvS19
8VGhAqtrPpCBE8r+EWkdRx60BMIytEwNUOz9D2JclJZgX3eJWepGmjTKSdJY/JWn
HDFJ/xmY32DH+rz5Cosv4LGCXntBGKDp2Ou4EDB7TEL3VNC88Rl1UyXvWgkLqxXl
sx4If62qBuRGXkZ/pd2NwZyfbzDrJLZjfIpmZfI3FxAwLdVGSbqsLI3sEAE7UsuG
9oQQpbFQ95XobQJIgsWj/TM2AqTbm7oletL61C78CjFLGUUGDuBl/x+7HYbXZNl4
Zd2EAe7p9lKYMNlgikSf3k9dAPcAEWLFSXoFuwkOz9+5yEVo22g=
=k0Em
-----END PGP SIGNATURE-----

F
F
Fis Trivial wrote on 17 Jan 2018 20:53
(name . Chris Marusich)(address . cmmarusich@gmail.com)(name . 30093@debbugs.gnu.org)(address . 30093@debbugs.gnu.org)
MWHPR16MB0063F08B82F75616BA2EA14892E90@MWHPR16MB0063.namprd16.prod.outlook.com
Toggle quote (5 lines)
>
> 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?
L
L
Ludovic Courtès wrote on 1 Feb 2018 18:43
control message for bug #30093
(address . control@debbugs.gnu.org)
878tccmwq0.fsf@gnu.org
severity 30093 important
M
M
Maxim Cournoyer wrote on 4 Oct 2020 20:25
Re: bug#30093: Installing python-ipython breaks Gnome on Fedora.
(name . Fis Trivial)(address . ybbs.daans@hotmail.com)
87d01xlufo.fsf@gmail.com
Hello,

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

Toggle quote (12 lines)
>>
>> 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
T
T
tomas.almeida@astrolabium.io wrote on 19 May 2021 18:14
bug#30093 what manual workaround?
(address . 30093@debbugs.gnu.org)(address . andre.gomes@astrolabium.io)
4557-60a53980-3e3-412dc980@34221159
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: file
C
C
Carlo Zancanaro wrote on 24 May 2021 02:16
Re: bug#30093: what manual workaround?
(name . tomas.almeida@astrolabium.io)(address . tomas.almeida@astrolabium.io)
87bl91htor.fsf@zancanaro.id.au
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:

Toggle quote (3 lines)
> 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
T
T
tomas.almeida@astrolabium.io wrote on 24 May 2021 12:30
Re: bug#30093: what manual workaround?
(name . Carlo Zancanaro)(address . carlo@zancanaro.id.au)
5586-60ab8000-f1-6eced080@82736962
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: file
M
M
Maxim Cournoyer wrote on 29 Sep 2022 04:50
Re: bug#30093: Installing python-ipython breaks Gnome on Fedora.
(address . tomas.almeida@astrolabium.io)
875yh6opvd.fsf_-_@gmail.com
Hi,

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

Toggle quote (17 lines)
> 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
Closed
?