Re: core-updates call for testing

[Jack Hill]

On Fri, 24 Apr 2020, Marius Bakke wrote:


The "core-updates" branch is ready for testing!


Hi,

I've reconfigured my user profile and system from the core-updates branch. 
I use a GNOME desktop session. However, I don't use too many fancy 
features. I mostly use GNOME-Terminal, GNOME-Web, and Emacs. I also use 
some GNOME shell extensions.


I have not done extensive testing, but so far the desktop itself seems to 
be in working order, including cursory use of the GNOME settings dialog.


I have opened a bug, 40837, for GNOME-Web/epiphany, which is not working 
for me currently.


Best,
Jack

Re: core-updates call for testing

[sirgazil]

  On Fri, 24 Apr 2020 21:52:54 + Marius Bakke  
wrote 
 > sirgazil  writes:
 > 
 > > This time, one of my packages in a custom channel failed with "no code for 
 > > (term ansi-color)" (the package definition: 
 > > https://gitlab.com/sirgazil/guix-channel-x/-/blob/master/sirgazil-x/packages/guile.scm#L13).
 > >  This is not a new package in my profile, I've been using it for a long 
 > > time. Since both error seemed to be related to Guile, I removed all 
 > > Guile-related packages from my profile and tried upgrading again. This 
 > > time, the upgrade succeeded.
 > 
 > The reason your custom package failed is because it is using guile-2.2,
 > but the dependencies are built with Guile 3.0.

Thanks, I will do that.

Re: core-updates call for testing

[Marius Bakke]

sirgazil  writes:

> This time, one of my packages in a custom channel failed with "no code for 
> (term ansi-color)" (the package definition: 
> https://gitlab.com/sirgazil/guix-channel-x/-/blob/master/sirgazil-x/packages/guile.scm#L13).
>  This is not a new package in my profile, I've been using it for a long time. 
> Since both error seemed to be related to Guile, I removed all Guile-related 
> packages from my profile and tried upgrading again. This time, the upgrade 
> succeeded.

The reason your custom package failed is because it is using guile-2.2,
but the dependencies are built with Guile 3.0.

Changing the native-input to 'guile-3.0' should do the trick.  Otherwise
you can change the dependencies to 'guile2.2-json' and similar.

Thanks for testing!


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Jack Hill]

On Fri, 24 Apr 2020, Marius Bakke wrote:


The "core-updates" branch is ready for testing!


pdfpc currently fails to build on core-updates. Upgrading to the latest 
pdfpc release fixes the issue.


Patch upgrading pdfpc is at: https://issues.guix.gnu.org/issue/40829

Best,
Jack

Re: core-updates call for testing

[sirgazil]

  On Fri, 24 Apr 2020 16:54:19 + Gábor Boskovits  
wrote 
 > Hello,
 > 
 > Marius Bakke  ezt írta (időpont: 2020. ápr. 24., Pén 
 > 18:25):
 > 
 > This comes up from time to time. It is locale related. I think we tried to 
 > fix this several times. Fallback always helps. The not so nice solution 
 > would be to ensure this always builds locally.
 > Best regards,g_bor
 > sirgazil  writes:
 > 
 > >   On Fri, 24 Apr 2020 03:20:41 + sirgazil  
 > > wrote 
 > >  >   On Thu, 23 Apr 2020 23:24:23 + Marius Bakke 
 > >  wrote 
 > >  >  > Hello Guix!
 > >  >  > 
 > >  >  > The "core-updates" branch is ready for testing!  According to 'guix
 > >  >  > weather', the substitute coverage is slightly better than on "master"
 > >  >  > for x86_64.  You can get it by running:
 > >  >  > 
 > >  >  >   guix pull --branch=core-updates
 > >  >  > 
 > >  >  > Please try upgrading your profiles and systems and file bugs for
 > >  >  > anything that does not work for you.  GNOME users in particular are
 > >  >  > encouraged to try the new GNOME 3.34 and report any regressions.
 > >  > 
 > >  > I pulled from core-updates without problems, but "guix upgrade" failed.
 > >  > 
 > >  > First, when running "guix upgrade", I got the following message, which 
 > > I think is confusing because I use GNU, not Guix on a foreign distro:
 > >  > 
 > >  > $ guix upgrade
 > >  > guile: warning: failed to install locale
 > >  > hint: Consider installing the `glibc-utf8-locales' or 
 > > `glibc-locales' package and defining `GUIX_LOCPATH', along these lines:
 > >  > 
 > >  >  guix package -i glibc-utf8-locales
 > >  >  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
 > >  > 
 > >  > See the "Application Setup" section in the manual, for more info.
 > >  > 
 > >  > Then, everything was going alright, until building emacs-guix 
 > > derivation failed:
 > >  > 
 > >  > building 
 > > /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv...
 > >  > \ 'configure' phasebuilder for 
 > > `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed 
 > > with exit code 1
 > >  > build of 
 > > /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv failed
 > >  > View build log at 
 > > '/var/log/guix/drvs/6k/dl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv.bz2'.
 > >  > guix upgrade: error: build of 
 > > `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed
 > >  > 
 > >  > 
 > >  > The build log said:
 > >  > 
 > >  > starting phase `configure'
 > >  > source directory: 
 > > "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2" (relative from 
 > > build: ".")
 > >  > build directory: 
 > > "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2"
 > >  > configure flags: 
 > > ("CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 > >  
 > > "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 > >  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
 > > "--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
 > >  > configure: WARNING: unrecognized options: --enable-fast-install
 > >  > checking for a BSD-compatible install... 
 > > /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/install -c
 > >  > checking whether build environment is sane... yes
 > >  > checking for a thread-safe mkdir -p... 
 > > /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/mkdir -p
 > >  > checking for gawk... gawk
 > >  > checking whether make sets $(MAKE)... no
 > >  > checking whether make supports nested variables... yes
 > >  > checking whether make supports nested variables... (cached) yes
 > >  > checking for pkg-config... 
 > > /gnu/store/krpyb0zi700dcrg9cc8932w4v0qivdg9-pkg-config-0.29.2/bin/pkg-config
 > >  > checking pkg-config is at least version 0.9.0... yes
 > >  > configure: checking for guile 2.2
 > >  > configure: checking for guile 2.0
 > >  > configure: error: 
 > >  > No Guile development packages were found.
 > >  > 
 > >  > Please verify that you have Guile installed.  If you installed Guile
 > >  > from a binary distribution, please verify that you have also 
 > > installed
 > >  > the development packages.  If you installed it yourself, you might 
 > > need
 > >  > to adjust your PKG_CONFIG_PATH; see the pkg-config man page for 
 > > more.
 > >  > 
 > >  > command 
 > > "/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash" 
 > > "./configure" 
 > > "CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 > >  
 > > "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 > >  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
 > > "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" 

Re: core-updates call for testing

[sirgazil]

  On Fri, 24 Apr 2020 03:20:41 + sirgazil  wrote 
 >   On Thu, 23 Apr 2020 23:24:23 + Marius Bakke  
 > wrote 
 >  > Hello Guix!
 >  > 
 >  > The "core-updates" branch is ready for testing!  According to 'guix
 >  > weather', the substitute coverage is slightly better than on "master"
 >  > for x86_64.  You can get it by running:
 >  > 
 >  >   guix pull --branch=core-updates
 >  > 
 >  > Please try upgrading your profiles and systems and file bugs for
 >  > anything that does not work for you.  GNOME users in particular are
 >  > encouraged to try the new GNOME 3.34 and report any regressions.
 > 
 > I pulled from core-updates without problems, but "guix upgrade" failed.
 > 
 > First, when running "guix upgrade", I got the following message, which I 
 > think is confusing because I use GNU, not Guix on a foreign distro:
 > 
 > $ guix upgrade
 > guile: warning: failed to install locale
 > hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' 
 > package and defining `GUIX_LOCPATH', along these lines:
 > 
 >  guix package -i glibc-utf8-locales
 >  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
 > 
 > See the "Application Setup" section in the manual, for more info.

I filed a bug about this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40826

Re: core-updates call for testing

[sirgazil]

  On Fri, 24 Apr 2020 16:25:13 + Marius Bakke  
wrote 
 > sirgazil  writes:
 > 
 > >   On Fri, 24 Apr 2020 03:20:41 + sirgazil  
 > > wrote 
 > >  >   On Thu, 23 Apr 2020 23:24:23 + Marius Bakke 
 > >  wrote 
 > >  >  > Hello Guix!
 > >  >  > 
 > >  >  > The "core-updates" branch is ready for testing!  According to 'guix
 > >  >  > weather', the substitute coverage is slightly better than on "master"
 > >  >  > for x86_64.  You can get it by running:
 > >  >  > 
 > >  >  >   guix pull --branch=core-updates
 > >  >  > 
 > >  >  > Please try upgrading your profiles and systems and file bugs for
 > >  >  > anything that does not work for you.  GNOME users in particular are
 > >  >  > encouraged to try the new GNOME 3.34 and report any regressions.
 > >  > 
 > >  > I pulled from core-updates without problems, but "guix upgrade" failed.
 > >  > 
 > >  > First, when running "guix upgrade", I got the following message, which 
 > > I think is confusing because I use GNU, not Guix on a foreign distro:
 > >  > 
 > >  > $ guix upgrade
 > >  > guile: warning: failed to install locale
 > >  > hint: Consider installing the `glibc-utf8-locales' or 
 > > `glibc-locales' package and defining `GUIX_LOCPATH', along these lines:
 > >  > 
 > >  >  guix package -i glibc-utf8-locales
 > >  >  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
 > >  > 
 > >  > See the "Application Setup" section in the manual, for more info.
 > >  > 
 > >  > Then, everything was going alright, until building emacs-guix 
 > > derivation failed:
 > >  > 
 > >  > building 
 > > /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv...
 > >  > \ 'configure' phasebuilder for 
 > > `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed 
 > > with exit code 1
 > >  > build of 
 > > /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv failed
 > >  > View build log at 
 > > '/var/log/guix/drvs/6k/dl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv.bz2'.
 > >  > guix upgrade: error: build of 
 > > `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed
 > >  > 
 > >  > 
 > >  > The build log said:
 > >  > 
 > >  > starting phase `configure'
 > >  > source directory: 
 > > "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2" (relative from 
 > > build: ".")
 > >  > build directory: 
 > > "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2"
 > >  > configure flags: 
 > > ("CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 > >  
 > > "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 > >  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
 > > "--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
 > >  > configure: WARNING: unrecognized options: --enable-fast-install
 > >  > checking for a BSD-compatible install... 
 > > /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/install -c
 > >  > checking whether build environment is sane... yes
 > >  > checking for a thread-safe mkdir -p... 
 > > /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/mkdir -p
 > >  > checking for gawk... gawk
 > >  > checking whether make sets $(MAKE)... no
 > >  > checking whether make supports nested variables... yes
 > >  > checking whether make supports nested variables... (cached) yes
 > >  > checking for pkg-config... 
 > > /gnu/store/krpyb0zi700dcrg9cc8932w4v0qivdg9-pkg-config-0.29.2/bin/pkg-config
 > >  > checking pkg-config is at least version 0.9.0... yes
 > >  > configure: checking for guile 2.2
 > >  > configure: checking for guile 2.0
 > >  > configure: error: 
 > >  > No Guile development packages were found.
 > >  > 
 > >  > Please verify that you have Guile installed.  If you installed Guile
 > >  > from a binary distribution, please verify that you have also 
 > > installed
 > >  > the development packages.  If you installed it yourself, you might 
 > > need
 > >  > to adjust your PKG_CONFIG_PATH; see the pkg-config man page for 
 > > more.
 > >  > 
 > >  > command 
 > > "/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash" 
 > > "./configure" 
 > > "CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 > >  
 > > "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 > >  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
 > > "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" failed with 
 > > status 1
 > >  > 
 > >  > 
 > >
 > >
 > > Then, I decided to remove emacs-guix, and try again to upgrade. This time, 
 > > one of my packages in a custom channel failed with "no code for (term 
 > > ansi-color)" (the package definition: 
 > > 

Outreachy

[Gábor Boskovits]

Hello,

On the Outreachy ML the following was communicated:

The new Outreachy intern announcement date is May 4.

They apologize for the inconvenience, and thank for patience.

This is to keep in sync with GSoC.

Mentors, please keep in mind not communicate the selections before the
announcement.

Applicants, I am sorry about this confusion and thanks for your understanding.

Best regards,
g_bor

-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: Packaging ‘clang-tools-extra’ (‘clang-tidy’, etc.)

[Nikita Gillmann]

Ludovic Courtès transcribed 4.9K bytes:
> Hello!
> 
> The patch below produces a ‘clang’ package that contains
> ‘clang-tools-extra’ commands¹.
> 
[...]
> Any idea how to best package it?
> 
> We could of course have a ‘clang-full’ package, but it seems wasteful.
> We could also have a separate output for the extra commands, but it’s
> inconvenient.  It would be ideal to have a ‘clang-tools-extra’ package
> that depends on ‘clang’, but building them separately appears to be
> impossible.

Is it? The way we build clang and clang-tools-extra in pkgsrc is to
have them separate.
Refer to lang/clang-tools-extra and lang/clang to see how.
The gist is, BUILD_TARGET for clang-tools-extra gets overridden
and appended with targets to build.
That'S just after skipping through the clang-tools-extra package
for a minute.
I'm not sure if this is applicable to guix in any way.

> Thanks in advance!  :-)
> 
> Ludo’.
> 
> ¹ https://releases.llvm.org/10.0.0/tools/clang/tools/extra/docs/index.html
> 

> diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
> index d6c519bcbd..a3bcd75190 100644
> --- a/gnu/packages/llvm.scm
> +++ b/gnu/packages/llvm.scm
> @@ -166,7 +166,11 @@ compiler.  In LLVM this library is called 
> \"compiler-rt\".")
>  (supported-systems (delete "mips64el-linux" %supported-systems
>  
>  (define* (clang-from-llvm llvm clang-runtime hash
> -  #:key (patches '()))
> +  #:key (patches '()) tools-extra)
> +  "Produce Clang with dependencies on LLVM and CLANG-RUNTIME, and applying 
> the
> +given PATCHES.  When TOOLS-EXTRA is given, it must point to the
> +'clang-tools-extra' tarball, which contains code for 'clang-tidy', 
> 'pp-trace',
> +'modularize', and other tools."
>(package
>  (name "clang")
>  (version (package-version llvm))
> @@ -187,7 +191,10 @@ compiler.  In LLVM this library is called 
> \"compiler-rt\".")
>  (inputs
>   `(("libxml2" ,libxml2)
> ("gcc-lib" ,gcc "lib")
> -   ,@(package-inputs llvm)))
> +   ,@(package-inputs llvm)
> +   ,@(if tools-extra
> + `(("clang-tools-extra" ,tools-extra))
> + '(
>  (propagated-inputs
>   `(("llvm" ,llvm)
> ("clang-runtime" ,clang-runtime)))
> @@ -208,6 +215,19 @@ compiler.  In LLVM this library is called 
> \"compiler-rt\".")
> #:build-type "Release"
>  
> #:phases (modify-phases %standard-phases
> +  ,@(if tools-extra
> +`((add-after 'unpack 'add-tools-extra
> +(lambda* (#:key inputs #:allow-other-keys)
> +  (let ((extra (assoc-ref inputs
> +  "clang-tools-extra")))
> +(invoke "tar" "xf" extra)
> +(rename-file ,(string-append
> +   "clang-tools-extra-"
> +   (package-version llvm)
> +   ".src")
> + "tools/extra")
> +#t
> +'())
>(add-after 'unpack 'add-missing-triplets
>  (lambda _
>;; Clang iterates through known triplets to search for
> @@ -376,7 +396,16 @@ output), and Binutils.")
>  (define-public clang-10
>(clang-from-llvm llvm-10 clang-runtime-10
> "08fbxa2a0kr3ni35ckppj0kyvlcyaywrhpqwcdrdy0z900mhcnw8"
> -   #:patches '("clang-10.0-libc-search-path.patch")))
> +   #:patches '("clang-10.0-libc-search-path.patch")
> +   #:tools-extra
> +   #f
> +   #;(origin
> + (method url-fetch)
> + (uri (llvm-download-uri "clang-tools-extra"
> + (package-version llvm-10)))
> + (sha256
> +  (base32
> +   
> "074ija5s2jsdn0k035r2dzmryjmqxdnyg4xwvaqych2bazv8rpxc")
>  
>  (define-public clang-toolchain-10
>(make-clang-toolchain clang-10))

Re: core-updates call for testing

[Gábor Boskovits]

Hello,

Marius Bakke  ezt írta (időpont: 2020. ápr. 24., Pén
18:25):

> sirgazil  writes:
>
> >   On Fri, 24 Apr 2020 03:20:41 + sirgazil 
> wrote 
> >  >   On Thu, 23 Apr 2020 23:24:23 + Marius Bakke <
> mba...@fastmail.com> wrote 
> >  >  > Hello Guix!
> >  >  >
> >  >  > The "core-updates" branch is ready for testing!  According to 'guix
> >  >  > weather', the substitute coverage is slightly better than on
> "master"
> >  >  > for x86_64.  You can get it by running:
> >  >  >
> >  >  >   guix pull --branch=core-updates
> >  >  >
> >  >  > Please try upgrading your profiles and systems and file bugs for
> >  >  > anything that does not work for you.  GNOME users in particular are
> >  >  > encouraged to try the new GNOME 3.34 and report any regressions.
> >  >
> >  > I pulled from core-updates without problems, but "guix upgrade"
> failed.
> >  >
> >  > First, when running "guix upgrade", I got the following message,
> which I think is confusing because I use GNU, not Guix on a foreign distro:
> >  >
> >  > $ guix upgrade
> >  > guile: warning: failed to install locale
> >  > hint: Consider installing the `glibc-utf8-locales' or
> `glibc-locales' package and defining `GUIX_LOCPATH', along these lines:
> >  >
> >  >  guix package -i glibc-utf8-locales
> >  >  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
> >  >
> >  > See the "Application Setup" section in the manual, for more info.
> >  >
> >  > Then, everything was going alright, until building emacs-guix
> derivation failed:
> >  >
> >  > building
> /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv...
> >  > \ 'configure' phasebuilder for
> `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed
> with exit code 1
> >  > build of
> /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv failed
> >  > View build log at
> '/var/log/guix/drvs/6k/dl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv.bz2'.
> >  > guix upgrade: error: build of
> `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed
> >  >
> >  >
> >  > The build log said:
> >  >
> >  > starting phase `configure'
> >  > source directory:
> "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2" (relative from
> build: ".")
> >  > build directory:
> "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2"
> >  > configure flags:
> ("CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2"
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
> >  > configure: WARNING: unrecognized options: --enable-fast-install
> >  > checking for a BSD-compatible install...
> /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/install -c
> >  > checking whether build environment is sane... yes
> >  > checking for a thread-safe mkdir -p...
> /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/mkdir -p
> >  > checking for gawk... gawk
> >  > checking whether make sets $(MAKE)... no
> >  > checking whether make supports nested variables... yes
> >  > checking whether make supports nested variables... (cached) yes
> >  > checking for pkg-config...
> /gnu/store/krpyb0zi700dcrg9cc8932w4v0qivdg9-pkg-config-0.29.2/bin/pkg-config
> >  > checking pkg-config is at least version 0.9.0... yes
> >  > configure: checking for guile 2.2
> >  > configure: checking for guile 2.0
> >  > configure: error:
> >  > No Guile development packages were found.
> >  >
> >  > Please verify that you have Guile installed.  If you installed
> Guile
> >  > from a binary distribution, please verify that you have also
> installed
> >  > the development packages.  If you installed it yourself, you
> might need
> >  > to adjust your PKG_CONFIG_PATH; see the pkg-config man page for
> more.
> >  >
> >  > command
> "/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "./configure"
> "CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
> "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2"
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" failed with
> status 1
> >  >
> >  >
> >
> >
> > Then, I decided to remove emacs-guix, and try again to upgrade. This
> time, one of my packages in a custom channel failed with "no code for (term
> ansi-color)" (the package definition:
> https://gitlab.com/sirgazil/guix-channel-x/-/blob/master/sirgazil-x/packages/guile.scm#L13).
> This is not a new package in my profile, I've been using it for a long
> time. Since both error seemed to be related to Guile, I removed all
> Guile-related packages from 

Re: Reflections on the release process

[Gábor Boskovits]

Hello Ludo,

Ludovic Courtès  ezt írta (időpont: 2020. ápr. 22., Sze
22:09):

> Hi!
>
> zimoun  skribis:
>
> > On Wed, 15 Apr 2020 at 22:18, Ludovic Courtès  wrote:
> >
> >> 4. We lack a clear way to mark bugs as release-critical.  I’m really
> >> happy Florian, Mathieu, and I have been able to work together and squash
> >> bugs one by one (thank you!).  Still, it would have been better if we
> >> could have tagged which is release-critical and which is not, to prevent
> >> misunderstandings such as regarding the NVMe bug:
> >> .  Can Debbugs help?  The GCC
> >> folks have a system that sends email with an update on the number of
> >> release-critical bugs.  I’m sure we can learn from how others deal with
> >> that.
> >
> > The first easy step seems to tag the relevant bug as release-critical
> > or simply rc.
> > Currently, the tags nomal, security, serious, moreinfo, important,
> > unreproducible are used in Debbugs.
>
> Yes, but how do we do that?  I don’t think Debbugs supports a
> “release-critical” tag, does it?  Or perhaps we could take advantage of
> Mumi to add special tags or something?
>

Actually the description of the severity level serious says its intended
meaning is making a bug release critical. I believe we could simply use
that.


> > Then a second step could be to collect these release critical bugs and
> > display them on issues.guix.gnu.org (or data.guix.gnu.org) for example
> > remplacing the circle exclamation mark by a red triangle exclamation
> > mark (or any really visible symbol). And because the "recent
> > activities" is already sorted, it becomes easier to point the
> > remaining release critical bugs, the ones stuck, etc.
>
> Agreed.
>
> >> For the other issues, I’m interested in any ideas you may have!
> >
> > About the "frozen" window, does it make to schedule it in advance? For
> > example a couple of months before.
> > And for example, does it make sense to say: at least one release each
> > year on the March 14th (Pi day ;-) or approximately.
> > Because in general FOSDEM is at the beginning of February and it is a
> > big party where some of us come then back home refill of energy, we
> > could agree around this date (beginning of Feb.) on the frozen window
> > date (say end of February) and then release around middle of March.
> > From my point of view, using the Guix Days as catalyst for releasing
> > should help the process.
>
> I think there’s no question we want more than one release per year.  For
> that to happen, we should make sure the process is well documented, as
> smooth as possible, largely automated, and not tied to a single person
> (ahem…).
>
> Once we have that, plus some planning such as marking RC-critical bugs,
> it’ll be easier to make releases IMO.
>
> Thanks,
> Ludo’.
>

Best regards,
g_bor

>
>

Re: core-updates call for testing

[Marius Bakke]

sirgazil  writes:

>   On Fri, 24 Apr 2020 03:20:41 + sirgazil  wrote 
> 
>  >   On Thu, 23 Apr 2020 23:24:23 + Marius Bakke 
>  wrote 
>  >  > Hello Guix!
>  >  > 
>  >  > The "core-updates" branch is ready for testing!  According to 'guix
>  >  > weather', the substitute coverage is slightly better than on "master"
>  >  > for x86_64.  You can get it by running:
>  >  > 
>  >  >   guix pull --branch=core-updates
>  >  > 
>  >  > Please try upgrading your profiles and systems and file bugs for
>  >  > anything that does not work for you.  GNOME users in particular are
>  >  > encouraged to try the new GNOME 3.34 and report any regressions.
>  > 
>  > I pulled from core-updates without problems, but "guix upgrade" failed.
>  > 
>  > First, when running "guix upgrade", I got the following message, which I 
> think is confusing because I use GNU, not Guix on a foreign distro:
>  > 
>  > $ guix upgrade
>  > guile: warning: failed to install locale
>  > hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' 
> package and defining `GUIX_LOCPATH', along these lines:
>  > 
>  >  guix package -i glibc-utf8-locales
>  >  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
>  > 
>  > See the "Application Setup" section in the manual, for more info.
>  > 
>  > Then, everything was going alright, until building emacs-guix derivation 
> failed:
>  > 
>  > building 
> /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv...
>  > \ 'configure' phasebuilder for 
> `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed 
> with exit code 1
>  > build of 
> /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv failed
>  > View build log at 
> '/var/log/guix/drvs/6k/dl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv.bz2'.
>  > guix upgrade: error: build of 
> `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed
>  > 
>  > 
>  > The build log said:
>  > 
>  > starting phase `configure'
>  > source directory: 
> "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2" (relative from 
> build: ".")
>  > build directory: 
> "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2"
>  > configure flags: 
> ("CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
>  
> "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
>  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
>  > configure: WARNING: unrecognized options: --enable-fast-install
>  > checking for a BSD-compatible install... 
> /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/install -c
>  > checking whether build environment is sane... yes
>  > checking for a thread-safe mkdir -p... 
> /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/mkdir -p
>  > checking for gawk... gawk
>  > checking whether make sets $(MAKE)... no
>  > checking whether make supports nested variables... yes
>  > checking whether make supports nested variables... (cached) yes
>  > checking for pkg-config... 
> /gnu/store/krpyb0zi700dcrg9cc8932w4v0qivdg9-pkg-config-0.29.2/bin/pkg-config
>  > checking pkg-config is at least version 0.9.0... yes
>  > configure: checking for guile 2.2
>  > configure: checking for guile 2.0
>  > configure: error: 
>  > No Guile development packages were found.
>  > 
>  > Please verify that you have Guile installed.  If you installed Guile
>  > from a binary distribution, please verify that you have also installed
>  > the development packages.  If you installed it yourself, you might need
>  > to adjust your PKG_CONFIG_PATH; see the pkg-config man page for more.
>  > 
>  > command 
> "/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash" 
> "./configure" 
> "CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
>  
> "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
>  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" failed with status 
> 1
>  > 
>  > 
>
>
> Then, I decided to remove emacs-guix, and try again to upgrade. This time, 
> one of my packages in a custom channel failed with "no code for (term 
> ansi-color)" (the package definition: 
> https://gitlab.com/sirgazil/guix-channel-x/-/blob/master/sirgazil-x/packages/guile.scm#L13).
>  This is not a new package in my profile, I've been using it for a long time. 
> Since both error seemed to be related to Guile, I removed all Guile-related 
> packages from my profile and tried upgrading again. This time, the upgrade 
> succeeded.

Thanks for testing!  I fixed the emacs-guix issue in commit
f568581c2bfb3a7367442c9ccc23613c43f6f1e9 plus 

Re: Reflections on the release process

[zimoun]

On Wed, 22 Apr 2020 at 22:09, Ludovic Courtès  wrote:


> Yes, but how do we do that?  I don’t think Debbugs supports a
> “release-critical” tag, does it?  Or perhaps we could take advantage of
> Mumi to add special tags or something?

The GNU instance of Debbugs does not support it, I agree.
However, the Debian instance supports more tags than the GNU one, e.g.,

patch, wontfix, moreinfo, unreproducible, help, security, upstream,
pending, confirmed, ipv6, lfs, d-i, l10n, newcomer, a11y, ftbfs,
fixed-upstream, fixed, fixed-in-experimental, potato, woody, sarge,
etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye,
bookworm, sid, experimental, sarge-ignore, etch-ignore, lenny-ignore,
squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore,
buster-ignore, bullseye-ignore, bookworm-ignore

https://www.debian.org/Bugs/

I have not dove into the Debbugs configuration so I do not know if it
is easy or not to extend the list of tags. However, because it is
managed by GNU sysadmin, it should be a long road. ;-)

And I do not know what is the "effect" of the 'block' command. Because
a "release vx.y" bug could be open. And the release critical issues
could be marked as "block release-vx.y". This bug "release vx.y" could
help to synchronise/coordinate and/or track progress and should help
for managing the schedule and deadlines.

I do not know. I am thinking loud.



> I think there’s no question we want more than one release per year.  For
> that to happen, we should make sure the process is well documented, as
> smooth as possible, largely automated, and not tied to a single person
> (ahem…).

Agree.


Cheers,
simon

Re: core-updates call for testing

[Jack Hill]

On Fri, 24 Apr 2020, Marius Bakke wrote:


The "core-updates" branch is ready for testing!


Thanks Marius and others who have worked on core-updates. It's exciting to 
see these updates nearing completion.


In my testing so far, I've noticed that font-gnu-freefont fails to build: 
https://issues.guix.gnu.org/issue/40819


Best,
Jack

Packaging ‘clang-tools-extra’ (‘clang-tidy’, etc.)

[Ludovic Courtès]

Hello!

The patch below produces a ‘clang’ package that contains
‘clang-tools-extra’ commands¹.

The problem is the size.  Before:

--8<---cut here---start->8---
$ guix size /gnu/store/qxdpxbvfdxfy5dnz4haql4xlxpmb5r6b-clang-10.0.0 |tail -1
total: 995.2 MiB
$ guix size /gnu/store/qxdpxbvfdxfy5dnz4haql4xlxpmb5r6b-clang-10.0.0 |head -2
store item   totalself
/gnu/store/qxdpxbvfdxfy5dnz4haql4xlxpmb5r6b-clang-10.0.0   995.2   
456.5  45.9%
--8<---cut here---end--->8---

After:

--8<---cut here---start->8---
$ guix size /gnu/store/5h3xgpg33wip2b8ccri690jp6ikbq16s-clang-10.0.0 |tail -1
total: 1525.4 MiB
$ guix size /gnu/store/5h3xgpg33wip2b8ccri690jp6ikbq16s-clang-10.0.0 |head -2
store item   totalself
/gnu/store/5h3xgpg33wip2b8ccri690jp6ikbq16s-clang-10.0.0  1525.4   
986.8  64.7%
--8<---cut here---end--->8---

(How they manage to fill that much disk space, I wonder.)

Any idea how to best package it?

We could of course have a ‘clang-full’ package, but it seems wasteful.
We could also have a separate output for the extra commands, but it’s
inconvenient.  It would be ideal to have a ‘clang-tools-extra’ package
that depends on ‘clang’, but building them separately appears to be
impossible.

Thanks in advance!  :-)

Ludo’.

¹ https://releases.llvm.org/10.0.0/tools/clang/tools/extra/docs/index.html

diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
index d6c519bcbd..a3bcd75190 100644
--- a/gnu/packages/llvm.scm
+++ b/gnu/packages/llvm.scm
@@ -166,7 +166,11 @@ compiler.  In LLVM this library is called \"compiler-rt\".")
 (supported-systems (delete "mips64el-linux" %supported-systems
 
 (define* (clang-from-llvm llvm clang-runtime hash
-  #:key (patches '()))
+  #:key (patches '()) tools-extra)
+  "Produce Clang with dependencies on LLVM and CLANG-RUNTIME, and applying the
+given PATCHES.  When TOOLS-EXTRA is given, it must point to the
+'clang-tools-extra' tarball, which contains code for 'clang-tidy', 'pp-trace',
+'modularize', and other tools."
   (package
 (name "clang")
 (version (package-version llvm))
@@ -187,7 +191,10 @@ compiler.  In LLVM this library is called \"compiler-rt\".")
 (inputs
  `(("libxml2" ,libxml2)
("gcc-lib" ,gcc "lib")
-   ,@(package-inputs llvm)))
+   ,@(package-inputs llvm)
+   ,@(if tools-extra
+ `(("clang-tools-extra" ,tools-extra))
+ '(
 (propagated-inputs
  `(("llvm" ,llvm)
("clang-runtime" ,clang-runtime)))
@@ -208,6 +215,19 @@ compiler.  In LLVM this library is called \"compiler-rt\".")
#:build-type "Release"
 
#:phases (modify-phases %standard-phases
+  ,@(if tools-extra
+`((add-after 'unpack 'add-tools-extra
+(lambda* (#:key inputs #:allow-other-keys)
+  (let ((extra (assoc-ref inputs
+  "clang-tools-extra")))
+(invoke "tar" "xf" extra)
+(rename-file ,(string-append
+   "clang-tools-extra-"
+   (package-version llvm)
+   ".src")
+ "tools/extra")
+#t
+'())
   (add-after 'unpack 'add-missing-triplets
 (lambda _
   ;; Clang iterates through known triplets to search for
@@ -376,7 +396,16 @@ output), and Binutils.")
 (define-public clang-10
   (clang-from-llvm llvm-10 clang-runtime-10
"08fbxa2a0kr3ni35ckppj0kyvlcyaywrhpqwcdrdy0z900mhcnw8"
-   #:patches '("clang-10.0-libc-search-path.patch")))
+   #:patches '("clang-10.0-libc-search-path.patch")
+   #:tools-extra
+   #f
+   #;(origin
+ (method url-fetch)
+ (uri (llvm-download-uri "clang-tools-extra"
+ (package-version llvm-10)))
+ (sha256
+  (base32
+   "074ija5s2jsdn0k035r2dzmryjmqxdnyg4xwvaqych2bazv8rpxc")
 
 (define-public clang-toolchain-10
   (make-clang-toolchain clang-10))

Re: Prototype tool for building derivations

[zimoun]

Hi Chris,

On Fri, 17 Apr 2020 at 22:22, Christopher Baines  wrote:

> Just let me know if you have any questions or comments!

>From what I understand of both your prototype and build systems, you
should interesting to read this paper [1]: "Build systems à la carte:
Theory and practice". It needs some imagination if you are not
familiar with Haskell notations. And you should interested by section
4 about Schedulers and section 5 about Rebuilders; especially Table 2
p.28, and also subsections 8.2 about Parallelism and 8.4 about Could
implementation.

[1] https://doi.org/10.1017/S095679682088


Thank you for the initiative and sharing your perspectives.

Cheers,
simon

Re: core-updates call for testing

[sirgazil]

  On Fri, 24 Apr 2020 03:20:41 + sirgazil  wrote 
 >   On Thu, 23 Apr 2020 23:24:23 + Marius Bakke  
 > wrote 
 >  > Hello Guix!
 >  > 
 >  > The "core-updates" branch is ready for testing!  According to 'guix
 >  > weather', the substitute coverage is slightly better than on "master"
 >  > for x86_64.  You can get it by running:
 >  > 
 >  >   guix pull --branch=core-updates
 >  > 
 >  > Please try upgrading your profiles and systems and file bugs for
 >  > anything that does not work for you.  GNOME users in particular are
 >  > encouraged to try the new GNOME 3.34 and report any regressions.
 > 
 > I pulled from core-updates without problems, but "guix upgrade" failed.
 > 
 > First, when running "guix upgrade", I got the following message, which I 
 > think is confusing because I use GNU, not Guix on a foreign distro:
 > 
 > $ guix upgrade
 > guile: warning: failed to install locale
 > hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' 
 > package and defining `GUIX_LOCPATH', along these lines:
 > 
 >  guix package -i glibc-utf8-locales
 >  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
 > 
 > See the "Application Setup" section in the manual, for more info.
 > 
 > Then, everything was going alright, until building emacs-guix derivation 
 > failed:
 > 
 > building 
 > /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv...
 > \ 'configure' phasebuilder for 
 > `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed 
 > with exit code 1
 > build of 
 > /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv failed
 > View build log at 
 > '/var/log/guix/drvs/6k/dl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv.bz2'.
 > guix upgrade: error: build of 
 > `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed
 > 
 > 
 > The build log said:
 > 
 > starting phase `configure'
 > source directory: 
 > "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2" (relative from 
 > build: ".")
 > build directory: 
 > "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2"
 > configure flags: 
 > ("CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 >  
 > "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 >  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
 > "--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
 > configure: WARNING: unrecognized options: --enable-fast-install
 > checking for a BSD-compatible install... 
 > /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/install -c
 > checking whether build environment is sane... yes
 > checking for a thread-safe mkdir -p... 
 > /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/mkdir -p
 > checking for gawk... gawk
 > checking whether make sets $(MAKE)... no
 > checking whether make supports nested variables... yes
 > checking whether make supports nested variables... (cached) yes
 > checking for pkg-config... 
 > /gnu/store/krpyb0zi700dcrg9cc8932w4v0qivdg9-pkg-config-0.29.2/bin/pkg-config
 > checking pkg-config is at least version 0.9.0... yes
 > configure: checking for guile 2.2
 > configure: checking for guile 2.0
 > configure: error: 
 > No Guile development packages were found.
 > 
 > Please verify that you have Guile installed.  If you installed Guile
 > from a binary distribution, please verify that you have also installed
 > the development packages.  If you installed it yourself, you might need
 > to adjust your PKG_CONFIG_PATH; see the pkg-config man page for more.
 > 
 > command 
 > "/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash" 
 > "./configure" 
 > "CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 >  
 > "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
 >  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
 > "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" failed with 
 > status 1
 > 
 > 


Then, I decided to remove emacs-guix, and try again to upgrade. This time, one 
of my packages in a custom channel failed with "no code for (term ansi-color)" 
(the package definition: 
https://gitlab.com/sirgazil/guix-channel-x/-/blob/master/sirgazil-x/packages/guile.scm#L13).
 This is not a new package in my profile, I've been using it for a long time. 
Since both error seemed to be related to Guile, I removed all Guile-related 
packages from my profile and tried upgrading again. This time, the upgrade 
succeeded.

I moved on to reconfiguring the system with "sudo system reconfigure 
my-gnome-config.scm", which failed with the following error:

downloading from 
https://ci.guix.gnu.org/nar/lzip/24yvi2yyknfrpyb7linxd09dkpc560xp-nss-certs-3.50
 ...
 

Re: Image generation

[Mathieu Othacehe]

> Wow! Why did it take 2h30? Do you have KVM?

Yes, I'm not sure why it's so long. It seems that
"estimated-partition-size" takes a large proportion of this time,
because if I run the same command with a fixed disk-image size it goes
faster.

Mathieu

Re: Image generation

[Mathieu Othacehe]

> * Add support for ISO images.

For ISO images, by running make-iso9660-image directly on the host (see
wip-disk-image branch), I have a considerable time decrease.

This command:

--8<---cut here---start->8---
guix system disk-image --file-system-type=iso9660 
gnu/system/examples/bare-bones.tmpl
--8<---cut here---end--->8---

takes,

* Without zisofs compression, on host: 4min
* With zisofs compression, on host: 8min
* With zisofs, on VM: 19min (master)

This makes me think that we may want to make iso compression optional,
so that tests can use uncompressed iso that takes more space but are
faster to produce.

It seems that there are also some alternatives to xorriso such as
genisoimage (used by genimage).

Mathieu

New Russian PO file for 'guix-manual' (version 1.1.0-pre2)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'guix-manual' has been submitted
by the Russian team of translators.  The file is available at:

https://translationproject.org/latest/guix-manual/ru.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

https://translationproject.org/latest/guix-manual/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/guix-manual.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.