GNU Guix 1.3.0rc1 available for testing!

GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

Hello Guix!

A first RC for the upcoming 1.3.0 release is now available for testing:

  source:
    https://alpha.gnu.org/gnu/guix/guix-1.3.0rc1.tar.gz

  binary tarball (to install on a “foreign distro”):
    https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.aarch64-linux.tar.xz
    https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.armhf-linux.tar.xz
    https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.i686-linux.tar.xz
    https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz
    https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz

  system installation:
    https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.i686-linux.iso.xz
    https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.x86_64-linux.iso.xz

  virtual machine image:
    https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz

SHA256 hashes:

46525e84d2a1d30a53bb40569de23bb1813b8df78731d09b5eac977818106ea7  guix-1.3.0rc1.tar.gz
2427e73f5f18c51446174cd230b6dc19c8461838641bec6f66761537e7aa7ad4  guix-binary-1.3.0rc1.aarch64-linux.tar.xz
89028139d049e1a868d41c5d1155f6b3be1b1b0407d93bfa86b7c713a87c1daf  guix-binary-1.3.0rc1.armhf-linux.tar.xz
5da4edf9075c87d575d653140b53fe316305f94b58179aa935af223f037b36c2  guix-binary-1.3.0rc1.i686-linux.tar.xz
f7c2a42f9f48fc6b2d7ba672ed49c3a6fc483cb3fbe261a8a79385b8381205ec  guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz
3348ec2fd116ed97c1806f8eac777ab2f7cff2b466b7c0dc5c2d1a904e4395f7  guix-binary-1.3.0rc1.x86_64-linux.tar.xz
429deb5af3a956e7530cd0ed4cab7d5b13a7f1d22a0fe690f6714ab89a846db6  guix-system-install-1.3.0rc1.i686-linux.iso.xz
a1772a8d08729471e7b1c04ac4d9213f4db077458aeacc59d14ff9f2399357b2  guix-system-install-1.3.0rc1.x86_64-linux.iso.xz
58ccabbc61cd00d9b1ec1f417360827aa2f8428567f1cfb0a83dc2191e67897e  guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz

All these files have an associated ‘.sig’, an OpenPGP signature that you
can verify as explained at
<https://guix.gnu.org/manual/en/html_node/Binary-Installation.html>.

You can help by:

  1. Testing the binary tarball on the distro of your choice.  You can
     download <https://guix.gnu.org/install.sh>.  Uncomment the
     ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
     should pick up 1.3.0rc1 automatically.

  2. Testing the graphical installer of Guix System.

  3. Testing the VM image.

In any case, please report success, failure, and annoyances in this
thread.

The remaining outstanding issues, which you can track here [0], are as
follow and affect the installer:

47567 Installer crash in 'uuid->string' for a FAT16 partition
44872 Installer crash: 'uuid->string' is passed #f in lieu of a UUID

If everything goes well, the final release is planned for the 10th of
May, which gives us about a week to test and fix any remaining issues.

Thanks in advance!

Maxim

[0]  http://issues.guix.gnu.org/47297

Re: GNU Guix 1.3.0rc1 available for testing!

[Vagrant Cascadian]

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

On 2021-05-01, Maxim Cournoyer wrote:
> A first RC for the upcoming 1.3.0 release is now available for testing:

Thanks for all the hard work getting rc1 ready!


Also soon coming to a Debian mirror near you:

  https://buildd.debian.org/status/package.php?p=guix&suite=experimental


live well,
  vagrant

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

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Sat, May 01, 2021 at 01:45:57AM -0400, Maxim Cournoyer wrote:
>     https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz

I tested the binary tarball on x86_64.

I used `guix package --export-manifest > manifest` before beginning the
test, so that I could easily recreate my profile afterwards.

> All these files have an associated ‘.sig’, an OpenPGP signature that you
> can verify as explained at
> <https://guix.gnu.org/manual/en/html_node/Binary-Installation.html>.

These instructions explain how to get Ludo's key, but that wasn't used
here.

In doc/guix.texi, the variables OPENPGP-SIGNING-KEY-ID and
OPENPGP-SIGNING-KEY-URL are defined.

Maybe we should update the manual to mention "1.3.0rc1" and the correct
key.

The "normal" manual would still mention 1.2.0, but the devel manual
would work for 1.3.0rc1. I think that it's fine to mention the release
candidate in the "devel" manual.

https://guix.gnu.org/manual/en/
https://guix.gnu.org/manual/devel/en/

> 
>   1. Testing the binary tarball on the distro of your choice.  You can
>      download <https://guix.gnu.org/install.sh>.  Uncomment the
>      ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
>      should pick up 1.3.0rc1 automatically.

The install.sh script also recommends installing Ludo's key, but of
course fails to verify the signature with it. After installing Ludo's
key, the installer does suggest the correct key — Maxim's.

Aside from that, the install.sh script worked fine on current Debian,
and I was able to conveniently restore my Guix profile with `guix
package -m ./manifest`.

Then I did `guix pull && guix upgrade`. All good!

I forgot to remove the existing Guix build users and the guixbuild group
before my test. It would be great if somebody can remember to check that
they are created successfully by the script.

Re: GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

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

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

> On Sat, May 01, 2021 at 01:45:57AM -0400, Maxim Cournoyer wrote:
>>     https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz
>
> I tested the binary tarball on x86_64.
>
> I used `guix package --export-manifest > manifest` before beginning the
> test, so that I could easily recreate my profile afterwards.
>
>> All these files have an associated ‘.sig’, an OpenPGP signature that you
>> can verify as explained at
>> <https://guix.gnu.org/manual/en/html_node/Binary-Installation.html>.
>
> These instructions explain how to get Ludo's key, but that wasn't used
> here.
>
> In doc/guix.texi, the variables OPENPGP-SIGNING-KEY-ID and
> OPENPGP-SIGNING-KEY-URL are defined.
>
> Maybe we should update the manual to mention "1.3.0rc1" and the correct
> key.
>
> The "normal" manual would still mention 1.2.0, but the devel manual
> would work for 1.3.0rc1. I think that it's fine to mention the release
> candidate in the "devel" manual.
>
> https://guix.gnu.org/manual/en/
> https://guix.gnu.org/manual/devel/en/

Thank you for pointing that issue; I caught the problem with
guix-install.sh before posting, but overlooked that one.  As you
pointed, that won't be reflected on our website, but I agree that having
the new key covered in the devel manual (master branch) is already an
improvement.  The attached patch augments the manual to cover for the
new key.  Let me know if it looks good to you.  If it does, I will push
it to the master branch (IIUC we can't push this change to the
version-1.3.0 branch as that would break the string freeze there).

>>
>>   1. Testing the binary tarball on the distro of your choice.  You can
>>      download <https://guix.gnu.org/install.sh>.  Uncomment the
>>      ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
>>      should pick up 1.3.0rc1 automatically.
>
> The install.sh script also recommends installing Ludo's key, but of
> course fails to verify the signature with it. After installing Ludo's
> key, the installer does suggest the correct key — Maxim's.

Are you sure you downloaded it from https://guix.gnu.org/install.sh
(which just redirects to the current copy on the master branch) ?  Since
commit e64af2060e8cfa48e74b887281acb3fd4c7e7781 (which was made just
before writing the original message), it checks for both keys.

> Aside from that, the install.sh script worked fine on current Debian,
> and I was able to conveniently restore my Guix profile with `guix
> package -m ./manifest`.
>
> Then I did `guix pull && guix upgrade`. All good!
>
> I forgot to remove the existing Guix build users and the guixbuild group
> before my test. It would be great if somebody can remember to check that
> they are created successfully by the script.

I've tested the install script in a Ubuntu 20.04 VM which had never
known Guix, and it was successful.  I guess that part is covered :-).

Thanks for the tests and feedback!

Maxim

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-doc-Update-to-cover-for-an-additional-OpenPGP-signin.patch --]
[-- Type: text/x-patch, Size: 3283 bytes --]

From 3b942cb833688520c4c4dadfb281270520510564 Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Sat, 1 May 2021 22:35:09 -0400
Subject: [PATCH] doc: Update to cover for an additional OpenPGP signing key.

The upcoming 1.3.0 release will be signed with my OpenPGP key, and further
releases may also be.

* doc/guix.texi (OPENPGP-SIGNING-KEY-ID, OPENPGP-SIGNING-KEY-URL): Rename to...
(OPENPGP-SIGNING-KEY-ID-1, OPENPGP-SIGNING-KEY-URL-1): ... these,
respectively.
(OPENPGP-SIGNING-KEY-ID-2, OPENPGP-SIGNING-KEY-URL-2): New variables.
(Binary Installation): Adjust to cover for the new key.
(USB Stick and DVD Installation): Likewise.
(Invoking guix refresh): Adjust accordingly.
---
 doc/guix.texi | 26 ++++++++++++++++----------
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 2fe7ad3a2a..b1bb0db74d 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -9,9 +9,11 @@
 
 @include version.texi
 
-@c Identifier of the OpenPGP key used to sign tarballs and such.
-@set OPENPGP-SIGNING-KEY-ID 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
-@set OPENPGP-SIGNING-KEY-URL https://sv.gnu.org/people/viewgpg.php?user_id=15145
+@c Identifier of the OpenPGP keys used to sign tarballs and such.
+@set OPENPGP-SIGNING-KEY-ID-1 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 @c ludo
+@set OPENPGP-SIGNING-KEY-URL-1 https://sv.gnu.org/people/viewgpg.php?user_id=15145
+@set OPENPGP-SIGNING-KEY-ID-2 27D586A4F8900854329FF09F1260E46482E63562 @c maxim
+@set OPENPGP-SIGNING-KEY-URL-2 https://sv.gnu.org/people/viewgpg.php?user_id=127547
 
 @c Base URL for downloads.
 @set BASE-URL https://ftp.gnu.org/gnu/guix
@@ -649,11 +651,13 @@ $ wget @value{BASE-URL}/guix-binary-@value{VERSION}.x86_64-linux.tar.xz.sig
 $ gpg --verify guix-binary-@value{VERSION}.x86_64-linux.tar.xz.sig
 @end example
 
-If that command fails because you do not have the required public key,
-then run this command to import it:
+If that command fails because you do not have the required public keys,
+then run these commands to import them:
 
 @example
-$ wget '@value{OPENPGP-SIGNING-KEY-URL}' \
+$ wget '@value{OPENPGP-SIGNING-KEY-URL-1}' \
+      -qO - | gpg --import -
+$ wget '@value{OPENPGP-SIGNING-KEY-URL-2}' \
       -qO - | gpg --import -
 @end example
 
@@ -2119,11 +2123,13 @@ $ wget @value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.
 $ gpg --verify guix-system-install-@value{VERSION}.x86_64-linux.iso.xz.sig
 @end example
 
-If that command fails because you do not have the required public key,
-then run this command to import it:
+If that command fails because you do not have the required public keys,
+then run these commands to import them:
 
 @example
-$ wget @value{OPENPGP-SIGNING-KEY-URL} \
+$ wget @value{OPENPGP-SIGNING-KEY-URL-1} \
+      -qO - | gpg --import -
+$ wget @value{OPENPGP-SIGNING-KEY-URL-2} \
       -qO - | gpg --import -
 @end example
 
@@ -11912,7 +11918,7 @@ Likewise, you can fetch keys to a specific keybox file like this:
 
 @example
 gpg --no-default-keyring --keyring mykeyring.kbx \
-  --recv-keys @value{OPENPGP-SIGNING-KEY-ID}
+  --recv-keys @value{OPENPGP-SIGNING-KEY-ID-1}
 @end example
 
 @xref{GPG Configuration Options, @option{--keyring},, gnupg, Using the GNU
-- 
2.31.1

Re: GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

Hi Vagrant,

Vagrant Cascadian <vagrant@debian.org> writes:

> On 2021-05-01, Maxim Cournoyer wrote:
>> A first RC for the upcoming 1.3.0 release is now available for testing:
>
> Thanks for all the hard work getting rc1 ready!
>
>
> Also soon coming to a Debian mirror near you:
>
>   https://buildd.debian.org/status/package.php?p=guix&suite=experimental

Swift!  On all 5 architectures supported!  Nice work :-).

Maxim

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

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

On Sat, May 01, 2021 at 05:25:45PM -0400, Leo Famulari wrote:
> Maybe we should update the manual to mention "1.3.0rc1" and the correct
> key.

I've attached a patch.

> >   1. Testing the binary tarball on the distro of your choice.  You can
> >      download <https://guix.gnu.org/install.sh>.  Uncomment the
> >      ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
> >      should pick up 1.3.0rc1 automatically.
> 
> The install.sh script also recommends installing Ludo's key, but of
> course fails to verify the signature with it. After installing Ludo's
> key, the installer does suggest the correct key — Maxim's.

I looked at 'guix-install.sh' and see that it recommends both Ludo's and
Maxim's keys. It's not great that it fails, recommends users to download
Ludo's key, and then fails again.

I tried re-sorting the array so that Maxim's key is first but, no matter
what, it still requires every key in the GPG_SIGNING_KEY array, and the
user will have to try the script three times before it can succeed. If
the next release is signed by someone besides Ludo or Maxim, then the
script will require four runs, etc.

It's annoying but hard to work around because the script is distributed
via that unversioned URL show above.

Ideas?

[-- Attachment #2: 0001-doc-Update-the-release-signing-key-for-1.3.0rc1.patch --]
[-- Type: text/plain, Size: 1028 bytes --]

From 205c786b985bd7cb2754aadf3adf91e1401b9d1b Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Sat, 1 May 2021 23:54:03 -0400
Subject: [PATCH] doc: Update the release signing key for 1.3.0rc1.

* doc/guix.texi (OPENPGP-SIGNING-KEY-ID): Use Maxim Cournoyer's key.
(OPENPGP-SIGNING-KEY-URL): Adjust accordingly.
---
 doc/guix.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index dbea5cadcb..3ca681a48b 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -10,8 +10,8 @@
 @include version.texi
 
 @c Identifier of the OpenPGP key used to sign tarballs and such.
-@set OPENPGP-SIGNING-KEY-ID 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
-@set OPENPGP-SIGNING-KEY-URL https://sv.gnu.org/people/viewgpg.php?user_id=15145
+@set OPENPGP-SIGNING-KEY-ID 27D586A4F8900854329FF09F1260E46482E63562
+@set OPENPGP-SIGNING-KEY-URL https://sv.gnu.org/people/viewgpg.php?user_id=127547
 
 @c Base URL for downloads.
 @set BASE-URL https://ftp.gnu.org/gnu/guix
-- 
2.31.1

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Sat, May 01, 2021 at 10:52:18PM -0400, Maxim Cournoyer wrote:
> > https://guix.gnu.org/manual/en/
> > https://guix.gnu.org/manual/devel/en/
> 
> Thank you for pointing that issue; I caught the problem with
> guix-install.sh before posting, but overlooked that one.  As you
> pointed, that won't be reflected on our website, but I agree that having
> the new key covered in the devel manual (master branch) is already an
> improvement.  The attached patch augments the manual to cover for the
> new key.  Let me know if it looks good to you.  If it does, I will push
> it to the master branch (IIUC we can't push this change to the
> version-1.3.0 branch as that would break the string freeze there).

The "devel" manual on the website reflects the master branch. So, there
will be a web-based location where users can find these instructions
documented immediately.

The non-"devel" website manual is tied to the release tag. So, we have
no choice but to make these changes on the version-1.3.0 branch, right?
Or else the "1.3.0" manual will mention the wrong signing key?

Your patch looks good except that the instructions about 'mykeyring.kbx'
are a no-op: The created keyring contains no keys afterwards. This is
with GnuPG 2.2.27 from current Guix. We should just remove these
instructions since "--recv-keys" almost never works these days, since
the keyserver network collapsed. For example:

------
$ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 27D586A4F8900854329FF09F1260E46482E63562 
gpg: keybox '/home/leo/.gnupg/mykeyring.kbx' created            
gpg: WARNING: server 'dirmngr' is older than us (2.2.12 < 2.2.27)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg: key 1260E46482E63562: no user ID
gpg: Total number processed: 1
$ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5  
gpg: WARNING: server 'dirmngr' is older than us (2.2.12 < 2.2.27)                                                        
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg: key 090B11993D9AEBB5: no user ID
gpg: Total number processed: 1
$ cat ~/.gnupg/mykeyring.kbx 
 KBXf`)y`)y%
$ wc -c ~/.gnupg/mykeyring.kbx
32 /home/leo/.gnupg/mykeyring.kbx
------

As you can see, it does not contain two PGP keys.

> Are you sure you downloaded it from https://guix.gnu.org/install.sh
> (which just redirects to the current copy on the master branch) ?

Yes.

> Since commit e64af2060e8cfa48e74b887281acb3fd4c7e7781 (which was made
> just before writing the original message), it checks for both keys.

It checks for them one at a time, failing after each missing key. I
described it here:

https://lists.gnu.org/archive/html/guix-devel/2021-05/msg00039.html

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Sun, May 02, 2021 at 12:05:42AM -0400, Leo Famulari wrote:
> I've attached a patch.

I sent this before seeing your patch. Feel free to disregard it.

Re: GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

Hi Leo,

Leo Famulari <leo@famulari.name> writes:

> On Sat, May 01, 2021 at 05:25:45PM -0400, Leo Famulari wrote:
>> Maybe we should update the manual to mention "1.3.0rc1" and the correct
>> key.
>
> I've attached a patch.
>
>> >   1. Testing the binary tarball on the distro of your choice.  You can
>> >      download <https://guix.gnu.org/install.sh>.  Uncomment the
>> >      ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
>> >      should pick up 1.3.0rc1 automatically.
>> 
>> The install.sh script also recommends installing Ludo's key, but of
>> course fails to verify the signature with it. After installing Ludo's
>> key, the installer does suggest the correct key — Maxim's.
>
> I looked at 'guix-install.sh' and see that it recommends both Ludo's and
> Maxim's keys. It's not great that it fails, recommends users to download
> Ludo's key, and then fails again.

It should fail only once (as it currently would if Ludo's key was
missing), and display two messages/two commands instead of one to get
the missing keys.  This is because we exit after the loop, based on the
exit_flag variable value we set in the loop.  Did it not behave that way
for you?

> I tried re-sorting the array so that Maxim's key is first but, no matter
> what, it still requires every key in the GPG_SIGNING_KEY array, and the
> user will have to try the script three times before it can succeed. If
> the next release is signed by someone besides Ludo or Maxim, then the
> script will require four runs, etc.

Could you help me understand what is failing?  I tested with no keys, or
with just Ludovic's key, and it was working as intended when attempting
to install the 1.3.0rc1 release (e.g., aborting + printing all the keys
missing with the accompanying suggested commands to resolve the issue,
and proceed with the installation normally thereafter)

Thank you!

Maxim

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Sun, May 02, 2021 at 02:45:18PM -0400, Maxim Cournoyer wrote:
> It should fail only once (as it currently would if Ludo's key was
> missing), and display two messages/two commands instead of one to get
> the missing keys.  This is because we exit after the loop, based on the
> exit_flag variable value we set in the loop.  Did it not behave that way
> for you?

I did not think that it had, but I tried it again just now, and it
worked as you described.

I noticed that it was 404 an hour or two ago. Maybe the revision of the
script being served by the website was cached and obsolete or something.

Anyways, it seems fine now!

We just need to update the manual on the version-1.3.0 branch (and
probably master too).

Re: GNU Guix 1.3.0rc1 available for testing!

[Tissevert]

Hi !!

I've just given the binary tarball a spin on Devuan. Worked almost flawlessly
(daemonize wasn't installed and I missed the part when it was mentioned because
I was a bit in a hurry but apart from that the overall experience was great —
the guix text art was surprising in a good kind of way).

I got the warning about the GPG keys, and I confirm I got a single warning for
both keys at once with a very simple click'n'paste command to import the keys
and fix the problem.

Once installed and the daemon started manually, it looks like it works (at
least the simple things I use do). To answer Leo's question if I understand it
correctly, I can guarantee you that absolutely no guix-related user or group
existed before I ran the script, and they have been successfully created (10
guix builder users named `printf "guixbuilder%02d" <$> [1..10]` and 1 group named
guixbuild).

It's so cool to be able to use Guix on that box (I'll soon reinstall it with
Guix I think but in the meantime it's there and that's handy). Thanks !


Tissevert

On Sat, 01 May 2021 01:45:57 -0400
Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> Hello Guix!
> 
> A first RC for the upcoming 1.3.0 release is now available for
> testing:
> 
>   source:
>     https://alpha.gnu.org/gnu/guix/guix-1.3.0rc1.tar.gz
> 
>   binary tarball (to install on a “foreign distro”):
>     https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.aarch64-linux.tar.xz
>     https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.armhf-linux.tar.xz
>     https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.i686-linux.tar.xz
>     https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz
>     https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz
> 
>   system installation:
>     https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.i686-linux.iso.xz
>     https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.x86_64-linux.iso.xz
> 
>   virtual machine image:
>     https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz
> 
> SHA256 hashes:
> 
> 46525e84d2a1d30a53bb40569de23bb1813b8df78731d09b5eac977818106ea7
> guix-1.3.0rc1.tar.gz
> 2427e73f5f18c51446174cd230b6dc19c8461838641bec6f66761537e7aa7ad4
> guix-binary-1.3.0rc1.aarch64-linux.tar.xz
> 89028139d049e1a868d41c5d1155f6b3be1b1b0407d93bfa86b7c713a87c1daf
> guix-binary-1.3.0rc1.armhf-linux.tar.xz
> 5da4edf9075c87d575d653140b53fe316305f94b58179aa935af223f037b36c2
> guix-binary-1.3.0rc1.i686-linux.tar.xz
> f7c2a42f9f48fc6b2d7ba672ed49c3a6fc483cb3fbe261a8a79385b8381205ec
> guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz
> 3348ec2fd116ed97c1806f8eac777ab2f7cff2b466b7c0dc5c2d1a904e4395f7
> guix-binary-1.3.0rc1.x86_64-linux.tar.xz
> 429deb5af3a956e7530cd0ed4cab7d5b13a7f1d22a0fe690f6714ab89a846db6
> guix-system-install-1.3.0rc1.i686-linux.iso.xz
> a1772a8d08729471e7b1c04ac4d9213f4db077458aeacc59d14ff9f2399357b2
> guix-system-install-1.3.0rc1.x86_64-linux.iso.xz
> 58ccabbc61cd00d9b1ec1f417360827aa2f8428567f1cfb0a83dc2191e67897e
> guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz
> 
> All these files have an associated ‘.sig’, an OpenPGP signature that
> you can verify as explained at
> <https://guix.gnu.org/manual/en/html_node/Binary-Installation.html>.
> 
> You can help by:
> 
>   1. Testing the binary tarball on the distro of your choice.  You can
>      download <https://guix.gnu.org/install.sh>.  Uncomment the
>      ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
>      should pick up 1.3.0rc1 automatically.
> 
>   2. Testing the graphical installer of Guix System.
> 
>   3. Testing the VM image.
> 
> In any case, please report success, failure, and annoyances in this
> thread.
> 
> The remaining outstanding issues, which you can track here [0], are as
> follow and affect the installer:
> 
> 47567 Installer crash in 'uuid->string' for a FAT16 partition
> 44872 Installer crash: 'uuid->string' is passed #f in lieu of a UUID
> 
> If everything goes well, the final release is planned for the 10th of
> May, which gives us about a week to test and fix any remaining issues.
> 
> Thanks in advance!
> 
> Maxim
> 
> [0]  http://issues.guix.gnu.org/47297
> 

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Mon, May 03, 2021 at 09:38:56PM +0200, Tissevert wrote:
> I've just given the binary tarball a spin on Devuan. Worked almost flawlessly
> (daemonize wasn't installed and I missed the part when it was mentioned because
> I was a bit in a hurry but apart from that the overall experience was great —
> the guix text art was surprising in a good kind of way).

I think that a big part of why we offer the SysV-init "/etc/init.d"
service management script is to serve Devuan — there are not many
distros using that style of service management anymore. If `daemonize`
is not available by default on Devuan, I wonder if there is some other
way we should be writing the script.

Can you check some "Devuan provided" scripts in '/etc/init.d' and see if
they use a different method of daemonizing things?
 
> I got the warning about the GPG keys, and I confirm I got a single warning for
> both keys at once with a very simple click'n'paste command to import the keys
> and fix the problem.

Great!

> Once installed and the daemon started manually, it looks like it works (at
> least the simple things I use do). To answer Leo's question if I understand it
> correctly, I can guarantee you that absolutely no guix-related user or group
> existed before I ran the script, and they have been successfully created (10
> guix builder users named `printf "guixbuilder%02d" <$> [1..10]` and 1 group named
> guixbuild).

Awesome, thanks for checking! That sounds exactly right.

Re: GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

Hi Leo,

Thanks for the feedback!

Leo Famulari <leo@famulari.name> writes:

> On Sat, May 01, 2021 at 10:52:18PM -0400, Maxim Cournoyer wrote:
>> > https://guix.gnu.org/manual/en/
>> > https://guix.gnu.org/manual/devel/en/
>> 
>> Thank you for pointing that issue; I caught the problem with
>> guix-install.sh before posting, but overlooked that one.  As you
>> pointed, that won't be reflected on our website, but I agree that having
>> the new key covered in the devel manual (master branch) is already an
>> improvement.  The attached patch augments the manual to cover for the
>> new key.  Let me know if it looks good to you.  If it does, I will push
>> it to the master branch (IIUC we can't push this change to the
>> version-1.3.0 branch as that would break the string freeze there).

I've clarified this with Julien, our Natural Language Support (NLS)
expert, and they said: "As long as you change only examples, @code, @url
etc, fragments I should be able to do the change manually in the po
files even if I don't know the language".  So this mean we can carefully
update some very limited parts of the manual; Julien will do one last
pass to adjust the .po files accordingly before the release.

[...]

> Your patch looks good except that the instructions about 'mykeyring.kbx'
> are a no-op: The created keyring contains no keys afterwards. This is
> with GnuPG 2.2.27 from current Guix. We should just remove these
> instructions since "--recv-keys" almost never works these days, since
> the keyserver network collapsed. For example:
>
> ------
> $ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 27D586A4F8900854329FF09F1260E46482E63562 
> gpg: keybox '/home/leo/.gnupg/mykeyring.kbx' created            
> gpg: WARNING: server 'dirmngr' is older than us (2.2.12 < 2.2.27)
> gpg: Note: Outdated servers may lack important security fixes.
> gpg: Note: Use the command "gpgconf --kill all" to restart them.
> gpg: key 1260E46482E63562: no user ID
> gpg: Total number processed: 1
> $ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5  
> gpg: WARNING: server 'dirmngr' is older than us (2.2.12 < 2.2.27)                                                        
> gpg: Note: Outdated servers may lack important security fixes.
> gpg: Note: Use the command "gpgconf --kill all" to restart them.
> gpg: key 090B11993D9AEBB5: no user ID
> gpg: Total number processed: 1
> $ cat ~/.gnupg/mykeyring.kbx 
>  KBXf`)y`)y%
> $ wc -c ~/.gnupg/mykeyring.kbx
> 32 /home/leo/.gnupg/mykeyring.kbx
> ------
>
> As you can see, it does not contain two PGP keys.

FWIW, it worked for me:

$ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 27D586A4F8900854329FF09F1260E46482E63562
gpg: keybox '/home/maxim/.gnupg/mykeyring.kbx' created
gpg: key 1260E46482E63562: public key "Maxim Cournoyer <maxim.cournoyer@gmail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
maxim@hurd ~/src/guix [env]$ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5  
gpg: key 090B11993D9AEBB5: public key "Ludovic Courtès <ludo@gnu.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
maxim@hurd ~/src/guix [env]$ 
maxim@hurd ~/src/guix [env]$ wc -c ~/.gnupg/mykeyring.kbx
8781 /home/maxim/.gnupg/mykeyring.kbx

I had similar bad experience in the past, but my understanding was that
these problems had been (mostly?) resolved.  In case the default server
is often problematic, we could perhaps suggest an alternative that is
known to be reliable (if such an alternative exists?).

I've pushed a commit to master; and a slightly different one to
version-1.3.0 later, adjusting the commit so as the manual text is
untouched.

Thank you!

Maxim

Re: GNU Guix 1.3.0rc1 available for testing!

[Chris Marusich]

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

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

> A first RC for the upcoming 1.3.0 release is now available for testing

I tested the binary for powerpc64le-linux on a Debian 10 ppc64el system.
It seems to be behaving as well as I expected it to.  Thank you for
preparing it!

On powerpc64le-linux, the installation script worked fine (I ran it
while logged into the root account via "su --login").  However, when I
ran "guix pull" (without substitutes, of course, since those are not yet
available for this platform), I encountered an error:

  building /gnu/store/6ljrcy6pd2g5c02gkfdj1zxca3ybpg18-texlive-latex-amscls-51265.drv...
  - 'build' phaseBacktrace:
            13 (primitive-load "/gnu/store/ylynparc7pjhyxkcs9p1kwqa09an3vba-compute-guix-derivation")
  In ice-9/eval.scm:
      155:9 12 (_ _)
      159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#<directory (guile-u?> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
  In ice-9/boot-9.scm:
      152:2 10 (with-fluid* _ _ _)
      152:2  9 (with-fluid* _ _ _)
  In ./guix/store.scm:
    2066:24  8 (run-with-store #<store-connection 256.99 7fff94a063c0> _ #:guile-for-build _ #:system _ #:target _)
     1900:8  7 (_ _)
  In ./guix/gexp.scm:
     256:18  6 (_ _)
     1137:2  5 (_ _)
     1003:2  4 (_ _)
      849:4  3 (_ _)
  In ./guix/store.scm:
    1948:12  2 (_ #<store-connection 256.99 7fff94a063c0>)
     1362:5  1 (map/accumulate-builds #<store-connection 256.99 7fff94a063c0> _ _)
    1373:15  0 (_ #<store-connection 256.99 7fff94a063c0> _ _)

  ./guix/store.scm:1373:15: ERROR:
    1. &store-protocol-error:
        message: "build of `/gnu/store/xfkrpagvnpc4xz43b6za80qrvnlsb8f0-po4a-0.61.drv' failed"
        status: 100
  guix pull: error: You found a bug: the program '/gnu/store/ylynparc7pjhyxkcs9p1kwqa09an3vba-compute-guix-derivation'
  failed to compute the derivation for Guix (version: "fcd002ccfa3a2bf28a9d05ab2992464afc6e5fca"; system: "powerpc64le-linux";
  host version: "1.3.0rc1"; pull-version: 1).
  Please report it by email to <bug-guix@gnu.org>.

When I tried building
/gnu/store/xfkrpagvnpc4xz43b6za80qrvnlsb8f0-po4a-0.61.drv a second time,
it succeeded:

  guix build --cores=1 \
             --max-jobs=1 \
             --keep-failed \
             /gnu/store/xfkrpagvnpc4xz43b6za80qrvnlsb8f0-po4a-0.61.drv

I was then able to successfully run "guix pull" a second time.  After
that, I successfully built GNU Hello via "guix build hello" and ran it.
So, everything seems OK, except for the non-deterministic po4a failure.

I wonder if the po4a failure affects other architectures, but maybe it
just isn't noticed because most people use substitutes.  As far as I can
tell, the po4a failure has not been reported in our bug tracker.  If I
can reproduce the issue, I'll open a bug report for it.

-- 
Chris

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

Re: GNU Guix 1.3.0rc1 available for testing!

[Tissevert]

Hi !!

On Mon, 3 May 2021 20:34:54 -0400
Leo Famulari <leo@famulari.name> wrote:
> I think that a big part of why we offer the SysV-init "/etc/init.d"
> service management script is to serve Devuan — there are not many
> distros using that style of service management anymore. If `daemonize`
> is not available by default on Devuan, I wonder if there is some other
> way we should be writing the script.
> 
> Can you check some "Devuan provided" scripts in '/etc/init.d' and see
> if they use a different method of daemonizing things?

Oh really ? I didn't think devuan was well-known enough for it to have an
impact on a design choice like this. Well no other of the 69 scripts I have in
/etc/init.d use daemonize. Most of them use /sbin/start-stop-daemon, although
the point of running Devuan was to have runit, but it's so well hidden you
wouldn't know it's PID 1 here… which is the main reason why I'm giving up on
Devuan, I came for my favourite, easy to use, init system, not for some
compat-bloat over it that end up hiding the best feature. So if this script is
only for Devuan, I think a proper runit daemon may be better.

Regards,

Tissevert

Re: GNU Guix 1.3.0rc1 available for testing!

[Vagrant Cascadian]

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

On 2021-05-03, Leo Famulari wrote:
> On Mon, May 03, 2021 at 09:38:56PM +0200, Tissevert wrote:
>> I've just given the binary tarball a spin on Devuan. Worked almost flawlessly
>> (daemonize wasn't installed and I missed the part when it was mentioned because
>> I was a bit in a hurry but apart from that the overall experience was great —
>> the guix text art was surprising in a good kind of way).
>
> I think that a big part of why we offer the SysV-init "/etc/init.d"
> service management script is to serve Devuan — there are not many
> distros using that style of service management anymore.

Out of the *five* bug reports the guix packages in Debian received,
*two* of them were related to using SysV init (or at least not using
systemd):

  https://bugs.debian.org/974751
  https://bugs.debian.org/983248

So while Debian defaults to systemd, there is still the ability to
choose between init systems, and some people do explore that option.

I also just noticed some openrc scripts available too...


> If `daemonize` is not available by default on Devuan, I wonder if
> there is some other way we should be writing the script.

Yeah, not sure what best practices are for SysV init scripts these
days. For Debian I just documented that users of SysV in debian should
install daemonize; in future versions I may make it a soft alternate
dependency to the relevent systemd packages.


live well,
  vagrant

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

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Wed, May 05, 2021 at 10:01:39AM -0700, Vagrant Cascadian wrote:
> Yeah, not sure what best practices are for SysV init scripts these
> days. For Debian I just documented that users of SysV in debian should
> install daemonize; in future versions I may make it a soft alternate
> dependency to the relevent systemd packages.

Somebody should figure out how these things are supposed to work and
suggest adjustments the script. If it doesn't work on other Debian or
Devuan, that leaves Slackware as the only other significant distro that
it could work on.