GNU bug report logs - #53886
guix home not respecting guix pull -C

Previous Next

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

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

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

From: Zacchaeus Scheffer <zaccysc <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: guix home not respecting guix pull -C
Date: Tue, 8 Feb 2022 18:57:14 -0500

[Message part 1 (text/plain, inline)]

Hi Guix!

I came across some weird behavior with guix home.  I wanted to recreate a
working home environment from one machine on another (because I need a
working qutebrowser install :3).  I did this by doing "guix pull
--allow-downgrades -C" on my non-working computer using a channels file on
the working one generated with "guix package --export-channels".  However,
when I did "guix home reconfigure ...", old versions of packages were NOT
installed.  I was able to downgrade the desired package with "guix package
-i" (only that package was downgraded).

My understanding is that "guix home reconfigure" SHOULD behave like "guix
package --manifest", and install all packages in the most recent guix pull.

Very minor and not impeding me, but thought y'all should know,
-Zacchaeus Scheffer

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

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

From: Leo Famulari <leo <at> famulari.name>
To: Zacchaeus Scheffer <zaccysc <at> gmail.com>
Cc: 53886 <at> debbugs.gnu.org
Subject: Re: bug#53886: guix home not respecting guix pull -C
Date: Tue, 8 Feb 2022 20:06:39 -0500

On Tue, Feb 08, 2022 at 06:57:14PM -0500, Zacchaeus Scheffer wrote:
> Hi Guix!
> 
> I came across some weird behavior with guix home.  I wanted to recreate a
> working home environment from one machine on another (because I need a
> working qutebrowser install :3).  I did this by doing "guix pull
> --allow-downgrades -C" on my non-working computer using a channels file on
> the working one generated with "guix package --export-channels".  However,
> when I did "guix home reconfigure ...", old versions of packages were NOT
> installed.  I was able to downgrade the desired package with "guix package
> -i" (only that package was downgraded).

I'm curious, after you did `guix pull --allow-downgrades -C`, did you
use `guix show foo` before reconfiguring, in order to check if the pull
had taken effect?

Also, did you pull and reconfigure as the same user, with the same
privileges? Remember that your "view" of Guix (i.e. `guix pull`) is
per-user.

> My understanding is that "guix home reconfigure" SHOULD behave like "guix
> package --manifest", and install all packages in the most recent guix pull.

That's my understanding as well.

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

From: Zacchaeus Scheffer <zaccysc <at> gmail.com>
To: 53886 <at> debbugs.gnu.org
Subject: Re: bug#53886: guix home not respecting guix pull -C
Date: Wed, 9 Feb 2022 01:40:47 -0500

[Message part 1 (text/plain, inline)]

> Also, did you pull and reconfigure as the same user, with the same
> privileges? Remember that your "view" of Guix (i.e. `guix pull`) is
> per-user.

Everything is done with the same user and same user/system config (other
than os host-name field).  I'm sure I didn't accidently run as root or
another user

> I'm curious, after you did `guix pull --allow-downgrades -C`, did you
> use `guix show foo` before reconfiguring, in order to check if the pull
> had taken effect?

I did not check, the command completed normally, so I believed.  See (far)
below for an example with guix show

Looking at guix package --list-generations, my packages were only modified
the one time I ran guix package -i qutebrowser.  After running guix package
-i qutebrowser, guix package --export-channels DID have the content passed
to guix pull -C PLUS the following comment:
;; Note: these other commits were also used to install some of the packages
in this profile:
;;   "97d97d7da1f5b500b2b76210131ca6adff6a1e80"

Looking at guix home list-generations, it looks like the generation has not
updated any of the numerous times I guix home reconfigured today after guix
pull --allow-downgrades -C'ing an old channels.  However, I was not able to
reproduce this behavior, so take it with a grain of salt.

To rule out the possibility that this is an already-solved problem, I tried
guix pull
guix home reconfigure ...
this DID create a new home generation but not package generation.  (Not
sure if that is expected.  Please someone tell me if this is abnormal.)  Now
ls -l $(which qutebrowser)
gives the old qutebrowser version but
ls -l $(which chromium)
gives the new chromium version.

I tried editing my home config and adding another package, "minetest".
 guix home reconfigure DID download "minetest" after "guix pull" and "guix
pull --allow-downgrades -C ..." (diff versions), but always "minetest" is
not in my path for even a fresh login shell.

To sumarize:
guix pull --allow-downgrades -C ...
guix home reconfigure ....
- > all package versions up-to-date
- > (no?) new home generation
guix package -i qutebrowser
- > all package versions up-to-date except qutebrowser downgraded
- > created a new package generation
guix pull
guix home reconfigure ...
- > all package versions up-to-date except qutebrowser downgraded
- > created a new home generation
guix pull --allow-downgrades -C ...
guix home reconfigure ....
- > new home generetaion
- > qutebrowser still downgraded
- > chromium upgraded
# add minetest to config
guix home reconfigure ...
- > new home generation
- > minetest installed (not sure what version)
- - > MINETEST NOT IN PATH
- > qutebrowser/chromium unchanged

Looking back, maybe guix home reconfigure has NEVER worked for my packages
and I haven't noticed because my most recent package manifest had all the
same packages.  My package defs in my home.scm look like:
(home-environment
 (packages
  (map
   specification->package
   (list
    ...
    "minetest"
    "qutebrowser"
    "ungoogled-chromium")))
 (services
  ...))

Now I feel more lost than before.  How could the above in a home
reconfigure, after a normal guix pull, not make even a fresh login shell
able to launch minetest?...

One last test to show off the weirdness:
guix pull
guix show qutebrowser     - > version 2.4
qutebrowser --version     - > version 2.3
guix home reconfigure ... - > full output below
guix show qutebrowser     - > version 2.4
qutebrowser --version     - > version 2.3

If you made it this far, thanks,
-Zacchaeus


##  BEGIN HOME RECONFIGURE OUTPUT PASTE
/gnu/store/02q0hr0k29wr866b1mrh88qnaixnk3v7-home
Cleaning up symlinks from previous home-environment.

Removing /home/zacchae/.config/fontconfig/fonts.conf... done
Removing /home/zacchae/.config/fontconfig... done
Removing /home/zacchae/.config/zsh/.zshrc... done
Removing /home/zacchae/.config/zsh/.zprofile... done
Removing /home/zacchae/.config/zsh/.zshenv... done
Skipping /home/zacchae/.config/zsh (not an empty directory)... done
Removing /home/zacchae/.config/syncthing/config... done
Skipping /home/zacchae/.config/syncthing (not an empty directory)... done
Removing /home/zacchae/.config/emacs/init.el... done
Skipping /home/zacchae/.config/emacs (not an empty directory)... done
Removing /home/zacchae/.config/kitty/kitty.conf... done
Removing /home/zacchae/.config/kitty... done
Removing /home/zacchae/.config/qutebrowser/config.py... done
Skipping /home/zacchae/.config/qutebrowser (not an empty directory)... done
Removing /home/zacchae/.config/zathura/zathurarc... done
Removing /home/zacchae/.config/zathura... done
Removing /home/zacchae/.config/redshift/redshift.conf... done
Removing /home/zacchae/.config/redshift... done
Skipping /home/zacchae/.config (not an empty directory)... done
Removing /home/zacchae/.ssh/config... done
Skipping /home/zacchae/.ssh (not an empty directory)... done
Removing /home/zacchae/.local/bin/stdinedit... done
Removing /home/zacchae/.local/bin... done
Skipping /home/zacchae/.local (not an empty directory)... done
Removing /home/zacchae/.gitconfig... done
Removing /home/zacchae/.exwm... done
Removing /home/zacchae/.zshenv... done
Removing /home/zacchae/.profile... done
Cleanup finished.

New symlinks to home-environment will be created soon.
All conflicting files will go to
/home/zacchae/1644387797-guix-home-legacy-configs-backup.

Skipping   /home/zacchae/.config (directory already exists)... done
Creating   /home/zacchae/.config/fontconfig... done
Symlinking /home/zacchae/.config/fontconfig/fonts.conf ->
/gnu/store/3hd0w1mcm3zg7gy3ifgvdf8w1n77khnm-fonts.conf... done
Skipping   /home/zacchae/.config/zsh (directory already exists)... done
Symlinking /home/zacchae/.config/zsh/.zshrc ->
/gnu/store/hyvqqy8i6ibi72xc5361p08qjibnwfk4-zshrc... done
Symlinking /home/zacchae/.config/zsh/.zprofile ->
/gnu/store/jgz1ykacgqwkjbwagd301nj4y9ygdi9m-zprofile... done
Symlinking /home/zacchae/.config/zsh/.zshenv ->
/gnu/store/251xg38dsqifyw3dzwzpvl28vi7c8wd6-zshenv... done
Skipping   /home/zacchae/.config/syncthing (directory already exists)...
done
Symlinking /home/zacchae/.config/syncthing/config ->
/gnu/store/7svbwjb0ixzjz2kllk6fxc8737aavd35-syncthing-config.xml... done
Skipping   /home/zacchae/.config/emacs (directory already exists)... done
Symlinking /home/zacchae/.config/emacs/init.el ->
/gnu/store/7p09csma6wk8bcanqm8wrra0v4yw496y-emacs-config... done
Creating   /home/zacchae/.config/kitty... done
Symlinking /home/zacchae/.config/kitty/kitty.conf ->
/gnu/store/pmnr4ivcviwyi2h2yrx1rg8gf0rjs0ay-kitty.conf... done
Skipping   /home/zacchae/.config/qutebrowser (directory already exists)...
done
Symlinking /home/zacchae/.config/qutebrowser/config.py ->
/gnu/store/c50z8wfsc4k1m0h7k3sbv0xsndh7bw6j-qutebrowser-config... done
Creating   /home/zacchae/.config/zathura... done
Symlinking /home/zacchae/.config/zathura/zathurarc ->
/gnu/store/kdi0gfbz5gcq2ay32yv89amvhbd5r3wg-zathura-config... done
Creating   /home/zacchae/.config/redshift... done
Symlinking /home/zacchae/.config/redshift/redshift.conf ->
/gnu/store/p1y1xfxf63pjn1dsd92vwp1xbrcsh7wn-redshift-config... done
Skipping   /home/zacchae/.ssh (directory already exists)... done
Symlinking /home/zacchae/.ssh/config ->
/gnu/store/519n9v56q5qnhwrb3yj8dh87lwspqlrb-ssh-config... done
Skipping   /home/zacchae/.local (directory already exists)... done
Creating   /home/zacchae/.local/bin... done
Symlinking /home/zacchae/.local/bin/stdinedit ->
/gnu/store/3rx8zb8phkr8a88sg5v8pd33qxn62zyh-stdinedit... done
Symlinking /home/zacchae/.gitconfig ->
/gnu/store/ci21256g0sys1a0gpwlrvakgazwbh5kb-git-config... done
Symlinking /home/zacchae/.exwm ->
/gnu/store/z43zay3w80cp0bnwdd1pi5j4zxay75mp-exwm-init... done
Symlinking /home/zacchae/.zshenv ->
/gnu/store/j1558r4rqn5nlj3caxs62jcs7rb2j4x4-auxiliary-zshenv... done
Symlinking /home/zacchae/.profile ->
/gnu/store/rnf1g1a1lywvy3lw4h8ywfs9i8f35fiq-shell-profile... done
 done
Finished updating symlinks.

Loading /gnu/store/2z8k6n538446fm0r5byk81kcv3khgkkn-shepherd.conf.
Starting services...

Comparing
/gnu/store/02q0hr0k29wr866b1mrh88qnaixnk3v7-home/profile/share/fonts and

/gnu/store/02q0hr0k29wr866b1mrh88qnaixnk3v7-home/profile/share/fonts...
done (same)
Evaluating on-change gexps.

On-change gexps evaluation finished.
## END RECONFIGURE PASTE

On Tue, Feb 8, 2022 at 8:06 PM Leo Famulari <leo <at> famulari.name> wrote:

> On Tue, Feb 08, 2022 at 06:57:14PM -0500, Zacchaeus Scheffer wrote:
> > Hi Guix!
> >
> > I came across some weird behavior with guix home.  I wanted to recreate a
> > working home environment from one machine on another (because I need a
> > working qutebrowser install :3).  I did this by doing "guix pull
> > --allow-downgrades -C" on my non-working computer using a channels file
> on
> > the working one generated with "guix package --export-channels".
> However,
> > when I did "guix home reconfigure ...", old versions of packages were NOT
> > installed.  I was able to downgrade the desired package with "guix
> package
> > -i" (only that package was downgraded).
>
> I'm curious, after you did `guix pull --allow-downgrades -C`, did you
> use `guix show foo` before reconfiguring, in order to check if the pull
> had taken effect?
>
> Also, did you pull and reconfigure as the same user, with the same
> privileges? Remember that your "view" of Guix (i.e. `guix pull`) is
> per-user.
>
> > My understanding is that "guix home reconfigure" SHOULD behave like "guix
> > package --manifest", and install all packages in the most recent guix
> pull.
>
> That's my understanding as well.
>

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

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

From: Josselin Poiret <dev <at> jpoiret.xyz>
To: Zacchaeus Scheffer <zaccysc <at> gmail.com>, 53886 <at> debbugs.gnu.org
Subject: Re: bug#53886: guix home not respecting guix pull -C
Date: Wed, 09 Feb 2022 10:10:16 +0100

Hello Zacchaeus and Leo,

Zacchaeus Scheffer <zaccysc <at> gmail.com> writes:

> Looking at guix package --list-generations, my packages were only modified
> the one time I ran guix package -i qutebrowser.  After running guix package
> -i qutebrowser, guix package --export-channels DID have the content passed
> to guix pull -C PLUS the following comment:
> ;; Note: these other commits were also used to install some of the packages
> in this profile:
> ;;   "97d97d7da1f5b500b2b76210131ca6adff6a1e80"
>
> [snip]
>
> Looking at guix home list-generations, it looks like the generation has not
> updated any of the numerous times I guix home reconfigured today after guix
> pull --allow-downgrades -C'ing an old channels.  However, I was not able to
> reproduce this behavior, so take it with a grain of salt.
>> > My understanding is that "guix home reconfigure" SHOULD behave like "guix
>> > package --manifest", and install all packages in the most recent guix
>> pull.
>>
>> That's my understanding as well.

I believe that's the main misunderstanding here, `guix home` acts like
`guix system`: it creates home generations, inside which there is a
profile.  That profile is _not_ ~/.guix-profile, but rather
~/.guix-home/profile.  They are disjoint and not operated on by the same
commands, guix home will not touch ~/.guix-profile.  If you configure
your shell environment variables with guix home alone, I believe only
the the guix home profile is available by default.

Best,
-- 
Josselin Poiret

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

From: Zacchaeus Scheffer <zaccysc <at> gmail.com>
To: Josselin Poiret <dev <at> jpoiret.xyz>
Cc: 53886 <at> debbugs.gnu.org
Subject: Re: bug#53886: guix home not respecting guix pull -C
Date: Wed, 9 Feb 2022 13:17:23 -0500

[Message part 1 (text/plain, inline)]

>
> I believe that's the main misunderstanding here, `guix home` acts like
> `guix system`: it creates home generations, inside which there is a
> profile.  That profile is _not_ ~/.guix-profile, but rather
> ~/.guix-home/profile.  They are disjoint and not operated on by the same
> commands, guix home will not touch ~/.guix-profile.  If you configure
> your shell environment variables with guix home alone, I believe only
> the the guix home profile is available by default.
>

I think I tracked down the problem.  In my home-zsh-service, I added the
contents of my previous .zprofile to to my new .zprofile, including "source
/etc/profile", so my .zprofile (with autogenerated lines) looked like:
source /etc/profile
source ~/.profile
source /etc/profile
Basically, /etc/profile stripped from my PATH the ~/.guix-home/profile
which was added by ~/.profile

I think this solves the original problem, but I don't like that
~/.guix-profile/ AND ~/.guix-home/profile are added to your path by
default.  I admit this is probably a "sane default" for most users, but I
care a lot about reproducibility.  Though I think there should be a better
solution, for now I am going to have guix home run "guix package -m" with
an empty manifest on reconfigure.

Thanks all for your help,
Zacchaeus

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

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

From: Zacchaeus Scheffer <eikcaz <at> zacchae.us>
To: 53886-done <at> debbugs.gnu.org
Subject: guix home not respecting guix pull -C
Date: Mon, 07 Apr 2025 16:50:58 -0400

Closing as main problem was resolved.

Previous Next

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