Re: Guix installing different package versions on different machines

[Zelphir Kaltstahl]

I fixed the problem by reinstalling Guix multiple times (I had other
issues popping up when doing so, but was able to solve them.).

However, after a fresh install of Guix the result of `which guix` is
still `/usr/local/bin/guix`. I think that might not be an actual problem.

I now have updated packages, just like on my machine at work.

On 9/28/19 10:43 PM, Zelphir Kaltstahl wrote:
> The moment at which I did the `guix pull` and `guix package- u` cannot
> be the issue for outdated packages, as I have done both multiple times
> weeks after noticing the behavior described. It is not, that the package
> was not available in the morning but was available in the afternoon or
> something like that. For weeks I've tried multiple times and the version
> difference is still there.
>
> On 9/28/19 4:41 PM, Tobias Geerinckx-Rice wrote:
>> Zelphir,
>>
>> Zelphir Kaltstahl 写道：
>>> I installed Guix on my own machine (Xubuntu 18.04.3) and at work on my
>>> machine (Ubuntu 18.04.3). Although I do `guix pull` and then `guix
>>> package -u`, both machines get different versions of packages installed
>>> this way.
>>> Guile (home: 2.2.4, work: 2.2.6).
>> This is not normal.  GNU Guile 2.2.6 was added to Guix almost 3 months
>> ago.
>>
>> What does ‘guix describe’ return on both machines?  Something recent? 
>> You can look up the commit IDs in the git history.
>>
>> What does ‘which guix’ say?  It should print the same thing on both
>> machines (/home/you!/.config/guix/current/bin/guix). Certainly not
>> /usr/local/bin/guix or anything like that.
> This seems to be more in the right direction:
>
> $ guix describe
> guix describe: error: failed to determine origin
>
> $ which guix
> /usr/local/bin/guix
>
> So there seems to be an issue here. The question then is, how it got to
> /usr/local/bin/guix. `sudo aptitude search guix` does not reveal any
> results, so I cannot have installed it in such a way. I am quite sure
> that I simply followed the instructions on the website to do a binary
> installation on both system, at work and at home.
>
> I currently do not have access to the machine at work for the next few
> days, so I cannot check what the results for those commands are on that
> machine.
>
> If /usr/local/bin/guix is wrong, what could cause it and do I need to
> reinstall Guix?
>
>>> I don't
>>> understand this behavior, as I thought that both installations of Guix
>>> should use the same repositories, because I installed them the same way
>>> and I even use the same OS at the core. Furthermore I thought, that Guix
>>> installs packages as they have been provided by contributors and does
>>> not perform checks, whether some package is suitable on a system.
>>>
>>> Where is my understanding wrong?
>> Trick question :-)  Your understanding is, generally, correct.
>>
>>> What can lead to this behavior?
>> Guix doesn't strictly ‘use repositories’: package definitions are part
>> of and updated in sync with the package manager, which is why it
>> matters *which* guix runs when you invoke it and why I'm interested in
>> the output of ‘which guix’ above.  ‘guix pull’ *only* updates
>> /home/you!/.config/guix/current/bin/guix.
>>
>> Packages can be marked as unsupported on certain architectures (e.g.
>> i686 vs. x86_64 or aarch64) and/or kernels (the Hurd or Linux), but
>> guile@2.2.6 supports all of them.
>>
>> AFAIK Guix only runs on one OS (GNU), so that can't affect things either.
>>
>> Jesse Gibbons 写道：
>>> To make sure all package versions match, write cron jobs to do this
>>> at the
>>> same time on both machines.
>> Yes.  If said matching is really important to you, having all machines
>> ‘git pull --commit=…’ to the same commit is even better but requires
>> some communication between them.
>
> It is not a production system, I just want to be on the up-to-date
> version of packages, when they are released. So not super important, but
> annoying to know, that for some reason I am not getting the new version
> at home.
>
> Thank for your help so far,
>
> Zelphir
>
>