Installing python-ipython breaks Gnome on Fedora.

OpenSubmitted by Fis Trivial.
Details
6 participants
  • Carlo Zancanaro
  • Chris Marusich
  • Ludovic Courtès
  • Maxim Cournoyer
  • tomas.almeida@astrolabium.io
  • 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
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 beto never use known environment variables in Guix search pathsspecifications.
Instead, we should introduce custom Guix-specific flavors of the samevariables, e.g. GUIX_GI_TYPELIB_PATH. That's more work (need to writeand maintain patches that add those Guix-specific variables along theirregular flavor), but that'd mean we can set all the variables we wantnot worrying about breaking a foreign distribution.
What do you think?
Maxim
T
T
tomas.almeida@astrolabium.io wrote on 19 May 18:14 +0200
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 profileGUIX_PROFILE="$HOME/.guix-profile"[ -L $GUIX_PROFILE ] || returnGUIX_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 installationsexport 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 02:16 +0200
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 12:30 +0200
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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send email to 30093@debbugs.gnu.org