GNU bug report logs -
#33647
First `guix pull' behaves unexpectedly
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 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.
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):
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):
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):
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):
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):
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):
[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):
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):
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):
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):
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):
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):
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):
[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):
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.