all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#36785: Impossible to pull on foreign distro
@ 2019-07-24 14:40 Julien Lepiller
  2019-07-25 23:03 ` Ludovic Courtès
  0 siblings, 1 reply; 21+ messages in thread
From: Julien Lepiller @ 2019-07-24 14:40 UTC (permalink / raw)
  To: 36785

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.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-07-24 14:40 bug#36785: Impossible to pull on foreign distro Julien Lepiller
@ 2019-07-25 23:03 ` Ludovic Courtès
  2019-07-26  6:22   ` Julien Lepiller
  0 siblings, 1 reply; 21+ messages in thread
From: Ludovic Courtès @ 2019-07-25 23:03 UTC (permalink / raw)
  To: Julien Lepiller; +Cc: 36785

Hi Julien,

Julien Lepiller <julien@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’.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-07-25 23:03 ` Ludovic Courtès
@ 2019-07-26  6:22   ` Julien Lepiller
  2019-07-26  8:09     ` Ludovic Courtès
  0 siblings, 1 reply; 21+ messages in thread
From: Julien Lepiller @ 2019-07-26  6:22 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 36785

Le 26 juillet 2019 01:03:08 GMT+02:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hi Julien,
>
>Julien Lepiller <julien@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?

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-07-26  6:22   ` Julien Lepiller
@ 2019-07-26  8:09     ` Ludovic Courtès
  2019-09-17 22:03       ` Ludovic Courtès
  0 siblings, 1 reply; 21+ messages in thread
From: Ludovic Courtès @ 2019-07-26  8:09 UTC (permalink / raw)
  To: Julien Lepiller; +Cc: 36785

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

Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

> Le 26 juillet 2019 01:03:08 GMT+02:00, "Ludovic Courtès" <ludo@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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 483 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 124 bytes --]


… but then ‘sudo guix pull’ won’t update root’s guix at all.

Otherwise I’m thinking of this gross hack:


[-- Attachment #4: Type: text/x-patch, Size: 816 bytes --]

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

[-- Attachment #5: Type: text/plain, Size: 154 bytes --]


I think it’s acceptable because that’s “throw away” code anyway, and
it’s not supposed to be triggered these days.

Thoughts?

Ludo’.

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-07-26  8:09     ` Ludovic Courtès
@ 2019-09-17 22:03       ` Ludovic Courtès
  2019-09-17 23:33         ` Gábor Boskovits
  2019-09-18 18:35         ` Ricardo Wurmus
  0 siblings, 2 replies; 21+ messages in thread
From: Ludovic Courtès @ 2019-09-17 22:03 UTC (permalink / raw)
  To: Julien Lepiller; +Cc: 36785

Hi,

Ludovic Courtès <ludo@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@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’.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-17 22:03       ` Ludovic Courtès
@ 2019-09-17 23:33         ` Gábor Boskovits
  2019-09-18  8:48           ` Ludovic Courtès
  2019-09-20  8:47           ` Maxim Cournoyer
  2019-09-18 18:35         ` Ricardo Wurmus
  1 sibling, 2 replies; 21+ messages in thread
From: Gábor Boskovits @ 2019-09-17 23:33 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 36785

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

Hello Ludo,

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

> Hi,
>
> Ludovic Courtès <ludo@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@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

[-- Attachment #2: Type: text/html, Size: 5773 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-17 23:33         ` Gábor Boskovits
@ 2019-09-18  8:48           ` Ludovic Courtès
  2019-09-20  8:47           ` Maxim Cournoyer
  1 sibling, 0 replies; 21+ messages in thread
From: Ludovic Courtès @ 2019-09-18  8:48 UTC (permalink / raw)
  To: Gábor Boskovits; +Cc: 36785

Hi,

Gábor Boskovits <boskovits@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’.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-17 22:03       ` Ludovic Courtès
  2019-09-17 23:33         ` Gábor Boskovits
@ 2019-09-18 18:35         ` Ricardo Wurmus
  2019-09-19  8:24           ` Ludovic Courtès
  1 sibling, 1 reply; 21+ messages in thread
From: Ricardo Wurmus @ 2019-09-18 18:35 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 36785


Ludovic Courtès <ludo@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@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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-18 18:35         ` Ricardo Wurmus
@ 2019-09-19  8:24           ` Ludovic Courtès
  0 siblings, 0 replies; 21+ messages in thread
From: Ludovic Courtès @ 2019-09-19  8:24 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: 36785-done

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@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’.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-17 23:33         ` Gábor Boskovits
  2019-09-18  8:48           ` Ludovic Courtès
@ 2019-09-20  8:47           ` Maxim Cournoyer
  2019-09-20 15:44             ` Ludovic Courtès
  1 sibling, 1 reply; 21+ messages in thread
From: Maxim Cournoyer @ 2019-09-20  8:47 UTC (permalink / raw)
  To: Gábor Boskovits; +Cc: 36785

Hello,

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

> Hello Ludo,
>
> Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. szept. 18., Sze,
> 0:04):
>
>> Hi,
>>
>> Ludovic Courtès <ludo@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@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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-20  8:47           ` Maxim Cournoyer
@ 2019-09-20 15:44             ` Ludovic Courtès
  2019-09-21 12:31               ` Maxim Cournoyer
  2019-09-21 12:32               ` Maxim Cournoyer
  0 siblings, 2 replies; 21+ messages in thread
From: Ludovic Courtès @ 2019-09-20 15:44 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: 36785

Maxim Cournoyer <maxim.cournoyer@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’.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-20 15:44             ` Ludovic Courtès
@ 2019-09-21 12:31               ` Maxim Cournoyer
  2019-09-23  8:29                 ` Ludovic Courtès
  2019-09-21 12:32               ` Maxim Cournoyer
  1 sibling, 1 reply; 21+ messages in thread
From: Maxim Cournoyer @ 2019-09-21 12:31 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 36785


[-- Attachment #1.1: Type: text/plain, Size: 3968 bytes --]

Hello,

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

> Maxim Cournoyer <maxim.cournoyer@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@e538556bf337: /\auser@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@e538556bf337: /\auser@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@e538556bf337: /\auser@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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-doc-Adapt-the-guix-pull-command-recommendation.patch --]
[-- Type: text/x-patch, Size: 2011 bytes --]

From bfa2f754592a00fefa4fcd20080582268b6273dd Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Sat, 21 Sep 2019 20:36:04 +0900
Subject: [PATCH] doc: Adapt the guix pull command recommendation.

This change follows the discussion for issue #36785 (see:
https://bugs.gnu.org/36785).

* doc/guix.texi (After System Installation): Add the '-i' sudo option to the
suggested commands used to keep a Guix System up-to-date.  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.
---
 doc/guix.texi | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 0ed59072c9..3690e3b152 100644
--- 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
-
 Join us on @code{#guix} on the Freenode IRC network or on
 @email{guix-devel@@gnu.org} to share your experience!
 
-- 
2.23.0


[-- Attachment #1.3: Type: text/plain, Size: 16 bytes --]


Thanks,

Maxim

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

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-20 15:44             ` Ludovic Courtès
  2019-09-21 12:31               ` Maxim Cournoyer
@ 2019-09-21 12:32               ` Maxim Cournoyer
  1 sibling, 0 replies; 21+ messages in thread
From: Maxim Cournoyer @ 2019-09-21 12:32 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 36785


[-- Attachment #1.1: Type: text/plain, Size: 3968 bytes --]

Hello,

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

> Maxim Cournoyer <maxim.cournoyer@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@e538556bf337: /\auser@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@e538556bf337: /\auser@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@e538556bf337: /\auser@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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-doc-Adapt-the-guix-pull-command-recommendation.patch --]
[-- Type: text/x-patch, Size: 2011 bytes --]

From bfa2f754592a00fefa4fcd20080582268b6273dd Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Sat, 21 Sep 2019 20:36:04 +0900
Subject: [PATCH] doc: Adapt the guix pull command recommendation.

This change follows the discussion for issue #36785 (see:
https://bugs.gnu.org/36785).

* doc/guix.texi (After System Installation): Add the '-i' sudo option to the
suggested commands used to keep a Guix System up-to-date.  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.
---
 doc/guix.texi | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 0ed59072c9..3690e3b152 100644
--- 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
-
 Join us on @code{#guix} on the Freenode IRC network or on
 @email{guix-devel@@gnu.org} to share your experience!
 
-- 
2.23.0


[-- Attachment #1.3: Type: text/plain, Size: 16 bytes --]


Thanks,

Maxim

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

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-21 12:31               ` Maxim Cournoyer
@ 2019-09-23  8:29                 ` Ludovic Courtès
  2019-09-23  9:00                   ` Gábor Boskovits
  2019-09-23 14:09                   ` Maxim Cournoyer
  0 siblings, 2 replies; 21+ messages in thread
From: Ludovic Courtès @ 2019-09-23  8:29 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: 36785

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@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’.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-23  8:29                 ` Ludovic Courtès
@ 2019-09-23  9:00                   ` Gábor Boskovits
  2019-09-23 12:48                     ` Ludovic Courtès
  2019-09-23 14:09                   ` Maxim Cournoyer
  1 sibling, 1 reply; 21+ messages in thread
From: Gábor Boskovits @ 2019-09-23  9:00 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 36785, Maxim Cournoyer

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

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. szept. 23., Hét
10:29):

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@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

>

[-- Attachment #2: Type: text/html, Size: 2835 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-23  9:00                   ` Gábor Boskovits
@ 2019-09-23 12:48                     ` Ludovic Courtès
  0 siblings, 0 replies; 21+ messages in thread
From: Ludovic Courtès @ 2019-09-23 12:48 UTC (permalink / raw)
  To: Gábor Boskovits; +Cc: 36785, Maxim Cournoyer

Hi Gábor,

Gábor Boskovits <boskovits@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’.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-23  8:29                 ` Ludovic Courtès
  2019-09-23  9:00                   ` Gábor Boskovits
@ 2019-09-23 14:09                   ` Maxim Cournoyer
  2019-09-24 12:37                     ` Ludovic Courtès
  1 sibling, 1 reply; 21+ messages in thread
From: Maxim Cournoyer @ 2019-09-23 14:09 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 36785

Hello,

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

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-23 14:09                   ` Maxim Cournoyer
@ 2019-09-24 12:37                     ` Ludovic Courtès
  2019-09-27 15:23                       ` Maxim Cournoyer
  0 siblings, 1 reply; 21+ messages in thread
From: Ludovic Courtès @ 2019-09-24 12:37 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: 36785

Hi,

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

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer@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’.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-24 12:37                     ` Ludovic Courtès
@ 2019-09-27 15:23                       ` Maxim Cournoyer
  2019-09-28 17:49                         ` Ludovic Courtès
  0 siblings, 1 reply; 21+ messages in thread
From: Maxim Cournoyer @ 2019-09-27 15:23 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 36785

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

Hi!

Ludovic Courtès <ludo@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


[-- Attachment #2: 0001-doc-Add-a-Upgrading-Guix-section-to-the-Installation.patch --]
[-- Type: text/x-patch, Size: 1966 bytes --]

From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@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@gnu.org>
---
 doc/guix.texi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 9fcce27597..45e6dfc442 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -513,6 +513,7 @@ ready to use it.
 * Setting Up the Daemon::       Preparing the build daemon's environment.
 * Invoking guix-daemon::        Running the build daemon.
 * Application Setup::           Application-specific setup.
+* Upgrading Guix::              Upgrading Guix and its build daemon.
 @end menu
 
 @node Binary Installation
@@ -1777,6 +1778,28 @@ invoke the actual linker with this new set of arguments.  You can instruct the
 wrapper to refuse to link against libraries not in the store by setting the
 @code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.
 
+@node Upgrading Guix
+@section Upgrading Guix
+
+@cindex Upgrading Guix, on a foreign distro
+
+To upgrade Guix, run:
+
+@example
+guix pull
+@end example
+
+@cindex Upgrading Guix for the root user, on a foreign distro
+@cindex Upgrading the Guix daemon, on a foreign distro
+@cindex @command{guix pull} for the root user, on a foreign distro
+
+When you need to upgrade the build daemon, for instance, which runs as
+root, run:
+
+@example
+sudo -i guix pull
+@end example
+
 @c TODO What else?
 
 @c *********************************************************************
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-27 15:23                       ` Maxim Cournoyer
@ 2019-09-28 17:49                         ` Ludovic Courtès
  2019-09-29  1:36                           ` Maxim Cournoyer
  0 siblings, 1 reply; 21+ messages in thread
From: Ludovic Courtès @ 2019-09-28 17:49 UTC (permalink / raw)
  To: Maxim Cournoyer; +Cc: 36785

Hi Maxim!

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

> From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer@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@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’.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#36785: Impossible to pull on foreign distro
  2019-09-28 17:49                         ` Ludovic Courtès
@ 2019-09-29  1:36                           ` Maxim Cournoyer
  0 siblings, 0 replies; 21+ messages in thread
From: Maxim Cournoyer @ 2019-09-29  1:36 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 36785

Hello Ludovic!

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

> Hi Maxim!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer@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@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

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2019-09-29  1:37 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-07-24 14:40 bug#36785: Impossible to pull on foreign distro Julien Lepiller
2019-07-25 23:03 ` Ludovic Courtès
2019-07-26  6:22   ` Julien Lepiller
2019-07-26  8:09     ` Ludovic Courtès
2019-09-17 22:03       ` Ludovic Courtès
2019-09-17 23:33         ` Gábor Boskovits
2019-09-18  8:48           ` Ludovic Courtès
2019-09-20  8:47           ` Maxim Cournoyer
2019-09-20 15:44             ` Ludovic Courtès
2019-09-21 12:31               ` Maxim Cournoyer
2019-09-23  8:29                 ` Ludovic Courtès
2019-09-23  9:00                   ` Gábor Boskovits
2019-09-23 12:48                     ` Ludovic Courtès
2019-09-23 14:09                   ` Maxim Cournoyer
2019-09-24 12:37                     ` Ludovic Courtès
2019-09-27 15:23                       ` Maxim Cournoyer
2019-09-28 17:49                         ` Ludovic Courtès
2019-09-29  1:36                           ` Maxim Cournoyer
2019-09-21 12:32               ` Maxim Cournoyer
2019-09-18 18:35         ` Ricardo Wurmus
2019-09-19  8:24           ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.