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

Done

Details

9 participants

bo0od
bo0od
Luke Burgess
Giovanni Biscuolo
Liliana Marie Prikler
Maxim Cournoyer
Maxime Devos
Mark H Weaver
zimoun

Owner: unassigned

Submitted by: bo0od

Severity: normal

bo0od wrote on 2 Jun 2021 20:56

Recipients:(address . bug-guix@gnu.org)

Message-ID: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!

Maxime Devos wrote on 3 Jun 2021 23:26

Recipients:

Message-ID: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-----

bo0od wrote on 4 Jun 2021 01:18

Recipients:

Message-ID: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.
>

Maxime Devos wrote on 5 Jun 2021 11:47

Recipients:

Message-ID: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-----

bo0od wrote on 5 Jun 2021 13:25

Recipients:

Message-ID: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

Mark H Weaver wrote on 5 Jun 2021 19:49

Recipients:

Message-ID: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.

Giovanni Biscuolo wrote on 17 Jun 2021 16:56

Recipients:

Message-ID: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

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

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

zimoun wrote on 2 Jul 2021 18:31

Recipients:(name . bo0od)(address . bo0od@riseup.net)(address . 48796@debbugs.gnu.org)

Message-ID: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.

1: http://issues.guix.gnu.org/issue/48796#5

Cheers,

simon

PS: I plan to mark the bug as notabug, WDYT?

bo0od wrote on 15 Jul 2021 15:09

Recipients:(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 48796@debbugs.gnu.org)

Message-ID: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?

bo0od wrote on 15 Jul 2021 16:05

Recipients:

Message-ID: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.

Luke Burgess wrote on 23 Aug 2021 02:58

Just a newb, srsly this saved me

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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

zimoun wrote on 23 Aug 2021 12:42

Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix

Recipients:(name . bo0od)(address . bo0od@riseup.net)(address . 48796@debbugs.gnu.org)

Message-ID: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

https://docs.flatpak.org/en/latest/using-flatpak.html#running-applications

Then reading:

https://docs.flatpak.org/en/latest/desktop-integration.html

https://docs.flatpak.org/en/latest/conventions.html

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

zimoun wrote on 23 Aug 2021 12:20

Recipients:(name . bo0od)(address . bo0od@riseup.net)

Message-ID: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.

http://guix.gnu.org/manual/devel/en/guix.html#Application-Setup

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

Maxim Cournoyer wrote on 23 Sep 2021 13:56

Recipients:(name . Luke Burgess)(address . burgesl@gmail.com)(address . 48796@debbugs.gnu.org)

Message-ID: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

Maxim Cournoyer wrote on 23 Sep 2021 14:10

Recipients:(name . bo0od)(address . bo0od@riseup.net)(address . 48796@debbugs.gnu.org)

Message-ID: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

bo0od wrote on 24 Sep 2021 22:46

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)(address . 48796@debbugs.gnu.org)

Message-ID: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
>

Maxim Cournoyer wrote on 26 Sep 2021 07:50

Recipients:(name . bo0od)(address . bo0od@riseup.net)(address . 48796@debbugs.gnu.org)

Message-ID: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

zimoun wrote on 5 Jan 2022 00:16

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:86mtkbay8b.fsf@gmail.com

Hi,

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

1: http://issues.guix.gnu.org/issue/48796

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

2: https://issues.guix.gnu.org/issue/48796#5

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

zimoun wrote on 12 Apr 2022 11:51

control message for bug #48796

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87lewa6346.fsf@gmail.com

tags 48796 + moreinfo

quit

Giovanni Biscuolo wrote on 28 Apr 2022 16:14

Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix

Recipients:

Message-ID: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

[...]

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

Giovanni Biscuolo wrote on 28 Apr 2022 17:59

Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix in Desktop Menus

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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

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

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)

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

Liliana Marie Prikler wrote on 29 Apr 2022 21:18

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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

Giovanni Biscuolo wrote on 2 May 2022 14:49

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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:

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)

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:

- https://wiki.debian.org/Xsession[2]

- https://wiki.debian.org/EnvironmentVariables#Using_graphical_display_manager

This statement (in https://wiki.debian.org/Xsession)

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?

Also: https://manpages.org/xsession/5

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

https://www.debian.org/doc/manuals/debian-reference/ch07.en.html#_starting_the_x_window_system

but that node is /not/ present on a recent manual

[3]

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables

[4] https://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_starting_a_program_from_gui

[5] https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html#third-party-howto

Giovanni Biscuolo

Xelera IT Infrastructures

Giovanni Biscuolo wrote on 4 May 2022 10:31

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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

Liliana Marie Prikler wrote on 4 May 2022 21:14

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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

Giovanni Biscuolo wrote on 5 May 2022 19:16

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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:

https://lists.debian.org/debian-user/2022/05/msg00153.html

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

Giovanni Biscuolo wrote on 7 May 2022 11:25

Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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

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

. /etc/profile.d/guix.sh

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:
https://lists.debian.org/debian-user/2022/05/msg00153.html
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

Giovanni Biscuolo wrote on 7 May 2022 12:59

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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'

[1] https://manpages.debian.org/experimental/libglib2.0-bin/glib-compile-schemas.1.en.html

Giovanni Biscuolo

Xelera IT Infrastructures

zimoun wrote on 23 Jun 2022 10:20

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID: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.

1: http://issues.guix.gnu.org/issue/48796

Therefore, if no objection and/or a clear next action, then I will close

it in the coming weeks.

Cheers,

simon

zimoun wrote on 8 Oct 2022 16:37

Recipients:(address . 48796-done@debbugs.gnu.org)

Message-ID:86v8ous7nz.fsf@gmail.com

Hi,

On Thu, 23 Jun 2022 at 10:20, zimoun <zimon.toutoune@gmail.com> wrote:

Toggle quote (9 lines)

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

> 1: <http://issues.guix.gnu.org/issue/48796>

> Therefore, if no objection and/or a clear next action, then I will close

> it in the coming weeks.

After waiting 3 months, closing.

Cheers,

simon

Closed

bo0od wrote on 14 Oct 2022 19:35

Re: bug#48796: closed (Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix)

Recipients:(address . 48796@debbugs.gnu.org)

Message-ID:b2a32780-9c09-f731-040c-5cd49a28602c@whonix.org

Everything is explained well in the past posts but no fixation proposed.

Saying need info while all the info there is just ridiculous, closing 
the bug is just a bug skip not fix which lead to either more comments 
here or duplicates tickets else where.

Unless there is a policy saying guix for guix OS only not for any other 
OS then this ticket is still valid.

GNU bug Tracking System:

Toggle quote (9 lines)> Your bug report
> 
> #48796: Guix on Debian 11 - Cant run or find applications from Guix
> 
> which was filed against the guix package, has been closed.
> 
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 48796@debbugs.gnu.org.
>

Attachment: OpenPGP_0xED4E3C19ACA54DD4.asc

Attachment: OpenPGP_signature

Maxim Cournoyer wrote on 17 Oct 2022 03:30

Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix

Recipients:(name . bo0od)(address . bo0od@whonix.org)(address . 48796@debbugs.gnu.org)

Message-ID:87a65vz17h.fsf_-_@gmail.com

Hi,

bo0od <bo0od@whonix.org> writes:

Toggle quote (9 lines)

> Everything is explained well in the past posts but no fixation proposed.

> Saying need info while all the info there is just ridiculous, closing

> the bug is just a bug skip not fix which lead to either more comments

> here or duplicates tickets else where.

> Unless there is a policy saying guix for guix OS only not for any

> other OS then this ticket is still valid.

I understand getting your issue closed without an apparent resolution
can be frustrating, but please keep the discussion courteous; we're
volunteers trying to keep the mountain of reported issues current and in
check.

For your info, this was fixed if you use the
https://guix.gnu.org/install.shscript with commits
30810aff713149d53cb25f36ae6d721ec66385da and
7ff169d04f52b15393b33a97959e2cd6a5957e26.

-- 
Thanks,
Maxim

Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it

mumi current 48796

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch