[debbugs-tracker] bug#36785: closed ('sudo guix pull' failure in the profile migration code)

[GNU bug Tracking System]

Your message dated Thu, 19 Sep 2019 10:24:18 +0200
with message-id <address@hidden>
and subject line Re: bug#36785: Impossible to pull on foreign distro
has caused the debbugs.gnu.org bug report #36785,
regarding 'sudo guix pull' failure in the profile migration code
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
36785: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36785
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> Impossible to pull on foreign distro
>
>
>
>
> Date: 
>
> Wed, 24 Jul 2019 16:40:42 +0200
>
>
>
>
> User-agent: 
>
> K-9 Mail for Android
>
>
>
>
> 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.
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#36785: Impossible to pull on foreign distro
>
>
>
>
> Date: 
>
> Thu, 19 Sep 2019 10:24:18 +0200
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
>
>
>
>
> Hi,
>
> Ricardo Wurmus <address@hidden> skribis:
>
> > Ludovic Courtès <address@hidden> 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’.
>
>
> --- End Message ---