GNU Guix 1.2.0rc2 available for testing!

GNU Guix 1.2.0rc2 available for testing!

[Ludovic Courtès]

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

Hello Guix!

Here’s the second and hopefully last release candidate for 1.2.0:

  source:
    https://alpha.gnu.org/gnu/guix/guix-1.2.0rc2.tar.gz

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

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

  virtual machine image:
    https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.2.0rc2.x86_64-linux.xz

SHA256 hashes:

  6d4cc24c6849e6d72b0ad8c0f7e32f668ff42e7fb226e828e201f837de0bbeb9  guix-1.2.0rc2.tar.gz
  d6df60b839112cbbb6d8d1f87f644cc2752611fd6ce443bf361de4bd8c70df1e  guix-binary-1.2.0rc2.aarch64-linux.tar.xz
  2528cf338fcf3e346225b0caa4bc1186964e01a86c0e7edcb44daea6384c791d  guix-binary-1.2.0rc2.armhf-linux.tar.xz
  eb735373f526329d09452ed6a88c88b7cf432533677fe56b40a96a0d822b86b8  guix-binary-1.2.0rc2.i686-linux.tar.xz
  f58248b6ea89ef1685826dd1e6ac2198771836cddf7449fd38d6242e03127bc9  guix-binary-1.2.0rc2.x86_64-linux.tar.xz
  1a9aa981c271fc951ae8a4793599f6e52a1689f12b2923c26556c94e35230f3e  guix-system-install-1.2.0rc2.i686-linux.iso.xz
  c90c5608f9926b6c6cacbf343757c2dcdb558062c3ddc92cb18c6c8df9874199  guix-system-install-1.2.0rc2.x86_64-linux.iso.xz
  bd9048fe5d22c0ca318e8734cb18ec895d35d6da88ee6b909189e02895a65211  guix-system-vm-image-1.2.0rc2.x86_64-linux.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.2.0rc2 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.

If everything goes well, let’s release on Monday 23rd.

You can also check the ‘NEWS’ file and the draft blog post at
<https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.2.0-released.md>
to make sure your favorite feature is mentioned and/or to discuss the
highlights in the blog post.

Thanks in advance!

Ludo’.

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

Re: GNU Guix 1.2.0rc2 available for testing!

[zimoun]

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

Hi Ludo,

On Wed, 18 Nov 2020 at 19:53, Ludovic Courtès <ludo@gnu.org> wrote:

> If everything goes well, let’s release on Monday 23rd.

Birthday release? :-)


> You can also check the ‘NEWS’ file and the draft blog post at
> <https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.2.0-released.md>
> to make sure your favorite feature is mentioned and/or to discuss the
> highlights in the blog post.

Attached the first rough draft blog post for GuixHPC blog; I forgot my
password to push to the INRIA forge… and too late to wait the reset. :-)


All the best,
simon
--

[-- Attachment #2: draft-hpc --]
[-- Type: text/x-diff, Size: 6696 bytes --]

From 2823439d49d83e35ae30df51dcd38d6fb86cd5b7 Mon Sep 17 00:00:00 2001
From: Simon Tournier <simon.tournier@u-paris.fr>
Date: Thu, 19 Nov 2020 03:10:55 +0100
Subject: [PATCH] Add draft notes for 1.2.0.

* drafts/hpc-reproducible-research-in-guix-1.2.0.md: New file.
---
 ...hpc-reproducible-research-in-guix-1.2.0.md | 132 ++++++++++++++++++
 1 file changed, 132 insertions(+)
 create mode 100644 drafts/hpc-reproducible-research-in-guix-1.2.0.md

diff --git a/drafts/hpc-reproducible-research-in-guix-1.2.0.md b/drafts/hpc-reproducible-research-in-guix-1.2.0.md
new file mode 100644
index 0000000..e3c997a
--- /dev/null
+++ b/drafts/hpc-reproducible-research-in-guix-1.2.0.md
@@ -0,0 +1,132 @@
+title: DRAFT HPC & reproducible research in Guix 1.2.0
+date: 2020-11-19 02:00:00
+author: Simon Tournier
+slug: hpc-reproducible-research-in-guix-1.2.0
+tags: packages, releases
+---
+
+Version 1.2.0 of Guix was [announced
+yesterday](https://guix.gnu.org/blog/2020/gnu-guix-1.2.0-released/).  As
+the announcement points out, some 200 people contributed more than
+10,000 commits since the previous release.  This post focuses on
+important changes for HPC users, admins, and scientists made since
+version 1.1.0 was released in April 2020.
+
+# Reproducible science workflows
+
+We’re giving users more flexibility on the command line, with the
+addition of three [*package transformation
+options*](https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html):
+`--with-debug-info` ([always debug in good
+conditions](https://guix.gnu.org/manual/devel/en/html_node/Rebuilding-Debug-Info.html)!),
+`--with-c-toolchain`, and `--without-tests`.  Consider this example:
+
+```
+guix build octave-cli \
+  --with-c-toolchain=fftw=gcc-toolchain@10 \
+  --with-c-toolchain=fftwf=gcc-toolchain@10
+```
+
+The command above builds a variant of the fftw and fftwf packages using
+version 10 of gcc-toolchain instead of the default tool chain, and then builds
+a variant of the GNU Octave command-line interface using them. GNU Octave
+itself is also built with gcc-toolchain@10.
+
+This other example builds the Hardware Locality (hwloc) library and its
+dependents up to intel-mpi-benchmarks with the Clang C compiler:
+
+```
+guix build --with-c-toolchain=hwloc=clang-toolchain \
+           intel-mpi-benchmarks
+```
+
+On the side of long-term archival of all the software Guix packages refer to,
+Guix now serves the file [`sources.json`](http://guix.gnu.org/sources.json)
+that is ingested by [Software Heritage](https://softwareheritage.org) via the
+[nixguix
+loader](https://docs.softwareheritage.org/devel/_modules/swh/loader/package/nixguix.html).
+In addition to the “archival” check of `guix lint` which sends a “save”
+request to Software Heritage for the specified packages.  More packages are
+continuously archived.
+
+The new option `--path` of [`guix
+graph`](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-graph.html),
+shows the shortest path between two nodes.  The example below shows the
+shortest path between the packages gmsh and cunit:
+
+```
+guix graph --path gmsh cunit
+gmsh@4.6.0
+metis@5.1.0
+openblas@0.3.9
+cunit@2.1-3
+
+```
+
+Moreover, the command [`guix
+repl`](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-repl.html)
+can now be passed a script which ease [package exploratinon in
+Guile](https://hpc.guix.info/blog/2020/01/reproducible-computations-with-guix/)
+especially when dealing with the new Scheme `(guix transformation)` module for
+package transformations.  And the section [“Programming
+Interface”](https://guix.gnu.org/manual/devel/en/html_node/Programming-Interface.html)
+of the *reference manual* has been greatly expounded.
+
+The [`guix
+pack`](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-pack.html#Invoking-guix-pack)
+command creates “application bundles” that can be used to deploy software on
+machines that do not run Guix (yet!), such as HPC clusters. Since its
+[inception in
+2017](https://guix.gnu.org/blog/2017/creating-bundles-with-guix-pack/), it has
+seen a number of improvements.  The relocatable packs can be now [faster by
+the addition of the Fakechroot
+engine](https://hpc.guix.info/blog/2020/05/faster-relocatable-packs-with-fakechroot/).
+
+
+# Packages
+
+Here are highlights among the 2,179 packages added and 4,487 packages
+upgraded since the previous release:
+
+ - [Gmsh](https://hpc.guix.info/package/gmsh) has been upgraded to 4.6.0.
+ - [MPICH](https://hpc.guix.info/package/mpich) is now at 3.3.2.
+ - [Open MPI](https://hpc.guix.info/package/openmpi) is now at 4.0.5.
+ - [GCC](https://hpc.guix.info/package/gcc-toolchain) 10.2.0 is
+    available and [LLVM, Clang](https://hpc.guix.info/package/clang-toolchain)
+    11.0.0 too.
+ - [Julia](https://hpc.guix.info/package/julia) has been upgraded to
+    1.5.2.
+ - [MPI4PY](https://hpc.guix.info/package/python-mpi4py) is at
+    3.0.3.
+ - For statisticians, there’s now a total of 1,488 R packages, many of
+    which comes from [Bioconductor](https://www.bioconductor.org/) 3.11.
+    
+Last but not least, *the manual is fully translated* to
+[French](https://guix.gnu.org/manual/fr/html_node/),
+[German](https://guix.gnu.org/manual/de/html_node/), and
+[Spanish](https://guix.gnu.org/manual/es/html_node/), with partial
+translations in [Russian](https://guix.gnu.org/manual/ru/html_node/) and
+[Chinese](https://guix.gnu.org/manual/zh-cn/html_node/).
+
+Do not miss the [release
+notes](https://guix.gnu.org/blog/2020/gnu-guix-1.2.0-released/) for more.
+
+### Try it!
+
+We want Guix to be accessible and useful to a broad audience and that
+has again been a guiding principle for this release.  The [graphical
+system
+installer](https://guix.gnu.org/en/videos/system-graphical-installer/)
+and the [script to install Guix on another
+distro](https://guix.gnu.org/manual/en/html_node/Binary-Installation.html)
+have both received bug fixes and usability improvements.  First-time
+users will appreciate the fact that `guix help` now gives a clear
+overview of the available commands, that `guix` commands are less
+verbose by default, and that `guix pull` displays a progress bar as it
+updates its Git checkout.
+
+We’ve been told [you may soon be able to `apt install
+guix`](https://packages.debian.org/guix) if you’re on Debian or a derivative
+distro!—[get in touch with us](https://guix.gnu.org/en/contact/).
+
+Enjoy the new release!

base-commit: 67a725bebe63d3933ae133da2bc5d778994dbc39
-- 
2.28.0

Re: GNU Guix 1.2.0rc2 available for testing!

[Pierre Neidhardt]

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

Hi!

zimoun <zimon.toutoune@gmail.com> writes:

> +`--with-c-toolchain`, and `--without-tests`.  Consider this example:

Oh, I didn't notice we had a --without-tests now, good to know!

I remember asking about such an option a while back, but this was
refused on the ground that it would encourage untested builds if I
recall correctly (I can look up the email again if you insist ;p).

So what's the rationale behind this change of position?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: GNU Guix 1.2.0rc2 available for testing!

[Ryan Prior]

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

On November 19, 2020, Pierre Neidhardt <mail@ambrevar.xyz> wrote:
> [--without-tests] would encourage untested builds if I
> recall correctly

That may have been a concern (I wasn't part of the conversation) but I
don't see how the current implementation could do that. If a normal
"guix build foo" fails, then it's a busted package period.

I'm glad for the "without-tests" option because when I'm working on
packages with a test suite that takes more than a few seconds, I like to
make sure that the rest of everything is working before I start running
the tests.

Another thing I'd like is an option to build a package reusing the state
from a previous build. If a package I'm working on takes a minute or
longer to build and I'm having some sort of difficulty, it's obnoxious
to wait for that to complete again after every cycle. It could be near
instantaneous if I could re-use a cached build, which is doable in
Docker, Earthly, and other containerized build systems.

[-- Attachment #2: Type: text/html, Size: 3305 bytes --]

Re: GNU Guix 1.2.0rc2 available for testing!

[zimoun]

Hi Ludo,

On Thu, 19 Nov 2020 at 03:24, zimoun <zimon.toutoune@gmail.com> wrote:

>> You can also check the ‘NEWS’ file and the draft blog post at
>> <https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.2.0-released.md>
>> to make sure your favorite feature is mentioned and/or to discuss the
>> highlights in the blog post.
>
> Attached the first rough draft blog post for GuixHPC blog; I forgot my
> password to push to the INRIA forge… and too late to wait the reset. :-)

Draft post pushed to GuixHPC website.


Cheers,
simon

Re: GNU Guix 1.2.0rc2 available for testing!

[Pierre Neidhardt]

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

Ryan Prior <ryanprior@hey.com> writes:

> I'm glad for the "without-tests" option because when I'm working on
> packages with a test suite that takes more than a few seconds, I like to
> make sure that the rest of everything is working before I start running
> the tests.

Exactly, that was my original thought.

> Another thing I'd like is an option to build a package reusing the state
> from a previous build. If a package I'm working on takes a minute or
> longer to build and I'm having some sort of difficulty, it's obnoxious
> to wait for that to complete again after every cycle. It could be near
> instantaneous if I could re-use a cached build, which is doable in
> Docker, Earthly, and other containerized build systems.

You can kind of do that manually now.
Build with the -K option and when it fails, drop to the temporary
directly, source the `environment-variables` file, fix the code or calls
then proceed.

Obviously reusing cached build would be nicer.

Maybe even better would be debugger access to the daemon.  On build
error we would be dropped in the debugger in the stack frame where it
errored.  We would fix it, then continue, in the most traditional Lisp
fashion!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

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

Re: GNU Guix 1.2.0rc2 available for testing!

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> On Thu, 19 Nov 2020 at 03:24, zimoun <zimon.toutoune@gmail.com> wrote:
>
>>> You can also check the ‘NEWS’ file and the draft blog post at
>>> <https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/gnu-guix-1.2.0-released.md>
>>> to make sure your favorite feature is mentioned and/or to discuss the
>>> highlights in the blog post.
>>
>> Attached the first rough draft blog post for GuixHPC blog; I forgot my
>> password to push to the INRIA forge… and too late to wait the reset. :-)
>
> Draft post pushed to GuixHPC website.

Awesome.  I’ll take a closer look before we publish but it LGTM.

Thanks a lot!

Ludo’.

Re: GNU Guix 1.2.0rc2 available for testing!

[Maxim Cournoyer]

Hey,

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Ryan Prior <ryanprior@hey.com> writes:
>
>> I'm glad for the "without-tests" option because when I'm working on
>> packages with a test suite that takes more than a few seconds, I like to
>> make sure that the rest of everything is working before I start running
>> the tests.
>
> Exactly, that was my original thought.
>
>> Another thing I'd like is an option to build a package reusing the state
>> from a previous build. If a package I'm working on takes a minute or
>> longer to build and I'm having some sort of difficulty, it's obnoxious
>> to wait for that to complete again after every cycle. It could be near
>> instantaneous if I could re-use a cached build, which is doable in
>> Docker, Earthly, and other containerized build systems.
>
> You can kind of do that manually now.
> Build with the -K option and when it fails, drop to the temporary
> directly, source the `environment-variables` file, fix the code or calls
> then proceed.
>
> Obviously reusing cached build would be nicer.
>
> Maybe even better would be debugger access to the daemon.  On build
> error we would be dropped in the debugger in the stack frame where it
> errored.  We would fix it, then continue, in the most traditional Lisp
> fashion!

I was thinking about such a thing recently; it would indeed be nice to
be able to debug in the "real" build environment.  Sometimes a test fail
just in the "real" build environment; so being able to debug it in situ
could be useful.

Maxim