How do I fix a messed-up Guix?

How do I fix a messed-up Guix?

[Konrad Hinsen]

Hi everyone,

since ¨guix pull" failed (see a recent message), I tried various ideas 
for getting back to a useable guix installation:

  - Build from a git checkout. Unfortunately, I cannot do "guix 
environment guix" anymore (like "guix pull", it tries to download 
python-2.7.12 and fails due to a hash mismatch). Running "./bootstrap" 
in my standard environment fails with an obscure error message about 
"autopoint" missing.

  - "guix package --roll-back" in the hope of going back to a state in 
which I can do "guix environment guix".

I ended up rolling back until my profile no longer contained "guix" (I 
have no idea how I could ever produce such a profile), so now I am 
completely stuck. Any idea for getting out of this mess?

Thanks in advance,
   Konrad.

Re: How do I fix a messed-up Guix?

[Konrad Hinsen]

On 16/05/2017 15:02, Konrad Hinsen wrote:

> I ended up rolling back until my profile no longer contained "guix" (I
> have no idea how I could ever produce such a profile), so now I am
> completely stuck. Any idea for getting out of this mess?

I forgot two details:

  - I tried building python-2.7.12 using --fallback. This fails because 
one of the tests (test_pty) fails.

  - Under another user account, I still have a working guix profile 
because I hardly ever update it. I'd like to avoid breaking it, and 
therefore avoid the brute-force approach of re-doing the binary install 
procedure.

Konrad.

Re: How do I fix a messed-up Guix?

[julien lepiller]

Le 2017-05-16 15:11, Konrad Hinsen a écrit :
> On 16/05/2017 15:02, Konrad Hinsen wrote:
> 
>> I ended up rolling back until my profile no longer contained "guix" (I
>> have no idea how I could ever produce such a profile), so now I am
>> completely stuck. Any idea for getting out of this mess?
> 
> I forgot two details:
> 
>  - I tried building python-2.7.12 using --fallback. This fails because
> one of the tests (test_pty) fails.
> 
>  - Under another user account, I still have a working guix profile
> because I hardly ever update it. I'd like to avoid breaking it, and
> therefore avoid the brute-force approach of re-doing the binary
> install procedure.
> 
> Konrad.

Hi Konrad,

You could probably use the other user's guix version. Copy 
~otheruser/.config/guix/latest to your own user's .config/guix, and try 
to guix pull from that. That won't mess with the other user's profile.

Re: How do I fix a messed-up Guix?

[Pjotr Prins]

If you still have guix in the store you can use the store path to
reach and run it.

As I had something similar today that there was no recent guix... I
actually restored with a slightly older 'guix pack' from a different
machine.

  https://www.gnu.org/software/guix/news/creating-bundles-with-guix-pack.html

You have to use an older version that does not get overwritten by a
new Guix. Otherwise the update will fail dramatically. It happened to
me first time :)

Alternatively you can unpack the store part of the binary install and
use that. Again, make sure you are not reinstalling the exact same
version.

If you still have a working guix you should use 'guix archive'.

Many options.

Pj.

On Tue, May 16, 2017 at 04:03:19PM +0200, julien lepiller wrote:
> Le 2017-05-16 15:11, Konrad Hinsen a ??crit??:
> >On 16/05/2017 15:02, Konrad Hinsen wrote:
> >
> >>I ended up rolling back until my profile no longer contained "guix" (I
> >>have no idea how I could ever produce such a profile), so now I am
> >>completely stuck. Any idea for getting out of this mess?

Re: How do I fix a messed-up Guix?

[Konrad Hinsen]

Hi Julien,

> You could probably use the other user's guix version. Copy
> ~otheruser/.config/guix/latest to your own user's .config/guix, and try
> to guix pull from that. That won't mess with the other user's profile.

Thanks, that helped, though not directly: the other user didn't have 
~/.config/guix at all. But now I know where guix stores the pointer to 
its current version, and that helped me figure out how to revive an 
older version of guix-latest, which... works!

Unfortunately, compiling the current git checkout with that version fails:

   GUILEC   guix/tests/http.go
Backtrace:
In ice-9/boot-9.scm:
  160: 9 [catch #t #<catch-closure 1a9de20> ...]
In unknown file:
    ?: 8 [apply-smob/1 #<catch-closure 1a9de20>]
In ice-9/boot-9.scm:
   66: 7 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
  432: 6 [eval # #]
In ice-9/boot-9.scm:
2404: 5 [save-module-excursion #<procedure 1ad87c0 at 
ice-9/boot-9.scm:4051:3 ()>]
4058: 4 [#<procedure 1ad87c0 at ice-9/boot-9.scm:4051:3 ()>]
1727: 3 [%start-stack load-stack ...]
1732: 2 [#<procedure 1aea6f0 ()>]
In unknown file:
    ?: 1 [primitive-load 
"/home/hinsen/Development/guix/./build-aux/compile-all.scm"]
In ice-9/threads.scm:
   99: 0 [loop (("guix/base16.scm" "guix/base64.scm" "guix/records.scm" 
...))]

ice-9/threads.scm:99:22: In procedure loop:
ice-9/threads.scm:99:22: In procedure fport_write: Bad address


But I could run "guix pull" to get the latest release, which is good 
enough for my current needs.

Thanks again,
   Konrad.