Guix Home generated .profile sets XDG_ vars that break GDM+Gnome login on foreign distros

Done

Details

3 participants

Andrew Tropin
Liliana Marie Prikler
Matt Armstrong

Owner: unassigned

Submitted by: Matt Armstrong

Severity: normal

Matt Armstrong wrote on 22 Nov 2022 07:02

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

Message-ID:87fsebbk80.fsf@rfc20.org

I am experimenting with Guix Home on Debian Testing, using GDM+Gnome.

The .profile generated by "guix home reconfigure" broke logging in to

the Gnome desktop. The gnome session would die, failing to initialize

what it considered to be essential things, and return to the login

screen I could log in to a tty, and was able to undo the new .profile

and get back to a working system.

The home-configuration.scm I used was generated by "guix home import"

and was quite simple:

----------------------------------------------------------------------

(use-modules (gnu home)

(gnu packages)

(gnu services)

(guix gexp)

(gnu home services shells))

(home-environment

;; Below is the list of packages that will show up in your

;; Home profile, under ~/.guix-home/profile.

(packages (specifications->packages (list "glibc-locales")))

;; Below is the list of Home services. To search for available

;; services, run 'guix home search KEYWORD' in a terminal.

(services

(list (service home-bash-service-type

(home-bash-configuration

(aliases '(("ls" . "ls --color=auto")))

(bashrc (list (local-file ".bashrc" "bashrc")))

(bash-logout (list (local-file ".bash_logout"

"bash_logout"))))))))

----------------------------------------------------------------------

Note: a stock GDM+Gnome setup runs the user's login shell when logging

in via the GDM display manager, and this shell execs

gnome-session-binary. This doesn't necessarily happen with other

display managers or other desktop environments, so on those systems the

Guix Home .profile may not even run before the DE is initialized.

Nearly all of my time debugging this was spent figuring this out! :-)

The .profile file generated by Guix Home is this:

----------------------------------------------------------------------

HOME_ENVIRONMENT=$HOME/.guix-home

. $HOME_ENVIRONMENT/setup-environment

$HOME_ENVIRONMENT/on-first-login

----------------------------------------------------------------------

The first thing I see is that $HOME/.guix-home/seutp-environment is

modifying various XDG_ variables incorrectly. It prepends new values

without honor the variable's default value if it doesn't happen to be

set already.

For example, if XDG_DATA_DIRS is not set its default value is

"/usr/local/share/:/usr/share/".

But .guix-home/setup-environment will instead prepend a value without

checking, leaving XDG_DATA_DIRS set incorrectly to

"$HOME/.guix-home/profile/share:" when it should be

"$HOME/.guix-home/profile/share:/usr/local/share/:/usr/share/".

See this code in setup-environment:

case $XDG_DATA_DIRS in

*$HOME_ENVIRONMENT/profile/share*) ;;

*) export XDG_DATA_DIRS=$HOME_ENVIRONMENT/profile/share:$XDG_DATA_DIRS ;;

esac

The correct idiom is this:

XDG_DATA_DIRS=PATH_TO_PREPEND:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}

XDG_DATA_DIRS=${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:PATH_TO_APPEND

The above is what I see in various Nix and Snap configuration files.

Because I have a few other things installed that modify XDG_DATA_DIRS

before Guix Home does, Guix Home doesn't break that particular variable.

It did break XDG_CONFIG_DIRS, since Guix Home was setting it to

"$HOME/.guix-home/profile/etc/xdg:". I worked around this problem by

running this code before Guix Home's .profile:

# Note: when XDG_CONFIG_DIRS is not set Guix home sets

# XDG_CONFIG_DIRS="$HOME/.guix-home/profile/etc/xdg:", which removes

# the default "/etc/xdg" value.

if [[ -z $XDG_CONFIG_DIRS ]]; then

XDG_CONFIG_DIRS=/etc/xdg

# Note: when XDG_DATA_DIRS is not set Guix home sets

# XDG_DATA_DIRS="$HOME/.guix-home/profile/share:", which removes the

# default "/usr/local/share:/usr/share" value.

if [[ -z $XDG_DATA_DIRS ]]; then

XDG_DATA_DIRS="/usr/local/share:/usr/share"

I have other more minor quibbles about how Guix Home handles XDG values:

XDG_STATE_HOME is set to a non-standard value. In the current XDG Base

Directory Specification it defaults to "$HOME/.local/state", but Guix

Home sets it to "$HOME/.local/var/lib". On a foreign distro this is

going to cause some disruption when a user switches to Guix Home, or

switches away.

XDG_LOG_HOME is a non-standard variable. The spec suggests that logs

should go in XDG_STATE_HOME. Why not a establish a GUIX_LOG_HOME

variable instead? (if it ever does become a standard XDG variable, its

default may not be the same one picked by Guix Home, causing the same

issue as above).

Setting XDG_RUNTIME_DIR is not something I would expect Guix Home to do

-- it is the job of whatever logs the user in.

XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME are set to their defaults

unnecessarily.

I modified my personal config by unsetting XDG_STATE_HOME, XDG_LOG_HOME,

XDG_CACHE_HOME, XDG_CONFIG_HOME, and XDG_DATA_HOME if Guix Home left

them set to their default values (in the case of XDG_STATE_HOME I unset

it unconditionally).

Liliana Marie Prikler wrote on 22 Nov 2022 08:09

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

Message-ID:b67b432bd83c5ca6fb2514d7f1df86c1d3880aa2.camel@ist.tugraz.at

Am Montag, dem 21.11.2022 um 22:02 -0800 schrieb Matt Armstrong:

Toggle quote (4 lines)

> The first thing I see is that $HOME/.guix-home/seutp-environment is

> modifying various XDG_ variables incorrectly.� It prepends new values

> without honor the variable's default value if it doesn't happen to be

> set already.

This is a known problem with Debian. Unlike Ubuntu, which relies on

Flatpak and Snaps for its basic operations, Debian doesn't and hence

hasn't set up these variables explicitly. Note that this isn't unique

to Guix Home or even just Guix.

Toggle quote (2 lines)

> For example, if XDG_DATA_DIRS is not set its default value is

> "/usr/local/share/:/usr/share/".

None of these directories exist in Guix System. Assuming them would be

a fault. Note that the install script you're meant to use already

initializes these variables since July [1].

Toggle quote (3 lines)

> XDG_STATE_HOME is set to a non-standard value.� In the current XDG

> Base Directory Specification it defaults to "$HOME/.local/state", but

> Guix Home sets it to "$HOME/.local/var/lib".

This is a genuine bug with Guix Home.

Toggle quote (5 lines)> XDG_LOG_HOME is a non-standard variable.� The spec suggests that logs
> should go in XDG_STATE_HOME.� Why not a establish a GUIX_LOG_HOME
> variable instead?� (if it ever does become a standard XDG variable,
> its default may not be the same one picked by Guix Home, causing the
> same issue as above).

Another genuine bug with Guix Home, although the variable does predate

our support for XDG_STATE_HOME. I suggest finding all uses of this

variable in Guix Home and replacing them accordingly.

Toggle quote (2 lines)

> Setting XDG_RUNTIME_DIR is not something I would expect Guix Home to

> do -- it is the job of whatever logs the user in.

I'm unsure about that one.

Toggle quote (2 lines)

> XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME are set to their

> defaults unnecessarily.

Explicit is better than implicit.

Cheers

[1]

http://git.savannah.gnu.org/cgit/guix.git/commit/?id=23aafc800c9e678662766440916449ec5bbce830

Andrew Tropin wrote on 13 Dec 2022 06:22

Re: bug#59474: Guix Home generated .profile sets XDG_ vars that break GDM+Gnome login on foreign distros

Recipients:

Message-ID:878rjbaneo.fsf@trop.in

On 2022-11-22 08:09, Liliana Marie Prikler wrote:

Toggle quote (17 lines)> Am Montag, dem 21.11.2022 um 22:02 -0800 schrieb Matt Armstrong:
>> The first thing I see is that $HOME/.guix-home/seutp-environment is
>> modifying various XDG_ variables incorrectly.� It prepends new values
>> without honor the variable's default value if it doesn't happen to be
>> set already.
> This is a known problem with Debian.  Unlike Ubuntu, which relies on
> Flatpak and Snaps for its basic operations, Debian doesn't and hence
> hasn't set up these variables explicitly.  Note that this isn't unique
> to Guix Home or even just Guix.
>
>> For example, if XDG_DATA_DIRS is not set its default value is
>> "/usr/local/share/:/usr/share/".
> None of these directories exist in Guix System.  Assuming them would be
> a fault.  Note that the install script you're meant to use already
> initializes these variables since July [1].
>

I understand the inconvinience, but not sure that it has to be fixed on

Guix Home side. According to the specification it's a fallback value

not a default value.

Toggle snippet (4 lines)

If $XDG_DATA_DIRS is either not set or empty, a value equal to

/usr/local/share/:/usr/share/ should be used.

XDG_DATA_DIRS is not empty in our case and hence /usr/local/share and
/usr/share doesn't have to be used.  If it's critical for operation it
should be set before ~/.guix-home/setup-environment called, I would say
it looks like a debian bug, not Guix Home.  They same thing is true for
XDG_CONFIG_DIRS.

Toggle quote (15 lines)>> XDG_STATE_HOME is set to a non-standard value.� In the current XDG
>> Base Directory Specification it defaults to "$HOME/.local/state", but
>> Guix Home sets it to "$HOME/.local/var/lib".
> This is a genuine bug with Guix Home.
>
>> XDG_LOG_HOME is a non-standard variable.� The spec suggests that logs
>> should go in XDG_STATE_HOME.� Why not a establish a GUIX_LOG_HOME
>> variable instead?� (if it ever does become a standard XDG variable,
>> its default may not be the same one picked by Guix Home, causing the
>> same issue as above).
> Another genuine bug with Guix Home, although the variable does predate
> our support for XDG_STATE_HOME.  I suggest finding all uses of this
> variable in Guix Home and replacing them accordingly.
>

XDG_STATE_HOME and XDG_LOG_HOME apppeared in Guix Home before they were

described in xdg base directory specification, so the values was picked

to mimic FHS. Probably they should be adjusted to the values defined in

specification.

Toggle quote (5 lines)

>> Setting XDG_RUNTIME_DIR is not something I would expect Guix Home to

>> do -- it is the job of whatever logs the user in.

> I'm unsure about that one.

If it's set by elogind or whatever - cool, we will use value provided,

if not we explicitly set it, looks ok to me.

Toggle quote (14 lines)>> XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME are set to their
>> defaults unnecessarily.
> Explicit is better than implicit.
>
> Cheers
>
>
> [1]
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=23aafc800c9e678662766440916449ec5bbce830
>
>
>
>

-- 
Best regards,
Andrew Tropin

Andrew Tropin wrote on 2 May 2023 04:55

Recipients:

Message-ID:87h6sv1lxv.fsf@trop.in

On 2022-11-21 22:02, Matt Armstrong wrote:

Toggle quote (124 lines)> I am experimenting with Guix Home on Debian Testing, using GDM+Gnome.
> The .profile generated by "guix home reconfigure" broke logging in to
> the Gnome desktop.  The gnome session would die, failing to initialize
> what it considered to be essential things, and return to the login
> screen I could log in to a tty, and was able to undo the new .profile
> and get back to a working system.
>
> The home-configuration.scm I used was generated by "guix home import"
> and was quite simple:
>
> ----------------------------------------------------------------------
> (use-modules (gnu home)
>              (gnu packages)
>              (gnu services)
>              (guix gexp)
>              (gnu home services shells))
>
> (home-environment
>   ;; Below is the list of packages that will show up in your
>   ;; Home profile, under ~/.guix-home/profile.
>   (packages (specifications->packages (list "glibc-locales")))
>
>   ;; Below is the list of Home services.  To search for available
>   ;; services, run 'guix home search KEYWORD' in a terminal.
>   (services
>    (list (service home-bash-service-type
>                   (home-bash-configuration
>                    (aliases '(("ls" . "ls --color=auto")))
>                    (bashrc (list (local-file ".bashrc" "bashrc")))
>                    (bash-logout (list (local-file ".bash_logout"
>                                                   "bash_logout"))))))))
> ----------------------------------------------------------------------
>
> Note: a stock GDM+Gnome setup runs the user's login shell when logging
> in via the GDM display manager, and this shell execs
> gnome-session-binary.  This doesn't necessarily happen with other
> display managers or other desktop environments, so on those systems the
> Guix Home .profile may not even run before the DE is initialized.
> Nearly all of my time debugging this was spent figuring this out!  :-)
>
> The .profile file generated by Guix Home is this:
>
> ----------------------------------------------------------------------
> HOME_ENVIRONMENT=$HOME/.guix-home
> . $HOME_ENVIRONMENT/setup-environment
> $HOME_ENVIRONMENT/on-first-login
> ----------------------------------------------------------------------
>
> The first thing I see is that $HOME/.guix-home/seutp-environment is
> modifying various XDG_ variables incorrectly.  It prepends new values
> without honor the variable's default value if it doesn't happen to be
> set already.
>
> For example, if XDG_DATA_DIRS is not set its default value is
> "/usr/local/share/:/usr/share/".
>
> But .guix-home/setup-environment will instead prepend a value without
> checking, leaving XDG_DATA_DIRS set incorrectly to
> "$HOME/.guix-home/profile/share:" when it should be
> "$HOME/.guix-home/profile/share:/usr/local/share/:/usr/share/".
>
> See this code in setup-environment:
>
> case $XDG_DATA_DIRS in
>   *$HOME_ENVIRONMENT/profile/share*) ;;
>   *) export XDG_DATA_DIRS=$HOME_ENVIRONMENT/profile/share:$XDG_DATA_DIRS ;;
> esac
>
> The correct idiom is this:
>
> XDG_DATA_DIRS=PATH_TO_PREPEND:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}
>
> or
>
> XDG_DATA_DIRS=${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:PATH_TO_APPEND
>
> The above is what I see in various Nix and Snap configuration files.
>
> Because I have a few other things installed that modify XDG_DATA_DIRS
> before Guix Home does, Guix Home doesn't break that particular variable.
>
> It did break XDG_CONFIG_DIRS, since Guix Home was setting it to
> "$HOME/.guix-home/profile/etc/xdg:".  I worked around this problem by
> running this code before Guix Home's .profile:
>
>     # Note: when XDG_CONFIG_DIRS is not set Guix home sets
>     # XDG_CONFIG_DIRS="$HOME/.guix-home/profile/etc/xdg:", which removes
>     # the default "/etc/xdg" value.
>     if [[ -z $XDG_CONFIG_DIRS ]]; then
>         XDG_CONFIG_DIRS=/etc/xdg
>     fi
>
>     # Note: when XDG_DATA_DIRS is not set Guix home sets
>     # XDG_DATA_DIRS="$HOME/.guix-home/profile/share:", which removes the
>     # default "/usr/local/share:/usr/share" value.
>     if [[ -z $XDG_DATA_DIRS ]]; then
>         XDG_DATA_DIRS="/usr/local/share:/usr/share"
>     fi
>
> I have other more minor quibbles about how Guix Home handles XDG values:
>
> XDG_STATE_HOME is set to a non-standard value.  In the current XDG Base
> Directory Specification it defaults to "$HOME/.local/state", but Guix
> Home sets it to "$HOME/.local/var/lib".  On a foreign distro this is
> going to cause some disruption when a user switches to Guix Home, or
> switches away.
>
> XDG_LOG_HOME is a non-standard variable.  The spec suggests that logs
> should go in XDG_STATE_HOME.  Why not a establish a GUIX_LOG_HOME
> variable instead?  (if it ever does become a standard XDG variable, its
> default may not be the same one picked by Guix Home, causing the same
> issue as above).
>
> Setting XDG_RUNTIME_DIR is not something I would expect Guix Home to do
> -- it is the job of whatever logs the user in.
>
> XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME are set to their defaults
> unnecessarily.
>
> I modified my personal config by unsetting XDG_STATE_HOME, XDG_LOG_HOME,
> XDG_CACHE_HOME, XDG_CONFIG_HOME, and XDG_DATA_HOME if Guix Home left
> them set to their default values (in the case of XDG_STATE_HOME I unset
> it unconditionally).

XDG_DATA_DIRS behavior seems reasonable, the problem should be reported
to Debian.  The work on STATE_HOME is happenning in a separate thread.
Closing this ticket.  Let us know if you have some other thoughts on the
topic.

-- 
Best regards,
Andrew Tropin

Andrew Tropin wrote on 2 May 2023 04:56

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

Message-ID:87ednz1lw3.fsf@trop.in

close 59474

Your comment

This issue is archived.

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

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date