bug#37865: guix pull: error: You found a bug:

bug#37865: guix pull: error: You found a bug:

[Kai Mertens]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

Dear Guix Developers,

unfortunately, I do not manage to update my GNU Guix version via “guix
pull”. The command fails with the listed message after being executed
for about 16hours.

I would very much apreciate if you find the time to investigate this
bug. What kind of information shall I provide, else?

best regards
Kai Mertens


~~~

guix pull: error: You found a bug: the program '/gnu/store/vi260mff4pp4svm3rwz7lcq7kcdxa03k-compute-guix-derivation'
failed to compute the derivation for Guix (version: "f0bbf894a1f935c1e0109f35899acb6dfcb977f2"; system: "i686-linux";
host version: "2e62ba46e2dc6f27398a65eb157b4ce711ff0e6b"; pull-version: 1).
Please report it by email to <bug-guix@gnu.org>.

~~~

-- 
Kai Mertens <kmx@posteo.net>
OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net
Key fingerprint = 7C83 0A80 01FF 679C 6E8E  AFD3 40B1 5AB4 B05B 5BF1
What is that? Please check: https://emailselfdefense.fsf.org/en/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#37865: guix pull: error: You found a bug:

[Ludovic Courtès]

Hi Kai,

Kai Mertens <kmx@posteo.net> skribis:

> unfortunately, I do not manage to update my GNU Guix version via “guix
> pull”. The command fails with the listed message after being executed
> for about 16hours.

Did you enable substitutes from <https://ci.guix.gnu.org>?
See <https://guix.gnu.org/manual/en/html_node/Substitutes.html>.

If it run for 16 hours, it may be that substitutes were disabled or
unavailable for some reason, and that Guix went ahead and started
building lots of things, eventually failing.

Perhaps the lines before the error showed the actual build issue?

> guix pull: error: You found a bug: the program '/gnu/store/vi260mff4pp4svm3rwz7lcq7kcdxa03k-compute-guix-derivation'
> failed to compute the derivation for Guix (version: "f0bbf894a1f935c1e0109f35899acb6dfcb977f2"; system: "i686-linux";
> host version: "2e62ba46e2dc6f27398a65eb157b4ce711ff0e6b"; pull-version: 1).
> Please report it by email to <bug-guix@gnu.org>.

I tried reproducing it by doing:

  guix pull --commit=2e62ba46e2dc6f27398a65eb157b4ce711ff0e6b -p /tmp/old-guix
  /tmp/old-guix/bin/guix pull --commit=f0bbf894a1f935c1e0109f35899acb6dfcb977f2 -p /tmp/old-to-new

but that worked.

So I guess the problem has to do with a transient build failure or
something.

Thanks,
Ludo’.

bug#37865: guix pull: error: You found a bug:

[Kai Mertens]

[-- Attachment #1: Type: text/plain, Size: 3100 bytes --]

On Tue, 22 Oct 2019 23:21:58 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> Hi Kai,
> 

Hello Ludovic,

> Kai Mertens <kmx@posteo.net> skribis:
> 
> > unfortunately, I do not manage to update my GNU Guix version via “guix
> > pull”. The command fails with the listed message after being executed
> > for about 16hours.  
> 
> Did you enable substitutes from <https://ci.guix.gnu.org>?
> See <https://guix.gnu.org/manual/en/html_node/Substitutes.html>.
> 

hmm, I did not enable substitutes explicitly in the command line, but
as far as I remember, I allowed guix to use substitutes when I set it
up some time ago. Is there a handy command that helps me to check the
current configuration? Anyway, I was not using option --no-substitutes.

> If it run for 16 hours, it may be that substitutes were disabled or
> unavailable for some reason, and that Guix went ahead and started
> building lots of things, eventually failing.

Hmm, shall I try
 guix pull --substitute-urls=https://ci.guix.gnu.org
next time?

> 
> Perhaps the lines before the error showed the actual build issue?

Ahh, you are right. And please accept my apologies, as I did not see
the essential hint:

> command "make" "check" "-j" "2" failed with status 2
> note: build failure may have been caused by lack of free disk space
> builder for `/gnu/store/wswfwmyrbd39blimabdkm46z6b138rlc-tar-1.32.drv' failed with exit code 1
> @ build-failed /gnu/store/wswfwmyrbd39blimabdkm46z6b138rlc-tar-1.32.drv - 1 builder for `/gnu/store/wswfwmyrbd39blimabdkm46z6b138rlc-tar-1.32.drv' failed with exit code 1
> cannot build derivation `/gnu/store/fpfj0ds2vd7vapp54dkf09jipl0mkzgw-ghostscript-9.27.drv': 1 dependencies couldn't be built
> [...]

Indeed, at the time of failure, the root partition had only about 2.8G
space left. But /tmp had something like 9G in spare. I wonder if I can
tell guix to use as much tmp-space as applicable?

 
> 
> > guix pull: error: You found a bug: the program
> > '/gnu/store/vi260mff4pp4svm3rwz7lcq7kcdxa03k-compute-guix-derivation'
> > failed to compute the derivation for Guix (version:
> > "f0bbf894a1f935c1e0109f35899acb6dfcb977f2"; system: "i686-linux";
> > host version: "2e62ba46e2dc6f27398a65eb157b4ce711ff0e6b";
> > pull-version: 1). Please report it by email to <bug-guix@gnu.org>.  
> 
> I tried reproducing it by doing:
> 
>   guix pull --commit=2e62ba46e2dc6f27398a65eb157b4ce711ff0e6b
> -p /tmp/old-guix /tmp/old-guix/bin/guix pull
> --commit=f0bbf894a1f935c1e0109f35899acb6dfcb977f2 -p /tmp/old-to-new
> 
> but that worked.
> 
> So I guess the problem has to do with a transient build failure or
> something.
> 

I will try to enlarge the root partition and try again.
Would you mind to give a recommendation for its size?

Thanks for your immediate, kind response!!
best regards
Kai


-- 
Kai Mertens <kmx@posteo.net>
OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net
Key fingerprint = 7C83 0A80 01FF 679C 6E8E  AFD3 40B1 5AB4 B05B 5BF1
What is that? Please check: https://emailselfdefense.fsf.org/en/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#37865: guix pull: error: You found a bug:

[Ludovic Courtès]

Hi,

Kai Mertens <kmx@posteo.net> skribis:

> On Tue, 22 Oct 2019 23:21:58 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Hi Kai,
>> 
>
> Hello Ludovic,
>
>> Kai Mertens <kmx@posteo.net> skribis:
>> 
>> > unfortunately, I do not manage to update my GNU Guix version via “guix
>> > pull”. The command fails with the listed message after being executed
>> > for about 16hours.  
>> 
>> Did you enable substitutes from <https://ci.guix.gnu.org>?
>> See <https://guix.gnu.org/manual/en/html_node/Substitutes.html>.
>> 
>
> hmm, I did not enable substitutes explicitly in the command line, but
> as far as I remember, I allowed guix to use substitutes when I set it
> up some time ago. Is there a handy command that helps me to check the
> current configuration? Anyway, I was not using option --no-substitutes.

If you installed it long ago, it could be that you authorized
substitutes from hydra.gnu.org (the former CI server, discontinued in
June¹) but not from ci.guix.gnu.org.

So you would need to check:

  1. which substitute URL guix-daemon is using;

  2. which keys are authorized in /etc/guix/acl.

The above chapter of the manual has more info on this.

LMK how it goes!

¹ https://lists.gnu.org/archive/html/info-guix/2019-06/msg00001.html

> Ahh, you are right. And please accept my apologies, as I did not see
> the essential hint:
>
>> command "make" "check" "-j" "2" failed with status 2
>> note: build failure may have been caused by lack of free disk space
>> builder for `/gnu/store/wswfwmyrbd39blimabdkm46z6b138rlc-tar-1.32.drv' failed with exit code 1
>> @ build-failed /gnu/store/wswfwmyrbd39blimabdkm46z6b138rlc-tar-1.32.drv - 1 builder for `/gnu/store/wswfwmyrbd39blimabdkm46z6b138rlc-tar-1.32.drv' failed with exit code 1
>> cannot build derivation `/gnu/store/fpfj0ds2vd7vapp54dkf09jipl0mkzgw-ghostscript-9.27.drv': 1 dependencies couldn't be built
>> [...]
>
> Indeed, at the time of failure, the root partition had only about 2.8G
> space left. But /tmp had something like 9G in spare. I wonder if I can
> tell guix to use as much tmp-space as applicable?

Guix needs space in /gnu/store to store the actual build results, and it
needs space in /tmp when it’s building stuff.

Building ‘tar’, for example, consumes quite a bit of space (in /tmp)
because its test suite runs on large files.

> I will try to enlarge the root partition and try again.
> Would you mind to give a recommendation for its size?

It depends on your use case of course, but most likely you’ll need at
least a dozen GiB.

But first, I recommend figuring out the substitute story so you don’t
have to build everything locally!

Thanks,
Ludo’.

bug#37865: guix pull: error: You found a bug:

[Kai Mertens]

[-- Attachment #1: Type: text/plain, Size: 3661 bytes --]

On Wed, 23 Oct 2019 11:50:44 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> >> Did you enable substitutes from <https://ci.guix.gnu.org>?
> >> See <https://guix.gnu.org/manual/en/html_node/Substitutes.html>.
> >>   
> >
> > hmm, I did not enable substitutes explicitly in the command line, but
> > as far as I remember, I allowed guix to use substitutes when I set it
> > up some time ago. Is there a handy command that helps me to check the
> > current configuration? Anyway, I was not using option --no-substitutes.  
> 
> If you installed it long ago, it could be that you authorized
> substitutes from hydra.gnu.org (the former CI server, discontinued in
> June¹) but not from ci.guix.gnu.org.
> 

Yes indeed!

> So you would need to check:
> 
>   1. which substitute URL guix-daemon is using;

I tried the example as seen in “4.3.2 Substitute Server Authorization”:

$ guix build emacs --dry-run
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'...  18.6%guix substitute: error: TLS error in procedure 'read_from_session_record_port': The TLS connection was non-properly terminated.
guix build: error: substituter `substitute' died unexpectedly

So apparently, guix is using the obsolete hydra server.

> 
>   2. which keys are authorized in /etc/guix/acl.
> 

This file shows only one key, but that one is listed four times as like:
 (entry 
  (public-key 
   (rsa 
    (n 
    #00DB1634E3D9DFAC97AE4734DAE968CCB15EE4815C82BDC254883DBB49FE1EF32268E82D4BBE0E35298C481C9DA15
    51642FAFF05AEC1A60712F1BB4BE7D25D7EFF7A4F89704A5A9AC232870CB9F2476C3B538A0E990A8825DEB73081D31
    7001FB8A188600F2FEF5F5F570E857F3EE4355077A3C3918ED72723A56BA55C466D400658974D7DAD1F6B7B63C192B
    9C2704D98BBFF1C3BD5B8EF11A8ADC83ACB8FD8E9F1E792FDAD262415D13F2DEE55F330908CFDA9C3C8C32B64F7DD0
    88457D34F445E2E2C83C6D680549DC9B6E6573B89496567204ED285E67A279F2F667080BA941D80D015CE87B0FB6A9
    1A99CECC7D91D2D210B00E4B6E611DA51DB008F1DFE3FCAC6B27393FA781D45F9A15FC7B8785A3E86BA6592B2916CA
    22CF1E40FC85F85CACA590461154F58F3580B16398908EF32076F411299C28727C94D88B6A618F84DD73AEBED8270B
    CB6690928CB1BF250C35E1F6BF3B1B30D05BA246ECE8F69D9065DE26F4B3E0D814D70A9C27CB5B7B050C9090590D3A
    9EF83374F2643E5446FBD39DDB124DBF6DFDAA6D18E2560AD0CBFA11C959C9B7316BF19963A191967054E9FD97DC14
    D71082B30B1C90A46E8996682474C3BCB51BA0882958897B6DD35E41B5174D0A6BCDE97B89043E95BD1B70DE61DA66
    6893B417196A180005466BC3A742FDF04E89B04460E3E6BC72E7F1B5FEA5B3092FEE551A3C447C12E104E65#) (e 
    #010001#) )
   )
  (tag 
   (guix import)
   )
  )

> The above chapter of the manual has more info on this.
> 
> LMK how it goes!

Well, I am not sure how to proceed with my old version of guix.

I wonder if the listed key is as well valid for https://ci.guix.gnu.org
just the same as it used to be valid for https://mirror.hydra.gnu.org.

If not, where can I get the new, correct one?

Once I have the keyfile, I am supposed to continue with section
 “4.3.2 Substitute Server Authorization”,
right?

Then I would try:
 # guix-daemon --substitute-urls=https://ci.guix.gnu.org
 # guix archive --authorize < my/path/to/ci.guix.gnu.org.pub

Is that correct?

Would that remove the obsolete substitute server information in the
same go?

best regards
Kai



> 
> ¹ https://lists.gnu.org/archive/html/info-guix/2019-06/msg00001.html



-- 
Kai Mertens <kmx@posteo.net>
OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net
Key fingerprint = 7C83 0A80 01FF 679C 6E8E  AFD3 40B1 5AB4 B05B 5BF1
What is that? Please check: https://emailselfdefense.fsf.org/en/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#37865: guix pull: error: You found a bug:

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 4562 bytes --]

On Wed, Oct 23, 2019 at 04:26:35PM +0200, Kai Mertens wrote:
> On Wed, 23 Oct 2019 11:50:44 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
> 
> > >> Did you enable substitutes from <https://ci.guix.gnu.org>?
> > >> See <https://guix.gnu.org/manual/en/html_node/Substitutes.html>.
> > >>   
> > >
> > > hmm, I did not enable substitutes explicitly in the command line, but
> > > as far as I remember, I allowed guix to use substitutes when I set it
> > > up some time ago. Is there a handy command that helps me to check the
> > > current configuration? Anyway, I was not using option --no-substitutes.  
> > 
> > If you installed it long ago, it could be that you authorized
> > substitutes from hydra.gnu.org (the former CI server, discontinued in
> > June¹) but not from ci.guix.gnu.org.
> > 
> 
> Yes indeed!
> 
> > So you would need to check:
> > 
> >   1. which substitute URL guix-daemon is using;
> 
> I tried the example as seen in “4.3.2 Substitute Server Authorization”:
> 
> $ guix build emacs --dry-run
> substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'...  18.6%guix substitute: error: TLS error in procedure 'read_from_session_record_port': The TLS connection was non-properly terminated.
> guix build: error: substituter `substitute' died unexpectedly
> 
> So apparently, guix is using the obsolete hydra server.
> 
> > 
> >   2. which keys are authorized in /etc/guix/acl.
> > 
> 
> This file shows only one key, but that one is listed four times as like:
>  (entry 
>   (public-key 
>    (rsa 
>     (n 
>     #00DB1634E3D9DFAC97AE4734DAE968CCB15EE4815C82BDC254883DBB49FE1EF32268E82D4BBE0E35298C481C9DA15
>     51642FAFF05AEC1A60712F1BB4BE7D25D7EFF7A4F89704A5A9AC232870CB9F2476C3B538A0E990A8825DEB73081D31
>     7001FB8A188600F2FEF5F5F570E857F3EE4355077A3C3918ED72723A56BA55C466D400658974D7DAD1F6B7B63C192B
>     9C2704D98BBFF1C3BD5B8EF11A8ADC83ACB8FD8E9F1E792FDAD262415D13F2DEE55F330908CFDA9C3C8C32B64F7DD0
>     88457D34F445E2E2C83C6D680549DC9B6E6573B89496567204ED285E67A279F2F667080BA941D80D015CE87B0FB6A9
>     1A99CECC7D91D2D210B00E4B6E611DA51DB008F1DFE3FCAC6B27393FA781D45F9A15FC7B8785A3E86BA6592B2916CA
>     22CF1E40FC85F85CACA590461154F58F3580B16398908EF32076F411299C28727C94D88B6A618F84DD73AEBED8270B
>     CB6690928CB1BF250C35E1F6BF3B1B30D05BA246ECE8F69D9065DE26F4B3E0D814D70A9C27CB5B7B050C9090590D3A
>     9EF83374F2643E5446FBD39DDB124DBF6DFDAA6D18E2560AD0CBFA11C959C9B7316BF19963A191967054E9FD97DC14
>     D71082B30B1C90A46E8996682474C3BCB51BA0882958897B6DD35E41B5174D0A6BCDE97B89043E95BD1B70DE61DA66
>     6893B417196A180005466BC3A742FDF04E89B04460E3E6BC72E7F1B5FEA5B3092FEE551A3C447C12E104E65#) (e 
>     #010001#) )
>    )
>   (tag 
>    (guix import)
>    )
>   )
> 
> > The above chapter of the manual has more info on this.
> > 
> > LMK how it goes!
> 
> Well, I am not sure how to proceed with my old version of guix.
> 
> I wonder if the listed key is as well valid for https://ci.guix.gnu.org
> just the same as it used to be valid for https://mirror.hydra.gnu.org.
> 

It's not. The long RSA key was only for hydra.

> If not, where can I get the new, correct one?

One option is from the git repo.
I don't see the key hosted online, but you likely already have it in
your store. It should be in
/gnu/store/...-guix-../share/guix/ci.guix.gnu.org.pub
Also if you've run 'guix pull' it should be in ~/.cache/guix/pull/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/etc/substitutes/ci.guix.gnu.org.pub

> 
> Once I have the keyfile, I am supposed to continue with section
>  “4.3.2 Substitute Server Authorization”,
> right?
> 
> Then I would try:
>  # guix-daemon --substitute-urls=https://ci.guix.gnu.org
>  # guix archive --authorize < my/path/to/ci.guix.gnu.org.pub
> 
> Is that correct?

If you're on Guix System then you'd want to do 'sudo herd restart
guix-daemon' after authorizing the key. If you're on a foreign system
then as long as you don't have '--substitute-urls' already in the
guix-daemon command then it'll default to ci.guix.gnu.org

> 
> Would that remove the obsolete substitute server information in the
> same go?

There's no need to remove it, but you could remove it by hand if you
want.

> 
> best regards
> Kai
> 

Hope that helps


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#37865: guix pull: error: You found a bug:

[Kai Mertens]

[-- Attachment #1: Type: text/plain, Size: 3042 bytes --]

On Wed, 23 Oct 2019 19:55:04 +0300
Efraim Flashner <efraim@flashner.co.il> wrote:

> > > 
> > > LMK how it goes!  
> > 
> > Well, I am not sure how to proceed with my old version of guix.
> > 
> > I wonder if the listed key is as well valid for https://ci.guix.gnu.org
> > just the same as it used to be valid for https://mirror.hydra.gnu.org.
> >   
> 
> It's not. The long RSA key was only for hydra.
> 
> > If not, where can I get the new, correct one?  
> 
> One option is from the git repo.
> I don't see the key hosted online, but you likely already have it in
> your store. It should be in
> /gnu/store/...-guix-../share/guix/ci.guix.gnu.org.pub
> Also if you've run 'guix pull' it should be in ~/.cache/guix/pull/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/etc/substitutes/ci.guix.gnu.org.pub

Yes, you are right. I found the keyfiles in the ~/.cache location,
thank you.

> 
> > 
> > Once I have the keyfile, I am supposed to continue with section
> >  “4.3.2 Substitute Server Authorization”,
> > right?
> > 
> > Then I would try:
> >  # guix-daemon --substitute-urls=https://ci.guix.gnu.org
> >  # guix archive --authorize < my/path/to/ci.guix.gnu.org.pub
> > 
> > Is that correct?  
> 
> If you're on Guix System then you'd want to do 'sudo herd restart
> guix-daemon' after authorizing the key. If you're on a foreign system
> then as long as you don't have '--substitute-urls' already in the
> guix-daemon command then it'll default to ci.guix.gnu.org

This machine is running GNU Guix on top of an old GNU/Linux-libre
distro (Trisquel7).

I edited the /etc/init/guix-daemon.conf configuration file and added
--substitute-urls=https://ci.guix.gnu.org to the exec line.

Then I used
 $ sudo -i
 # guix archive --authorize < path/to/ci.guix.gnu.org.pub
to authorize the server url.

But I think guix still tried to substitute from hydra.
So I deleted the rsa key entries in /etc/guix/acl manually and
performed a logout-login sequence to restart the daemon.

Now it works, hurray! I was able to perform a fast 'guix pull' (~2h)
and the space in / and /tmp turned out to be sufficient.

When invoking guix package -I for example, I encountered an error like
 guile: failed to install locale

But that went away after having updated and installed some packages.
Unfortunately, I don't know exactly which action was responsible to
make this message disappear.

Now that I am running an up-to-date version of guix, there seem to be
no further need to use --substitute-urls=https://ci.guix.gnu.org in the exec
line of the daemon config file nor to have the rsa key deleted in /etc/guix/acl.

I thank you all very much for your help. I feel pretty much relieved
and encouraged to keep trying guix.

best regards
Kai


-- 
Kai Mertens <kmx@posteo.net>
OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net
Key fingerprint = 7C83 0A80 01FF 679C 6E8E  AFD3 40B1 5AB4 B05B 5BF1
What is that? Please check: https://emailselfdefense.fsf.org/en/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#37865: guix pull: error: You found a bug:

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

Sounds like this bug had a happy ending. Closing the bug.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#37865: guix pull: error: You found a bug:

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

Hello Kai,

Kai Mertens <kmx@posteo.net> skribis:

> I wonder if the listed key is as well valid for https://ci.guix.gnu.org
> just the same as it used to be valid for https://mirror.hydra.gnu.org.

No it’s not.

> If not, where can I get the new, correct one?

You could download guix-1.0.1.tar.gz for instance, verify its signature,
and grab ‘etc/substitutes/ci.guix.gnu.org.pub’ from there.

Alternately, here’s the key of ci.guix.gnu.org:

--8<---------------cut here---------------start------------->8---
(public-key 
 (ecc 
  (curve Ed25519)
  (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)
  )
 )
--8<---------------cut here---------------end--------------->8---

This message is signed, so be sure to check its signature before going
any further.

> Once I have the keyfile, I am supposed to continue with section
>  “4.3.2 Substitute Server Authorization”,
> right?
>
> Then I would try:
>  # guix-daemon --substitute-urls=https://ci.guix.gnu.org
>  # guix archive --authorize < my/path/to/ci.guix.gnu.org.pub
>
> Is that correct?

Yes.

> Would that remove the obsolete substitute server information in the
> same go?

No, but that’s OK.

HTH!

Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#37865: guix pull: error: You found a bug:

[Bengt Richter]

On +2019-10-24 13:34:29 +0200, Kai Mertens wrote:

[...]

> This machine is running GNU Guix on top of an old GNU/Linux-libre
> distro (Trisquel7).
> 
> I edited the /etc/init/guix-daemon.conf configuration file and added
> --substitute-urls=https://ci.guix.gnu.org to the exec line.
> 
> Then I used
>  $ sudo -i
>  # guix archive --authorize < path/to/ci.guix.gnu.org.pub
> to authorize the server url.
> 
> But I think guix still tried to substitute from hydra.
> So I deleted the rsa key entries in /etc/guix/acl manually and
> performed a logout-login sequence to restart the daemon.
> 
> Now it works, hurray! I was able to perform a fast 'guix pull' (~2h)
> and the space in / and /tmp turned out to be sufficient.
> 
> When invoking guix package -I for example, I encountered an error like
>  guile: failed to install locale
>

I have encountered the same error. It seems to recur for me after major updates.
So there seems to be something lurking to reawaken the real error message source.
I collected some symptoms and posted them as bug#37900.

I hope it will be obvious to someone what is happening, so this nuisance
can be eliminated (and everyone will be relieved of hearing about it repeatedly :)
(if I am doing something dumb for my case, I promise to try to avoid repeating :)

> But that went away after having updated and installed some packages.
> Unfortunately, I don't know exactly which action was responsible to
> make this message disappear.
>

When you were getting the error message from guix commands (which apparently
uses guile in a way that causes _guile_ to complain),
were you also getting the same error message when invoking guile directly?

I was not -- please see #bug37900 for my attempt to explore the difference.

> Now that I am running an up-to-date version of guix, there seem to be
> no further need to use --substitute-urls=https://ci.guix.gnu.org in the exec
> line of the daemon config file nor to have the rsa key deleted in /etc/guix/acl.
> 
> I thank you all very much for your help. I feel pretty much relieved
> and encouraged to keep trying guix.
>

Me too. I think guix can be great, though my user experience
is not quite great yet :)
HTH
--
Regards,
Bengt Richter

bug#37865: guix pull: error: You found a bug:

[Bengt Richter]

On +2019-10-24 13:49:56 -0700, Bengt Richter wrote:
> On +2019-10-24 13:34:29 +0200, Kai Mertens wrote:
> 
> [...]
> > 
> > When invoking guix package -I for example, I encountered an error like
> >  guile: failed to install locale
> >
> 
> I have encountered the same error. It seems to recur for me after major updates.
> So there seems to be something lurking to reawaken the real error message source.
> I collected some symptoms and posted them as bug#37900.
> 
A recently committed fix enabled me to fix my problem with "guile: failed to install locale"
that was triggered by any invocation of guix:

guix pull          ## make sure the fix is in! ;-)

guix install avahi ## likely you won't need this first, but it stood in my way per bug#37900
     	     	   ## (after the fix, I might not have needed it either for the locale upgrade, idk).

guix install glibc-utf8-locales ## if your locale is within '("de_DE" "el_GR" "en_US" "fr_FR" "tr_TR")

If you have an exotic locale outside of those, you may have to install the big one:

guix install glibc-locales

A snip from  guix edit glibc-utf8-locales:
---------------------------------------
                               ;; tests---e.g., in Guile's i18n tests.
                               '("de_DE" "el_GR" "en_US" "fr_FR" "tr_TR"))
                     #t))))
    (native-inputs `(("glibc" ,glibc)
                     ("gzip" ,gzip)))
    (synopsis "Small sample of UTF-8 locales")
    (description
     "This package provides a small sample of UTF-8 locales mostly useful in
test environments.")
---------------------------------------
HTH, in case your "guile: failed to install locale" hasn't gone away yet :)
--
Regards,
Bengt Richter

bug#37865: guix pull: error: You found a bug:

[Kai Mertens]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

On Thu, 24 Oct 2019 13:49:56 -0700
Bengt Richter <bokr@bokr.com> wrote:

> > 
> > When invoking guix package -I for example, I encountered an error
> > like guile: failed to install locale
> >  
> 
> I have encountered the same error. It seems to recur for me after
> major updates. So there seems to be something lurking to reawaken the
> real error message source. I collected some symptoms and posted them
> as bug#37900.
> 

Hello Bengt,

as I see, issue #37900 is closed, but I don't understand the solution,
unfortunately.

This issue #37865 is closed as well, so I don't know whether this reply
reaches you well and is placed correctly.

I for myself use a different way to get around the warning messages,
which re-occurred after a while:

 $ guix package -I
 guile: warning: failed to install locale
 warning: failed to install locale: Invalid argument

I have the impression, that

cat<<EOF >> ~/.bash_profile
GUIX_PROFILE="$HOME/.guix-profile"
source "\$GUIX_PROFILE/etc/profile"
EOF

is not enough to provide full information regarding search paths.

As a complement, I put the output of

 guix package --search-paths -p "$HOME/.guix-profile"

into my ‘~/.bashrc’, but append the

 ${<VAR>:+:}$<VAR>

pattern to each line in order to keep existing variable content.

However, it seems as if the output of that command is incomplete as
well, as it often (not always) misses information regarding
GUIX_LOCPATH and PATH (~/.config/guix/current).

I append these definitions as well, just to make sure they are not
missing. (In a helper script, I use a ‘sort -u’ to avoid redundant
occurences of lines.)

cat<<EOF >> ~/.bashrc
export PATH="$HOME/.config/guix/current/bin\${PATH:+:}\$PATH"
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale\${GUIX_LOCPATH:+:}\$GUIX_LOCPATH"
EOF

Placing these complementary lines altogether in ~/.bash_profile won't
help me, I use ~/.bashrc instead.

Then I perform a logout, login sequence and the error messages
disappear and everything seems to run smoothly.

I update my ~/.bashrc after each new package generation.

As a conclusion, I would like to word three assumptions:

1. sourcing GUIX_PROFILE is not enough
2. output of ‘guix package --search-paths’ is incomplete
3. ~/.bash_profile and ~/.bashrc are not equally weighted in respect to
   guix environment settings

@all
What do you think? Could this be regarded as useful information?
Or does it address my specific use case only?

best regards
Kai

-- 
Kai Mertens <kmx@posteo.net>
OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net
Key fingerprint = 7C83 0A80 01FF 679C 6E8E  AFD3 40B1 5AB4 B05B 5BF1
What is that? Please check: https://emailselfdefense.fsf.org/en/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#37865: guix pull: error: You found a bug:

[Bengt Richter]

Hi Kai,

On +2019-10-27 08:54:19 +0100, Kai Mertens wrote:
> On Thu, 24 Oct 2019 13:49:56 -0700
> Bengt Richter <bokr@bokr.com> wrote:
> 
> > > 
> > > When invoking guix package -I for example, I encountered an error
> > > like guile: failed to install locale
> > >  
> > 
> > I have encountered the same error. It seems to recur for me after
> > major updates. So there seems to be something lurking to reawaken the
> > real error message source. I collected some symptoms and posted them
> > as bug#37900.
> > 
> 
> Hello Bengt,
> 
> as I see, issue #37900 is closed, but I don't understand the solution,
> unfortunately.
> 
> This issue #37865 is closed as well, so I don't know whether this reply
> reaches you well and is placed correctly.
> 
> I for myself use a different way to get around the warning messages,
> which re-occurred after a while:
> 
>  $ guix package -I
>  guile: warning: failed to install locale
>  warning: failed to install locale: Invalid argument
> 
> I have the impression, that
> 
> cat<<EOF >> ~/.bash_profile
> GUIX_PROFILE="$HOME/.guix-profile"
> source "\$GUIX_PROFILE/etc/profile"
> EOF
> 
> is not enough to provide full information regarding search paths.
> 
> As a complement, I put the output of
> 
>  guix package --search-paths -p "$HOME/.guix-profile"
> 
> into my ‘~/.bashrc’, but append the
> 
>  ${<VAR>:+:}$<VAR>
> 
> pattern to each line in order to keep existing variable content.
> 
> However, it seems as if the output of that command is incomplete as
> well, as it often (not always) misses information regarding
> GUIX_LOCPATH and PATH (~/.config/guix/current).
> 
> I append these definitions as well, just to make sure they are not
> missing. (In a helper script, I use a ‘sort -u’ to avoid redundant
> occurences of lines.)
> 
> cat<<EOF >> ~/.bashrc
> export PATH="$HOME/.config/guix/current/bin\${PATH:+:}\$PATH"
> export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale\${GUIX_LOCPATH:+:}\$GUIX_LOCPATH"
> EOF
> 
> Placing these complementary lines altogether in ~/.bash_profile won't
> help me, I use ~/.bashrc instead.
> 
> Then I perform a logout, login sequence and the error messages
> disappear and everything seems to run smoothly.
> 
> I update my ~/.bashrc after each new package generation.
> 
> As a conclusion, I would like to word three assumptions:
> 
> 1. sourcing GUIX_PROFILE is not enough
> 2. output of ‘guix package --search-paths’ is incomplete
> 3. ~/.bash_profile and ~/.bashrc are not equally weighted in respect to
>    guix environment settings
>

1. I think what produces GUIX_PROFILE is not designed to do what you are doing manually,
   nor IMO should it be, as there is (or should be) a proper solution ;-)
2. I don't know if it's incomplete, but I suspect you are saying so because it does not
   serve your current approach to solving the problem :)
3. True. Normally ~/.bash_profile is sourced only at login, whereas I think ~/.bashrc is
   sourced by any new subshell being entered (normally, though AIUI options can make a difference). 

To diagnose your situation would you post the ouputs of:

1. strace guix -v |& grep locale

2. which guix|xargs readlink -f|xargs cat -n

3. guix package -I glibc

#1 should show where locale is being looked for and failing to be found

#2 will show that guix on the command line invokes a hash-bang guile script,
   setting some things up and calling the real machinery of guix.

My current version for #2 lists 3 script lines:
     1	#!/gnu/store/sc7z07gim1iq5zvfz1amdwf2irxrzifg-guile-2.2.6/bin/guile --no-auto-compile
     2	!#
     3	(begin (set! %load-path (cons (string-append "/gnu/store/053vb2vkbrv6mjddhkyhb6ddkj85d9ia-guix-module-union" "/share/guile/site/" (effective-version)) %load-path)) (set! %load-compiled-path (cons (string-append "/gnu/store/053vb2vkbrv6mjddhkyhb6ddkj85d9ia-guix-module-union" "/lib/guile/" (effective-version) "/site-ccache") %load-compiled-path)) (let ((locpath (getenv "GUIX_LOCPATH"))) (setenv "GUIX_LOCPATH" (string-append (if locpath (string-append locpath ":") "") "/gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29/lib/locale"))) (let ((guix-main (module-ref (resolve-interface (quote (guix ui))) (quote guix-main)))) (begin (bindtextdomain "guix" "/gnu/store/0m73px55qzbx70v2k346igajrszzz8kb-guix-locale-guix") (bindtextdomain "guix-packages" "/gnu/store/c01aal3wvwlhi
 5h81rz14yasf70w04j2-guix-locale-guix-packages")) (apply guix-main (command-line))))

Notice the -2.29 version of "/gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29/lib/locale"
My problem was that I had version 2.28 installed, but not 2.29 -- at least not where it could be seen
What version is referenced in your #2 output?

My current output for #3 is
glibc	2.28	out	/gnu/store/c43rbmzv1laxgbnkvf76hx4305n4206a-glibc-2.28
glibc-locales	2.28	out	/gnu/store/bb9alx1ap57pz0vmx7p1r8qk0lxxfg3x-glibc-locales-2.28
glibc-utf8-locales	2.29	out	/gnu/store/n79cf8bvy3k96gjk1rf18d36w40lkwlr-glibc-utf8-locales-2.29

Before the solution to my problem, that command only showed the 2.28 lines.
The obvious thing to try was to install 2.29, so I chose the smaller glibc-utf8-locales.

guix install glibc-utf8-locales

That should have worked, but didn't, and that's what all the confusing stuff in bug#37900 came from.
Somehow avahi was mixed into the problem -- but this was solved by some mystery (to me) update,
and then after guix pull had pulled that in, guix install glibc-utf8-locales worked normally.

It consequently appeared in my #3 output -- and the locale complaints went away -- at least after a reboot,
but I'm not sure that was necessary.

So, bottom line, I would suggest posting the outputs to #1,#2, and #3 and figuring out what to do.

My bet is you'll revert your workarounds, do a guix pull and maybe guix update for good measure,
then guix install glibc-utf8-locales (unless you have an exotic locale, in which case you may need
to do guix install glibc-locales) then reboot, and hopefully the locale complaints will be gone.

> @all
> What do you think? Could this be regarded as useful information?
> Or does it address my specific use case only?
>
Hard to say for sure, until we see the outputs to #1,#2, and #3 :)

In general, I don't think it's a good idea to tempt people with obstacles
to copy possibly dangerous "solutions" -- especially when it comes to permissions,
but also bypassing intended barriers between profiles or other entities.

But it's good to let developers see what desperate hacks people are willing to use
to get on with life, so that they can provide user-friendly alternatives, as I think
they are all motivated to do. The core developers are amazingly energetic and productive,
but they only have so many man^H^H^H :) person-hours to give, so kudos to them!

> best regards
> Kai
> 
> -- 
> Kai Mertens <kmx@posteo.net>
> OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net
> Key fingerprint = 7C83 0A80 01FF 679C 6E8E  AFD3 40B1 5AB4 B05B 5BF1
> What is that? Please check: https://emailselfdefense.fsf.org/en/

HTH and doesn't mislead :)
--
Regards,
Bengt Richter

bug#37865: guix pull: error: You found a bug:

[Kai Mertens]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

On Sun, 27 Oct 2019 04:52:14 -0700
Bengt Richter <bokr@bokr.com> wrote:

> My bet is you'll revert your workarounds, do a guix pull and maybe guix update for good measure,
> then guix install glibc-utf8-locales (unless you have an exotic locale, in which case you may need
> to do guix install glibc-locales) then reboot, and hopefully the locale complaints will be gone.

Hi Bengt,

hmm, yes, this is exactly what I did. I reverted my workarounds, but
found some constraints that I was not aware of, see list below.

(This applies to
  guix describe (GNU Guix) 7696af421b9fa05f479cda9c742883a99e6faec3
on top of trisquel or debian.)


1) File ~/.profile is not read by bash in case file ~/.bash_profile is
present. As a result, some settings were skipped when I used the latter
file to define environment variables. Now I set GUIX_PROFILE and source
$GUIX_PROFILE/etc/profile (as suggested by guix) within ~/.profile.
This works fine.

2) Additionally, I have to explicitly define more standard content for
XDG_DATA_DIRS (as like “/usr/share” and “/usr/local/share”) when
sourcing the guix profile environment as with 1). This is essential,
otherwise my graphic login won't work. I don't understand why, though.

3) In order to get rid of "guile: warning: failed to set locale" with
commands like “guix package -I”, I install matching versions of
glibc-locales (or glibc-utf8-locales) *and* glibc. Having only the
locales package installed is not sufficient. This might be obvious for
experienced users, but I myself was not aware of that ANDed condition.

4) Furthermore, with an old initial version of guix, PATH needs to
point to “$HOME/.config/guix/current/bin” to make sure that I am running
the latest version of guix. Otherwise the locale complains will be back.


This concept of environment variables confused me in the beginning, but
now I start to get more familiar.

best regards
Kai


-- 
Kai Mertens <kmx@posteo.net>
OpenPGP Key-ID: 0x40B15AB4B05B5BF1 on keys.gnupg.net
Key fingerprint = 7C83 0A80 01FF 679C 6E8E  AFD3 40B1 5AB4 B05B 5BF1
What is that? Please check: https://emailselfdefense.fsf.org/en/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]