It’s building!

It’s building!

[Ludovic Courtès]

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

Hello Guix!

Good news: the new machine, bayfront.guixsd.org, is building Guix master
for x86_64/i686 with Cuirass⁰!

You can get substitutes from https://bayfront.guixsd.org; just authorize
its key (with ‘guix archive --authorize’), which is:

  (public-key 
   (ecc 
    (curve Ed25519)
    (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))

The machine was initially installed using substitutes from
hydra.gnu.org, but ever since it has been building stuff on its own (it
does not offload to any other machine at this point).  Thus it can be
used to check for reproducibility issues:

  guix challenge gdk-pixbuf \
    --substitute-urls="https://mirror.hydra.gnu.org https://bayfront.guixsd.org"

The machine runs GuixSD and its config is under version control:

  http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm

Currently Cuirass doesn’t expose much over HTTP¹ but hopefully we can
incrementally add the URLs that guix-hydra.el expects.

There are a few glitches to address, such as the fact that it builds
with max-jobs = 1 due to <https://bugs.gnu.org/20217>, but we’ll get
there.

Woohoo!  :-)

Ludo’.

⁰ See <https://www.gnu.org/software/guix/news/growing-our-build-farm.html> and
  <https://lists.gnu.org/archive/html/guix-devel/2017-01/msg00109.html> if
  you missed the previous episodes.

¹ https://notabug.org/mthl/cuirass/src/master/src/cuirass/http.scm

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

Re: It’s building!

[Kei Kebreau]

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

ludo@gnu.org (Ludovic Courtès) writes:

> Hello Guix!
>
> Good news: the new machine, bayfront.guixsd.org, is building Guix master
> for x86_64/i686 with Cuirass⁰!
>
> You can get substitutes from https://bayfront.guixsd.org; just authorize
> its key (with ‘guix archive --authorize’), which is:
>
>   (public-key 
>    (ecc 
>     (curve Ed25519)
>     (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))
>
> The machine was initially installed using substitutes from
> hydra.gnu.org, but ever since it has been building stuff on its own (it
> does not offload to any other machine at this point).  Thus it can be
> used to check for reproducibility issues:
>
>   guix challenge gdk-pixbuf \
>     --substitute-urls="https://mirror.hydra.gnu.org https://bayfront.guixsd.org"
>
> The machine runs GuixSD and its config is under version control:
>
>   http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm
>
> Currently Cuirass doesn’t expose much over HTTP¹ but hopefully we can
> incrementally add the URLs that guix-hydra.el expects.
>
> There are a few glitches to address, such as the fact that it builds
> with max-jobs = 1 due to <https://bugs.gnu.org/20217>, but we’ll get
> there.
>
> Woohoo!  :-)
>
> Ludo’.
>
> ⁰ See <https://www.gnu.org/software/guix/news/growing-our-build-farm.html> and
>   <https://lists.gnu.org/archive/html/guix-devel/2017-01/msg00109.html> if
>   you missed the previous episodes.
>
> ¹ https://notabug.org/mthl/cuirass/src/master/src/cuirass/http.scm

Wow, this is cool! Thanks to everyone who was/is/will be working on this!

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

Re: It’s building!

[David Craven]

Awesome stuff!

Re: It’s building!

[Alex Sassmannshausen]

Kei Kebreau writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hello Guix!
>>
>> Good news: the new machine, bayfront.guixsd.org, is building Guix master
>> for x86_64/i686 with Cuirass⁰!
>>
>> You can get substitutes from https://bayfront.guixsd.org; just authorize
>> its key (with ‘guix archive --authorize’), which is:
>>
>>   (public-key 
>>    (ecc 
>>     (curve Ed25519)
>>     (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))
>>
>> The machine was initially installed using substitutes from
>> hydra.gnu.org, but ever since it has been building stuff on its own (it
>> does not offload to any other machine at this point).  Thus it can be
>> used to check for reproducibility issues:
>>
>>   guix challenge gdk-pixbuf \
>>     --substitute-urls="https://mirror.hydra.gnu.org https://bayfront.guixsd.org"
>>
>> The machine runs GuixSD and its config is under version control:
>>
>>   http://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm
>>
>> Currently Cuirass doesn’t expose much over HTTP¹ but hopefully we can
>> incrementally add the URLs that guix-hydra.el expects.
>>
>> There are a few glitches to address, such as the fact that it builds
>> with max-jobs = 1 due to <https://bugs.gnu.org/20217>, but we’ll get
>> there.
>>
>> Woohoo!  :-)
>>
>> Ludo’.
>>
>> ⁰ See <https://www.gnu.org/software/guix/news/growing-our-build-farm.html> and
>>   <https://lists.gnu.org/archive/html/guix-devel/2017-01/msg00109.html> if
>>   you missed the previous episodes.
>>
>> ¹ https://notabug.org/mthl/cuirass/src/master/src/cuirass/http.scm
>
> Wow, this is cool! Thanks to everyone who was/is/will be working on this!

I can only concur with this!

Great work :-D

Alex

Re: It’s building!

[Ludovic Courtès]

Hello Guix!

ludo@gnu.org (Ludovic Courtès) skribis:

> The machine was initially installed using substitutes from
> hydra.gnu.org, but ever since it has been building stuff on its own (it
> does not offload to any other machine at this point).  Thus it can be
> used to check for reproducibility issues:
>
>   guix challenge gdk-pixbuf \
>     --substitute-urls="https://mirror.hydra.gnu.org https://bayfront.guixsd.org"

As mentioned in another thread, this is now summarized here:

  https://www.gnu.org/software/guix/packages/reproducibility.html

The code for this page uses the API of ‘guix challenge’:

  http://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/www/packages.scm#n467

Although for many packages we can’t tell anything because bayfront
hasn’t built them yet, we can already see that a number of packages have
reproducibility issues, some of which were already filed at
<https://bugs.gnu.org/>.

Let’s address these!

To investigate reproducibility issues, you need to extract the nars
linked from the page above with ‘guix archive -x’, as shown at:

  https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html

(Remember that those from hydra.gnu.org are bzip2-compressed, while
those from bayfront are gzipped.)

Ludo’.

Re: It’s building!

[myglc2]

On 01/12/2017 at 17:10 Ludovic Courtès writes:

> Hello Guix!
>
> Good news: the new machine, bayfront.guixsd.org, is building Guix master
> for x86_64/i686 with Cuirass⁰!
>
> You can get substitutes from https://bayfront.guixsd.org; just authorize
> its key (with ‘guix archive --authorize’), which is:
>
>   (public-key 
>    (ecc 
>     (curve Ed25519)
>     (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))

Hi Ludo, I have a couple questions. I autorized bayfront like so ...

g1@g1 ~/src$ cat bayfront.guixsd.org.pub
 (public-key 
  (ecc 
   (curve Ed25519)
   (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))

g1@g1 ~/src$ sudo guix archive --authorize < bayfront.guixsd.org.pub

... and I read this ...

3.7 Invoking ‘guix archive’
===========================
[...]
     The list of authorized keys is kept in the human-editable file
     ‘/etc/guix/acl’.  The file contains “advanced-format s-expressions”
     (http://people.csail.mit.edu/rivest/Sexp.txt) and is structured as
     an access-control list in the Simple Public-Key Infrastructure
     (SPKI) (http://theworld.com/~cme/spki.txt).

... so I expected to find the bayfront key here ...

g1@g1 ~/src$ sudo cat /etc/guix/acl
(acl 
 (entry 
  (public-key 
   (rsa 
    (n #00DB1634E3D9DFAC97AE4734DAE968CCB15EE4815C82BDC254883DBB49FE1EF32268E82D4BBE0E35298C481C9DA1551642FAFF05AEC1A60712F1BB4BE7D25D7EFF7A4F89704A5A9AC232870CB9F2476C3B538A0E990A8825DEB73081D317001FB8A188600F2FEF5F5F570E857F3EE4355077A3C3918ED72723A56BA55C466D400658974D7DAD1F6B7B63C192B9C2704D98BBFF1C3BD5B8EF11A8ADC83ACB8FD8E9F1E792FDAD262415D13F2DEE55F330908CFDA9C3C8C32B64F7DD088457D34F445E2E2C83C6D680549DC9B6E6573B89496567204ED285E67A279F2F667080BA941D80D015CE87B0FB6A91A99CECC7D91D2D210B00E4B6E611DA51DB008F1DFE3FCAC6B27393FA781D45F9A15FC7B8785A3E86BA6592B2916CA22CF1E40FC85F85CACA590461154F58F3580B16398908EF32076F411299C28727C94D88B6A618F84DD73AEBED8270BCB6690928CB1BF250C35E1F6BF3B1B30D05BA246ECE8F69D9065DE26F4B3E0D814D70A9C27CB5B7B050C9090590D3A9EF83374F2643E5446FBD39DDB124DBF6DFDAA6D18E2560AD0CBFA11C959C9B7316BF19963A191967054E9FD97DC14D71082B30B1C90A46E8996682474C3BCB51BA0882958897B6DD35E41B5174D0A6BCDE97B89043E95BD1B70DE61DA666893B417196A180005466BC3A742FDF04E89B04460E3E6BC72E7F1B5FEA5B3092FEE551A3C447C12E104E65#)
    (e #010001#)
    )
   )
  (tag 
   (guix import)
   )
  )
 )


... but no. Where did it go?

Also you recommended ...

>   guix challenge gdk-pixbuf \
>     --substitute-urls="https://mirror.hydra.gnu.org https://bayfront.guixsd.org"

... which I tried _before_ I had authorized bayfront. I was surprised that it
worked before authorization. Should it?

TIA - George

Archive authentication & ‘guix challenge’

[Ludovic Courtès]

Hi!

myglc2 <myglc2@gmail.com> skribis:

> Hi Ludo, I have a couple questions. I autorized bayfront like so ...
>
> g1@g1 ~/src$ cat bayfront.guixsd.org.pub
>  (public-key 
>   (ecc 
>    (curve Ed25519)
>    (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))
>
> g1@g1 ~/src$ sudo guix archive --authorize < bayfront.guixsd.org.pub
>
> ... and I read this ...
>
> 3.7 Invoking ‘guix archive’
> ===========================
> [...]
>      The list of authorized keys is kept in the human-editable file
>      ‘/etc/guix/acl’.  The file contains “advanced-format s-expressions”
>      (http://people.csail.mit.edu/rivest/Sexp.txt) and is structured as
>      an access-control list in the Simple Public-Key Infrastructure
>      (SPKI) (http://theworld.com/~cme/spki.txt).
>
> ... so I expected to find the bayfront key here ...

[...]

> ... but no. Where did it go?

Could it be that the ‘guix archive’ you ran uses a configuration
directory other than this one?  What does:

  guile -c '(use-modules (guix config)) (pk %config-directory)'

print?

> Also you recommended ...
>
>>   guix challenge gdk-pixbuf \
>>     --substitute-urls="https://mirror.hydra.gnu.org https://bayfront.guixsd.org"
>
> ... which I tried _before_ I had authorized bayfront. I was surprised that it
> worked before authorization. Should it?

Yes.  It is not actually importing the archives into your store, only
looking at the content hashes that the servers advertise, so there is no
risk here and no requirement to authenticate.

That said, we could add an option to restrict to authorized servers.

HTH!

Ludo’.

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/09/2017 at 17:36 Ludovic Courtès writes:

> Hi!
>
> myglc2 <myglc2@gmail.com> skribis:
>
>> Hi Ludo, I have a couple questions. I autorized bayfront like so ...
>>
>> g1@g1 ~/src$ cat bayfront.guixsd.org.pub
>>  (public-key 
>>   (ecc 
>>    (curve Ed25519)
>>    (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))
>>
>> g1@g1 ~/src$ sudo guix archive --authorize < bayfront.guixsd.org.pub
>>
>> ... and I read this ...
>>
>> 3.7 Invoking ‘guix archive’
>> ===========================
>> [...]
>>      The list of authorized keys is kept in the human-editable file
>>      ‘/etc/guix/acl’.  The file contains “advanced-format s-expressions”
>>      (http://people.csail.mit.edu/rivest/Sexp.txt) and is structured as
>>      an access-control list in the Simple Public-Key Infrastructure
>>      (SPKI) (http://theworld.com/~cme/spki.txt).
>>
>> ... so I expected to find the bayfront key here ...
>
> [...]
>
>> ... but no. Where did it go?
>
> Could it be that the ‘guix archive’ you ran uses a configuration
> directory other than this one?  What does:
>
>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>
> print?

Thanks Ludo ...

g1@g1 ~/src/guix [env]$ guile -c '(use-modules (guix config)) (pk %config-directory)'

;;; ("/etc/guix")

Running from git checkout ...

g1@g1 ~/src/guix [env]$ git -C ~/.config/guix/latest log -n 1 --oneline
e1a65ae57 doc: Fix typos.

g1@g1 ~/src/guix [env]$ stat ~/.config/guix/latest | grep File
  File: '/home/g1/.config/guix/latest' -> '../../src/guix'

>> Also you recommended ...
>>
>>>   guix challenge gdk-pixbuf \
>>>     --substitute-urls="https://mirror.hydra.gnu.org https://bayfront.guixsd.org"
>>
>> ... which I tried _before_ I had authorized bayfront. I was surprised that it
>> worked before authorization. Should it?
>
> Yes.  It is not actually importing the archives into your store, only
> looking at the content hashes that the servers advertise, so there is no
> risk here and no requirement to authenticate.

Oh DUH! Of course. Thanks! - George

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/09/2017 at 17:36 Ludovic Courtès writes:

> Hi!
>
> myglc2 <myglc2@gmail.com> skribis:
>
>> Hi Ludo, I have a couple questions. I autorized bayfront like so ...
>>
>> g1@g1 ~/src$ cat bayfront.guixsd.org.pub
>>  (public-key 
>>   (ecc 
>>    (curve Ed25519)
>>    (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))
>>
>> g1@g1 ~/src$ sudo guix archive --authorize < bayfront.guixsd.org.pub
>>
>> ... and I read this ...
>>
>> 3.7 Invoking ‘guix archive’
>> ===========================
>> [...]
>>      The list of authorized keys is kept in the human-editable file
>>      ‘/etc/guix/acl’.  The file contains “advanced-format s-expressions”
>>      (http://people.csail.mit.edu/rivest/Sexp.txt) and is structured as
>>      an access-control list in the Simple Public-Key Infrastructure
>>      (SPKI) (http://theworld.com/~cme/spki.txt).
>>
>> ... so I expected to find the bayfront key here ...
>
> [...]
>
>> ... but no. Where did it go?
>
> Could it be that the ‘guix archive’ you ran uses a configuration
> directory other than this one?  What does:
>
>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>
> print?

Thanks Ludo ...

g1@g1 ~/src/guix [env]$ guile -c '(use-modules (guix config)) (pk %config-directory)'

;;; ("/etc/guix")

I'm Running git checkout ...

g1@g1 ~/src/guix [env]$ git -C ~/.config/guix/latest log -n 1 --oneline
e1a65ae57 doc: Fix typos.

g1@g1 ~/src/guix [env]$ stat ~/.config/guix/latest | grep File
  File: '/home/g1/.config/guix/latest' -> '../../src/guix'

>> Also you recommended ...
>>
>>>   guix challenge gdk-pixbuf \
>>>     --substitute-urls="https://mirror.hydra.gnu.org https://bayfront.guixsd.org"
>>
>> ... which I tried _before_ I had authorized bayfront. I was surprised that it
>> worked before authorization. Should it?
>
> Yes.  It is not actually importing the archives into your store, only
> looking at the content hashes that the servers advertise, so there is no
> risk here and no requirement to authenticate.

Oh DUH! Of course. Thanks! - George

Re: Archive authentication & ‘guix challenge’

[Ludovic Courtès]

myglc2 <myglc2@gmail.com> skribis:

> On 02/09/2017 at 17:36 Ludovic Courtès writes:

[...]

>> Could it be that the ‘guix archive’ you ran uses a configuration
>> directory other than this one?  What does:
>>
>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>
>> print?
>
> Thanks Ludo ...
>
> g1@g1 ~/src/guix [env]$ guile -c '(use-modules (guix config)) (pk %config-directory)'
>
> ;;; ("/etc/guix")

Hmm so that should definitely be writing to /etc/guix/acl.  Maybe you
could strace it to see what’s happening?

HTH,
Ludo’.

Re: Archive authentication & ‘guix challenge’

[myglc2]

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

On 02/11/2017 at 15:32 Ludovic Courtès writes:

> myglc2 <myglc2@gmail.com> skribis:
>
>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>
> [...]
>
>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>> directory other than this one?  What does:
>>>
>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>
>>> print?
>>
>> Thanks Ludo ...
>>
>> g1@g1 ~/src/guix [env]$ guile -c '(use-modules (guix config)) (pk %config-directory)'
>>
>> ;;; ("/etc/guix")
>
> Hmm so that should definitely be writing to /etc/guix/acl.  Maybe you
> could strace it to see what’s happening?

Thanks. Seems like a lot of "No such file or directory" messages.  I
have attached the installed packages (user and system) & a compressed
strace log.  HTH. - George


g1@g1 ~/src$ guix package -I
strace	4.7	out	/gnu/store/1iz5kyphiv1hbmbfpmn92f4ykjrxza5w-strace-4.7
icecat	45.5.1-gnu1	out	/gnu/store/4x3vwpm5lc92ks0pklvnizd5gh1z9zzx-icecat-45.5.1-gnu1
conkeror	1.0.3	out	/gnu/store/nbq3lidc743m2dqn0mx5c98x7cy82841-conkeror-1.0.3
unzip	6.0	out	/gnu/store/g4r98y5lrnvri4bi5x8ghkallxng323y-unzip-6.0
curl	7.50.3	out	/gnu/store/73ypa3smnqcj9pwnay42mfn07g00yjly-curl-7.50.3
xev	1.2.2	out	/gnu/store/x95xnxh26c64p9g8w1382c91wf8bvhbi-xev-1.2.2
r-hmisc	4.0-2	out	/gnu/store/8qi4v3ayrpy6rz7s21gw69phc4f0i5iq-r-hmisc-4.0-2
nss-certs	3.27.1	out	/gnu/store/nd946vlingp0ff63y18sqmv823cday9w-nss-certs-3.27.1
emacs-ess	16.04	out	/gnu/store/8pf9wjfhqpsk1dfv85wvyhdzxa39rvim-emacs-ess-16.04
r	3.3.2	out	/gnu/store/ckawwykzravj0kyxxm8mhf32ar6qk6al-r-3.3.2
graphviz	2.38.0	out	/gnu/store/s9haf97nzfcj02ph1y5kkcm7aqy64y04-graphviz-2.38.0
isync	1.2.1	out	/gnu/store/kwmsrdnq72j5241qdzylfylkrshylf7k-isync-1.2.1
mu	0.9.18	out	/gnu/store/nkafv9ry3nxf1p44azzslalvlafjbvzc-mu-0.9.18
notmuch	0.23.5	out	/gnu/store/c98yr3va54fr0ppp3cn3klyiz1kvvb8s-notmuch-0.23.5
aspell-dict-en	2016.11.20-0	out	/gnu/store/r6sk12qgms7g7rv5idg64xzbms80n74d-aspell-dict-en-2016.11.20-0
tree	1.7.0	out	/gnu/store/w17yydrmw1sndzad7yh1pvsjnixvlqh6-tree-1.7.0
mosh	1.2.6	out	/gnu/store/9l555sgh8gl7nsz8fr444f1lwmp8whir-mosh-1.2.6

g1@g1 ~/src$ guix package --list-installed --profile=/run/current-system/profile
shepherd	0.3.2	out	/gnu/store/qfax650mynyx9x8wm8lq8w7fp82kkfc6-shepherd-0.3.2
lzip	1.16	out	/gnu/store/41q4ln3k4f9awmyrsmazv84mrwc1i5xq-lzip-1.16
xz	5.2.2	out	/gnu/store/4yg6q1kp856m68arkpqc85hqgbffhpxf-xz-5.2.2
bzip2	1.0.6	out	/gnu/store/d5nscny560slzpljixqzim6b8ms7hhv2-bzip2-1.0.6
gzip	1.8	out	/gnu/store/ginbign0swn8h69k3z4fy18r8pwq3rqx-gzip-1.8
tar	1.29	out	/gnu/store/9l52vcmb1ambc3ypf7nxn38ac0976yyf-tar-1.29
gawk	4.1.4	out	/gnu/store/k03y1lfaj1xw0d7j2lxdil8ii5c67fdy-gawk-4.1.4
patch	2.7.5	out	/gnu/store/fs49m4pvdf2v7kixf9sls8nmhvh40ajl-patch-2.7.5
diffutils	3.5	out	/gnu/store/g0lyirlbqday5n2n0n6lh6nmdxi8a45z-diffutils-3.5
sed	4.2.2	out	/gnu/store/9761yfpvyr1fcpjhry8pgb3f0k6kj8n4-sed-4.2.2
grep	2.25	out	/gnu/store/hb301wl5s7352vbn1vds85dhy32n0hkw-grep-2.25
findutils	4.6.0	out	/gnu/store/cz7dl482c1j6j5s4vh1pll4lzdl5sl6b-findutils-4.6.0
coreutils	8.25	out	/gnu/store/9xfn6q7cxqxaxsv6kgiic9iygl2iv2ci-coreutils-8.25
bash	4.4.0	out	/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0
guile	2.0.12	out	/gnu/store/6slzn4ixcjlhy3av3biglqfli9pwxcn9-guile-2.0.12
bash-completion	2.4	out	/gnu/store/nwwbi0b9r7ssw6z76pn6l4ags2w8d37q-bash-completion-2.4
kbd	2.0.3	out	/gnu/store/xd59ar5n2dhgc5szbgryhwchpry8dn6g-kbd-2.0.3
e2fsprogs	1.42.13	out	/gnu/store/k1lp8v81m07aykvpn5ky2dqs2nckw804-e2fsprogs-1.42.13
eudev	3.2	out	/gnu/store/ji6b6zhk7l3y7vbjhx7kpnb9v7hlbc6v-eudev-3.2
kmod	23	out	/gnu/store/vzlgcmkys1dpw238wq7qb9klb4g84p5l-kmod-23
sudo	1.8.19p1	out	/gnu/store/2j4rpb610jr1fr5fm5m0p6dy80zw11dn-sudo-1.8.19p1
info-reader	6.3	out	/gnu/store/z2awzispx2fhmbpv0rn1g7bsfz56gy85-info-reader-6.3
man-db	2.7.5	out	/gnu/store/vmxcccvhlfyc64x5772cp3wfwb57a3pp-man-db-2.7.5
net-tools	1.60	out	/gnu/store/s6p28awc14di0r1w3d6s3a90cj0hyzyi-net-tools-1.60
iproute2	4.9.0	out	/gnu/store/v963yg0fiqv16xbnd38390qzfxzisyl3-iproute2-4.9.0
rfkill	0.5	out	/gnu/store/sjs8rhamynivkvk7sx5zh4596zwrds09-rfkill-0.5
wireless-tools	30.pre9	out	/gnu/store/9fmsh9i7vwnvn8swkdf1whyl9ww52x7n-wireless-tools-30.pre9
iw	4.9	out	/gnu/store/v7r8v0v7bm1hgldwhq5wi8hbh69hjcda-iw-4.9
isc-dhcp	4.3.5	out	/gnu/store/94l9y9sch5p6lblbhzsxxbixwdzg9gzj-isc-dhcp-4.3.5
inetutils	1.9.4	out	/gnu/store/40fz3iw8vw6pdh6dy8xlgqbri0finpqy-inetutils-1.9.4
util-linux	2.28.1	out	/gnu/store/8b5ffm91zlmm1k5i4kq5qix59v7jm9ln-util-linux-2.28.1
usbutils	008	out	/gnu/store/zhj1kx6b2mzm4cbw9kjfibkak461hkfz-usbutils-008
pciutils	3.5.2	out	/gnu/store/rqg4malz30sm4hakrvr4xln54w77yiz8-pciutils-3.5.2
lsof	4.88	out	/gnu/store/5y86yvq9iv47lp5pl2p7kmpyfysb0750-lsof-4.88
nano	2.7.4	out	/gnu/store/vv6y33ji06dg3xchlwd7lyc0pdj59s61-nano-2.7.4
zile	2.4.13	out	/gnu/store/abs3kz5h42gqd9dnjp6iy4xgjhv11jk8-zile-2.4.13
less	481	out	/gnu/store/r3bzsqkgr4hd3kkih5qw0w9abxl82ns4-less-481
which	2.21	out	/gnu/store/cn670s29lsf2nr5axd8gmhl8sb9qpyiq-which-2.21
psmisc	22.20	out	/gnu/store/dxxq3bhv1dw0ngjrr392f83c94pyy7yq-psmisc-22.20
procps	3.3.12	out	/gnu/store/9cw2mj574gh8kmhjnv5rzyjj3dqvgqv5-procps-3.3.12
magit	2.10.0	out	/gnu/store/wrqa6ip8rc5pd4npq4giaa2c754n7d0y-magit-2.10.0
emacs-paredit	24	out	/gnu/store/0fs8zw8lpllmnlgn3xagha4kkkfws3fw-emacs-paredit-24
emacs-flycheck	28	out	/gnu/store/d2q44vd2hm6d092cz3s47civy702iwjx-emacs-flycheck-28
aspell	0.60.6.1	out	/gnu/store/683xx2qh0b7vwyfrdhs9rvsjfgjy07rz-aspell-0.60.6.1
gv	3.7.4	out	/gnu/store/2yrxzvfdvacx2hbzdak3wblhlna12yc0-gv-3.7.4
emacs-simple-httpd	1.4.6	out	/gnu/store/izqwlcmk4ms6b11yg20sixspwvvbbpkp-emacs-simple-httpd-1.4.6
emacs-web-mode	14	out	/gnu/store/x3cbykxg2h3larx0vd4y33miaymlr085-emacs-web-mode-14
emacs-markdown-mode	2.1	out	/gnu/store/v0m8pcidp3sg27ibn13isi1611lykyfi-emacs-markdown-mode-2.1
emacs-zenburn-theme	2.4	out	/gnu/store/lnsmqidf9g4n1yqxzhaqfdgzs8lpvv76-emacs-zenburn-theme-2.4
font-gnu-freefont-ttf	20120503	out	/gnu/store/dl11724dj1z6dsw7i82jmavk75ixp0b8-font-gnu-freefont-ttf-20120503
font-dejavu	2.37	out	/gnu/store/8rid533v40vawypqqckxx6v30sc89yby-font-dejavu-2.37
gs-fonts	8.11	out	/gnu/store/mh3mx042h5ayvg9mgmfln4kwvs102lzp-gs-fonts-8.11
emacs-guix	0.2.2	out	/gnu/store/6z7krzimq3zi3fg8j67dv0nznisb0w4b-emacs-guix-0.2.2
emacs-no-x-toolkit	25.1	out	/gnu/store/2c4bgx9x5s6ddrha9r4linjiswln1br1-emacs-no-x-toolkit-25.1
qemu	2.8.0	out	/gnu/store/i9dvddg1ws6rzm55pfjjflhb5s69k5rl-qemu-2.8.0
cups	2.2.1	out	/gnu/store/qwjjdghipirqgllgvk7aivzwyh113cam-cups-2.2.1
mdadm	3.4	out	/gnu/store/ax95zmrfrcz02gr0qgnl7bbsgr4sp02x-mdadm-3.4
smartmontools	6.5	out	/gnu/store/7ln31xfpz5nmydi2akwdzicffd6ai221-smartmontools-6.5
parted	3.2	out	/gnu/store/z268kiqgmr3sgaml2gc0dr9yz577l9i2-parted-3.2
glibc-utf8-locales	2.24	out	/gnu/store/bhj5xdwwd2dg770lmlks7hyny8vzjm9x-glibc-utf8-locales-2.24
xauth	1.0.9	out	/gnu/store/08fqa5ngkjaj0xwgysni80ik4i2gpmrb-xauth-1.0.9
nss-certs	3.27.1	out	/gnu/store/nd946vlingp0ff63y18sqmv823cday9w-nss-certs-3.27.1
openssh	7.4p1	out	/gnu/store/akr22bjpf3c9h48b1rzipgr6s8032zjr-openssh-7.4p1
sicp	20160220-1.5b52db5	out	/gnu/store/rkph460yqpllgfclmzvha8ia4f58mszf-sicp-20160220-1.5b52db5
guix	0.12.0-4.d9da	out	/gnu/store/9hhljacc22jppmjx57xc7c46by10y8gh-guix-0.12.0-4.d9da
make	4.2.1	out	/gnu/store/l8sygb0q4yxv058w83n6bllvyhs8ag21-make-4.2.1
git	2.11.0	out	/gnu/store/iy9g5fsg9q70c6vpy0xyialm6ccsx1xk-git-2.11.0
wget	1.18	out	/gnu/store/sdzy9pxdqqf91s1xpjiikf5xxm9clgwi-wget-1.18
rsync	3.1.2	out	/gnu/store/4pln27ifkr5iscm04725kk6hz70jcj24-rsync-3.1.2
screen	4.5.0	out	/gnu/store/m2rb17jzbmnz1pdp1wswxkf6xf7bfn3i-screen-4.5.0
freeipmi	1.5.5	out	/gnu/store/dwbmsbiwl2sah8sbdgh5p0s50v7w2xxp-freeipmi-1.5.5
g1@g1 ~/src$



[-- Attachment #2: strace.guix-authorize.txt.gz --]
[-- Type: application/octet-stream, Size: 20799 bytes --]

Re: Archive authentication & ‘guix challenge’

[Maxim Cournoyer]

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

Hello,

ludo@gnu.org (Ludovic Courtès) writes:

> myglc2 <myglc2@gmail.com> skribis:
>
>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>
> [...]
>
>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>> directory other than this one?  What does:
>>>
>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>
>>> print?

I remember being equally confused by not finding the key imported in the
/etc/guix/acl file, as per the manual.

On my GuixSD system, the value of %config-directory is:
"/usr/local/etc/guix", and the file "/usr/local/etc/guix/acl" does
contain multiple times the public key of Bayfront, which must be due
to passed attempts at adding the Bayfront key using "guix archive".

Maxim

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

Re: Archive authentication & ‘guix challenge’

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> myglc2 <myglc2@gmail.com> skribis:
>>
>>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>>
>> [...]
>>
>>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>>> directory other than this one?  What does:
>>>>
>>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>>
>>>> print?
>
> I remember being equally confused by not finding the key imported in the
> /etc/guix/acl file, as per the manual.
>
> On my GuixSD system, the value of %config-directory is:
> "/usr/local/etc/guix", and the file "/usr/local/etc/guix/acl" does
> contain multiple times the public key of Bayfront, which must be due
> to passed attempts at adding the Bayfront key using "guix archive".

I suppose that’s because you installed Guix in /usr/local at some point?

myglc2, are you in a similar situation?

Ludo’.

Re: Archive authentication & ‘guix challenge’

[myglc2]

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


On 02/13/2017 at 14:05 Ludovic Courtès writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> myglc2 <myglc2@gmail.com> skribis:
>>>
>>>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>>>
>>> [...]
>>>
>>>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>>>> directory other than this one?  What does:
>>>>>
>>>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>>>
>>>>> print?
>>
>> I remember being equally confused by not finding the key imported in the
>> /etc/guix/acl file, as per the manual.
>>
>> On my GuixSD system, the value of %config-directory is:
>> "/usr/local/etc/guix", and the file "/usr/local/etc/guix/acl" does
>> contain multiple times the public key of Bayfront, which must be due
>> to passed attempts at adding the Bayfront key using "guix archive".
>
> I suppose that’s because you installed Guix in /usr/local at some point?
>
> myglc2, are you in a similar situation?

Hmm, apparently so ...

guile -c '(use-modules (guix config)) (pk %config-directory)'

... returns ...

;;; ("/etc/guix")

... but in the REPL I get ...

(use-modules (guix config))
(pk %config-directory)

=> "/usr/local/etc/guix"

... /usr/local/etc/guix/acl is the only file under /usr and I didn't
install in /usr/local.  The system was created with 'guix init' on a
previous GuixSD system and has since been modified by 'guix reconfigure'
and 'guix package', running either from 'git pull' or git checkout.

I don't know if this is related, but I see that guix config.log
(attached) has ...

guix_sysconfdir='/usr/local/etc'

Also, you may recall that, on the previous system, we had to make
/usr/local/sbin/guix-register a symlink to guix-register to get 'guix
init' to work ...

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25444

HTH, - George


[-- Attachment #2: config.log.gz --]
[-- Type: application/octet-stream, Size: 8489 bytes --]

Re: Archive authentication & ‘guix challenge’

[Maxim Cournoyer]

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

Hello Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> myglc2 <myglc2@gmail.com> skribis:
>>>
>>>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>>>
>>> [...]
>>>
>>>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>>>> directory other than this one?  What does:
>>>>>
>>>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>>>
>>>>> print?
>>
>> I remember being equally confused by not finding the key imported in the
>> /etc/guix/acl file, as per the manual.
>>
>> On my GuixSD system, the value of %config-directory is:
>> "/usr/local/etc/guix", and the file "/usr/local/etc/guix/acl" does
>> contain multiple times the public key of Bayfront, which must be due
>> to passed attempts at adding the Bayfront key using "guix archive".
>
> I suppose that’s because you installed Guix in /usr/local at some point?
>

Not that I'm aware of. Like myglc2, I installed GuixSD from the USB
bootable image, following the manual instructions (guix system init or
similar).

It seems that both myglc2 and I are running guix from a git
checkout. Could this has something to do with it?

Thanks,

Maxim

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

Re: Archive authentication & ‘guix challenge’

[Ludovic Courtès]

myglc2 <myglc2@gmail.com> skribis:

> On 02/13/2017 at 14:05 Ludovic Courtès writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>
>>>> myglc2 <myglc2@gmail.com> skribis:
>>>>
>>>>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>>>>
>>>> [...]
>>>>
>>>>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>>>>> directory other than this one?  What does:
>>>>>>
>>>>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>>>>
>>>>>> print?
>>>
>>> I remember being equally confused by not finding the key imported in the
>>> /etc/guix/acl file, as per the manual.
>>>
>>> On my GuixSD system, the value of %config-directory is:
>>> "/usr/local/etc/guix", and the file "/usr/local/etc/guix/acl" does
>>> contain multiple times the public key of Bayfront, which must be due
>>> to passed attempts at adding the Bayfront key using "guix archive".
>>
>> I suppose that’s because you installed Guix in /usr/local at some point?
>>
>> myglc2, are you in a similar situation?
>
> Hmm, apparently so ...
>
> guile -c '(use-modules (guix config)) (pk %config-directory)'
>
> ... returns ...
>
> ;;; ("/etc/guix")
>
> ... but in the REPL I get ...
>
> (use-modules (guix config))
> (pk %config-directory)
>
> => "/usr/local/etc/guix"
>
> ... /usr/local/etc/guix/acl is the only file under /usr and I didn't
> install in /usr/local.  The system was created with 'guix init' on a
> previous GuixSD system and has since been modified by 'guix reconfigure'
> and 'guix package', running either from 'git pull' or git checkout.
>
> I don't know if this is related, but I see that guix config.log
> (attached) has ...
>
> guix_sysconfdir='/usr/local/etc'
>
> Also, you may recall that, on the previous system, we had to make
> /usr/local/sbin/guix-register a symlink to guix-register to get 'guix
> init' to work ...

Right.

‘guix pull’ preserves your (guix config) module.  So if the ‘guix’ you
run was configured to use /etc, it’ll keep using that; if it was
configured to use /usr/local/etc, it’ll keep using that.

If you run “./pre-inst-env guix pull”, then you end up using (guix
config) from your build tree, which is configured to use /usr/local/etc
by default.  That’s probably what happened, no?

To fix it, you can either run:

  rm -f ~/.config/guix/latest && guix pull

or just do:

  ./configure --sysconfdir=/etc

in your checkout.

Admittedly all this is kind of ugly and I look forward to the ‘guix
pull’ replacement…

HTH!

Ludo’.

Re: Archive authentication & ‘guix challenge’

[myglc2]

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


On 02/14/2017 at 09:20 Ludovic Courtès writes:

> myglc2 <myglc2@gmail.com> skribis:
>
>> On 02/13/2017 at 14:05 Ludovic Courtès writes:
>>
>>> Hi Maxim,
>>>
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>
>>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>>
>>>>> myglc2 <myglc2@gmail.com> skribis:
>>>>>
>>>>>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>>>>>> directory other than this one?  What does:
>>>>>>>
>>>>>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>>>>>
>>>>>>> print?
>>>>
>>>> I remember being equally confused by not finding the key imported in the
>>>> /etc/guix/acl file, as per the manual.
>>>>
>>>> On my GuixSD system, the value of %config-directory is:
>>>> "/usr/local/etc/guix", and the file "/usr/local/etc/guix/acl" does
>>>> contain multiple times the public key of Bayfront, which must be due
>>>> to passed attempts at adding the Bayfront key using "guix archive".
>>>
>>> I suppose that’s because you installed Guix in /usr/local at some point?
>>>
>>> myglc2, are you in a similar situation?
>>
>> Hmm, apparently so ...
>>
>> guile -c '(use-modules (guix config)) (pk %config-directory)'
>>
>> ... returns ...
>>
>> ;;; ("/etc/guix")
>>
>> ... but in the REPL I get ...
>>
>> (use-modules (guix config))
>> (pk %config-directory)
>>
>> => "/usr/local/etc/guix"
>>
>> ... /usr/local/etc/guix/acl is the only file under /usr and I didn't
>> install in /usr/local.  The system was created with 'guix init' on a
>> previous GuixSD system and has since been modified by 'guix reconfigure'
>> and 'guix package', running either from 'git pull' or git checkout.
>>
>> I don't know if this is related, but I see that guix config.log
>> (attached) has ...
>>
>> guix_sysconfdir='/usr/local/etc'
>>
>> Also, you may recall that, on the previous system, we had to make
>> /usr/local/sbin/guix-register a symlink to guix-register to get 'guix
>> init' to work ...
>
> Right.
>
> ‘guix pull’ preserves your (guix config) module.  So if the ‘guix’ you
> run was configured to use /etc, it’ll keep using that; if it was
> configured to use /usr/local/etc, it’ll keep using that.
>
> If you run “./pre-inst-env guix pull”, then you end up using (guix
> config) from your build tree, which is configured to use /usr/local/etc
> by default.  That’s probably what happened, no?
>
> To fix it, you can either run:
>
>   rm -f ~/.config/guix/latest && guix pull
>
> or just do:
>
>   ./configure --sysconfdir=/etc
>
> in your checkout.

Hi Ludo,

I tried both approaches but ...

sudo guix archive --authorize < bayfront.guixsd.org.pub

... continues to add the key to /usr/local/etc/guix/acl

:-(

Like Maxim, I usually run from the git checkout with
/home/g1/.config/guix/latest pointing to the checkout.

But after ...

rm -f ~/.config/guix/latest && guix pull

... I confirmed ...

stat ~/.config/guix/latest | grep File
  File: '/home/g1/.config/guix/latest' ->
  '/gnu/store/8ag16yziir9gl7rq02vswr31ip4k33ab-guix-latest'

I have attached the config log again in hopes it might provide
insight. I can also provide shell logs if they are of interest.


Also, FWIW, when I did ...

g1@g1 ~/src/guix [env]$ ./configure --sysconfdir=/etc

... it gave this message ...

[...]
checking the current installation's localstatedir... /var
configure: error: chosen localstatedir '/usr/local/var' does not match that of the existing installation '/var'
Installing may corrupt /gnu/store!
Use './configure --localstatedir=/var'.

... which left me wondering if it meant ...

1) it failed, or

2) it worked, but results would be unpredictable

So maybe this message should be made more clear.


[-- Attachment #2: config.log.gz --]
[-- Type: application/octet-stream, Size: 8569 bytes --]

Re: Archive authentication & ‘guix challenge’

[Ludovic Courtès]

myglc2 <myglc2@gmail.com> skribis:

> g1@g1 ~/src/guix [env]$ ./configure --sysconfdir=/etc
>
> ... it gave this message ...
>
> [...]
> checking the current installation's localstatedir... /var
> configure: error: chosen localstatedir '/usr/local/var' does not match that of the existing installation '/var'
> Installing may corrupt /gnu/store!
> Use './configure --localstatedir=/var'.
>
> ... which left me wondering if it meant ...

Do like it says.  :-)

That is, it noticed that your system has /var/guix/db and that you were
configuring with a different state directory, which is a mistake you’d
rather avoid (see the bits about localstatedir at
<https://www.gnu.org/software/guix/manual/html_node/Requirements.html>).

So:

  ./configure --localstatedir=/var --sysconfdir=/etc -C

Ludo’.

Re: Archive authentication & ‘guix challenge’

[Maxim Cournoyer]

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

Hi George and Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

[...]
>
> ‘guix pull’ preserves your (guix config) module.  So if the ‘guix’ you
> run was configured to use /etc, it’ll keep using that; if it was
> configured to use /usr/local/etc, it’ll keep using that.
>
> If you run “./pre-inst-env guix pull”, then you end up using (guix
> config) from your build tree, which is configured to use /usr/local/etc
> by default.  That’s probably what happened, no?
>

I ran guix pull initially (before starting to use a git checkout). And
I remember mistakenly running "guix pull" from my guix checkout, which
if I followed your explanation would have caused (guix config) to point
to /usr/local/etc. So that seems like a plausible explication! I guess
in the newer Guix releases the default path has been fixed (to /etc)?

> To fix it, you can either run:
>
>   rm -f ~/.config/guix/latest && guix pull
>
> or just do:
>
>   ./configure --sysconfdir=/etc
>

I ran ./configure --localstatedir=/var --sysconfig=/etc && make, and I
can now confirm that it fixed it:

guile -c "(use-modules (guix config)) (pk %config-directory)"
;;; ("/etc/guix")

I also checked that:

sudo guix archive --authorize < bayfront.guixsd.org.pub

Produced an entry in /etc/guix/acl.

George, as an alternative, you might be interested in declaring the extra
key in your system's config.scm file [0].

Thanks for the help, Ludovic!

Maxim

[0] https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01746.html

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

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/14/2017 at 16:29 Ludovic Courtès writes:

> myglc2 <myglc2@gmail.com> skribis:
>
>> g1@g1 ~/src/guix [env]$ ./configure --sysconfdir=/etc
>>
>> ... it gave this message ...
>>
>> [...]
>> checking the current installation's localstatedir... /var
>> configure: error: chosen localstatedir '/usr/local/var' does not match that of the existing installation '/var'
>> Installing may corrupt /gnu/store!
>> Use './configure --localstatedir=/var'.
>>
>> ... which left me wondering if it meant ...
>
> Do like it says.  :-)
>
> That is, it noticed that your system has /var/guix/db and that you were
> configuring with a different state directory, which is a mistake you’d
> rather avoid (see the bits about localstatedir at
> <https://www.gnu.org/software/guix/manual/html_node/Requirements.html>).
>
> So:
>
>   ./configure --localstatedir=/var --sysconfdir=/etc -C

OK, thank you. That works :-) Many thanks! 

FWIW, here are a couple patches that would make this clearer.

diff --git a/doc/guix.texi b/doc/guix.texi
index 6cdb5e592..60cc073a0 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -582,12 +582,13 @@ C++11 standard.
 
 @cindex state directory
 When configuring Guix on a system that already has a Guix installation,
-be sure to specify the same state directory as the existing installation
-using the @code{--localstatedir} option of the @command{configure}
-script (@pxref{Directory Variables, @code{localstatedir},, standards,
-GNU Coding Standards}).  The @command{configure} script protects against
-unintended misconfiguration of @var{localstatedir} so you do not
-inadvertently corrupt your store (@pxref{The Store}).
+you should specify the same state directory as the existing
+installation, (typically @code{/var} on GuixSD, and @code{???} on Guix
+installations) using the @code{--localstatedir} option of the
+@command{configure} script (@pxref{Directory Variables,
+@code{localstatedir},, standards, GNU Coding Standards}).  If in doubt,
+leave it unspecified and the @command{configure} script will recommend
+the correct value.
 
 @cindex Nix, compatibility
 When a working installation of @url{http://nixos.org/nix/, the Nix package


diff --git a/m4/guix.m4 b/m4/guix.m4
index 663059841..25de46516 100644
--- a/m4/guix.m4
+++ b/m4/guix.m4
@@ -357,10 +357,9 @@ AC_DEFUN([GUIX_CHECK_LOCALSTATEDIR], [
       case "$localstatedir" in
         NONE|\${prefix}*)
           # User kept the default value---i.e., did not pass '--localstatedir'.
-          AC_MSG_ERROR([chosen localstatedir '$guix_localstatedir' does not match \
-that of the existing installation '$guix_cv_current_localstatedir'
-Installing may corrupt $storedir!
-Use './configure --localstatedir=$guix_cv_current_localstatedir'.])
+          AC_MSG_ERROR([The default localstatedir '$guix_localstatedir' does not match \
+that of the existing installation, which is '$guix_cv_current_localstatedir'
+so you should add './configure --localstatedir=$guix_cv_current_localstatedir'.])
           ;;
         *)
           # User passed an explicit '--localstatedir'.  Assume they know what

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/14/2017 at 17:43 Maxim Cournoyer writes:

> Hi George and Ludovic,
>
> ludo@gnu.org (Ludovic Courtès) writes:
>
> [...]
>>
>> ‘guix pull’ preserves your (guix config) module.  So if the ‘guix’ you
>> run was configured to use /etc, it’ll keep using that; if it was
>> configured to use /usr/local/etc, it’ll keep using that.

Could you please clarify? Does it do this when invoked by 'guix pull' or
by './pre-inst-env guix pull', or in both cases?

>> If you run “./pre-inst-env guix pull”, then you end up using (guix
>> config) from your build tree, which is configured to use /usr/local/etc
>> by default.  That’s probably what happened, no?

I don't use './pre-inst-env' so I don't think so. But maybe I did on the
system from which I did 'system init' to create this one. Would that
explain it?

[...]

> George, as an alternative, you might be interested in declaring the extra
> key in your system's config.scm file [0].

Great point, thank you Maxim.