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 > >
