Guix on Debian 11 - Cant run or find applications from Guix

OpenSubmitted by bo0od.
Details
8 participants
  • bo0od
  • Luke Burgess
  • Giovanni Biscuolo
  • Liliana Marie Prikler
  • Maxim Cournoyer
  • Maxime Devos
  • Mark H Weaver
  • zimoun
Owner
unassigned
Severity
normal
B
B
bo0od wrote on 2 Jun 2021 20:56
(address . bug-guix@gnu.org)
e2e42e82-4581-a7e0-8944-a845d9851b37@riseup.net
Hi There,

I have installed Guix package manager over debian bullseye 11 then i
installed a package using guix (after running guix pull) with two ways:
(x package i tried is icecat)

guix install x

sudo -i guix install x

both of the commands worked but the x package has no icon nor i can run
it using terminal.


ThX!
M
M
Maxime Devos wrote on 3 Jun 2021 23:26
a6b07c8d78ee553736d70b756317bbaf6c835e41.camel@telenet.be
bo0od schreef op wo 02-06-2021 om 18:56 [+0000]:
Toggle quote (10 lines)
> Hi There,
>
> I have installed Guix package manager over debian bullseye 11 then i
> installed a package using guix (after running guix pull) with two ways:
> (x package i tried is icecat)
>
> guix install x
>
> sudo -i guix install x

There should be no need to install anything as root,
unless you make a habit of logging in as the root user
and work from there (not recommended).

(Except the guix daemon itself maybe? But that's "sudo guix pull"
I think, not "sudo guix install guix". I'm on Guix System
myself.)

Toggle quote (3 lines)
> both of the commands worked but the x package has no icon nor i can run
> it using terminal.

Which icon are you looking at? The icon in a desktop menu?
The ‘cat around a globe’ image you'd see on ‘new tab’ windows
above the search bar? The same image, but downscaled, before
‘New Tab’ in the tab bar?

Toggle quote (2 lines)
> nor i can run it using terminal

I can use IceCat just fine from the terminal (Guix System),
more details are needed, ‘I can't run it’ is rather vague.
Is there any log output, does IceCat start but crash soon,
maybe ‘bash: icecat: command not found’, ...?

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYLlJHRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7qbmAP9Q/R4rs86wFa5hodpSc7inPhS/
kf2JhALo3Fa0dO66kAD/UnSPgeaYYomSa+PoRVWxZSmTj1X+kFS2aSpVZ8g3nQI=
=d0xr
-----END PGP SIGNATURE-----


B
B
bo0od wrote on 4 Jun 2021 01:18
d81cc63c-559f-ef24-7a08-83fe3f10ffb4@riseup.net
Toggle quote (1 lines)
> There should be no need to install anything as root,
> unless you make a habit of logging in as the root user
> and work from there (not recommended).

I know i just mentioned this info to say with or without root nothing is
appeared to be readable from the system.

> Which icon are you looking at? The icon in a desktop menu?
> The ‘cat around a globe’ image you'd see on ‘new tab’ windows
> above the search bar? The same image, but downscaled, before
> ‘New Tab’ in the tab bar?

There is nothing exist of any kind from icons. (icecat starting icon in
the applications menu or so)

> I can use IceCat just fine from the terminal (Guix System),
> more details are needed, ‘I can't run it’ is rather vague.
> Is there any log output, does IceCat start but crash soon,

I can use that as well fine in guixsd, But not in debian.

> maybe ‘bash: icecat: command not found’, ...?

yes, and if i type ice and press Tab nothing appearing.

So whether graphical or terminal nothing indicating that there is a
software installed/exist in the system (though the software installed
and exist)

Note:

manually going to
/home/user/.guix-profile/share/applications/icecat.desktop and pressing
it it will run icecat.(but thats not how applications should be running)


Maxime Devos:
Toggle quote (37 lines)
> bo0od schreef op wo 02-06-2021 om 18:56 [+0000]:
>> Hi There,
>>
>> I have installed Guix package manager over debian bullseye 11 then i
>> installed a package using guix (after running guix pull) with two ways:
>> (x package i tried is icecat)
>>
>> guix install x
>>
>> sudo -i guix install x
>
> There should be no need to install anything as root,
> unless you make a habit of logging in as the root user
> and work from there (not recommended).
>
> (Except the guix daemon itself maybe? But that's "sudo guix pull"
> I think, not "sudo guix install guix". I'm on Guix System
> myself.)
>
>> both of the commands worked but the x package has no icon nor i can run
>> it using terminal.
>
> Which icon are you looking at? The icon in a desktop menu?
> The ‘cat around a globe’ image you'd see on ‘new tab’ windows
> above the search bar? The same image, but downscaled, before
> ‘New Tab’ in the tab bar?
>
>> nor i can run it using terminal
>
> I can use IceCat just fine from the terminal (Guix System),
> more details are needed, ‘I can't run it’ is rather vague.
> Is there any log output, does IceCat start but crash soon,
> maybe ‘bash: icecat: command not found’, ...?
>
> Greetings,
> Maxime.
>
M
M
Maxime Devos wrote on 5 Jun 2021 11:47
fe6389b86adea892cda1b40823d25bb99af9420e.camel@telenet.be
bo0od schreef op do 03-06-2021 om 23:18 [+0000]:
Toggle quote (8 lines)
> > Which icon are you looking at? The icon in a desktop menu?
> > The ‘cat around a globe’ image you'd see on ‘new tab’ windows
> > above the search bar? The same image, but downscaled, before
> > ‘New Tab’ in the tab bar?
>
> There is nothing exist of any kind from icons. (icecat starting icon in
> the applications menu or so)

For clarification, which option applies?

(a) IceCat does not appear in the application menu at all
(b) or:
IceCat does appear in the application menu, but its icon
is missing (but there is still some text like ‘GNU IceCat webbrowser’)

Toggle quote (10 lines)
> > I can use IceCat just fine from the terminal (Guix System),
> > more details are needed, ‘I can't run it’ is rather vague.
> > Is there any log output, does IceCat start but crash soon,
>
> I can use that as well fine in guixsd, But not in debian.
>
> > maybe ‘bash: icecat: command not found’, ...?
>
> yes, and if i type ice and press Tab nothing appearing.

What's the output of "echo $PATH"? Normally, $HOME/.guix-profile/bin
should be present in $PATH, but maybe somehow it isn't.

Also, what's the output of
ls -l ~/.guix-profile/bin/icecat

and
ls -l ~/.guix-profile/bin
?

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYLtISRccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7tBmAP9AmyxhvHXuulN/7NSfE4CJxCFi
uv2JuHAMTlGSOZaJFwEA/EI2OAt1tSzdOmT+NRwsZy1+H8afr2qCh4e33en/GwA=
=h1PK
-----END PGP SIGNATURE-----


B
B
bo0od wrote on 5 Jun 2021 13:25
013bc325-d178-4eb1-68fb-e96865540b62@riseup.net
Toggle quote (2 lines)
> (a) IceCat does not appear in the application menu at all

This one

> What's the output of...

Check the uploaded image.

Maxime Devos:
Toggle quote (39 lines)
> bo0od schreef op do 03-06-2021 om 23:18 [+0000]:
>> > Which icon are you looking at? The icon in a desktop menu?
>> > The ‘cat around a globe’ image you'd see on ‘new tab’ windows
>> > above the search bar? The same image, but downscaled, before
>> > ‘New Tab’ in the tab bar?
>>
>> There is nothing exist of any kind from icons. (icecat starting icon in
>> the applications menu or so)
>
> For clarification, which option applies?
>
> (a) IceCat does not appear in the application menu at all
> (b) or:
> IceCat does appear in the application menu, but its icon
> is missing (but there is still some text like ‘GNU IceCat webbrowser’)
>
>> > I can use IceCat just fine from the terminal (Guix System),
>> > more details are needed, ‘I can't run it’ is rather vague.
>> > Is there any log output, does IceCat start but crash soon,
>>
>> I can use that as well fine in guixsd, But not in debian.
>>
>> > maybe ‘bash: icecat: command not found’, ...?
>>
>> yes, and if i type ice and press Tab nothing appearing.
>
> What's the output of "echo $PATH"? Normally, $HOME/.guix-profile/bin
> should be present in $PATH, but maybe somehow it isn't.
>
> Also, what's the output of
> ls -l ~/.guix-profile/bin/icecat
>
> and
> ls -l ~/.guix-profile/bin
> ?
>
> Greetings,
> Maxime.
>
Attachment: guixpaths.png
M
M
Mark H Weaver wrote on 5 Jun 2021 19:49
878s3ogq0m.fsf@netris.org
Hi,

bo0od <bo0od@riseup.net> writes:

Toggle quote (11 lines)
> I have installed Guix package manager over debian bullseye 11 then i
> installed a package using guix (after running guix pull) with two ways:
> (x package i tried is icecat)
>
> guix install x
>
> sudo -i guix install x
>
> both of the commands worked but the x package has no icon nor i can run
> it using terminal.

The reason you can't simply type "icecat" in the terminal is because
Guix puts the 'icecat' executable in ~/.guix-profile/bin/icecat, but
that directory is not in your PATH environment variable.

Likewise, the reason there's no icon, i.e. no entry for IceCat in the
list of applications known by desktop environments in Debian, is because
by default desktop environments look in /usr/share/applications for the
".desktop" files, but Guix puts the desktop files in
~/.guix-profile/share/applications.

On a standalone Guix system, these issues are addressed by making sure
your environment variables are set as needed to make these things work.

~/.guix-profile/etc/profile should contain Bash shell commands that set
the environment variables appropriately for the set of packages
currently installed.

If you type "source ~/.guix-profile/etc/profile" from a Bash shell, it
loads the needed environment variable settings into that shell instance,
and henceforth you should be able to run "icecat" by simply typing its
name, *but* _only_ in that shell or other processes later spawned from
that shell. That's because environment variable settings are _not_
global. Each process has its own set of environment variable settings.
Typically, newly spawned processes inherit their environment variable
settings from the parent process that launched them.

In order to set your environment variables appropriately for your entire
desktop environment, you must arrange for the environment variable
settings to be loaded before the desktop session is launched. I don't
remember off-hand how to do this in Debian. I seem to recall that one
approach is to create an ~/.xsessionrc file, which should be an
executable Bash script that loads the needed environment variable
settings and then launches the desktop environment. Maybe there's a
better way.

I'm surprised this isn't well-trodden territory, long ago documented in
our manual, but I guess it isn't. It would be good if some Debian
expert(s), or at least someone who runs Guix on top of Debian, would
step forward to fill in the details.

Thanks for raising this issue.

Regards,
Mark

--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about https://stallmansupport.org.
G
G
Giovanni Biscuolo wrote on 17 Jun 2021 16:56
87wnqsletx.fsf@xelera.eu
Hi,

I use Guix on top of Debian, but I installed it long ago "manually" and
not via the Debian package "guix"... anyway once installed there are no
differences :-)

Mark H Weaver <mhw@netris.org> writes:

[...]

Toggle quote (7 lines)
>> both of the commands worked but the x package has no icon nor i can run
>> it using terminal.
>
> The reason you can't simply type "icecat" in the terminal is because
> Guix puts the 'icecat' executable in ~/.guix-profile/bin/icecat, but
> that directory is not in your PATH environment variable.

bo0od please ensure you have this in your ~/.bash_profile:

Toggle snippet (6 lines)
GUIX_PROFILE="$HOME/.config/guix/current"
. "$GUIX_PROFILE/etc/profile"


Actually, I set all the env variables for Guix in my ~/.profile that
(AFAIU) on Debian is included by default in ~/.bash_profile:

My ~/.bash_profile:

Toggle snippet (7 lines)
if [ -f ~/.profile ]; then
. ~/.profile
fi


My (edited) ~/.profile:

Toggle snippet (25 lines)
### Guix settings
#
# add Guix current path
export PATH="$HOME/.config/guix/current/bin${PATH:+:}$PATH"
# add Guix infopath
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
# Guix locpath
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
# set default Guix profile
export GUIX_PROFILE="$HOME/.guix-profile"
# set Guix extra profiles
export GUIX_EXTRA_PROFILES="$HOME/.guix-extra-profiles"
# set timezone data dir (zoneinfo)
export TZDIR=${GUIX_PROFILE}/share/zoneinfo
# source default Guix profile
. $GUIX_PROFILE/etc/profile

### XDG_CONFIG_DIRS fixes
# see Message-ID: <87r2asweu1.fsf@roquette.mug.biscuolo.net>
unset XDG_CONFIG_DIRS
export XDG_CONFIG_DIRS="${GUIX_PROFILE}/etc/xdg:/etc/xdg"


Actually I don't know if all env variables are still really needed, I
need to test things

Also (I don't know why) in my home this two profiles are differing:

Toggle snippet (6 lines)
$HOME/.config/guix/current -> /var/guix/profiles/per-user/root/current-guix
$HOME/.guix-profile -> /var/guix/profiles/per-user/giovanni/guix-profile


so I'm using my user (giovanni) profile for my GUIX_PROFILE env
variable.

[...]

Toggle quote (5 lines)
> That's because environment variable settings are _not_ global. Each
> process has its own set of environment variable settings. Typically,
> newly spawned processes inherit their environment variable settings
> from the parent process that launched them.

This is the reason why with Guix installed programs we have to set the
variables for each shell we use:

1. for the bash shell you do this by setting the variables in
~/.bash_profile (or ~/.profile like I'm doing)

Toggle quote (6 lines)
> In order to set your environment variables appropriately for your entire
> desktop environment, you must arrange for the environment variable
> settings to be loaded before the desktop session is launched. I don't
> remember off-hand how to do this in Debian. I seem to recall that one
> approach is to create an ~/.xsessionrc file,

Yes, AFAIK Mark is right:

2. for the desktop environment (shell) I include ~/.profile in my
~/.xsessionrc (because I like to keep all variables in one place)

My ~/.xsessionrc:

Toggle snippet (7 lines)
if [ -f ~/.profile ]; then
. ~/.profile
fi


This way all your xsessions (all X sessions should read ~/.xsessionrc)
will have the right environment (from your default Guix profile) and you
will be able to start Guix installed programs there (i.e. I use i3 for
this and it works well)

For the record, application and icons are sourced by XDG compliant
desktop environment from the XDG_DATA_DIRS env variable, that variable
should be in your default user profile, in
$HOME/.guix-profile/etc/profile, that you should source both in
~/.bash_profile and ~/.xsessionrc as explained above

Toggle quote (2 lines)
> which should be an executable Bash script

AFAIU it can be a regular file

[...]

Toggle quote (5 lines)
> I'm surprised this isn't well-trodden territory, long ago documented in
> our manual, but I guess it isn't. It would be good if some Debian
> expert(s), or at least someone who runs Guix on top of Debian, would
> step forward to fill in the details.

I'll try do propose some patch for the Guix manual but... don't hold
your breath, I need some testing.

Happy hacking! Gio'

[...]

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmDLYqsMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSuoUP/j+mdBATqh6kKiamwJh1Lts4c4IZx1IYER0xOiNB
AsS9DmjGxI7euIZyakc1QdJal0oe/eMe43HR6tqYcaFlFOCVZuiXbyf5UDnDI/p8
8V+dPwhmhC1UbGYECNcPXuGWN1SNqcWUsAoA8780UmaeA9l7CNBFnnViw6BhVWfO
jNv88wRs5fmpN3obE9SaA8yMhYVNMJitAwrlR2+hQClSGTK4CdRqPT+HflL1CEO/
3m0EqBjEyePKEbvSaeBpB1z2794gg3+73y3E7U9CYGw0pBKEaDUBnSbpbeAGAvnw
nRDqho+h3/Z5j9GOQlhNSCsIKbAFlXGra5VJpG9IK5ZEJ6vdyfkLTYoJoNKigIoi
XCd8qX/iWuDBYR4iUHl228TubQMyWYk7GpwJtUwAfseorGS9cexzI+VnyZ8MF737
19rp1e3MzCEysyZlI58eEk0u4z4FXjPA/ykQgr0FhvaRKj2qIS7Xo4M1V0D8kExh
UHSsa8x1bqpiLj59AMsmWBxFK4aOIrhugCln0bUfhIjg07ab4cwy4Xg7RoNaVuhA
yjpuHd1NYhqdvGVPl+k17W2e9SlQMg/VKdYz8vCIW+y88X41vQys8RTw7aJN035Z
g62/SCNP+GFSC95yUWw9vpr9CWjnnnwpJBysFbSlFB1S6uqAqAYAFo9v6hVhOgce
J0H7
=sbMJ
-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 2 Jul 2021 18:31
(name . bo0od)(address . bo0od@riseup.net)(address . 48796@debbugs.gnu.org)
87im1sn0dh.fsf@gmail.com
Hi,

On Wed, 02 Jun 2021 at 18:56, bo0od <bo0od@riseup.net> wrote:

Toggle quote (11 lines)
> I have installed Guix package manager over debian bullseye 11 then i installed
> a package using guix (after running guix pull) with two ways: (x package i
> tried is icecat)
>
> guix install x
>
> sudo -i guix install x
>
> both of the commands worked but the x package has no icon nor i can run it
> using terminal.

Does this message [1] fix your issue? If not, please provide details on
what is wrong for you.


Cheers,
simon

PS: I plan to mark the bug as notabug, WDYT?
B
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 48796@debbugs.gnu.org)
3ec187dc-b525-a92a-f278-2aeb87d2f003@riseup.net
Toggle quote (2 lines)
> Does this message [1] fix your issue?

"If you type "source ~/.guix-profile/etc/profile" from a Bash shell, it
loads the needed environment variable"

yes it worked, but thats not really what im asking as this is workaround
for the issue but im asking for a solution to the users as they can type
the app name and it should run and icon should be shown somewhere on
application menu or desktop or so.

flatpak , snap which work almost similarly to guix can do that then guix
should do that as well.

otherwise guix should mention that there wont be icons nor ability to
run the applications from terminal unless you do 1 2 3 after guix app
installaion which is sadly a downside for new comers.




zimoun:
Toggle quote (1 lines)
> Does this message [1] fix your issue?
B
c06bdc99-fbb5-9716-5c4b-408e31649757@riseup.net
Toggle quote (1 lines)
> I'll try do propose some patch for the Guix manual but... don't hold
> your breath, I need some testing.

Sure tyt, but its a disaster way for guix for not doing this
automatically. Imagine new user he should do stuff manually after
installing guix through apt.. yeah he (mostly) wont stay around after
that to be a guix user.

Giovanni Biscuolo:
Toggle quote (2 lines)
> I'll try do propose some patch for the Guix manual but... don't hold
> your breath, I need some testing.
L
L
Luke Burgess wrote on 23 Aug 2021 02:58
Just a newb, srsly this saved me
(address . 48796@debbugs.gnu.org)
CAASP0RAcT+g31O+EYBrV9sJL3sGRoN3zk+yTH+655Pg1-AXHBg@mail.gmail.com
Toggle quote (5 lines)
>If you type "source ~/.guix-profile/etc/profile"
>from a Bash shell, it loads the needed
>environment variable settings into that
>shell instance,and henceforth you
>should be able to run "icecat"
Maybe I should have read and understood the GUIX manual better.... Maybe I
should not be haphazardly putting together my config.scm files on the
fly.... Maybe I shouldn't be using root bash to test modifications I plan
to make to my config.scm files... Maybe running GUIX on the 6 bear metal
computers I use it on was a bad idea and I should be using VMs... But this
explanation just saved me...Some root shells working and others not
working, boy was I confused???... and this just saved me ... Mark H Weaver,
Thank you, Thank you Thank you.
Just one little thing I might still be getting totaly wrong... given I know
the classical lines:
#GUIX_PROFILE="/root/.config"
#. "$GUIX_PROFILE/etc/profile"
What would this do differently in root, if anything?
#source /root/.config/etc/profile
Attachment: file
Z
Z
zimoun wrote on 23 Aug 2021 12:42
Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix
(name . bo0od)(address . bo0od@riseup.net)(address . 48796@debbugs.gnu.org)
87bl5owigo.fsf@gmail.com
Hi,

On Thu, 15 Jul 2021 at 13:09, bo0od <bo0od@riseup.net> wrote:
Toggle quote (13 lines)
>> Does this message [1] fix your issue?
>
> "If you type "source ~/.guix-profile/etc/profile" from a Bash shell, it loads
> the needed environment variable"
>
> yes it worked, but thats not really what im asking as this is workaround for
> the issue but im asking for a solution to the users as they can type the app
> name and it should run and icon should be shown somewhere on application menu
> or desktop or so.
>
> flatpak , snap which work almost similarly to guix can do that then guix
> should do that as well.

I have never used Flatpack but from the doc, I read:

Toggle snippet (3 lines)
$ flatpak run org.gimp.GIMP


Then reading:


I am not convinced that Guix should follow the Flatpack approach by
default. And somehow, it is not what “guix pack” already does. ;-)

About Snap, I have not been able to get the right doc.

Toggle quote (4 lines)
> otherwise guix should mention that there wont be icons nor ability to run the
> applications from terminal unless you do 1 2 3 after guix app installaion
> which is sadly a downside for new comers.

As Mark explained,

In order to set your environment variables appropriately for
your entire desktop environment, you must arrange for the
environment variable settings to be loaded before the desktop
session is launched. I don't remember off-hand how to do this
in Debian. I seem to recall that one approach is to create an
~/.xsessionrc file, which should be an executable Bash script
that loads the needed environment variable settings and then
launches the desktop environment. Maybe there's a better way.

I'm surprised this isn't well-trodden territory, long ago documented in
our manual, but I guess it isn't. It would be good if some Debian
expert(s), or at least someone who runs Guix on top of Debian, would
step forward to fill in the details.

it is possible to have the icons and run them from the desktop
launcher. The configuration has to be done manually though.

Therefore, a section should be added to the manual under «Application
Setup», IMHO.


All the best,
simon
Z
Z
zimoun wrote on 23 Aug 2021 12:20
(name . bo0od)(address . bo0od@riseup.net)
87eeakwjgd.fsf@gmail.com
Hi,

On Thu, 15 Jul 2021 at 14:05, bo0od <bo0od@riseup.net> wrote:
Toggle quote (8 lines)
>> I'll try do propose some patch for the Guix manual but... don't hold
>> your breath, I need some testing.
>
> Sure tyt, but its a disaster way for guix for not doing this
> automatically. Imagine new user he should do stuff manually after
> installing guix through apt.. yeah he (mostly) wont stay around after that to
> be a guix user.

It is already the case for couple of configurations, see:

When using Guix on top of GNU/Linux distribution other than Guix
System—a so-called foreign distro—a few additional steps are
needed to get everything in place. Here are some of them.


Therefore, I do not see why it should be different, i.e., the user has
to manually setup the correct configuration for icons apps as Mark
explained.

Let keep open this report open as a reminder until a patch improving the
manual is submitted. :-)

All the best,
simon
M
M
Maxim Cournoyer wrote on 23 Sep 2021 13:56
(name . Luke Burgess)(address . burgesl@gmail.com)(address . 48796@debbugs.gnu.org)
874kabld3l.fsf_-_@gmail.com
Hello,

Luke Burgess <burgesl@gmail.com> writes:

Toggle quote (19 lines)
>>If you type "source ~/.guix-profile/etc/profile"
>>from a Bash shell, it loads the needed
>>environment variable settings into that
>>shell instance,and henceforth you
>>should be able to run "icecat"
> Maybe I should have read and understood the GUIX manual better.... Maybe I
> should not be haphazardly putting together my config.scm files on the
> fly.... Maybe I shouldn't be using root bash to test modifications I plan
> to make to my config.scm files... Maybe running GUIX on the 6 bear metal
> computers I use it on was a bad idea and I should be using VMs... But this
> explanation just saved me...Some root shells working and others not
> working, boy was I confused???... and this just saved me ... Mark H Weaver,
> Thank you, Thank you Thank you.
> Just one little thing I might still be getting totaly wrong... given I know
> the classical lines:
> #GUIX_PROFILE="/root/.config"
> #. "$GUIX_PROFILE/etc/profile"
> What would this do differently in root, if anything?
> #source /root/.config/etc/profile
^ .config/guix/current/etc/profile ?

In any case, it doesn't matter if the user is root or something else,
it should work the same for any user.

Maxim
M
M
Maxim Cournoyer wrote on 23 Sep 2021 14:10
(name . bo0od)(address . bo0od@riseup.net)(address . 48796@debbugs.gnu.org)
87zgs3jxvr.fsf@gmail.com
Hello,

bo0od <bo0od@riseup.net> writes:

Toggle quote (13 lines)
> Hi There,
>
> I have installed Guix package manager over debian bullseye 11 then i
> installed a package using guix (after running guix pull) with two
> ways: (x package i tried is icecat)
>
> guix install x
>
> sudo -i guix install x
>
> both of the commands worked but the x package has no icon nor i can
> run it using terminal.

There are two things that Guix does to help users correctly configure
their system so that Guix installed applications appear on PATH.

1. The guix-install.sh installation script installs a
/etc/profile.d/guix.sh script that configures the PATH when logging in:

Toggle snippet (22 lines)
# cat /etc/profile.d/guix.sh
# _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_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/}"

It even set XDG_DATA_DIRS, which should allow integration with the GNOME
Shell and other graphical dashboards.

I suspect you didn't install Guix via this script? If so, could you try
creating the above file, closing relogin in your graphical session and
report if it fixed things for you?

Perhaps we should more strongly recommend using this installation script
and/or augment the manual installation procedure to cover for the above
configuration.

A second thing that Guix does to help users configure their environ Guix
is to hinted at sourcing the profile, if the user ~/.guix-profile/bin
was not already in PATH, like so:


Toggle snippet (26 lines)
# env PATH=/usr/local/bin:/bin guix install zile
guix install: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.

The following package will be installed:
zile 2.4.15

substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivation will be built:
/gnu/store/015zpn0xl8fn2ff1l0vf69w127frp76a-profile.drv

0.1 MB will be downloaded
zile-2.4.15 108KiB 97KiB/s 00:01 [##################] 100.0%
building CA certificate bundle...
building fonts directory...
building directory of Info manuals...
building database for manual pages...
building profile with 6 packages...
hint: Consider setting the necessary environment variables by running:

GUIX_PROFILE="/root/.guix-profile"
. "$GUIX_PROFILE/etc/profile"

Alternately, see `guix package --search-paths -p "/root/.guix-profile"'.

Didn't you see this on your terminal after installing the Guix
applications?

Thanks,

Maxim
B
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 48796@debbugs.gnu.org)
288d3c24-39fe-d6bc-5dae-dcff1018c921@riseup.net
Toggle quote (1 lines)
> I suspect you didn't install Guix via this script? If so, could you try
> creating the above file, closing relogin in your graphical session and
> report if it fixed things for you?

Its already answered how to fix it after installation, Thats not the
only issue, The real issue is guix isnt doing this by default after
installing it, You dont expect users to make crazy steps after
installation just to make guix works properly.

Solution to this must developed in a way that when user install guix
package then he type guix install x then it should work without further
configs.

Otherwise we have snap and flatpak which both are better than guix not
just with lower complexity but even more security. (snap use
lxc(container)+apparmor(mac), flatpak use bubblerap (namespace/seccomp),
while guix doesnt use anything by default).




Maxim Cournoyer:
Toggle quote (96 lines)
> Hello,
>
> bo0od <bo0od@riseup.net> writes:
>
>> Hi There,
>>
>> I have installed Guix package manager over debian bullseye 11 then i
>> installed a package using guix (after running guix pull) with two
>> ways: (x package i tried is icecat)
>>
>> guix install x
>>
>> sudo -i guix install x
>>
>> both of the commands worked but the x package has no icon nor i can
>> run it using terminal.
>
> There are two things that Guix does to help users correctly configure
> their system so that Guix installed applications appear on PATH.
>
> 1. The guix-install.sh installation script installs a
> /etc/profile.d/guix.sh script that configures the PATH when logging in:
>
> --8<---------------cut here---------------start------------->8---
> # cat /etc/profile.d/guix.sh
> # _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_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/}"
> --8<---------------cut here---------------end--------------->8---
>
> It even set XDG_DATA_DIRS, which should allow integration with the GNOME
> Shell and other graphical dashboards.
>
> I suspect you didn't install Guix via this script? If so, could you try
> creating the above file, closing relogin in your graphical session and
> report if it fixed things for you?
>
> Perhaps we should more strongly recommend using this installation script
> and/or augment the manual installation procedure to cover for the above
> configuration.
>
> A second thing that Guix does to help users configure their environ Guix
> is to hinted at sourcing the profile, if the user ~/.guix-profile/bin
> was not already in PATH, like so:
>
>
> --8<---------------cut here---------------start------------->8---
> # env PATH=/usr/local/bin:/bin guix install zile
> guix install: warning: Consider running 'guix pull' followed by
> 'guix package -u' to get up-to-date packages and security updates.
>
> The following package will be installed:
> zile 2.4.15
>
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> The following derivation will be built:
> /gnu/store/015zpn0xl8fn2ff1l0vf69w127frp76a-profile.drv
>
> 0.1 MB will be downloaded
> zile-2.4.15 108KiB 97KiB/s 00:01 [##################] 100.0%
> building CA certificate bundle...
> building fonts directory...
> building directory of Info manuals...
> building database for manual pages...
> building profile with 6 packages...
> hint: Consider setting the necessary environment variables by running:
>
> GUIX_PROFILE="/root/.guix-profile"
> . "$GUIX_PROFILE/etc/profile"
>
> Alternately, see `guix package --search-paths -p "/root/.guix-profile"'.
> --8<---------------cut here---------------end--------------->8---
>
> Didn't you see this on your terminal after installing the Guix
> applications?
>
> Thanks,
>
> Maxim
>
M
M
Maxim Cournoyer wrote on 26 Sep 2021 07:50
(name . bo0od)(address . bo0od@riseup.net)(address . 48796@debbugs.gnu.org)
87v92nj36a.fsf@gmail.com
Hello,

bo0od <bo0od@riseup.net> writes:

Toggle quote (9 lines)
>> I suspect you didn't install Guix via this script? If so, could you try
>> creating the above file, closing relogin in your graphical session and
>> report if it fixed things for you?
>
> Its already answered how to fix it after installation, Thats not the
> only issue, The real issue is guix isnt doing this by default after
> installing it, You dont expect users to make crazy steps after
> installation just to make guix works properly.

You are right, that the installation script should probably source the
/etc/profile.d/guix.sh that it installed so that things work normally
already in the current shell.

Toggle quote (4 lines)
> Solution to this must developed in a way that when user install guix
> package then he type guix install x then it should work without
> further configs.

I agree that making things as smooth as possible for new users is a
worthy goal.

Thanks,

Maxim
Z
Z
zimoun wrote on 5 Jan 00:16 +0100
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
86mtkbay8b.fsf@gmail.com
Hi,

What is the concrete next action of this bug [1]?


On Sun, 26 Sep 2021 at 01:50, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
Toggle quote (15 lines)
> bo0od <bo0od@riseup.net> writes:
>
>>> I suspect you didn't install Guix via this script? If so, could you try
>>> creating the above file, closing relogin in your graphical session and
>>> report if it fixed things for you?
>>
>> Its already answered how to fix it after installation, Thats not the
>> only issue, The real issue is guix isnt doing this by default after
>> installing it, You dont expect users to make crazy steps after
>> installation just to make guix works properly.
>
> You are right, that the installation script should probably source the
> /etc/profile.d/guix.sh that it installed so that things work normally
> already in the current shell.

Well, I think this was similarly answered [2] in this same thread. ;-)


What could be the improvements here?


Toggle quote (7 lines)
>> Solution to this must developed in a way that when user install guix
>> package then he type guix install x then it should work without
>> further configs.
>
> I agree that making things as smooth as possible for new users is a
> worthy goal.

Is it related to this bug? ;-)


Cheers,
simon
Z
Z
zimoun wrote on 12 Apr 11:51 +0200
control message for bug #48796
(address . control@debbugs.gnu.org)
87lewa6346.fsf@gmail.com
tags 48796 + moreinfo
quit
G
G
Giovanni Biscuolo wrote on 28 Apr 16:14 +0200
Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix
87sfpxgura.fsf@xelera.eu
Hi!

unfortunately AFAIU we still have issues with XDG-related environment
variables

please consider that $PATH env variable is /not/ the issue, the issue is
only related to XDG and *.desktop files

zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (4 lines)
> What is the concrete next action of this bug [1]?
>
> 1: <http://issues.guix.gnu.org/issue/48796>

solve it, since XDG Desktop integration of Guix installed application
unfortunately still don't work on (few? many?) foreign distributions, at
least it does non work on Debian 11

solving probably means better documentation

[...]

Toggle quote (2 lines)
> What could be the improvements here?

find a documented and reproducible way to make Guix installed
application appear in a Debian 11 (and others) installed desktop manager
menu

[...]

I'm going to reply to one of my previous messages in this thread to
recap the situation trying to not repeat all the details.

...to be continued

Happy hacking! Gio'

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmJqoUkMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSnD8QALnJ5PVF3Up688Q3LRglh2gR3Zpx3XhA73ub1ZTH
rBKkcEdpsvqpafq8dUwg9bMVfKUW0vtTy7tux2fdNfMhDr9oEn8CGlrihGsRyFno
w5t96xBZiariwn9+lwsuYkSU1zIwR1QcPxDbuhJcqnCykEVJ5KF9ri8G6eoCGQQi
c4tcOVwfsn7QO2CvPX6g31uyBZyhpWmnFyLM0YYPRLqF8SLNdr8Aatozu94reMQV
Thx9bKLkKHpZNcQBSMgCsY/Ee4cfdhUxiGscFDxpkpeq01iGRQsUffFPblfxxYVU
TnF8O0F9RU17Ys+nN1uiFyBAUWm8a8OUc7zaveEEAqCrASClxtFQc7UkhmiK6QVG
XCVwmXqmBIKY12eAjp99ix8TjYh1pxspXNPjpJQvvtKR3LmhEuolh9/Zyjbw9GAF
pq55sIXVjJO6DGrLnFhEYX66DrO594XzTPrRsjIs0uCl1x9wewY9S3VnentGv2+J
Aj5Vhp1Dsa3UHzgrxsTdvLMKyw/9jHHFWJHq7DmdR8hjfrMgDk3UXo4r7iLoOTfL
o3OB0ECyPxCor6uzeky0PKxpcg4qdxxa6UU1Wceiq6dasOGB5OHgmVK9xNo5C38s
w7q+bMHsCZqB3NI9HbL5dGkvNxYzROygPm9vUDLklwmGQyfeoIfMv808HjVz6M+v
JQf9
=UeFg
-----END PGP SIGNATURE-----

G
G
Giovanni Biscuolo wrote on 28 Apr 17:59 +0200
Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix in Desktop Menus
(address . 48796@debbugs.gnu.org)
87pml1gpw8.fsf@xelera.eu
Hi Maxim and bo0od,

This is my report about my recent testing experience with guix installed
desktop applications in a desktop environment on Debian 11 (I usually do
not use a desktop environment with a graphical menu, I use i3).

I've added "in Desktop Menus" to the subject because actually users can
find and run applications using a terminal (dash shell in Debian) or the
"Execute" menu option found in many Desktop Environments (this means
$PATH configuration is fine).

The user experience is this:

0. user install the guix package manager via apt

1. user logs in via display manager (I tested LXDM and GDM3, installed
via apt)

2. user gets a desktop manager (I tested LXDE and Mate, installad via
apt) with a graphical menu

3. user installs a desktop application via "guix package..."

4. user does /not/ see the newly installed application, but the person
can start the program via terminal or "Execute" menu item (with
completion, this means $PATH does include the ~/.guix-profile/<stuff>)

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

Toggle quote (3 lines)
> There are two things that Guix does to help users correctly configure
> their system so that Guix installed applications appear on PATH.

Yes: PATH configuration works, it's not the problem causing this bug
report.

Toggle quote (5 lines)
> 1. The guix-install.sh installation script installs a
> /etc/profile.d/guix.sh script that configures the PATH when logging in:
>
> --8<---------------cut here---------------start------------->8---

[...]

Toggle quote (7 lines)
> # set XDG_DATA_DIRS to include Guix installations
> export XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"
> --8<---------------cut here---------------end--------------->8---
>
> It even set XDG_DATA_DIRS, which should allow integration with the GNOME
> Shell and other graphical dashboards.

No: this does not work, for three reasons:

1. AFAIU "/etc/profile.d/guix.sh" or "~/.profile" are not
sourced/executed in a graphical session (graphical shell?), we need to
~/.xsessionrc to configure that environment: am I wrong?

2. XDG_DATA_DIRS gets someway hard reset by "something" to this value:

XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/

(I found workaround, see below)

3. desktop menus (I tested LXDE and Mate, not Gnone Shell) are not
updated

This is my workaround, in ~/.profile I have:

Toggle snippet (21 lines)
### Guix settings
#
# add Guix current path
export PATH="$HOME/.config/guix/current/bin${PATH:+:}$PATH"
# Locale path
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
# add Guix infopath
export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"
# set default Guix profile
export GUIX_PROFILE="$HOME/.guix-profile"
# source default Guix profile
. $GUIX_PROFILE/etc/profile

# Needed to find Guix XDG data, included *.desktop files
# when not set, XDG_DATA_HOME is $HOME/.local/share
# only ONE directory is permitted, setting two does not work (?)
export XDG_DATA_HOME="$GUIX_PROFILE/share"


and in ~/.xsessionrc:

Toggle snippet (7 lines)
if [ -f ~/.profile ]; then
. ~/.profile
fi

The main point of this workaround is that I configure XDG_DATA_HOME,
described in the specifications:

Toggle snippet (6 lines)
$XDG_DATA_HOME defines the base directory relative to which
user-specific data files should be stored. If $XDG_DATA_HOME is either
not set or empty, a default equal to $HOME/.local/share should be used.

(from

With the above workaround I'm able to see all guix installed *.desktop
files in the menu of my desktop environment (tested on LXDE mainly).

Anyway to make the new installed *.desktop files appear in the menu, I
have to logout and login again: I've still not found a command (or
configuration) to update the menu, "xdg-desktop-menu forceupdate" does
not work.

[...]

If my experience is consistent with those of other users, I'm willing to
propose a patch for the manual (I'm thinking of a specific "2.6.6 -
XSession setup" in (guix)Getting Started)

WDYT?

Thanks! Gio'

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmJquecMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSnJ0P/ArAYcnieZ+sS9Qun+39VQJ3mj2CB3o0vhigbBzY
N2mUaVvZEaT0SlZu3ZpTUY0TL1Sz2KplbbhAq2Tj0q0WONFv4Ez++42rMVQhaw45
03cWU/4a6z7RRzP7GkiAeSRjTZP89Tn1bX3eFD304GGi9F4M5NIJFrgUIvVz5dzE
OyfTQrMVEr0hdtGVe6UsZOJE/G9cXumHAvcK+w7ZOdtoV0VRegK+2zUIa4yQni82
ZLcsKNQuB/34FKTePF/LGInDjhrwkQ+7aEKUuOoFGFQx0B0lcqQcTyzJ3rAuHXE5
wq5iCIG6/1CmFnG5oOrVBlrBBFU5U2h4RYAE4QA2C5MJ+vY5RiFNYlTgKvTok7rP
sc4hPi6Z/mBjbcvHtkuyJnpjV0SbJ2J3WWv8i9R9gvcS4t45YdpSz7ibIO1UEdyQ
tb4zw8VC2oUAb0bCUqVb3+2Vw2c1jc/R+PfgGECHeIapgD3upH4kK5Al+Hc5uhsq
a/jmRnxXv6J+Nw5GeFXVUsDw8hT+7SwBqP9kcLVYLudwrwRQ6p4jd7yTTZ4JaYG4
xbFgU/VQkJyHBlI57imaYy9rITPyWqJ3gcUOa0bxLGdHuAkzvCn0Ws8z2nywxUxI
o2vq82lI8LUeVC/tvmMAo0etw4tN8yQBNlAa1C2fZI1kVUJAa3YXPKEzpqWAwTTr
DqeD
=sGhP
-----END PGP SIGNATURE-----

L
L
Liliana Marie Prikler wrote on 29 Apr 21:18 +0200
(address . 48796@debbugs.gnu.org)
59eff3512f8726c4ac0ee4071d878536b197d31f.camel@gmail.com
Hi Giovanni,

Am Donnerstag, dem 28.04.2022 um 17:59 +0200 schrieb Giovanni Biscuolo:
Toggle quote (14 lines)
> [...]
> > # set XDG_DATA_DIRS to include Guix installations
> > export XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-
> > /usr/local/share/:/usr/share/}"
> > --8<---------------cut here---------------end--------------->8---
> >
> > It even set XDG_DATA_DIRS, which should allow integration with the
> > GNOME Shell and other graphical dashboards.
>
> No: this does not work, for three reasons:
>
> 1. AFAIU "/etc/profile.d/guix.sh" or "~/.profile" are not
> sourced/executed in a graphical session (graphical shell?), we need
> to ~/.xsessionrc to configure that environment: am I wrong?
Depends on your setup. Some systemd setups don't source it, but note
that you can work around that by editing the offending file. More
importantly...

Toggle quote (6 lines)
> 2. XDG_DATA_DIRS gets someway hard reset by "something" to this
> value:
>
> XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/men
> u-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-
> xdg/
I would investigate what actually "resets" this. If it survives
XDG_DATA_DIRS=blah $SHELL, then it's in the stuff your shell sources.
If it doesn't, then you probably just experience (1).

Toggle quote (4 lines)
> (I found workaround, see below)
>
> 3. desktop menus (I tested LXDE and Mate, not Gnome Shell) are not
> updated
We hacked our Gnome Shell package to do this on Guix – naturally this
won't work for foreign systems or other packages.

Toggle quote (3 lines)
> [...]
> The main point of this workaround is that I configure XDG_DATA_HOME,
> described in the specifications:
And that is evil.

Toggle quote (5 lines)
> [...]
> Anyway to make the new installed *.desktop files appear in the menu,
> I have to logout and login again: I've still not found a command (or
> configuration) to update the menu, "xdg-desktop-menu forceupdate"
> does not work.
Should it? It might only honor XDG_DATA_DIRS and ignore XDG_DATA_HOME
by accident. Other than that, restarting your shell (if running on X)
might be a more lightweight way of refreshing the menu.

Cheers
G
G
Giovanni Biscuolo wrote on 2 May 14:49 +0200
(address . 48796@debbugs.gnu.org)
871qxcf6ak.fsf@xelera.eu
Hi Liliana Marie,

thank you for your heads up!

I confess I'm pretty much confused about "Freedesktop.org's xdg menu
system" because I thought it's now a cross-distro standard that should
work out of the box without much tinkering by the distro maintainers
and/or by the user. There is a non zero chance that it does depend on
poor implementation or documentation, and for sure I'm not the only one
that is experiencing issues in this regard[1]. There is obviously a non
zero chance it depends on my poor understanding, please forgive me in
this case.

This situation (obviously) does /not/ depend on Guix, it depends on the
Xsession setup and "xdg menu system" (and lack of documentation?) of the
foreign distro side.

I just think that if Guix (the package manager) cannot automate desktop
integration on all foreign distros then it should be stated in the
manual, possibly explaining why and pointing users to the foreign distro
documentation.

Anyway, I still think (hope) that we can "fill the gap" since we
probably have al the pieces (env and information) and we probably "just"
need to connect the dots to have the whole picture... working
cross-distro I mean.

To add a little bit of context (and highlight it's not an issue just for
Guix as a package manager) I found this bug reports interesting:

flatpak directories not added to XDG_DATA_DIRS on Plasma + Wayland
(still open, last update 2022-04-16)

snapd: Installed snaps do not appear in desktop launcher in Debian
buster.
(still open, last update 2022-04-22)

XDG_DATA_DIRS not set when using openbox-gnome-session
(resolved on 2013-07-23)

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

Toggle quote (10 lines)
>> > It even set XDG_DATA_DIRS, which should allow integration with the
>> > GNOME Shell and other graphical dashboards.
>>
>> No: this does not work, for three reasons:
>>
>> 1. AFAIU "/etc/profile.d/guix.sh" or "~/.profile" are not
>> sourced/executed in a graphical session (graphical shell?), we need
>> to ~/.xsessionrc to configure that environment: am I wrong?
> Depends on your setup. Some systemd setups don't source it,

So it depends on the /default/ systemd setup of the foreign distro,
Debian 11 in this case, because I did not customize it: please do you
know where I should check for the systemd specific documentation on "xdg
related stuff"?

The documentation I was able to find does not help me with systemd
config:




Toggle snippet (8 lines)
Finally, note that the ~/.xsession file is only read if you are using a
Debian X session. If you login with gdm3 and choose a GNOME session, the
~/.xsession file will be ignored completely. (But you may still use
~/.xsessionrc.)


makes me wonder what (and why) is the differenxe betweeen a Gnome
Session and an LXDE one: shouldn't the setup be standard? It's the
systemd specific way to setup an xsession?


By default, on Debian 11 this is the content of
/etc/X11/Xsession.options:

Toggle snippet (13 lines)
# $Id: Xsession.options 189 2005-06-11 00:04:27Z branden $
#
# configuration options for /etc/X11/Xsession
# See Xsession.options(5) for an explanation of the available options.
allow-failsafe
allow-user-resources
allow-user-xsession
use-ssh-agent
use-session-dbus


Do I miss some specific systemd Debian 11 xdg related documentation?

Toggle quote (2 lines)
> but note that you can work around that by editing the offending file.

Please can you point me to the offending file?

Toggle quote (11 lines)
> More importantly...
>
>> 2. XDG_DATA_DIRS gets someway hard reset by "something" to this
>> value:
>>
>> XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/men
>> u-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-
>> xdg/
> I would investigate what actually "resets" this. If it survives
> XDG_DATA_DIRS=blah $SHELL, then it's in the stuff your shell sources.

Actually if I give that command in a terminal I get
"XDG_DATA_DIRS=blah", but I'm pretty sure there is nothing in the stuff
of my shell sources that resets XDG_DATA_DIRS

Toggle quote (2 lines)
> If it doesn't, then you probably just experience (1).

Yes: there is something in the default systemd/xsession configuration
of Debian 11 that resets XDG_DATA_DIR.

Please is there some user with a default Debian 11 xsession
configuration that can try to reproduce this?

Am I the only one to experience this XDG_DATA_DIR reset issue?

Toggle quote (7 lines)
>> (I found workaround, see below)
>>
>> 3. desktop menus (I tested LXDE and Mate, not Gnome Shell) are not
>> updated
> We hacked our Gnome Shell package to do this on Guix – naturally this
> won't work for foreign systems or other packages.

OK thank you, now I understand how it works.

I still have not found some time to check how Debian packages are
live-updating the desktop menus, AFAIK that update works
cross-desktop-environment and I'd like to know:

1. is that also a cross-distro standard?

2. why "xdg-desktop-menu forceupdate" does not work for user installed
*.desktop menus?

3. is there any other CLI that allows users to uptate their graphical
menus after having "manually installed" (write the right file in the
right folder) a *.desktop file?

Toggle quote (5 lines)
>> [...]
>> The main point of this workaround is that I configure XDG_DATA_HOME,
>> described in the specifications:
> And that is evil.

Please can you expand what do you mean with "evil"?

I as told (did I told?) I found that information in the "XDG Base
Directory Specification" [3]

Also, the "9.4.10. Starting a program from GUI" [4] current Debian
manual states:

Toggle snippet (29 lines)
This is an oversimplified description. The *.desktop files are scanned as follows.

The desktop environment sets $XDG_DATA_HOME and $XDG_DATA_DIR environment variables. For example, under the GNOME 3:

$XDG_DATA_HOME is unset. (The default value of $HOME/.local/share is used.)

$XDG_DATA_DIRS is set to /usr/share/gnome:/usr/local/share/:/usr/share/.

So the base directories (see XDG Base Directory Specification) and the applications directories are as follows.

$HOME/.local/share/ → $HOME/.local/share/applications/

/usr/share/gnome/ → /usr/share/gnome/applications/

/usr/local/share/ → /usr/local/share/applications/

/usr/share/ → /usr/share/applications/

The *.desktop files are scanned in these applications directories in this order.

[Tip] Tip
A user custom GUI menu entry can be created by adding a *.desktop file in the $HOME/.local/share/applications/ directory.

[Tip] Tip
Similarly, if a *.desktop file is created in the autostart directory under these base directories, the specified program in the *.desktop file is executed automatically when the desktop environment is started. See Desktop Application Autostart Specification.


Also, the Freedesktop.org "Desktop Menu Specification" chapter
"C. Integrating your application in the menus" [5] documents how to add
menu items; it states:

Toggle snippet (5 lines)
If an application is intended to be installed by an unprivileged user for exclusive use by that user only then $XDG_DATA_HOME should be used as value for datadir and $XDG_CONFIG_HOME should be used as value for sysconfdir. If $XDG_DATA_HOME is not set, the default value of $HOME/.local/share should be used for it. If $XDG_CONFIG_HOME is not set, the default value of $HOME/.config should be used for it.


Reading the above it seems perfectly legit to customize XDG_DATA_HOME
pointing that variable to any user directory I need to add custom GUIX
menu entries... and I let handle that menu entries to my guix profile:
do I miss something?

Should I also customize $XDG_CONFIG_HOME to point to a specific
directory different from $HOME/.config?

Toggle quote (8 lines)
>> [...]
>> Anyway to make the new installed *.desktop files appear in the menu,
>> I have to logout and login again: I've still not found a command (or
>> configuration) to update the menu, "xdg-desktop-menu forceupdate"
>> does not work.
> Should it? It might only honor XDG_DATA_DIRS and ignore XDG_DATA_HOME
> by accident.

AFAIU xdg-desktop-menu is supposed to also update user menus

Toggle quote (3 lines)
> Other than that, restarting your shell (if running on X) might be a
> more lightweight way of refreshing the menu.

Restarting the shell means restarting the desktop environment?

I know how to do it with i3 (reload config) but I don't know hot to do
it with LXDE (or mate, Gnome3, ecc.)

Cheers.

Gio'



[1] as I already wrote, I don't use any desktop environment graphical
menu so I rarely experience this issues, but when trying to help other
users I still cannot find a deterministic solution to this class of
issues.

[2] it also points to
but that node is /not/ present on a recent manual

[3]



--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmJv02QMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSFywQAIY0vmyexNexicFHcY6E5P764fEUrwq0165vCk4S
IZH6Gj8Xkg9WXxaZefEPJAfmyihGrsEJYukWxl4eXCDLIgkuYTvkfAzirBQjzIna
pJRxRcI/4p7Jnm7erggJI4zBXyChVoF2ku7+M7IKlxczrfUaGmbqaHetHcPJyuSy
FCvxrvodscFYyg+R2TVkEBfaQkUKcOoMNp+Wb+cT91groadop9wsr+KfnFJ8tBcc
zGRyPs0Y8/w9hnmpZihej0YybGqRDfSF1xDiwOozy9rqTkfMouQQ8l6mpqYzcXRB
YquuvsnMd6XG4kVSVWUJ3POH/sYqbS9sU6SFInkI8yn1c5NqznXuNgHvboqfkvhS
d5FYc6b6NoiTKj686gqTPGOruNd4mnZgPmzQAaSLZXjcGZO0ZksJuj3Ar9SPdw2u
MCrOhuxCx4I5sn9YAWC+CehGlY1fh7+qNkU3JD5kN7BozYpFBd9dNfhea2oPJqNB
kLjkmTbEgodbPP5dL4Y3h7vgi2+6QErlrX2UoHSmvptBMi5BINfm1PprUXUTXpeT
FNCjYcaPPr0Nn9hfVFaqTPvnyNejK1eePf5V3TjYa8BonNTgMGuJzH9/RN5ku85L
FVtAYqwm9XnvzctVBgEAoCARxPexHsLdNePIJb8Uq4OCB7bGERakFbIUXKzL/FZ6
9qwN
=YNOa
-----END PGP SIGNATURE-----

G
G
Giovanni Biscuolo wrote on 4 May 10:31 +0200
(address . 48796@debbugs.gnu.org)
875ymlem12.fsf@xelera.eu
Hi Liliana Marie,

Giovanni Biscuolo <g@xelera.eu> writes:

[...]

Toggle quote (3 lines)
> There is obviously a non zero chance it depends on my poor
> understanding, please forgive me in this case.

my "workaround" is an instance of this case, sorry (see below)

[...]

Toggle quote (3 lines)
> Yes: there is something in the default systemd/xsession configuration
> of Debian 11 that resets XDG_DATA_DIR.

I'm still pretty sure this is what's happening, but i still don't know
why

Toggle quote (2 lines)
> Please is there some user with a default Debian 11 xsession

[...]

Toggle quote (6 lines)
>>> The main point of this workaround is that I configure XDG_DATA_HOME,
>>> described in the specifications:
>> And that is evil.
>
> Please can you expand what do you mean with "evil"?

I'll answer myself: because XDG_DATA_HOME (and $XDG_CONFIG_HOME
obviously) must be writeable by user (processes) to store data (and
config); Guix profiles are (and obviously must be) write-only (they are
stateless, while data and config are (obviously) /status/.

My workaround simply messes up /every/ application that follows the XDG
standard (not all, but many) to save data and config,
e.g. TelegramDesktop

The one and ONLY solution to this problem is to get XDG_DATA_DIR
properly configured; Guix does this if $HOME/.guix-profile/etc/profile
is sourced in the user profile, but as I told "something" resets
XDG_DATA_DIR (AFAIU by default on Debian 11) in the "desktop manager"
profile to a "hardcoded" value.

I reverted the "workaround" and now my XDG_DATA_HOME points to the
default value $HOME/.local/share: applications are happy again but again
I cannot see Guix installed applications in the LXDE menu

[...]

Toggle quote (8 lines)
>> Other than that, restarting your shell (if running on X) might be a
>> more lightweight way of refreshing the menu.
>
> Restarting the shell means restarting the desktop environment?
>
> I know how to do it with i3 (reload config) but I don't know hot to do
> it with LXDE (or mate, Gnome3, ecc.)

I tried "bash -l -c 'lxpanelctl restart'" but applications still don't
appear

[...]

I'm still lost in environment :-(

Thanks! Gio'

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmJyOfoMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSdskQAIzJzDBHyMTW45c73mw/NFB+v9R9/aIFOMoC9Ek4
PghqMqZuWakRjtkGG0LIxZytmqgrqIUuYLn2ljIG/BDvP4FGaYxmnPIK2XR+SZ6l
KxYZoaT93oEDV34lj1Vkk9FMFMGXOrEhgmfFQsxvuWgEO8YARU2dKqlHWCNrWm4t
gbnIGCldbO58W/NtVJGybQKR1b8v0SbmgFGKwv2hSFQVPH0PN7+svzu0rfNu+nGT
SsKgQJYLMWvbe1H6sIYzjwsD5NPiA2xGXhUMWpNl4K4PlyvA/jwWqUrpFPjPNd3g
cSzFZhfwNfnZVHjmPD5l951J8G7Q3gd4qmejQXD11M4goVtEHpG1YhcgzM7xoIiY
24D5YPAVKc5lLnl41Z5XiWYT8i13+32J9Kluc/3JW+3lfYZTmRb5YAsQpby9ROJA
ozeGBbJpNW8xf7zOa63uQB97cugeYvAztBddeLS4xyQhEWOC8l/m1he+7sNQu1kd
XZBZV1emSg2Us4WTNjwBVuunGZpoS4iCMXO0hsF4kggjoTYDeFezWFzDzZEYdS2p
4L5W6IRRDon6H1P+E+bAPFNsvpN6BvZJUldHD4bgT+VIIwVuR87ZJV+TmJd4jT/9
fycpfZ8WrDavLY2IJWpr0s0qYBp0ePsfplPnNxtIr1jwq1z8mBvgTB3e8QBzZdAQ
wrvz
=9Zbm
-----END PGP SIGNATURE-----

L
L
Liliana Marie Prikler wrote on 4 May 21:14 +0200
(address . 48796@debbugs.gnu.org)
fad87031e3ad8eab7b397bf9963e6a1772203dac.camel@gmail.com
Am Montag, dem 02.05.2022 um 14:49 +0200 schrieb Giovanni Biscuolo:
Toggle quote (1 lines)
> Hi Liliana Marie,
Hi Giovanni,

sorry for the late reply. It seems my slowness caused you to
investigate things on your own, which might have prompted some wrong
conclusions.

Toggle quote (4 lines)
> I just think that if Guix (the package manager) cannot automate
> desktop integration on all foreign distros then it should be stated
> in the manual, possibly explaining why and pointing users to the
> foreign distro documentation.
Fair point and I agree (and even submitted a documentation patch once
already), but this problem hits a great many applications and can not
easily be described in all of its failure modes.

Toggle quote (15 lines)
> To add a little bit of context (and highlight it's not an issue just
> for Guix as a package manager) I found this bug reports interesting:
>
> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927907
> flatpak directories not added to XDG_DATA_DIRS on Plasma + Wayland
> (still open, last update 2022-04-16)
>
> 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931776
> snapd: Installed snaps do not appear in desktop launcher in Debian
> buster. (still open, last update 2022-04-22)
>
> 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647427
> XDG_DATA_DIRS not set when using openbox-gnome-session
> (resolved on 2013-07-23)
>
This seems to be a rather Debian-specific issue then. Note that Ubuntu
Focal Fossa (and probably later Ubuntus) don't experience these issues
because Ubuntu worked around them so that they can ship snaps by
default. If I wanted to look at this more closely, it'd make sense
then to look at the difference between a basic Debian installation and
a basic Ubuntu installation and check what they do differently w.r.t.
flatpak and snap.

Toggle quote (14 lines)
> > > > It even set XDG_DATA_DIRS, which should allow integration with
> > > > the GNOME Shell and other graphical dashboards.
> > >
> > > No: this does not work, for three reasons:
> > >
> > > 1. AFAIU "/etc/profile.d/guix.sh" or "~/.profile" are not
> > > sourced/executed in a graphical session (graphical shell?), we
> > > need to ~/.xsessionrc to configure that environment: am I wrong?
> > Depends on your setup.  Some systemd setups don't source it,
>
> So it depends on the /default/ systemd setup of the foreign distro,
> Debian 11 in this case, because I did not customize it: please do you
> know where I should check for the systemd specific documentation on
> "xdg related stuff"?
There are two things you need to look up. First, how to modify
environment variables systemd services, and second which service is
actually the one launching your session. Once you have both, you can
add an override, that starts it with your environment variables. I'm
not sure if you can tell systemd to "please source my ~/.profile.sh or
similar" easily, but that'd also be an option.

Toggle quote (3 lines)
> makes me wonder what (and why) is the differenxe betweeen a Gnome
> Session and an LXDE one: shouldn't the setup be standard? It's the
> systemd specific way to setup an xsession?
What do you mean by standard? The standard way of spawning a process
in Unix is fork() followed by exec(). All the shell interpreting in
between if you're using a bash-based flow is merely convenience.
Toggle quote (6 lines)
>

> > but note that you can work around that by editing the offending
> > file.
>
> Please can you point me to the offending file?
I don't sit on your computer and know too little about your setup to do
so. You can try various debugging techniques to find out which files
affect your environment variables in a graphical session.

Toggle quote (17 lines)
> > More importantly...
> >
> > > 2. XDG_DATA_DIRS gets someway hard reset by "something" to this
> > > value:
> > >
> > > XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib
> > > /men
> > > u-
> > > xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-
> > > xdg/
> > I would investigate what actually "resets" this.  If it survives
> > XDG_DATA_DIRS=blah $SHELL, then it's in the stuff your shell
> > sources.
>
> Actually if I give that command in a terminal I get
> "XDG_DATA_DIRS=blah", but I'm pretty sure there is nothing in the
> stuff of my shell sources that resets XDG_DATA_DIRS
Great. This means there is actually no resetting at all, your code to
set XDG_DATA_DIRS simply isn't evaluated at all and thus the variable
retains its default value, which is probably set somewhere internal to
systemd or the desktop manager.

Toggle quote (4 lines)
> > If it doesn't, then you probably just experience (1).
>
> Yes: there is something in the default systemd/xsession configuration
> of Debian 11 that resets XDG_DATA_DIR.
No, there isn't. It not being set doesn't mean that something's
resetting it, it can also mean the code to set it is not run. Since we
spawned a new shell and found the value unchanged, that is exactly
what's happening.

Toggle quote (4 lines)
> Please is there some user with a default Debian 11 xsession
> configuration that can try to reproduce this?
>
> Am I the only one to experience this XDG_DATA_DIR reset issue?
While I haven't experienced this with XDG_DATA_DIRS in particular, I
know the issue itself. However, I'm not sure if I'm getting across
what's behind it.

As noted above, the issue appears to be more or less specific to
Debian, as other distros tackle related problems w.r.t. flatpak and
snap and those solutions work for Guix too.
Toggle quote (3 lines)
> >

> 1. is that also a cross-distro standard?
Probably not to the extent you're hoping. I'd hazard a guess that
every window manager more or less rolls their own implementation, which
basically boils down to watching for changes in a certain directory.

Toggle quote (2 lines)
> 2. why "xdg-desktop-menu forceupdate" does not work for user
> installed *.desktop menus?
Probably because your environment variables are borked.

Toggle quote (3 lines)
> 3. is there any other CLI that allows users to uptate their graphical
> menus after having "manually installed" (write the right file in the
> right folder) a *.desktop file?
Not afaik.

Toggle quote (6 lines)
> > > [...]
> > > The main point of this workaround is that I configure
> > > XDG_DATA_HOME, described in the specifications:
> > And that is evil.
>
> Please can you expand what do you mean with "evil"?
I don't need to, you already found out yourself.

Toggle quote (5 lines)
> [...]
> Reading the above it seems perfectly legit to customize XDG_DATA_HOME
> pointing that variable to any user directory I need to add custom
> GUIX menu entries... and I let handle that menu entries to my guix
> profile: do I miss something?
You already found out, but to repeat: yes.

Toggle quote (2 lines)
> Should I also customize $XDG_CONFIG_HOME to point to a specific
> directory different from $HOME/.config?
No, unless you know what you're doing and/or are testing an application
that should not write to your actual configuration files.

Toggle quote (10 lines)
> >
> > > [...]
> > > Anyway to make the new installed *.desktop files appear in the
> > > menu, I have to logout and login again: I've still not found a
> > > command (or configuration) to update the menu, "xdg-desktop-menu
> > > forceupdate" does not work.
> > Should it?  It might only honor XDG_DATA_DIRS and ignore
> > XDG_DATA_HOME by accident.
>
> AFAIU xdg-desktop-menu is supposed to also update user menus
As per the XDG spec, XDG_DATA_DIRS is a preference-ordered PATH
consisting of directories to search for XDG_DATA. XDG_DATA_HOME not
being included in it is a violation of the XDG spec.

Toggle quote (7 lines)
> > Other than that, restarting your shell (if running on X) might be a
> > more lightweight way of refreshing the menu.
>
> Restarting the shell means restarting the desktop environment?
>
> I know how to do it with i3 (reload config) but I don't know hot to
> do it with LXDE (or mate, Gnome3, ecc.)
<M-f2> r RET, or Alt+F2 r Return if you prefer this style of writing
keybindings. In either case, that's the GNOME binding, but Mate should
have the same. (Don't know about LXDE.)


Cheers
G
G
Giovanni Biscuolo wrote on 5 May 19:16 +0200
(address . 48796@debbugs.gnu.org)
874k23dhmc.fsf@xelera.eu
Hi Liliana Marie,

thank you for your support but I'm still completely lost

Obviously this is a Debian 11 relate issue and there is nothing Guix can
do to solve this issue, so I propose to close this bug report

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

Toggle quote (8 lines)
>> I just think that if Guix (the package manager) cannot automate
>> desktop integration on all foreign distros then it should be stated
>> in the manual, possibly explaining why and pointing users to the
>> foreign distro documentation.
> Fair point and I agree (and even submitted a documentation patch once
> already), but this problem hits a great many applications and can not
> easily be described in all of its failure modes.

With the adoption of Freedesktop standard and systemd I just thought
that this kind of configuration (environment) would be... standard,
probably I'm wrong.

This also means that it's hard to support users (and for users to
auto-support) impementing Guix in their foreign-distro

[...]

Toggle quote (3 lines)
> This seems to be a rather Debian-specific issue then. Note that Ubuntu
> Focal Fossa (and probably later Ubuntus) don't experience these issues

OK, I just opened this thread on debian-user ml:

I'll see if there is someone there that knows how to customize a Debian
11 diplay manager environment

[...]

Thanks! Gio'

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmJ0BosMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSr1AP/irSPsp23uVMBeLiTSkdhl7u4sfuw53kswMaOr1D
Lx72ZNXTPzn1+4OJoZ2NlorFI9IYRUQnMkCAGaUxKxIF6p6QiEqU/bnRK6BOKf0S
ykP+bm8WMfU4knPOFwNw5lMKfhYFSH0yQ8mkkc/pnIsCLbs41a1K2MmS1ZatAWht
/TOZ91ttFd57TXjhUJ8UiEN15KRcsqe5eRbyEMu89wiJIpM9i8TkwsX6jXBy+16K
X2mmRt/JQTDqSW8Xt/jHqyIisYCT0Gxt9UzTgICgQlR13wrqvuVGfFI1CQ26rDFc
afjSMfbpZFEVONXHHPkvF2kj9pfpAyZZIhGxLTX+gg4tY2el08U0oL5KG0R8NKie
6j9bSTR6HjXG58VfH+l4J93y1T4jKSwbz2uGIZEnH80O6sNFrkwAmDKWMX9fTv3o
JEBjZdNVQSaXW5Hj2Z0joPrpYZKRwtyUGpJTDTaYJn39S0gtb/YbVE9kGZiBvSae
1vzU+fU+4UCbzm2ruz63MWabBxsg54Q6+Pq9JDsR/OlzSozCGg5NTpZw78n1AARA
v1gGJ5mStpPRuZcw89hhHbuGiEn+ZCqofQJxwdkQUvrQDDm0m78+IBq0tvw0cT9e
mEeVWsYtHJauKVZj0FEMg1FqoVN7NLAr+VsVoenTDb53dtfgo7sRXIbcHwFyjOo3
mFxq
=qnjJ
-----END PGP SIGNATURE-----

G
G
Giovanni Biscuolo wrote on 7 May 11:25 +0200
Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix
(address . 48796@debbugs.gnu.org)
8735hlbsnv.fsf@xelera.eu
Hello Maxim,

sorry to come back to this after so long but this is still a bug

I'm still trying to solve how to configure the "environment machinery"
on a new Debian 11 laptop, on this machine there is no old user
configuration status that could interfere: it's a brand new Debian 11
"basic" desktop

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

Toggle quote (7 lines)
> There are two things that Guix does to help users correctly configure
> their system so that Guix installed applications appear on PATH.
>
> 1. The guix-install.sh installation script installs a
> /etc/profile.d/guix.sh script that configures the PATH when logging
> in:

I've installed guix using the Debian package (apt install guix) and it
installed /etc/profile.d/guix.sh, I have it

[...]

Toggle quote (4 lines)
> I suspect you didn't install Guix via this script? If so, could you try
> creating the above file, closing relogin in your graphical session and
> report if it fixed things for you?

No, if I remove all the Guix related environment settings from the user
~/.profile (plz see my recent messages in this bug report for details if
you need) no environment variable from $GUIX_PROFILE/etc/profile (the
file is there) is sourced in the resulting graphical user session: I
tried both with LXDE and Mate (via lightdm)

That file is sourced and environment variables are properly configured
only via a succesful console login (ALT+F1) or an ssh login from a
remote machine, I've tried

The sourcing of /etc/profile.d/guix.sh is only working if I source that
file from ~/.xsessionrc:

Toggle snippet (13 lines)
if [ -f ~/.profile ]; then
. ~/.profile
fi

if [ -f /etc/profile.d/guix.sh ]; then
. /etc/profile.d/guix.sh
fi

export XSESSION_WAS_HERE="Yes"


This is the (partial) env after I succesfully login in LXDE, I got it
starting LXTerminal from the graphical session:

Toggle snippet (29 lines)
GUIX_LOCPATH=/home/patrizia/.guix-profile/lib/locale
GUIX_PROFILE=/home/patrizia/.guix-profile
XDG_CONFIG_DIRS=/etc/xdg/lubuntu:/etc/xdg
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session2
XDG_MENU_PREFIX=lxde-
XDG_DATA_HOME=/home/patrizia/.local/share
XDG_CONFIG_HOME=/home/patrizia/.config
XDG_SEAT=seat0
XDG_SESSION_DESKTOP=LXDE
XDG_SESSION_TYPE=x11
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/patrizia
XDG_CURRENT_DESKTOP=LXDE
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_CLASS=user
XDG_VTNR=7
XDG_SESSION_ID=12
XDG_RUNTIME_DIR=/run/user/1001
XDG_DATA_DIRS=/etc/xdg/lubuntu:/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session2
GIT_EXEC_PATH=/home/patrizia/.guix-profile/libexec/git-core
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
INFOPATH=/home/patrizia/.config/guix/current/share/info:
GUIX_LOCPATH=/home/patrizia/.guix-profile/lib/locale
PATH=/home/patrizia/.guix-profile/bin:/home/patrizia/.guix-profile/sbin:/home/patrizia/.config/guix/current/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
GIO_EXTRA_MODULES=/home/patrizia/.guix-profile/lib/gio/modules


Unfortunately, still XDG_DATA_DIRS is reset to a different value after I
login to a LXDE user session (lxsession); please see my recent messages
in this bug report for details; so basically I can run all Guix
installed application "manually" but they are missing from the menu,
also all the mime/type->application associasions are missing in the
filemanager

I've also opened a thread for this specific issue on debian-user:
but how XDG_DATA_DIRS is reset after ~/.xsession sourcing is still a
great mistery.

More unfortunately, if I try to login using a Mate session (with the
above configuration, thus with that environment) it fails with this
error (via journalctl):

Toggle snippet (6 lines)
mag 07 09:21:14 raifort mate-session[818]: GLib-GIO-ERROR: Settings schema 'org.mate.session' is not installed
aborting...


If I remove /etc/profile.d/guix.sh from the user's ~/.xsession Mate is
able to login with no problems (is this related to GIO_EXTRA_MODULES?)
but I miss the Guix environment variables, obviously.

[...]

Happy hacking! Gio'

--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmJ2OyQMHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSrPYP/j8nzCcZeQmFTPuPZr11Mq43kMQrw6RH5VyrJHAU
NsvgGE12On8paG7HneAT0hoFmgHg38RCiEgPvexr96IVU1jJGhkffRHuZw+/CvY3
qL+Jl3Q5UCLd0rNnVjjU82Cnt8BlRDSFabKKqFAJVJjjkpbzn87VKpLJYcBse0Ab
/D8m9CEUVPBnUSIY+vjKQapl898vLw7wWBLdWxoUzZ7D6iLhZ9JejtVLmwLxXrV5
A4avKhIXMrK9ktkY9QjcSG/hjr9M7zkKMGUOG3hPRzQAZvI1WPGrHd6si4WhQypG
W9HZO93En49ooUblkzCEhwkO+qucvZHxK+0M8GxQe5/LjHkvlVCI5IGqZ1B8d8uD
GCgAiUDkHTiUuKX0aHIqyBPO7ISAaRWsNyisRQrD3MMvyS9IPyOBuICflXezbN51
5kwENgYsFf0WBlRn/ZMUlsdqc2t+rA8Fut45RccAl66tqR5Ed4YZVmYUWbA7QF7I
r0twgYE9n3DSrH/7wt1Ps5BiIATATs/FejsfWgjvxphckZ9TEeaxNWUTnHl5cSB9
g4W3kGMhJ+3AkdJuoz1sKBsFcNW1U0tJ4fQk3m4Dg94U4Dp4hit6P1a1Z/BhU9pR
xS9JM0nq/BEKMwxsBTSRW2p+lJEXTYm+GRvFw5Gd7AKVAQGbTO5tty1CViHcW1mF
04ev
=dlY2
-----END PGP SIGNATURE-----

G
G
Giovanni Biscuolo wrote on 7 May 12:59 +0200
(address . 48796@debbugs.gnu.org)
87tua1a9rk.fsf@xelera.eu
Hello Maxim,

I finally was able to get a working Mate desktop environment, with all
Guix installed apps listed in the graphical menu and all the
mime->applications associations working as expected

Getting a user Xsession environment suitable for Guix on a foreign
distro unfortunately is a very hard task, because things seems to be
dependant on many "things" related on what distro /and/ session-manager
is used ;-(

Giovanni Biscuolo <g@xelera.eu> writes:

[...]

Toggle quote (14 lines)
> More unfortunately, if I try to login using a Mate session (with the
> above configuration, thus with that environment) it fails with this
> error (via journalctl):
>
> --8<---------------cut here---------------start------------->8---
>
> mag 07 09:21:14 raifort mate-session[818]: GLib-GIO-ERROR: Settings schema 'org.mate.session' is not installed
> aborting...
>
> --8<---------------cut here---------------end--------------->8---
>
> If I remove /etc/profile.d/guix.sh from the user's ~/.xsession Mate is
> able to login with no problems (is this related to GIO_EXTRA_MODULES?)

No, I found out why Mate was not starting: «At runtime, GSettings looks
for schemas in the glib-2.0/schemas subdirectories of all directories
specified in the XDG_DATA_DIRS environment variable.» (from man
glib-compile-schemas [1])

I figured out what was wrong when looking at XDG_DATA_DIRS env variable
after a console login for that user:

XDG_DATA_DIRS=/home/patrizia/.guix-profile/share

XDG_DATA_DIR was missing the Debian default "/usr/share/" directory
where all packages are installing schemas

I fixed the problem with this workaround in /etc/profile.d/guix.sh:

Toggle snippet (9 lines)
[...]

# set XDG_DATA_DIRS to include Guix installations
# export XDG_DATA_DIRS="$GUIX_PROFILE/share:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}"
export XDG_DATA_DIRS="$XDG_DATA_DIRS:/usr/local/share/:/usr/share/"


I commented out that export because the sourced
$GUIX_PROFILE/etc/profile already exports a proper XDG_DATA_DIRS
variable, IMHO it should be removed from upstream

Then I added the last line to (re)add "/usr/local/share/:/usr/share/",
so now mate-session is happy again

I'm still wondering how we can document and/or provide proper
distro-agnostic configuration files for Xsessions on foreign disrtos.

Unfortunately the situation is still /very/ confising for users

Happy hacking! Gio'



--
Giovanni Biscuolo

Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----

iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmJ2UQ8MHGdAeGVsZXJh
LmV1AAoJENN9DqfOzDkSCCoQAKJT5TFa5MtLGNHWWSO/NRVgBNnnior9zk/nNWLV
7x0nw2+/xFD1y0fX3Olpxznkfiq8fjNdpYurbcnqDSPOe36iRj9dhw/zmpXoxF1t
I6pL9yCc+BxdPtPZwfehSlQqmlHcsbWPW8FOWkSIDzCmi0u87lL3FGOY8BCy0QYG
TMexCuxPUvoUY2+AbX3omdK/+hzgI/8sZgark0M+QMJTRBGAoi/SDHPUbfqaar1O
B9FvzhyJiMcrtaTLJxmq9UrapVRwAb4YSZI5SyDVNqimrtTUnEu/PPdZHj22iVza
GF22cPuujW5cJXp2WIHnYQMAE2GMVEV8J8O5xpc7APZi2OojBzmltcw9GuSXLsew
yHPuAApl7Dskh789ZArF+H7tKSM8+uVLmDeHpo+yPg1kSOXJI+j1bkIPUnblpmuX
RZPFxXx3kZgA+8S7h+TRfxrV9uxef6FRlK9YK86eBNiJ8WGC47bGdnr5t7480Rds
JcFQc2qDByFsq0LlaPnrFxavSwF1TClU4Ky8GYWe1ra/th2JsbS/OfadIuG/zRa+
IXIk3AetCz43dR9T9y9BlfcKLCir0qdHFbn2KWM1BBNCClBjr2dCE5Tt65F/9Yar
+/zNT9hPnTp3gKQ3m8KWgGmbIRmSw81QHhkPEXaTdBRNIKwopJzXjz0CGGl5eEsK
8wpl
=Dn98
-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 23 Jun 10:20 +0200
(address . 48796@debbugs.gnu.org)
86r13f94fa.fsf@gmail.com
Hi,

This report #48796 [1] is marked as moreinfo since some weeks. Although
I understand the need, but since I do not see what could be the next
actionable step, I am in favor to close it.


Therefore, if no objection and/or a clear next action, then I will close
it in the coming weeks.

Cheers,
simon
?