GNU bug report logs - #33647
First `guix pull' behaves unexpectedly

Previous Next

Package: guix;

Reported by: Diego Nicola Barbato <dnbarbato <at> posteo.de>

Date: Thu, 6 Dec 2018 14:58:02 UTC

Severity: normal

Done: Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de>

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 33647 in the body.
You can then email your comments to 33647 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#33647; Package guix. (Thu, 06 Dec 2018 14:58:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Diego Nicola Barbato <dnbarbato <at> posteo.de>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Thu, 06 Dec 2018 14:58:02 GMT) Full text and rfc822 format available.

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

From: Diego Nicola Barbato <dnbarbato <at> posteo.de>
To: bug-guix <at> gnu.org
Subject: First `guix pull' behaves unexpectedly
Date: Thu, 06 Dec 2018 15:56:48 +0100
Hello Guix,

The first time a user runs ‘guix pull’ after a fresh install it does not
seem to update guix.  ‘guix --version’ reports that guix is still
version 0.15.0 after running ‘guix pull’, instead of showing the hash of
the latest commit.
This can be mitigated by logging out and back in, after which
‘guix --version’ returns the expected version.

Greetings

Diego




Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Thu, 06 Dec 2018 15:43:01 GMT) Full text and rfc822 format available.

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

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Diego Nicola Barbato <dnbarbato <at> posteo.de>
Cc: 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Thu, 06 Dec 2018 16:42:11 +0100
Hi Diego,

> Hello Guix,
>
> The first time a user runs ‘guix pull’ after a fresh install it does not
> seem to update guix.  ‘guix --version’ reports that guix is still
> version 0.15.0 after running ‘guix pull’, instead of showing the hash of
> the latest commit.

“guix pull” should have reminded you to add ~/.config/guix/current/bin
to the front of your PATH environment variable.  When you do that you
will be using the new version of Guix.

-- 
Ricardo





Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Thu, 06 Dec 2018 17:04:01 GMT) Full text and rfc822 format available.

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

From: Diego Nicola Barbato <dnbarbato <at> posteo.de>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Thu, 06 Dec 2018 18:03:04 +0100
Hello Ricardo,

Thank you for the prompt reply.

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

> Hi Diego,
>
>> Hello Guix,
>>
>> The first time a user runs ‘guix pull’ after a fresh install it does not
>> seem to update guix.  ‘guix --version’ reports that guix is still
>> version 0.15.0 after running ‘guix pull’, instead of showing the hash of
>> the latest commit.
>
> “guix pull” should have reminded you to add ~/.config/guix/current/bin
> to the front of your PATH environment variable.

I just checked the output and there was nothing after
“1 package in profile”, which is where the
“The following environment variable definitions may be needed:” lines
are usually printed.  If ‘guix pull’ is indeed supposed to print a
reminder this is probably the bug.

Greetings

Diego




Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Thu, 06 Dec 2018 23:07:02 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 33647 <at> debbugs.gnu.org, Diego Nicola Barbato <dnbarbato <at> posteo.de>
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Fri, 07 Dec 2018 00:06:01 +0100
Hello,

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

>> Hello Guix,
>>
>> The first time a user runs ‘guix pull’ after a fresh install it does not
>> seem to update guix.  ‘guix --version’ reports that guix is still
>> version 0.15.0 after running ‘guix pull’, instead of showing the hash of
>> the latest commit.
>
> “guix pull” should have reminded you to add ~/.config/guix/current/bin
> to the front of your PATH environment variable.  When you do that you
> will be using the new version of Guix.

In addition, be aware that Bash maintains a cache of commands it looked
up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
invalidate its cache thus you kept using that old version.

The solution is to run “hash guix” at the Bash prompt to force cache
invalidation (info "(bash) Bourne Shell Builtins").

HTH!

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Fri, 07 Dec 2018 08:37:02 GMT) Full text and rfc822 format available.

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

From: Diego Nicola Barbato <dnbarbato <at> posteo.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Fri, 07 Dec 2018 09:36:31 +0100
Hello,

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

> Hello,
>
> Ricardo Wurmus <rekado <at> elephly.net> skribis:
>
>>> Hello Guix,
>>>
>>> The first time a user runs ‘guix pull’ after a fresh install it does not
>>> seem to update guix.  ‘guix --version’ reports that guix is still
>>> version 0.15.0 after running ‘guix pull’, instead of showing the hash of
>>> the latest commit.
>>
>> “guix pull” should have reminded you to add ~/.config/guix/current/bin
>> to the front of your PATH environment variable.  When you do that you
>> will be using the new version of Guix.

I forgot to mention that this is on GuixSD, where
~/.config/guix/currend/bin is already in PATH, which maybe explains why
I did not get a reminder.

> In addition, be aware that Bash maintains a cache of commands it looked
> up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
> really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
> invalidate its cache thus you kept using that old version.
>
> The solution is to run “hash guix” at the Bash prompt to force cache
> invalidation (info "(bash) Bourne Shell Builtins").

I believe this is it.  This also explains why ‘which guix’ returned the
updated guix while ‘guix --version’ claimed it was still the older
version, which I found rather confusing.
I am afraid being unaware of this has led me to inadvertently downgrade
GuixSD whenever I reconfigured for the first time after a fresh install.

Thanks!

Diego




Reply sent to Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de>:
You have taken responsibility. (Fri, 07 Dec 2018 09:42:01 GMT) Full text and rfc822 format available.

Notification sent to Diego Nicola Barbato <dnbarbato <at> posteo.de>:
bug acknowledged by developer. (Fri, 07 Dec 2018 09:42:02 GMT) Full text and rfc822 format available.

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

From: Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de>
To: Diego Nicola Barbato <dnbarbato <at> posteo.de>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 33647-done <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Fri, 7 Dec 2018 10:41:36 +0100
[Message part 1 (text/plain, inline)]
On Fri, 07 Dec 2018 09:36:31 +0100
Diego Nicola Barbato <dnbarbato <at> posteo.de> wrote:

> I believe this is it.  This also explains why ‘which guix’ returned
> the updated guix while ‘guix --version’ claimed it was still the older
> version, which I found rather confusing.
> I am afraid being unaware of this has led me to inadvertently
> downgrade GuixSD whenever I reconfigured for the first time after a
> fresh install.

OK, then I'm closing this issue.

Björn
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Fri, 07 Dec 2018 13:31:02 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Diego Nicola Barbato <dnbarbato <at> posteo.de>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Fri, 07 Dec 2018 14:30:09 +0100
Hi,

Diego Nicola Barbato <dnbarbato <at> posteo.de> skribis:

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

[...]

>> In addition, be aware that Bash maintains a cache of commands it looked
>> up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
>> really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
>> invalidate its cache thus you kept using that old version.
>>
>> The solution is to run “hash guix” at the Bash prompt to force cache
>> invalidation (info "(bash) Bourne Shell Builtins").
>
> I believe this is it.  This also explains why ‘which guix’ returned the
> updated guix while ‘guix --version’ claimed it was still the older
> version, which I found rather confusing.
> I am afraid being unaware of this has led me to inadvertently downgrade
> GuixSD whenever I reconfigured for the first time after a fresh install.

Yeah.  This is not strictly speaking a Guix bug, but clearly it’s a
common pitfall.  Perhaps we should print a hint upon completion?

Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Wed, 19 Dec 2018 12:50:02 GMT) Full text and rfc822 format available.

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

From: Diego Nicola Barbato <dnbarbato <at> posteo.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Wed, 19 Dec 2018 13:49:17 +0100
Hello,

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

> Diego Nicola Barbato <dnbarbato <at> posteo.de> skribis:
>
>> Ludovic Courtès <ludo <at> gnu.org> writes:
>
> [...]
>
>>> In addition, be aware that Bash maintains a cache of commands it looked
>>> up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
>>> really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
>>> invalidate its cache thus you kept using that old version.
>>>
>>> The solution is to run “hash guix” at the Bash prompt to force cache
>>> invalidation (info "(bash) Bourne Shell Builtins").
>>
>> I believe this is it.  This also explains why ‘which guix’ returned the
>> updated guix while ‘guix --version’ claimed it was still the older
>> version, which I found rather confusing.
>> I am afraid being unaware of this has led me to inadvertently downgrade
>> GuixSD whenever I reconfigured for the first time after a fresh install.
>
> Yeah.  This is not strictly speaking a Guix bug, but clearly it’s a
> common pitfall.  Perhaps we should print a hint upon completion?

While I think it would be nice for Guix (or strictly speaking Bash) to
just do what a noob like me would expect it to do in this situation, a
hint would have certainly saved me some trouble.  If it is unreasonably
cumbersome to make Guix tell Bash to invalidate its cache upon
completion of ‘guix pull’, I believe a hint would be good enough.

Greetings,

Diego




Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Wed, 19 Dec 2018 17:32:01 GMT) Full text and rfc822 format available.

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

From: swedebugia <swedebugia <at> riseup.net>
To: bug-guix <at> gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Wed, 19 Dec 2018 18:37:24 +0100
On 2018-12-19 13:49, Diego Nicola Barbato wrote:
> Hello,
> 
> Ludovic Courtès <ludo <at> gnu.org> writes:
> 
>> Diego Nicola Barbato <dnbarbato <at> posteo.de> skribis:
>>
>>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>> [...]
>>
>>>> In addition, be aware that Bash maintains a cache of commands it looked
>>>> up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
>>>> really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
>>>> invalidate its cache thus you kept using that old version.
>>>>
>>>> The solution is to run “hash guix” at the Bash prompt to force cache
>>>> invalidation (info "(bash) Bourne Shell Builtins").
>>>
>>> I believe this is it.  This also explains why ‘which guix’ returned the
>>> updated guix while ‘guix --version’ claimed it was still the older
>>> version, which I found rather confusing.
>>> I am afraid being unaware of this has led me to inadvertently downgrade
>>> GuixSD whenever I reconfigured for the first time after a fresh install.
>>
>> Yeah.  This is not strictly speaking a Guix bug, but clearly it’s a
>> common pitfall.  Perhaps we should print a hint upon completion?
> 
> While I think it would be nice for Guix (or strictly speaking Bash) to
> just do what a noob like me would expect it to do in this situation, a
> hint would have certainly saved me some trouble.  If it is unreasonably
> cumbersome to make Guix tell Bash to invalidate its cache upon
> completion of ‘guix pull’, I believe a hint would be good enough.

I wholeheartedly agree with Diego.

Either we fix it (preferably, even if we have to patch bash in order to 
archive what we want) or we tell the users what to do (this is bad 
because we already tell the users a lot of env variables and this just 
adds clutter and one more cumbersome thing to remember).

FWW I just ran "hash pacman" on parabola and the result was this:
egil <at> parabola:~$ time hash pacman

real	0m0,000s
user	0m0,000s
sys	0m0,000s

So it won't and any measuable overhead to just call this in the end of 
guix package after updating the symlinks to the new profile generation.

-- 
Cheers Swedebugia




Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Wed, 19 Dec 2018 19:28:02 GMT) Full text and rfc822 format available.

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

From: Tobias Geerinckx-Rice <somebody <at> not-sent-or-endorsed-by.tobias.gr>
To: swedebugia <swedebugia <at> riseup.net>
Cc: 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Wed, 19 Dec 2018 20:27:24 +0100
swedebugia wrote:
> egil <at> parabola:~$ time hash pacman
>
> real	0m0,000s
> user	0m0,000s
> sys	0m0,000s
>
> So it won't and any measuable overhead to just call this in the 
> end of
> guix package after updating the symlinks to the new profile
> generation.

Do you mean to put something like

 guix() {
   command "$1" "$@"
   hash "$1"
 }

in the default /etc/profile (or wherever such things belong)?

I think this is far too intrusive and magical to do by default, 
considering its limited one-time-only usefulness.  The same goes 
for patching shells.

Kind regards,

T G-R




Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Thu, 20 Dec 2018 05:18:01 GMT) Full text and rfc822 format available.

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

From: swedebugia <swedebugia <at> riseup.net>
To: Tobias Geerinckx-Rice <somebody <at> not-sent-or-endorsed-by.tobias.gr>
Cc: 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Thu, 20 Dec 2018 06:24:11 +0100
On 2018-12-19 20:27, Tobias Geerinckx-Rice wrote:
> swedebugia wrote:
>> egil <at> parabola:~$ time hash pacman
>>
>> real    0m0,000s
>> user    0m0,000s
>> sys    0m0,000s
>>
>> So it won't and any measuable overhead to just call this in the end of
>> guix package after updating the symlinks to the new profile
>> generation.
> 
> Do you mean to put something like
> 
>   guix() {
>     command "$1" "$@"
>     hash "$1"
>   }
> 
> in the default /etc/profile (or wherever such things belong)?
> 
> I think this is far too intrusive and magical to do by default, 
> considering its limited one-time-only usefulness.  The same goes for 
> patching shells.

That sounds like it could work even though it look like an ugly hack. :)

-- 
Cheers Swedebugia




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 17 Jan 2019 12:24:07 GMT) Full text and rfc822 format available.

bug unarchived. Request was from Diego Nicola Barbato <dnbarbato <at> posteo.de> to control <at> debbugs.gnu.org. (Thu, 17 Jan 2019 17:28:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Fri, 18 Jan 2019 16:56:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Diego Nicola Barbato <dnbarbato <at> posteo.de>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 33647-done <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Fri, 18 Jan 2019 17:54:58 +0100
Hi Diego,

Diego Nicola Barbato <dnbarbato <at> posteo.de> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Diego Nicola Barbato <dnbarbato <at> posteo.de> skribis:
>>
>>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>
>> [...]
>>
>>>> In addition, be aware that Bash maintains a cache of commands it looked
>>>> up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
>>>> really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
>>>> invalidate its cache thus you kept using that old version.
>>>>
>>>> The solution is to run “hash guix” at the Bash prompt to force cache
>>>> invalidation (info "(bash) Bourne Shell Builtins").
>>>
>>> I believe this is it.  This also explains why ‘which guix’ returned the
>>> updated guix while ‘guix --version’ claimed it was still the older
>>> version, which I found rather confusing.
>>> I am afraid being unaware of this has led me to inadvertently downgrade
>>> GuixSD whenever I reconfigured for the first time after a fresh install.
>>
>> Yeah.  This is not strictly speaking a Guix bug, but clearly it’s a
>> common pitfall.  Perhaps we should print a hint upon completion?
>
> While I think it would be nice for Guix (or strictly speaking Bash) to
> just do what a noob like me would expect it to do in this situation, a
> hint would have certainly saved me some trouble.  If it is unreasonably
> cumbersome to make Guix tell Bash to invalidate its cache upon
> completion of ‘guix pull’, I believe a hint would be good enough.

Thanks for the heads-up.  Commit
3bbd6919bd84b76686d1aa626ba861faf3fc8ceb changes ‘guix pull’ to display
a hint in this case.

Ludo’.




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

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

From: Diego Nicola Barbato <dnbarbato <at> posteo.de>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Tue, 22 Jan 2019 23:07:04 +0100
[Message part 1 (text/plain, inline)]
Hello Ludo,

Sorry to bother you with this again.

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


[...]


>
> Thanks for the heads-up.  Commit
> 3bbd6919bd84b76686d1aa626ba861faf3fc8ceb changes ‘guix pull’ to display
> a hint in this case.
>
> Ludo’.

I just tried to check if this worked.  I installed GuixSD in a VM (with
the 0.16.0 installer), rebooted, and ran ‘guix pull’
(commit d1dfcc7c1b38d816dddc2868917ba490db7e7c3b).  It did not print any
hint (I have attached the bash session).
Will this change only take effect once the installer is updated?

Regards,

Diego

[guix_pull.log (application/octet-stream, attachment)]

Information forwarded to bug-guix <at> gnu.org:
bug#33647; Package guix. (Wed, 23 Jan 2019 09:52:01 GMT) Full text and rfc822 format available.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Diego Nicola Barbato <dnbarbato <at> posteo.de>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 33647 <at> debbugs.gnu.org
Subject: Re: bug#33647: First `guix pull' behaves unexpectedly
Date: Wed, 23 Jan 2019 10:51:01 +0100
Hi Diego,

Diego Nicola Barbato <dnbarbato <at> posteo.de> skribis:

>> Thanks for the heads-up.  Commit
>> 3bbd6919bd84b76686d1aa626ba861faf3fc8ceb changes ‘guix pull’ to display
>> a hint in this case.
>>
>> Ludo’.
>
> I just tried to check if this worked.  I installed GuixSD in a VM (with
> the 0.16.0 installer), rebooted, and ran ‘guix pull’
> (commit d1dfcc7c1b38d816dddc2868917ba490db7e7c3b).  It did not print any
> hint (I have attached the bash session).
> Will this change only take effect once the installer is updated?

Yes, since the change is in ‘guix pull’ itself, the 0.16.0 ‘guix pull’
won’t display the message.  So you’d have to run the ‘guix pull’ you
just obtained from ‘guix pull’ (ah!) to see the message.

HTH,
Ludo’.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 20 Feb 2019 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 38 days ago.

Previous Next


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