From: Phil <phil@beadling.co.uk>
To: zimoun <zimon.toutoune@gmail.com>
Cc: help-guix <help-guix@gnu.org>
Subject: Re: Channel details of profile generation
Date: Tue, 12 Jan 2021 19:16:33 +0000 [thread overview]
Message-ID: <857doiezk2.fsf@beadling.co.uk> (raw)
In-Reply-To: <86a6tftm1d.fsf@gmail.com>
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.
next prev parent reply other threads:[~2021-01-12 19:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-28 17:52 Channel details of profile generation Phil
2020-12-30 13:41 ` zimoun
2021-01-04 17:29 ` Phil
2021-01-05 17:01 ` zimoun
2021-01-09 13:34 ` Phil
2021-01-11 17:34 ` zimoun
2021-01-12 19:16 ` Phil [this message]
2021-01-13 14:28 ` Phil
2021-01-13 20:15 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=857doiezk2.fsf@beadling.co.uk \
--to=phil@beadling.co.uk \
--cc=help-guix@gnu.org \
--cc=zimon.toutoune@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).