GNU bug report logs - #36785
'sudo guix pull' failure in the profile migration code

Previous Next

Package: guix;

Reported by: Julien Lepiller <julien <at> lepiller.eu>

Date: Wed, 24 Jul 2019 14:41:02 UTC

Severity: normal

Merged with 37148

Done: Ludovic Courtès <ludo <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36785 in the body.
You can then email your comments to 36785 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Wed, 24 Jul 2019 14:41:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Lepiller <julien <at> lepiller.eu>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Wed, 24 Jul 2019 14:41:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: bug-guix <at> gnu.org
Subject: Impossible to pull on foreign distro
Date: Wed, 24 Jul 2019 16:40:42 +0200
Hi guix,

I gave a small tutorial to someone today, where we installed guix on top of a foreign distro. We used the script and everything went smoothly, and after finding out that we were going to build php (we were trying to define a VM that would serve one of their services), we tried to run guix pull:

sudo guix pull —commit=…

However the command failed immediately with:

Migrating profile generations to '/var/guix/profiles/per-user/root'...
Guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/root/current-guix"

Indeed, the file exists and everything looks good. Why does guix try to migrate a profile that's already good?

I was able to work around that situation, but it's not great for our users.




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Thu, 25 Jul 2019 23:04:02 GMT) Full text and rfc822 format available.

Message #8 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: 36785 <at> debbugs.gnu.org
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Fri, 26 Jul 2019 01:03:08 +0200
Hi Julien,

Julien Lepiller <julien <at> lepiller.eu> skribis:

> I gave a small tutorial to someone today, where we installed guix on top of a foreign distro. We used the script and everything went smoothly, and after finding out that we were going to build php (we were trying to define a VM that would serve one of their services), we tried to run guix pull:
>
> sudo guix pull —commit=…
>
> However the command failed immediately with:
>
> Migrating profile generations to '/var/guix/profiles/per-user/root'...
> Guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/root/current-guix"
>
> Indeed, the file exists and everything looks good. Why does guix try to migrate a profile that's already good?
>
> I was able to work around that situation, but it's not great for our users.

I’m guessing the machine had remnants of a previous Guix installation,
no?  See:

  ;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks.  Move
  ;; them to %PROFILE-DIRECTORY.
  (unless (string=? %profile-directory
                    (dirname (canonicalize-profile %user-profile-directory)))
    (migrate-generations %user-profile-directory %profile-directory))

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Fri, 26 Jul 2019 06:23:01 GMT) Full text and rfc822 format available.

Message #11 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36785 <at> debbugs.gnu.org
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Fri, 26 Jul 2019 08:22:01 +0200
Le 26 juillet 2019 01:03:08 GMT+02:00, "Ludovic Courtès" <ludo <at> gnu.org> a écrit :
>Hi Julien,
>
>Julien Lepiller <julien <at> lepiller.eu> skribis:
>
>> I gave a small tutorial to someone today, where we installed guix on
>top of a foreign distro. We used the script and everything went
>smoothly, and after finding out that we were going to build php (we
>were trying to define a VM that would serve one of their services), we
>tried to run guix pull:
>>
>> sudo guix pull —commit=…
>>
>> However the command failed immediately with:
>>
>> Migrating profile generations to
>'/var/guix/profiles/per-user/root'...
>> Guix pull: error: symlink: File exists:
>"/var/guix/profiles/per-user/root/current-guix"
>>
>> Indeed, the file exists and everything looks good. Why does guix try
>to migrate a profile that's already good?
>>
>> I was able to work around that situation, but it's not great for our
>users.
>
>I’m guessing the machine had remnants of a previous Guix installation,
>no?  See:
>
>;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks. 
>Move
>  ;; them to %PROFILE-DIRECTORY.
>  (unless (string=? %profile-directory
>              (dirname (canonicalize-profile %user-profile-directory)))
>    (migrate-generations %user-profile-directory %profile-directory))
>
>Ludo’.

Not at all, this was the first install on that machine. The OS was even installed recently, so there can't be any remnant of the 0.15 era :). Installation went smoothly and /root/.config/guix/current was already a symlink to /var/guix/profiles/per-user/root. We ran guix pull as user just before and it worked perfectly well (with the message about migrating, although ~/.config/guix/current didn't exist).

Could there be some veird interaction between sudo and these %profile-directory and %user-profile-directory variables?




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Fri, 26 Jul 2019 08:10:02 GMT) Full text and rfc822 format available.

Message #14 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: 36785 <at> debbugs.gnu.org
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Fri, 26 Jul 2019 10:09:02 +0200
[Message part 1 (text/plain, inline)]
Hi Julien,

Julien Lepiller <julien <at> lepiller.eu> skribis:

> Le 26 juillet 2019 01:03:08 GMT+02:00, "Ludovic Courtès" <ludo <at> gnu.org> a écrit :

[...]

>>;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks. 
>>Move
>>  ;; them to %PROFILE-DIRECTORY.
>>  (unless (string=? %profile-directory
>>              (dirname (canonicalize-profile %user-profile-directory)))
>>    (migrate-generations %user-profile-directory %profile-directory))

[...]

> Could there be some veird interaction between sudo and these %profile-directory and %user-profile-directory variables?

Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
(canonicalize-profile %user-profile-directory), and here’s what I see
with ‘sudo’:

--8<---------------cut here---------------start------------->8---
$ sudo -E ./pre-inst-env guix pull

;;; (pd "/var/guix/profiles/per-user/root")

;;; (upd "/home/ludo/.config/guix/current")
Migrating profile generations to '/var/guix/profiles/per-user/root'...
guix pull: error: symlink: Dosiero jam ekzistas: "/var/guix/profiles/per-user/root/current-guix"
--8<---------------cut here---------------end--------------->8---

‘%user-profile-directory’ is computed as a function of $HOME, which is
unchanged when using ‘sudo’, whereas ‘%profile-directory’ is computed as
a function of $USER.

I think $HOME should always prevail over the home directory defined in
/etc/passwd, so think we should not change the way
‘%user-profile-directory’ is computed.

We could do this:

[Message part 2 (text/x-patch, inline)]
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1721,7 +1721,8 @@ because the NUMBER is zero.)"
 
 (define %profile-directory
   (string-append %state-directory "/profiles/"
-                 (or (and=> (or (getenv "USER")
+                 (or (and=> (or (getenv "SUDO_USER")
+                                (getenv "USER")
                                 (getenv "LOGNAME"))
                             (cut string-append "per-user/" <>))
                      "default")))
[Message part 3 (text/plain, inline)]
… but then ‘sudo guix pull’ won’t update root’s guix at all.

Otherwise I’m thinking of this gross hack:

[Message part 4 (text/x-patch, inline)]
diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index 54bbaddf30..8d8a8aa889 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -293,8 +293,9 @@ true, display what would be built without actually building it."
 
   ;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks.  Move
   ;; them to %PROFILE-DIRECTORY.
-  (unless (string=? %profile-directory
-                    (dirname (canonicalize-profile %user-profile-directory)))
+  (unless (or (getenv "SUDO_USER")
+              (string=? (pk 'pd %profile-directory)
+                        (dirname (pk 'upd (canonicalize-profile %user-profile-directory)))))
     (migrate-generations %user-profile-directory %profile-directory))
 
   ;; Make sure ~/.config/guix/current points to /var/guix/profiles/….
[Message part 5 (text/plain, inline)]
I think it’s acceptable because that’s “throw away” code anyway, and
it’s not supposed to be triggered these days.

Thoughts?

Ludo’.

Changed bug title to ''sudo guix pull' failure in the profile migration code' from 'Impossible to pull on foreign distro' Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Fri, 26 Jul 2019 09:21:02 GMT) Full text and rfc822 format available.

Merged 36785 37148. Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 17 Sep 2019 07:37:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Tue, 17 Sep 2019 22:04:01 GMT) Full text and rfc822 format available.

Message #21 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: 36785 <at> debbugs.gnu.org, Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Wed, 18 Sep 2019 00:03:01 +0200
Hi,

Ludovic Courtès <ludo <at> gnu.org> skribis:

> Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
> (canonicalize-profile %user-profile-directory), and here’s what I see
> with ‘sudo’:
>
> $ sudo -E ./pre-inst-env guix pull
>
> ;;; (pd "/var/guix/profiles/per-user/root")
>
> ;;; (upd "/home/ludo/.config/guix/current")

I used ‘-E’ above, which is why HOME was ~ludo instead of ~root.
Without ‘-E’, HOME is ~root as expected, and so “sudo guix pull” does
the right thing (this is on Guix System):

--8<---------------cut here---------------start------------->8---
$ sudo guix repl
GNU Guile 2.2.4
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> (getenv "HOME")
$1 = "/root"
scheme@(guix-user)> ,m(guix scripts pull)
scheme@(guix scripts pull)> %profile-directory
$2 = "/var/guix/profiles/per-user/root"
scheme@(guix scripts pull)> %user-profile-directory
$3 = "/root/.config/guix/current"
scheme@(guix scripts pull)> (cache-directory)
$4 = "/root/.cache/guix"
scheme@(guix scripts pull)> (config-directory)
$5 = "/root/.config/guix"
--8<---------------cut here---------------end--------------->8---

So ‘sudo guix pull’ really updates root’s profile and writes to
~root/.cache, everything is fine.

Done?

I investigated a bit, tried Debian, then Ubuntu, and found that ‘sudo’
on Ubuntu behaves differently: it preserves ‘HOME’ by default:

  $ sudo env | grep HOME
  HOME=/home/ubuntu

This is written here:

  https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells

(That’s with sudo 1.8.21p2, FWIW.)

Ubuntu’s /etc/sudoers doesn’t have anything special.  Actually, Debian
has (almost) the same /etc/sudoers and yet it does not preserve HOME.

(Time passes…)

Digging further, I fetched the source from
<https://packages.ubuntu.com/bionic/sudo>, and boom! I found the
culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.

--8<---------------cut here---------------start------------->8---
Description: Set HOME in initial_keepenv_table
 Set HOME in initial_keepenv_table; without this, $HOME will never be 
 preserved unless added to keep_env.  There's appropriate logic to handle
 resetting the home for -H and -i options, so this is the only part that's
 missing.
Author: Steve Langasek <steve.langasek <at> canonical.com>
--- a/plugins/sudoers/env.c
+++ b/plugins/sudoers/env.c
@@ -189,6 +189,7 @@
     "COLORS",
     "DISPLAY",
     "DPKG_COLORS",
+    "HOME",
     "HOSTNAME",
     "KRB5CCNAME",
     "LS_COLORS",
--8<---------------cut here---------------end--------------->8---

(This patch is playing with fire IMO.  If you’re an Ubuntu user,
consider reporting a bug!)

But anyway, what can we do?

We could ignore the issue, it’s-Ubuntu’s-fault, done.

We could also add some logic to detect whether (1) we’re running under
sudo, and in that case, and whether (2) $HOME matches $USER’s home
directory as it appears in /etc/passwd.  If both conditions are
satisfied, we could ignore $HOME and use the home directory from
/etc/passwd instead.

But… that’s complicated, and it’d break uses of ‘sudo -H’.

We could apply the patch I posted earlier, which simply disables profile
migration when SUDO_USER is set.  That won’t address the fact that root
writes to the user’s ~/.cache, but there’s not much we can do here.

Thoughts?

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Tue, 17 Sep 2019 23:34:01 GMT) Full text and rfc822 format available.

Message #24 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Gábor Boskovits <boskovits <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36785 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Wed, 18 Sep 2019 01:33:40 +0200
[Message part 1 (text/plain, inline)]
Hello Ludo,

Ludovic Courtès <ludo <at> gnu.org> ezt írta (időpont: 2019. szept. 18., Sze,
0:04):

> Hi,
>
> Ludovic Courtès <ludo <at> gnu.org> skribis:
>
> > Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
> > (canonicalize-profile %user-profile-directory), and here’s what I see
> > with ‘sudo’:
> >
> > $ sudo -E ./pre-inst-env guix pull
> >
> > ;;; (pd "/var/guix/profiles/per-user/root")
> >
> > ;;; (upd "/home/ludo/.config/guix/current")
>
> I used ‘-E’ above, which is why HOME was ~ludo instead of ~root.
> Without ‘-E’, HOME is ~root as expected, and so “sudo guix pull” does
> the right thing (this is on Guix System):
>
> --8<---------------cut here---------------start------------->8---
> $ sudo guix repl
> GNU Guile 2.2.4
> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guix-user)> (getenv "HOME")
> $1 = "/root"
> scheme@(guix-user)> ,m(guix scripts pull)
> scheme@(guix scripts pull)> %profile-directory
> $2 = "/var/guix/profiles/per-user/root"
> scheme@(guix scripts pull)> %user-profile-directory
> $3 = "/root/.config/guix/current"
> scheme@(guix scripts pull)> (cache-directory)
> $4 = "/root/.cache/guix"
> scheme@(guix scripts pull)> (config-directory)
> $5 = "/root/.config/guix"
> --8<---------------cut here---------------end--------------->8---
>
> So ‘sudo guix pull’ really updates root’s profile and writes to
> ~root/.cache, everything is fine.
>
> Done?
>
> I investigated a bit, tried Debian, then Ubuntu, and found that ‘sudo’
> on Ubuntu behaves differently: it preserves ‘HOME’ by default:
>
>   $ sudo env | grep HOME
>   HOME=/home/ubuntu
>
> This is written here:
>
>
> https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells
>
> (That’s with sudo 1.8.21p2, FWIW.)
>
> Ubuntu’s /etc/sudoers doesn’t have anything special.  Actually, Debian
> has (almost) the same /etc/sudoers and yet it does not preserve HOME.
>
> (Time passes…)
>
> Digging further, I fetched the source from
> <https://packages.ubuntu.com/bionic/sudo>, and boom! I found the
> culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.
>
> --8<---------------cut here---------------start------------->8---
> Description: Set HOME in initial_keepenv_table
>  Set HOME in initial_keepenv_table; without this, $HOME will never be
>  preserved unless added to keep_env.  There's appropriate logic to handle
>  resetting the home for -H and -i options, so this is the only part that's
>  missing.
> Author: Steve Langasek <steve.langasek <at> canonical.com>
> --- a/plugins/sudoers/env.c
> +++ b/plugins/sudoers/env.c
> @@ -189,6 +189,7 @@
>      "COLORS",
>      "DISPLAY",
>      "DPKG_COLORS",
> +    "HOME",
>      "HOSTNAME",
>      "KRB5CCNAME",
>      "LS_COLORS",
> --8<---------------cut here---------------end--------------->8---
>
> (This patch is playing with fire IMO.  If you’re an Ubuntu user,
> consider reporting a bug!)
>
> But anyway, what can we do?
>
> We could ignore the issue, it’s-Ubuntu’s-fault, done.
>
> We could also add some logic to detect whether (1) we’re running under
> sudo, and in that case, and whether (2) $HOME matches $USER’s home
> directory as it appears in /etc/passwd.  If both conditions are
> satisfied, we could ignore $HOME and use the home directory from
> /etc/passwd instead.
>
> But… that’s complicated, and it’d break uses of ‘sudo -H’.
>
> We could apply the patch I posted earlier, which simply disables profile
> migration when SUDO_USER is set.  That won’t address the fact that root
> writes to the user’s ~/.cache, but there’s not much we can do here.
>
> Thoughts?
>

We could simply document a proper sudo invocation for updating root's guix,
that
always works. Wdyt?

We could provide it simply as a hint if it fails.


>
> Ludo’.
>
>
>
>
Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
[Message part 2 (text/html, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Wed, 18 Sep 2019 08:51:01 GMT) Full text and rfc822 format available.

Message #27 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Gábor Boskovits <boskovits <at> gmail.com>
Cc: 36785 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Wed, 18 Sep 2019 10:48:42 +0200
Hi,

Gábor Boskovits <boskovits <at> gmail.com> skribis:

> We could simply document a proper sudo invocation for updating root's guix,
> that
> always works. Wdyt?

The thing is “sudo guix pull” works on all (?) distros but Ubuntu, which
provides a patched sudo.  So we’d have to explicitly mention Ubuntu.

That’s probably a good idea, though chances are people will run “sudo
guix pull” before they’ve read that footnote in the manual.  (A
colleague of mine ran “sudo guix pull” mostly because they were used to
“sudo apt-get update” and didn’t really think ‘sudo’ was unnecessary.)

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Wed, 18 Sep 2019 18:36:01 GMT) Full text and rfc822 format available.

Message #30 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36785 <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Wed, 18 Sep 2019 20:35:19 +0200
Ludovic Courtès <ludo <at> gnu.org> writes:

> Digging further, I fetched the source from
> <https://packages.ubuntu.com/bionic/sudo>, and boom! I found the
> culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.
>
> --8<---------------cut here---------------start------------->8---
> Description: Set HOME in initial_keepenv_table
>  Set HOME in initial_keepenv_table; without this, $HOME will never be 
>  preserved unless added to keep_env.  There's appropriate logic to handle
>  resetting the home for -H and -i options, so this is the only part that's
>  missing.
> Author: Steve Langasek <steve.langasek <at> canonical.com>
> --- a/plugins/sudoers/env.c
> +++ b/plugins/sudoers/env.c
> @@ -189,6 +189,7 @@
>      "COLORS",
>      "DISPLAY",
>      "DPKG_COLORS",
> +    "HOME",
>      "HOSTNAME",
>      "KRB5CCNAME",
>      "LS_COLORS",
> --8<---------------cut here---------------end--------------->8---
>
> (This patch is playing with fire IMO.  If you’re an Ubuntu user,
> consider reporting a bug!)

Wow.  Changing fundamental behaviour like that is bad.

> We could apply the patch I posted earlier, which simply disables profile
> migration when SUDO_USER is set.  That won’t address the fact that root
> writes to the user’s ~/.cache, but there’s not much we can do here.

This sounds fine to me.

-- 
Ricardo





Reply sent to Ludovic Courtès <ludo <at> gnu.org>:
You have taken responsibility. (Thu, 19 Sep 2019 08:25:02 GMT) Full text and rfc822 format available.

Notification sent to Julien Lepiller <julien <at> lepiller.eu>:
bug acknowledged by developer. (Thu, 19 Sep 2019 08:25:03 GMT) Full text and rfc822 format available.

Message #35 received at 36785-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 36785-done <at> debbugs.gnu.org, Julien Lepiller <julien <at> lepiller.eu>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Thu, 19 Sep 2019 10:24:18 +0200
Hi,

Ricardo Wurmus <rekado <at> elephly.net> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:

[...]

>> We could apply the patch I posted earlier, which simply disables profile
>> migration when SUDO_USER is set.  That won’t address the fact that root
>> writes to the user’s ~/.cache, but there’s not much we can do here.
>
> This sounds fine to me.

I went ahead and pushed that as
ee25048e51dd45ad91a1ad4b0f25f4013843c52b.

Thanks,
Ludo’.




Reply sent to Ludovic Courtès <ludo <at> gnu.org>:
You have taken responsibility. (Thu, 19 Sep 2019 08:25:03 GMT) Full text and rfc822 format available.

Notification sent to Tobias Geerinckx-Rice <me <at> tobias.gr>:
bug acknowledged by developer. (Thu, 19 Sep 2019 08:25:03 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Fri, 20 Sep 2019 08:48:01 GMT) Full text and rfc822 format available.

Message #43 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Gábor Boskovits <boskovits <at> gmail.com>
Cc: 36785 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Fri, 20 Sep 2019 17:47:11 +0900
Hello,

Gábor Boskovits <boskovits <at> gmail.com> writes:

> Hello Ludo,
>
> Ludovic Courtès <ludo <at> gnu.org> ezt írta (időpont: 2019. szept. 18., Sze,
> 0:04):
>
>> Hi,
>>
>> Ludovic Courtès <ludo <at> gnu.org> skribis:
>>
>> > Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
>> > (canonicalize-profile %user-profile-directory), and here’s what I see
>> > with ‘sudo’:
>> >
>> > $ sudo -E ./pre-inst-env guix pull
>> >
>> > ;;; (pd "/var/guix/profiles/per-user/root")
>> >
>> > ;;; (upd "/home/ludo/.config/guix/current")
>>
>> I used ‘-E’ above, which is why HOME was ~ludo instead of ~root.
>> Without ‘-E’, HOME is ~root as expected, and so “sudo guix pull” does
>> the right thing (this is on Guix System):
>>
>> --8<---------------cut here---------------start------------->8---
>> $ sudo guix repl
>> GNU Guile 2.2.4
>> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>>
>> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>> This program is free software, and you are welcome to redistribute it
>> under certain conditions; type `,show c' for details.
>>
>> Enter `,help' for help.
>> scheme@(guix-user)> (getenv "HOME")
>> $1 = "/root"
>> scheme@(guix-user)> ,m(guix scripts pull)
>> scheme@(guix scripts pull)> %profile-directory
>> $2 = "/var/guix/profiles/per-user/root"
>> scheme@(guix scripts pull)> %user-profile-directory
>> $3 = "/root/.config/guix/current"
>> scheme@(guix scripts pull)> (cache-directory)
>> $4 = "/root/.cache/guix"
>> scheme@(guix scripts pull)> (config-directory)
>> $5 = "/root/.config/guix"
>> --8<---------------cut here---------------end--------------->8---
>>
>> So ‘sudo guix pull’ really updates root’s profile and writes to
>> ~root/.cache, everything is fine.
>>
>> Done?
>>
>> I investigated a bit, tried Debian, then Ubuntu, and found that ‘sudo’
>> on Ubuntu behaves differently: it preserves ‘HOME’ by default:
>>
>>   $ sudo env | grep HOME
>>   HOME=/home/ubuntu
>>
>> This is written here:
>>
>>
>> https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells
>>
>> (That’s with sudo 1.8.21p2, FWIW.)
>>
>> Ubuntu’s /etc/sudoers doesn’t have anything special.  Actually, Debian
>> has (almost) the same /etc/sudoers and yet it does not preserve HOME.
>>
>> (Time passes…)
>>
>> Digging further, I fetched the source from
>> <https://packages.ubuntu.com/bionic/sudo>, and boom! I found the
>> culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.
>>
>> --8<---------------cut here---------------start------------->8---
>> Description: Set HOME in initial_keepenv_table
>>  Set HOME in initial_keepenv_table; without this, $HOME will never be
>>  preserved unless added to keep_env.  There's appropriate logic to handle
>>  resetting the home for -H and -i options, so this is the only part that's
>>  missing.
>> Author: Steve Langasek <steve.langasek <at> canonical.com>
>> --- a/plugins/sudoers/env.c
>> +++ b/plugins/sudoers/env.c
>> @@ -189,6 +189,7 @@
>>      "COLORS",
>>      "DISPLAY",
>>      "DPKG_COLORS",
>> +    "HOME",
>>      "HOSTNAME",
>>      "KRB5CCNAME",
>>      "LS_COLORS",
>> --8<---------------cut here---------------end--------------->8---
>>
>> (This patch is playing with fire IMO.  If you’re an Ubuntu user,
>> consider reporting a bug!)
>>
>> But anyway, what can we do?
>>
>> We could ignore the issue, it’s-Ubuntu’s-fault, done.
>>
>> We could also add some logic to detect whether (1) we’re running under
>> sudo, and in that case, and whether (2) $HOME matches $USER’s home
>> directory as it appears in /etc/passwd.  If both conditions are
>> satisfied, we could ignore $HOME and use the home directory from
>> /etc/passwd instead.
>>
>> But… that’s complicated, and it’d break uses of ‘sudo -H’.
>>
>> We could apply the patch I posted earlier, which simply disables profile
>> migration when SUDO_USER is set.  That won’t address the fact that root
>> writes to the user’s ~/.cache, but there’s not much we can do here.
>>
>> Thoughts?
>>
>
> We could simply document a proper sudo invocation for updating root's guix,
> that
> always works. Wdyt?
>
> We could provide it simply as a hint if it fails.

Indeed, the default recommended invocation to update the root's guix
could be changed to be 'sudo -i guix pull', which should work on all
systems including Ubuntu.

Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Fri, 20 Sep 2019 15:45:01 GMT) Full text and rfc822 format available.

Message #46 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 36785 <at> debbugs.gnu.org,
 Gábor Boskovits <boskovits <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Fri, 20 Sep 2019 17:44:26 +0200
Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Indeed, the default recommended invocation to update the root's guix
> could be changed to be 'sudo -i guix pull', which should work on all
> systems including Ubuntu.

Oh right.  Could you make this change in the manual?

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Sat, 21 Sep 2019 12:32:02 GMT) Full text and rfc822 format available.

Message #49 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36785 <at> debbugs.gnu.org,
 Gábor Boskovits <boskovits <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Sat, 21 Sep 2019 21:31:16 +0900
[Message part 1 (text/plain, inline)]
Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Indeed, the default recommended invocation to update the root's guix
>> could be changed to be 'sudo -i guix pull', which should work on all
>> systems including Ubuntu.
>
> Oh right.  Could you make this change in the manual?
>
> Thanks,
> Ludo’.

I looked at what was in the manual, and became less sure, thought maybe
'sudo -E' could be better, so I've done the following little experiment
using Docker to test an Ubuntu enviroment:

Here's the Dockerfile, with instructions to reproduce in it:

--8<---------------cut here---------------start------------->8---
FROM ubuntu

RUN apt-get update && apt-get install sudo
RUN useradd -ms /bin/bash user
RUN usermod -aG sudo user
RUN echo user:user | chpasswd

USER user

CMD bash

# To test (in the directory where this file is written as 'Dockerfile'):
# docker build .
# docker run -it --rm <container_id>

# Then run the following commands:
# export PATH=extra-stuff:$PATH
# sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
# sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
# sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
--8<---------------cut here---------------end--------------->8---

And the result:

--8<---------------cut here---------------start------------->8---
echo $PATH
echo $PATH
extra-stuff:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0;user <at> e538556bf337: /user <at> e538556bf337:/$ sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
-e env when using -E:
SUDO_GID=1000
USER=root
HOSTNAME=e538556bf337
SHLVL=1
HOME=/home/user
SUDO_UID=1000
LOGNAME=root
_=/usr/bin/sudo
TERM=xterm
USERNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:[...]

SUDO_COMMAND=/bin/sh -c echo -e "env when using -E:
$(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/

0;user <at> e538556bf337: /user <at> e538556bf337:/$ sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
-e env when using -i:
SUDO_GID=1000
MAIL=/var/mail/root
USER=root
HOSTNAME=e538556bf337
SHLVL=1
HOME=/root
SUDO_UID=1000
LOGNAME=root
_=/bin/sh
USERNAME=root
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:ln=01;36: [...]

$(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/root

user <at> e538556bf337: /user <at> e538556bf337:/$ sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
-e env with plain sudo: SUDO_GID=1000
MAIL=/var/mail/root
USER=root
HOSTNAME=e538556bf337
HOME=/home/user
SUDO_UID=1000
LOGNAME=root
TERM=xterm
USERNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:ln=01;36: [...]
SUDO_COMMAND=/bin/sh -c echo -e "env with plain sudo: $(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/
--8<---------------cut here---------------end--------------->8---

What do we get from this?

Well, first, the user's PATH is *not* preserved when using 'sudo', at
least on Debian and Ubuntu.  These are configured out of the box to
reset the PATH to a 'safe' value, even when using the -E option of sudo.

We also see, as Ludovic found out, that the user's HOME is preserved for
the normal invocation of sudo on Ubuntu.

In light of this, I suggest the attached patch to our documentation.
It's a bit sub-optimal in that it modifies a section of the 'Guix
System', which behaved as described; but given that it's the only place
where we mention of 'sudo guix pull', better safe than sorry, I'd say
(foreign distribution users might read it, thinking it also applies to
themselves).

Does that seem worthwile/reasonable?

[0001-doc-Adapt-the-guix-pull-command-recommendation.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
Thanks,

Maxim
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Sat, 21 Sep 2019 12:33:01 GMT) Full text and rfc822 format available.

Message #52 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36785 <at> debbugs.gnu.org,
 Gábor Boskovits <boskovits <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Sat, 21 Sep 2019 21:32:13 +0900
[Message part 1 (text/plain, inline)]
Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Indeed, the default recommended invocation to update the root's guix
>> could be changed to be 'sudo -i guix pull', which should work on all
>> systems including Ubuntu.
>
> Oh right.  Could you make this change in the manual?
>
> Thanks,
> Ludo’.

I looked at what was in the manual, and became less sure, thought maybe
'sudo -E' could be better, so I've done the following little experiment
using Docker to test an Ubuntu enviroment:

Here's the Dockerfile, with instructions to reproduce in it:

--8<---------------cut here---------------start------------->8---
FROM ubuntu

RUN apt-get update && apt-get install sudo
RUN useradd -ms /bin/bash user
RUN usermod -aG sudo user
RUN echo user:user | chpasswd

USER user

CMD bash

# To test (in the directory where this file is written as 'Dockerfile'):
# docker build .
# docker run -it --rm <container_id>

# Then run the following commands:
# export PATH=extra-stuff:$PATH
# sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
# sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
# sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
--8<---------------cut here---------------end--------------->8---

And the result:

--8<---------------cut here---------------start------------->8---
echo $PATH
echo $PATH
extra-stuff:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0;user <at> e538556bf337: /user <at> e538556bf337:/$ sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
-e env when using -E:
SUDO_GID=1000
USER=root
HOSTNAME=e538556bf337
SHLVL=1
HOME=/home/user
SUDO_UID=1000
LOGNAME=root
_=/usr/bin/sudo
TERM=xterm
USERNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:[...]

SUDO_COMMAND=/bin/sh -c echo -e "env when using -E:
$(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/

0;user <at> e538556bf337: /user <at> e538556bf337:/$ sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
-e env when using -i:
SUDO_GID=1000
MAIL=/var/mail/root
USER=root
HOSTNAME=e538556bf337
SHLVL=1
HOME=/root
SUDO_UID=1000
LOGNAME=root
_=/bin/sh
USERNAME=root
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:ln=01;36: [...]

$(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/root

user <at> e538556bf337: /user <at> e538556bf337:/$ sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
-e env with plain sudo: SUDO_GID=1000
MAIL=/var/mail/root
USER=root
HOSTNAME=e538556bf337
HOME=/home/user
SUDO_UID=1000
LOGNAME=root
TERM=xterm
USERNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:ln=01;36: [...]
SUDO_COMMAND=/bin/sh -c echo -e "env with plain sudo: $(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/
--8<---------------cut here---------------end--------------->8---

What do we get from this?

Well, first, the user's PATH is *not* preserved when using 'sudo', at
least on Debian and Ubuntu.  These are configured out of the box to
reset the PATH to a 'safe' value, even when using the -E option of sudo.

We also see, as Ludovic found out, that the user's HOME is preserved for
the normal invocation of sudo on Ubuntu.

In light of this, I suggest the attached patch to our documentation.
It's a bit sub-optimal in that it modifies a section of the 'Guix
System', which behaved as described; but given that it's the only place
where we mention of 'sudo guix pull', better safe than sorry, I'd say
(foreign distribution users might read it, thinking it also applies to
themselves).

Does that seem worthwile/reasonable?

[0001-doc-Adapt-the-guix-pull-command-recommendation.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
Thanks,

Maxim
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Mon, 23 Sep 2019 08:30:02 GMT) Full text and rfc822 format available.

Message #55 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 36785 <at> debbugs.gnu.org,
 Gábor Boskovits <boskovits <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Mon, 23 Sep 2019 10:29:43 +0200
Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From then on, you can update the
>  system whenever you want by running, say:
>  
>  @example
> -guix pull
> -sudo guix system reconfigure /etc/config.scm
> +sudo -i guix pull
> +sudo -i guix system reconfigure /etc/config.scm
>  @end example
>  
>  @noindent
> @@ -2396,14 +2396,6 @@ This builds a new system generation with the latest packages and services
>  (@pxref{Invoking guix system}).  We recommend doing that regularly so that
>  your system includes the latest security updates (@pxref{Security Updates}).
>  
> -@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
> -@quotation Note
> -@cindex sudo vs. @command{guix pull}
> -Note that @command{sudo guix} runs your user's @command{guix} command and
> -@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged.  To
> -explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
> -@end quotation

I think these bits were correct.

That is, when running “sudo foo”, “foo” is looked up in the user’s
$PATH, not in root’s $PATH.  That’s what led to this text in commit
796a4491fdaa4a0a3d669457b89356f9fbfc966e.

So this part is fine.

Perhaps we need another section for this?  Or perhaps we can drop the
ball…

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Mon, 23 Sep 2019 09:02:02 GMT) Full text and rfc822 format available.

Message #58 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Gábor Boskovits <boskovits <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36785 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Mon, 23 Sep 2019 11:00:48 +0200
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> ezt írta (időpont: 2019. szept. 23., Hét
10:29):

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
> > --- a/doc/guix.texi
> > +++ b/doc/guix.texi
> > @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From
> then on, you can update the
> >  system whenever you want by running, say:
> >
> >  @example
> > -guix pull
> > -sudo guix system reconfigure /etc/config.scm
> > +sudo -i guix pull
> > +sudo -i guix system reconfigure /etc/config.scm
> >  @end example
> >
> >  @noindent
> > @@ -2396,14 +2396,6 @@ This builds a new system generation with the
> latest packages and services
> >  (@pxref{Invoking guix system}).  We recommend doing that regularly so
> that
> >  your system includes the latest security updates (@pxref{Security
> Updates}).
> >
> > -@c See <
> https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
> > -@quotation Note
> > -@cindex sudo vs. @command{guix pull}
> > -Note that @command{sudo guix} runs your user's @command{guix} command
> and
> > -@emph{not} root's, because @command{sudo} leaves @code{PATH}
> unchanged.  To
> > -explicitly run root's @command{guix}, type @command{sudo -i guix
> @dots{}}.
> > -@end quotation
>
> I think these bits were correct.
>
> That is, when running “sudo foo”, “foo” is looked up in the user’s
> $PATH, not in root’s $PATH.  That’s what led to this text in commit
> 796a4491fdaa4a0a3d669457b89356f9fbfc966e.
>
> So this part is fine
>
I believe sudo -H would work in all distros for doing a root guix pull. Can
someone confirm?

>
> Perhaps we need another section for this?  Or perhaps we can drop the
> ball…
>
> Thanks,
> Ludo’.
>
Best regards,
g_bor

>
[Message part 2 (text/html, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Mon, 23 Sep 2019 12:49:01 GMT) Full text and rfc822 format available.

Message #61 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Gábor Boskovits <boskovits <at> gmail.com>
Cc: 36785 <at> debbugs.gnu.org, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Mon, 23 Sep 2019 14:48:40 +0200
Hi Gábor,

Gábor Boskovits <boskovits <at> gmail.com> skribis:

> I believe sudo -H would work in all distros for doing a root guix pull. Can
> someone confirm?

I think so, yes.

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Mon, 23 Sep 2019 14:11:02 GMT) Full text and rfc822 format available.

Message #64 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36785 <at> debbugs.gnu.org,
 Gábor Boskovits <boskovits <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Mon, 23 Sep 2019 23:09:52 +0900
Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From then on, you can update the
>>  system whenever you want by running, say:
>>  
>>  @example
>> -guix pull
>> -sudo guix system reconfigure /etc/config.scm
>> +sudo -i guix pull
>> +sudo -i guix system reconfigure /etc/config.scm
>>  @end example
>>  
>>  @noindent
>> @@ -2396,14 +2396,6 @@ This builds a new system generation with the latest packages and services
>>  (@pxref{Invoking guix system}).  We recommend doing that regularly so that
>>  your system includes the latest security updates (@pxref{Security Updates}).
>>  
>> -@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
>> -@quotation Note
>> -@cindex sudo vs. @command{guix pull}
>> -Note that @command{sudo guix} runs your user's @command{guix} command and
>> -@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged.  To
>> -explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
>> -@end quotation
>
> I think these bits were correct.

They are correct when applied to a Guix System; what my commits aim to
do is make them generally true regardless of the Guix System vs foreign
distro situation, in an attempt to negate possible confusion.  It's not
succeeding, obviously :-).

I had modified that bit of the manual because that's apparently the only
place where we mention 'sudo guix pull' in the manual.

In the commit message I wrote:

   Although this section is specific to Guix System, it is likely to be
   read by users of foreign GNU/Linux distributions as well.  Remove the
   note, given that sudo doesn't preserve the user's PATH on foreign
   distributions such as Debian.

> That is, when running “sudo foo”, “foo” is looked up in the user’s
> $PATH, not in root’s $PATH.  That’s what led to this text in commit
> 796a4491fdaa4a0a3d669457b89356f9fbfc966e.
>
> So this part is fine.
>
> Perhaps we need another section for this?  Or perhaps we can drop the
> ball…

Agreed, until more real use cases come so that the proper solution can
be more clear (in regards to what needs to be changed in the manual).

Maxim




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Tue, 24 Sep 2019 12:38:01 GMT) Full text and rfc822 format available.

Message #67 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 36785 <at> debbugs.gnu.org,
 Gábor Boskovits <boskovits <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Tue, 24 Sep 2019 14:37:32 +0200
Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>>
>>> --- a/doc/guix.texi
>>> +++ b/doc/guix.texi
>>> @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From then on, you can update the
>>>  system whenever you want by running, say:
>>>  
>>>  @example
>>> -guix pull
>>> -sudo guix system reconfigure /etc/config.scm
>>> +sudo -i guix pull
>>> +sudo -i guix system reconfigure /etc/config.scm
>>>  @end example
>>>  
>>>  @noindent
>>> @@ -2396,14 +2396,6 @@ This builds a new system generation with the latest packages and services
>>>  (@pxref{Invoking guix system}).  We recommend doing that regularly so that
>>>  your system includes the latest security updates (@pxref{Security Updates}).
>>>  
>>> -@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
>>> -@quotation Note
>>> -@cindex sudo vs. @command{guix pull}
>>> -Note that @command{sudo guix} runs your user's @command{guix} command and
>>> -@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged.  To
>>> -explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
>>> -@end quotation
>>
>> I think these bits were correct.
>
> They are correct when applied to a Guix System;

It’s a paragraph that explains how to upgrade Guix System, so I think
foreign distros should be discussed elsewhere.  (I appreciate your
attempt to add proper documentation about that for foreign distros!)

> what my commits aim to do is make them generally true regardless of
> In the commit message I wrote:
>
>    Although this section is specific to Guix System, it is likely to be
>    read by users of foreign GNU/Linux distributions as well.  Remove the
>    note, given that sudo doesn't preserve the user's PATH on foreign
>    distributions such as Debian.

But users of foreign distros would hopefully realize that ‘guix system
reconfigure’ (in the same snippet) is not for them.  :-)

What about adding a section that we could call “Upgrading Guix”
under “Application Setup”, which is where setup on foreign distros is
discussed?

The section could say:

  1. Run ‘guix pull’ to upgrade Guix.

  2. When you need to upgrade the build daemon, for instance, which runs
     as root, run:

       sudo -i guix pull

How does that sound?

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Fri, 27 Sep 2019 15:24:01 GMT) Full text and rfc822 format available.

Message #70 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36785 <at> debbugs.gnu.org,
 Gábor Boskovits <boskovits <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Sat, 28 Sep 2019 00:23:34 +0900
[Message part 1 (text/plain, inline)]
Hi!

Ludovic Courtès <ludo <at> gnu.org> writes:

[...]

> It’s a paragraph that explains how to upgrade Guix System, so I think
> foreign distros should be discussed elsewhere.  (I appreciate your
> attempt to add proper documentation about that for foreign distros!)
>
>> what my commits aim to do is make them generally true regardless of
>> In the commit message I wrote:
>>
>>    Although this section is specific to Guix System, it is likely to be
>>    read by users of foreign GNU/Linux distributions as well.  Remove the
>>    note, given that sudo doesn't preserve the user's PATH on foreign
>>    distributions such as Debian.
>
> But users of foreign distros would hopefully realize that ‘guix system
> reconfigure’ (in the same snippet) is not for them.  :-)

I've been guilty myself of using C-s or 'i' in the manual and reading
something that didn't apply to my system but *did* match my
search... :-) 

>> What about adding a section that we could call “Upgrading Guix”
> under “Application Setup”, which is where setup on foreign distros is
> discussed?
>
> The section could say:
>
>   1. Run ‘guix pull’ to upgrade Guix.
>
>   2. When you need to upgrade the build daemon, for instance, which runs
>      as root, run:
>
>        sudo -i guix pull
>
> How does that sound?

This sounds much simpler than attempting to twist some other section
into something it wasn't really meant for ;-).

I've attached a simple patch implementing the idea.

Thanks for your patience!

Maxim

[0001-doc-Add-a-Upgrading-Guix-section-to-the-Installation.patch (text/x-patch, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Sat, 28 Sep 2019 17:50:01 GMT) Full text and rfc822 format available.

Message #73 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 36785 <at> debbugs.gnu.org,
 Gábor Boskovits <boskovits <at> gmail.com>
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Sat, 28 Sep 2019 19:49:28 +0200
Hi Maxim!

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
> Date: Sat, 28 Sep 2019 00:11:28 +0900
> Subject: [PATCH] doc: Add a 'Upgrading Guix' section to the 'Installation'
>  chapter.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> This follows a discussion regarding issue #36785 (see:
> https://bugs.gnu.org/36785).
>
> * doc/guix.texi (Upgrading Guix): New section.
>
> Co-authored-by: Ludovic Courtès <ludo <at> gnu.org>

[...]

> +@node Upgrading Guix
> +@section Upgrading Guix
> +
> +@cindex Upgrading Guix, on a foreign distro

Nitpicking: index entries are usually lower-case.

> +To upgrade Guix, run:
> +
> +@example
> +guix pull
> +@end example

Perhaps add:

  @xref{Invoking guix pull}, for more information.

> +When you need to upgrade the build daemon, for instance, which runs as
> +root, run:
> +
> +@example
> +sudo -i guix pull
> +@end example

What about restating upfront that we’re talking about foreign distros
specifically:

  On a foreign distro, you can upgrade the build daemon by running:

  @example
  sudo -i guix pull
  @end example

  @noindent
  followed by (assuming your distro uses the systemd service management
  tool):

  @example
  systemctl restart guix-daemon.service
  @end example

  On Guix System, upgrading the daemon is achieved by reconfiguring the
  system (@pxref{Invoking guix system, @code{guix system reconfigure}}).

?

Feel free to push something along these lines.

Thank you,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#36785; Package guix. (Sun, 29 Sep 2019 01:37:01 GMT) Full text and rfc822 format available.

Message #76 received at 36785 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 36785 <at> debbugs.gnu.org
Subject: Re: bug#36785: Impossible to pull on foreign distro
Date: Sun, 29 Sep 2019 10:36:01 +0900
Hello Ludovic!

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi Maxim!
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
>> Date: Sat, 28 Sep 2019 00:11:28 +0900
>> Subject: [PATCH] doc: Add a 'Upgrading Guix' section to the 'Installation'
>>  chapter.
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> This follows a discussion regarding issue #36785 (see:
>> https://bugs.gnu.org/36785).
>>
>> * doc/guix.texi (Upgrading Guix): New section.
>>
>> Co-authored-by: Ludovic Courtès <ludo <at> gnu.org>
>
> [...]
>
>> +@node Upgrading Guix
>> +@section Upgrading Guix
>> +
>> +@cindex Upgrading Guix, on a foreign distro
>
> Nitpicking: index entries are usually lower-case.

Oh! I hadn't realized this was the convention used in Guix, thanks for
pointing it out.

>> +To upgrade Guix, run:
>> +
>> +@example
>> +guix pull
>> +@end example
>
> Perhaps add:
>
>   @xref{Invoking guix pull}, for more information.
>
>> +When you need to upgrade the build daemon, for instance, which runs as
>> +root, run:
>> +
>> +@example
>> +sudo -i guix pull
>> +@end example
>
> What about restating upfront that we’re talking about foreign distros
> specifically:
>
>   On a foreign distro, you can upgrade the build daemon by running:
>
>   @example
>   sudo -i guix pull
>   @end example
>
>   @noindent
>   followed by (assuming your distro uses the systemd service management
>   tool):
>
>   @example
>   systemctl restart guix-daemon.service
>   @end example
>
>   On Guix System, upgrading the daemon is achieved by reconfiguring the
>   system (@pxref{Invoking guix system, @code{guix system reconfigure}}).
>
> ?

Great additions.

> Feel free to push something along these lines.

Pushed as 5510bb01e9.

Thank you!

Maxim




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 27 Oct 2019 11:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 154 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.