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

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

[bo0od]

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!

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

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[bo0od]

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

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

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

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

[bo0od]

[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

 > (a) IceCat does not appear in the application menu at all

This one

 > What's the output of...

Check the uploaded image.

Maxime Devos:
> 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 #2: guixpaths.png --]
[-- Type: image/png, Size: 60221 bytes --]

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

[Mark H Weaver]

Hi,

bo0od <bo0od@riseup.net> writes:

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

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 4897 bytes --]

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:

[...]

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

--8<---------------cut here---------------start------------->8---

GUIX_PROFILE="$HOME/.config/guix/current"
. "$GUIX_PROFILE/etc/profile"

--8<---------------cut here---------------end--------------->8---

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:

--8<---------------cut here---------------start------------->8---

if [ -f ~/.profile ]; then
    . ~/.profile
fi

--8<---------------cut here---------------end--------------->8---

My (edited) ~/.profile:

--8<---------------cut here---------------start------------->8---

### 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"

--8<---------------cut here---------------end--------------->8---

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:

--8<---------------cut here---------------start------------->8---

$HOME/.config/guix/current -> /var/guix/profiles/per-user/root/current-guix
$HOME/.guix-profile -> /var/guix/profiles/per-user/giovanni/guix-profile

--8<---------------cut here---------------end--------------->8---

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

[...]

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

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

--8<---------------cut here---------------start------------->8---

if [ -f ~/.profile ]; then
    . ~/.profile
fi

--8<---------------cut here---------------end--------------->8---

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

> which should be an executable Bash script

AFAIU it can be a regular file

[...]

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[zimoun]

Hi,

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

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

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

[bo0od]

 > 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:
> Does this message [1] fix your issue?

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

[bo0od]

 > 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:
> I'll try do propose some patch for the Guix manual but... don't hold
> your breath, I need some testing.

bug#48796: Just a newb, srsly this saved me

[Luke Burgess]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

>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 #2: Type: text/html, Size: 1249 bytes --]

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

[zimoun]

Hi,

On Thu, 15 Jul 2021 at 14:05, bo0od <bo0od@riseup.net> wrote:
>> 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

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

[zimoun]

Hi,

On Thu, 15 Jul 2021 at 13:09, bo0od <bo0od@riseup.net> wrote:
>> 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:

--8<---------------cut here---------------start------------->8---
$ flatpak run org.gimp.GIMP
--8<---------------cut here---------------end--------------->8---

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

> 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

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

[Maxim Cournoyer]

Hello,

Luke Burgess <burgesl@gmail.com> writes:

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

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

[Maxim Cournoyer]

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

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

[bo0od]

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

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

[Maxim Cournoyer]

Hello,

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.

> 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

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

[zimoun]

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


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

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

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:

> 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

[...]

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 4646 bytes --]

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:

[...]

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

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

[...]

> # 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:

--8<---------------cut here---------------start------------->8---

### 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"

--8<---------------cut here---------------end--------------->8---

and in ~/.xsessionrc:

--8<---------------cut here---------------start------------->8---

if [ -f ~/.profile ]; then
    . ~/.profile
fi
 
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---

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

--8<---------------cut here---------------end--------------->8---
(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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Liliana Marie Prikler]

Hi Giovanni,

Am Donnerstag, dem 28.04.2022 um 17:59 +0200 schrieb Giovanni Biscuolo:
> [...]
> > # 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...

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

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

> [...]
> The main point of this workaround is that I configure XDG_DATA_HOME,
> described in the specifications:
And that is evil.

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

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 10069 bytes --]

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:

[...]

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

--8<---------------cut here---------------start------------->8---

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

--8<---------------cut here---------------end--------------->8---

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:

--8<---------------cut here---------------start------------->8---

# $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

--8<---------------cut here---------------end--------------->8---

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

> but note that you can work around that by editing the offending file.

Please can you point me to the offending file?

> 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

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

>> (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?

>> [...]
>> 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:

--8<---------------cut here---------------start------------->8---

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.

--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---

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.

--8<---------------cut here---------------end--------------->8---

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?

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

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]

Hi Liliana Marie,

Giovanni Biscuolo <g@xelera.eu> writes:

[...]

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

[...]

> 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

> Please is there some user with a default Debian 11 xsession

[...]

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

[...]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Liliana Marie Prikler]

Am Montag, dem 02.05.2022 um 14:49 +0200 schrieb Giovanni Biscuolo:
> 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

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:

[...]

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

[...]

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 4749 bytes --]

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:

[...]

> 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

[...]

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

--8<---------------cut here---------------start------------->8---

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"

--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---

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

--8<---------------cut here---------------end--------------->8---

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):

--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?)
but I miss the Guix environment variables, obviously.

[...]

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

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:

[...]

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

--8<---------------cut here---------------start------------->8---

[...]

# 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/"

--8<---------------cut here---------------end--------------->8---

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

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

[zimoun]

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

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

[zimoun]

Hi,

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

> 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

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

[bo0od via Bug reports for GNU Guix]

[-- Attachment #1.1.1: Type: text/plain, Size: 711 bytes --]

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:
> 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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3161 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Maxim Cournoyer]

Hi,

bo0od <bo0od@whonix.org> writes:

> 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.sh script with commits
30810aff713149d53cb25f36ae6d721ec66385da and
7ff169d04f52b15393b33a97959e2cd6a5957e26.

-- 
Thanks,
Maxim