Hi,
Thanks - I think the original question is answered now - however I am
curious over why only I can reproduce issues with the incorrect use of
'guix pull'. It's tempting to say it's just undefined behaviour and
move on with my life, but I've done a bit more digging....
* This appears to have nothing to do with defined channels - I have now
removed the channel.scm completely and can still reproduce the
problem.
* The problem occurs whenever 'guix pull -l' is called incorrectly on a
standard profile which has > 1 generation in it.
* There are 2 outcomes I've observed so far - a) a backtrace is given,
or b) the command halts for at least 27 minutes in what appears to be
a frozen state (but could just be very slow).
When I sent my first e-mail about this issue I showed the backtrace as
per a) above. I have now tried the experiment on a completely different
server and I can reproduce a), that is, I can create a profile
containing 1 package in 1st generation, and use 'guix pull -l' OK.
Then if I install another package for the 2nd generation I get the
backtrace occurring (see below).
However - I cannot reproduce b) myself on another machine, that is, I cannot
reproduce the freezing of 'guix pull -l' apart from on one specific
server. Instead I get the backtrace.
Perhaps the problem is specific to running Guix on Ubuntu 18.04 as all
my servers run this?
ubuntu@foobar:~$ guix pull -p /tmp/test-profile-only-guix-3 -l
\Generation 1 Jan 12 2021 18:51:57\
python 3.8.2
\Generation 2 Jan 12 2021 18:52:19\ (current)
python 3.8.2
python-numpy 1.17.3
Backtrace:
11 (primitive-load "/home/ubuntu/.config/guix/curre…")
In guix/ui.scm:
2154:12 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
1736:10 9 (with-exception-handler _ _ #:unwind? _ # _)
1731:15 8 (with-exception-handler #<procedure 7f757a497390 at ic…> …)
1731:15 7 (with-exception-handler #<procedure 7f757a497360 at ic…> …)
1731:15 6 (with-exception-handler #<procedure 7f757a49f9c0 at ic…> …)
In guix/scripts/pull.scm:
636:4 5 (_)
In guix/memoization.scm:
100:0 4 (_ #<hash-table 7f757a499fa0 0/31> "/tmp/test-profile-…" …)
In guix/scripts/pull.scm:
538:21 3 (_)
In guix/inferior.scm:
256:2 2 (inferior-available-packages #f)
251:13 1 (send-inferior-request (defined? (quote #)) #f)
In ice-9/boot-9.scm:
1669:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting
struct): #f
A few more comments inline.
zimoun writes:
> yet. Maybe an option ’--export-manifest’ is coming… ;-)
>
> http://logs.guix.gnu.org/guix-hpc/2021-01-11.log
Cool - thanks for pointer.
> Do you mean issues when replicating my example with only the channels
> guix and guix-science?
I've actually reduced this down to no channel.scm file (so only default
guix channel), and picking 2 packages in guix - eg python and python-numpy.
>
> By hanging, do you mean “you were not enough patient“? or “after several
> minutes” (10-20min), it was not finished yet?
I've waited up to 27 mins with no change.
> Thank for the details. Well, does it fail or is it slow?
When run with only 1 generation the command returns immediately, so if
it is slow, then there's a marked degrading of performance from
generation 1 -> 2. My guess is it's hanging not slow - but it is a
guess.
>
>
>> I'm running out of steam a bit here but both this error in ui.scm@2154
>> and the original backtrace I posted ui.scm@2127 come from the
>> run-guix-command function on attempting a primitive-load of, I assume,
>> the current guix script.
>
> The bracktrace is a fail. But I am not able to reproduce.
> For your experiment, I do not know if it is failure or slowness.
To be clear the backtrace only failed once I killed the process (after
waiting several minutes as discussed above). My hope was by killing it
the strace might show something illuminating.
