Installing python-ipython breaks Gnome on Fedora.

OpenSubmitted by Fis Trivial.
Details
3 participants
  • Chris Marusich
  • Ludovic Courtès
  • Fis Trivial
Owner
unassigned
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 [1]: https://lists.gnu.org/archive/html/help-guix/2017-05/msg00072.html
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:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26202
It has been known for a while that certain environment variables mightcause problems like this if they are not configured "correctly" on aforeign distribution. What is "correct" depends on the distro, itseems.
For more discussion about this kind of issue in general, you might beinterested in the following threads:
https://lists.gnu.org/archive/html/help-guix/2017-11/msg00031.htmlhttps://lists.gnu.org/archive/html/help-guix/2017-05/msg00161.html
By the way, I found those threads by searching for the bug number 26202on 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 Ubuntuderivative), I think. Perhaps you have discovered a new example of thiskind of problem on Fedora. I wonder what Fedora is doing withGI_TYPELIB_PATH that causes this problem to occur for you?
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlpapfwACgkQ3UCaFdgiRp0RGRAAxAkHygHeQLfH4MrhH4elKI3tUJvDeo7uQIh+0M9h5cAWUQquMGGSoDFl13jaXDZF8yxKNUyZ+CbCDlqHVxNXLJmpPUZR8ufiBA4wMm4WlcCsjQ+FULoCXQr7mUdaQKxA94zg1m7BSQMuAtgNBNEai2CvkxvVL3VaQQKqBHIPWQ2zU4N6PUTOAdi+VGxvL49oBwqV9YMUr5PI35VO9VDLVBHjNgjenNwVD9IBlWGA+/8QGbCkM47unv9mBGHbX1EoHHpLHexPHdf06i7SKUl7O4lCUIzqDEPnDylc0z7OB5NNaX8X00BHJVlbAI3WpupeBVm+29ZCtFROcsObCEwcAOfhc7/MAjteW1Q27exQS1IZ/m9y5xE6Qw025kjvLEbMhLCevLpThaSzPxmflwsNIupzlDxCyV0jpYBiPDyUbBbxIAiX5dY4MxD1V9u/myiGit7/UqaWmP/r5gr1bscC57lyE5PTJQAicEiqxA+5pJgMuBUFHCcaKuRZSoOUTVm+3bfLPAuszQhrC4KYqdprpITioeDxQ2MIbi3dMmMmpk2uUcKPDcf6oEY8s8OHNN3BFh5emUJz/bN6N2Ow/vT9M61emGIcw52RZiKcNznZe5tKt8Ph2wXNG79C2aNvftCKYW230iIZxB8liJZwUGAdthzCB2QVllj6H6YI9Es2hNw==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: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29824
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, theclassification doesn't really match reality, which limits itsusefulness.
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'senvironment variables when building the profile. This is notpermissible in the purely functional software deployment model that Guixfollows. 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 ofGuix's purely functional model. In general, for any given foreigndistribution, there may be other problems that occur because theenvironment variables set by Guix are not formed or used in preciselythe way that the foreign distribution expects. These problems mayrequire changes that are, in general, impossible for Guix to predict or(if the solution requires changes that depend impurely on theenvironment) impossible for Guix to make without violating the purelyfunctional model.
I suspect that this class of problem won't be easy to fix genericallyfrom within Guix. Instead, I suspect it's more realistic to look forsolutions on a case-by-case basis. For example, the work-around for Bug26202 is currently a reasonable solution for that particular issue onthat particular foreign distribution. Even if we might be able to solvea particular problem like that one by introducing impurities into thebuild, 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 tointroduce impurities into the build probably makes it a non-starter forthe reasons I mentioned above.
Of course, if there is a way to solve this class of problem moregenerally without introducing impurities, that'd be great. I just can'tthink of one at this time.
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlpb2OwACgkQ3UCaFdgiRp1ATBAAwAui9DKp4jXn8RUerVeQs5hedbLYXe/atup4fuoqqYfqwnXvHyUfuqEvuAOK/N80dk8V+H2qUQmsri6JxE4OnHaOh932KBLDY2Bx4DOX2oxfo9bDMXnxxmHy7RpvxrI5p4xHprUxtnlKJ4vgkKRo846tqxllw2HnagARb03H1tWwCdNazK2CIQF91IePWIHFhmWIod1FwAQZZ4l1FRNJwD738NqsZfVysWL8Urg1wfbrtgRuGckuBfhzREE4NvdBCYeeONdvlDdjac+edzwMYedE/kHGNe5eKWv+O/TCf+BiBkHsr2C56lstmJBZZhAB9Jc9BVBK0KIthuq7ehbNLZi6//Hnm4Y0D0gh9AaNUx/jIXprFMjnjr/qhgu+zvFRghnUqxZVj6yJl63Mt7QJuDnjXKvn11aCCg+dtfdAM30vRp19L/PaCvHAKHl1lng5irjsBPZDXGxu6YG8gtpAuI0b4gvhC+tu9TReQ7IWofFByXg0+Tp/EqCgf9n1S8GTLq8xLrxvFTviwP19h1dTJPnPKL4lquLmzgfovAwQ2cVXZYNrqrXHykH/uh4TzalrtGUk+IwjL3TkadyuNpG/wDn54dFcChYGjNkx+LtH2DuPKp9Y75nEsoGDkVgE+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 whichdepend on things outside of the store. The specific examples I know ofare:
- 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 theoutside 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 scopeof a derivation, since derivations should only be able to access filesthat exist in the store.
Anyway, this means that technically, we probably could come up with asolution that takes the current value of an environment variable andultimately incorporates it into a build that creates the new profilegeneration. However, it doesn't change the fact that this class ofproblem will probably continue to occur on foreign distributions, so Istill think it might be best to deal with the problems on a case by casebasis. -- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlpb+Y0ACgkQ3UCaFdgiRp2zMRAAqtUktuf0qFunNaHkm7nu9USD0ggnjKmgcjFW/Fj1PBdkPT178tFBKDaojiRzzDhMLfxprSjwcHyyPRofqV30EI2lYHd50tq0A4pQhNjz0uv8tRJdghXWVvbMhA3rtlSZlY2GmRZBE4S4PCW15OtCysi5faBsX37+J9M4OU0DPYgKwPdCdkjmK1wdl8FLK3akhuLrji+YGtSbt54JuxwLynaHPXCiVxPuMtmIkZQQSHPWAobfbWQb9dMUL/Uu3C6pSuLfk+7ya1ngyIvYCwLdzh0CgirY//4qL587FZ49UUiqz60XdhLgXapsmm0z66tFipvkpfb774N/4WMbrLksjmsY0CWamdoUzKLFqjuXfFKOktGmH+xBvS198VGhAqtrPpCBE8r+EWkdRx60BMIytEwNUOz9D2JclJZgX3eJWepGmjTKSdJY/JWnHDFJ/xmY32DH+rz5Cosv4LGCXntBGKDp2Ou4EDB7TEL3VNC88Rl1UyXvWgkLqxXlsx4If62qBuRGXkZ/pd2NwZyfbzDrJLZjfIpmZfI3FxAwLdVGSbqsLI3sEAE7UsuG9oQQpbFQ95XobQJIgsWj/TM2AqTbm7oletL61C78CjFLGUUGDuBl/x+7HYbXZNl4Zd2EAe7p9lKYMNlgikSf3k9dAPcAEWLFSXoFuwkOz9+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
?