bug#39941: Disk-image size increase on core-updates.

[Mathieu Othacehe]

Hey Marius,

> Maybe file a different bug report for those so it does not get
> forgotten?  One thing at the time...

Ok!

> FWIW I think the original problem with huge closure increase has been
> fixed with 8e98f750e63e8723db0361f4e3e960193278fa47 and
> 7688dbbdd7a7a091c9a0fc4850e70725e3ff64e3.
>
> I'm getting 1372 MiB for the cross-mini example at approximately commit
> d594963856690f1aacf228c8a83e406d33bc44ce (cross-built for
> arm-linux-gnueabihf).

What's cross-mini? On commit d594963856690f1aacf228c8a83e406d33bc44ce of
core-updates (both patches you mentionned included), I still have a
1.9GiB closure.

Note, that applying the "lib" output patch, it drops down to 1.6GiB,
which is good news :).

> The patch is almost 40k lines!  Most of the changes are whitespace
> changes in the ChangeLog files, could you remove the commit log and
> ChangeLog entries altogether to make the patch easier to parse?
>
> Where did you find this patch?

You'll find a trimmed patch attached. I found the GCC patch upstream
(pushed in January), after finding the option in the online manual.

Thanks,

Mathieu

>From d8c45710847b504912670ebccf319354746f06f9 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Sat, 14 Mar 2020 11:39:52 +0100
Subject: [PATCH] gnu: cross-gcc: Add a "lib" output.

Add a "lib" output to cross-gcc. This requires an upstream GCC patch adding
support for --with-toolexeclibdir configure option. This option allows to
install cross-built GCC libraries in a specific location.

This also fixes the computation of TOOLDIR_BASE_PREFIX, that fails when
/gnu/store/... directories are involved.

* gnu/packages/patches/gcc-7-cross-toolexeclibdir.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/cross-base.scm (cross-gcc)[source]: Apply it,
[outputs]: add a "lib" output,
(cross-gcc-snippet): fix TOOLDIR_BASE_PREFIX.
---
 gnu/local.mk  |3 +-
 gnu/packages/cross-base.scm   |   41 +-
 .../patches/gcc-7-cross-toolexeclibdir.patch  | 2654 +
 3 files changed, 2684 insertions(+), 14 deletions(-)
 create mode 100644 gnu/packages/patches/gcc-7-cross-toolexeclibdir.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 21a149c469..3af841efea 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -14,7 +14,7 @@
 # Copyright © 2016, 2017, 2018, 2019 Jan (janneke) Nieuwenhuizen 
 # Copyright © 2017, 2018, 2019, 2020 Tobias Geerinckx-Rice 
 # Copyright © 2017, 2018 Clément Lassieur 
-# Copyright © 2017 Mathieu Othacehe 
+# Copyright © 2017, 2020 Mathieu Othacehe 
 # Copyright © 2017, 2018, 2019 Gábor Boskovits 
 # Copyright © 2018 Amirouche Boubekki 
 # Copyright © 2018, 2019, 2020 Oleg Pykhalov 
@@ -911,6 +911,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/gcc-6-source-date-epoch-2.patch		\
   %D%/packages/patches/gcc-7-cross-mingw.patch			\
   %D%/packages/patches/gcc-7-cross-environment-variables.patch	\
+  %D%/packages/patches/gcc-7-cross-toolexeclibdir.patch		\
   %D%/packages/patches/gcc-8-cross-environment-variables.patch	\
   %D%/packages/patches/gcc-8-strmov-store-file-names.patch	\
   %D%/packages/patches/gcc-9-asan-fix-limits-include.patch	\
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 667d1f786a..d373e522d5 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -6,6 +6,7 @@
 ;;; Copyright © 2018 Tobias Geerinckx-Rice 
 ;;; Copyright © 2019, 2020 Marius Bakke 
 ;;; Copyright © 2019 Carl Dong 
+;;; Copyright © 2020 Mathieu Othacehe 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -162,6 +163,13 @@ base compiler and using LIBC (which may be either a libc package or #f.)"
"--disable-libsanitizer"
 ))
 
+   ;; Install cross-built libraries such as libgcc_s.so in
+   ;; the "lib" output.
+   ,@(if libc
+ `((string-append "--with-toolexeclibdir="
+  (assoc-ref %outputs "lib")
+  "/" ,target "/lib"))
+ '())
;; For a newlib (non-glibc) target
,@(if (cross-newlib? target)
  '("--with-newlib")
@@ -196,12 +204,18 @@ base compiler and using LIBC (which may be either a libc package or #f.)"
 
 (define (cross-gcc-snippet target)
   "Return GCC snippet needed for TARGET."
-  (cond ((target-mingw? target)
- '(begin
-(copy-recursively "libstdc++-v3/config/os/mingw32-w64"
-  "libstdc++-v3/config/os/newlib")
-#t))
-(else #f)))
+  `(begin
+ ,@(if (target-mingw? target)
+   '((copy-recursively "libstdc++-v3/config/os/mingw32-w64"
+   "libstdc++-v3/config/os/newlib"))
+   '())
+ ;; TOOLDIR_BASE_PREFIX is erroneous when using a separate "l

bug#40071: Cross-compiled package closure size.

[Mathieu Othacehe]

Hello,

After applying the patch proposed here[1], the closure of cross-compiled
"hello" still contains unwanted packages.

--8<---cut here---start->8---
mathieu@elbruz ~/guix [env]$ guix size 
/gnu/store/14ygibryjr7mcly0q9mb8306hlg16nhq-hello-2.10
store item   totalself
/gnu/store/vm2gaw5jk1zr1x9qzj4z52qjxvrh0nk9-glibc-cross-aarch64-linux-gnu-2.31  
 158.971.4  38.2%
/gnu/store/w00jb174abikqpznadwzvvgwl3r7qfzd-glibc-2.31  38.4
36.7  19.6%
/gnu/store/08vqg0s77dnff7rz90b0h87n2rfyaszg-gcc-7.5.0-lib   71.0
32.6  17.5%
/gnu/store/vqsixs9ks4chpjynhizkpdd1gdshv87h-gcc-cross-aarch64-linux-gnu-7.5.0-lib
   186.827.9  14.9%
/gnu/store/fgrpk8r46k34pyqv6xkbi8gbv997dbpx-gcc-cross-sans-libc-aarch64-linux-gnu-7.5.0-lib
80.8 9.8   5.2%
/gnu/store/zf5603c5l6ilgyg35gqfkn82v3k9hbri-linux-libre-headers-cross-aarch64-linux-gnu-5.4.20
 5.1 5.1   2.7%
/gnu/store/6hhsxa3vvbh8gvcfjw4k5sfk1qrhkcrf-bash-static-5.0.16   1.6 
1.6   0.9%
/gnu/store/nvc3r588745kkj159lm1pa4xz5g99rqd-bash-static-5.0.16   1.6 
1.6   0.9%
/gnu/store/14ygibryjr7mcly0q9mb8306hlg16nhq-hello-2.10 187.0 
0.2   0.1%
--8<---cut here---end--->8---

The native glibc, gcc-lib and one of the two bash-static packages should
be removed.

The gcc-cross-sans-libc-aarch64-linux-gnu-7.5.0-lib may also be removed.

Ideally, we would have a closure similar to the native one, with
something like this:

--8<---cut here---start->8---
/gnu/store/vm2gaw5jk1zr1x9qzj4z52qjxvrh0nk9-glibc-cross-aarch64-linux-gnu-2.31  
 158.971.4  38.2%
/gnu/store/vqsixs9ks4chpjynhizkpdd1gdshv87h-gcc-cross-aarch64-linux-gnu-7.5.0-lib
   186.827.9  14.9%
/gnu/store/6hhsxa3vvbh8gvcfjw4k5sfk1qrhkcrf-bash-static-5.0.16   1.6 
1.6   0.9%
/gnu/store/14ygibryjr7mcly0q9mb8306hlg16nhq-hello-2.10 187.0 
0.2   0.1%
--8<---cut here---end--->8---

Thanks,

Mathieu

[1]: https://lists.gnu.org/archive/html/bug-guix/2020-03/msg00170.html

bug#40073: Checksum mismatch on python-llvmlite patch

[Marius Bakke]

Hello,

python-llvmlite fails to build because it tries to download a patch that
has the wrong checksum.

Starting download of 
/gnu/store/hb3kk3d4nngxglfdflf99incbhmbw14h-D47188-svml-VF.patch
From 
https://raw.githubusercontent.com/numba/llvmlite/v0.30.0/conda-recipes/D47188-svml-VF.patch...
downloading from 
https://raw.githubusercontent.com/numba/llvmlite/v0.30.0/conda-recipes/D47188-svml-VF.patch...
 D47188-svml-VF.patch  73KiB 1.5MiB/s 00:00 
[##] 100.0%
sha256 hash mismatch for 
/gnu/store/hb3kk3d4nngxglfdflf99incbhmbw14h-D47188-svml-VF.patch:
  expected hash: 0wxhgb61k17f0zg2m0726sf3hppm41f8jar2kkg2n8sl5cnjj9mr
  actual hash:   0dlr2kmzjrif0wgqql1s3f6pmmsa8fjwjpm08ni68wwvjjx2lcli
hash mismatch for store item 
'/gnu/store/hb3kk3d4nngxglfdflf99incbhmbw14h-D47188-svml-VF.patch'
build of /gnu/store/vgni0s5mqdyc8pijaz1pdb6pirqd7ddh-D47188-svml-VF.patch.drv 
failed

This is likely a regression from
6608727262f45d351c55cd1ae40414db7768a374 and would go unnoticed if you
already had the previous patch in your store with the expected checksum.

I tried to simply update the patch, but the updated patch fails to apply
on LLVM 7, and the *other* patch fails to apply if I change to LLVM 8.

There is a new version of python-llvmlite out too, but no changes to the
patches.

Not sure what to do from here, help wanted!


signature.asc
Description: PGP signature

bug#40074: trilinos-serial-xyce source disappeared

[Marius Bakke]

The source URI for 'trilios-serial-xyce' serves a 404 page.  Following
download links from the home page only leads to the git repository.

This package should probably be changed to download a tagged git
revision instad of attempting to fetch a defunct tarball.

ci.guix.gnu.org has a copy of the previous source tarball so it's not
very urgent (anyone coming here can add "--fallback" to their guix
invokation to get it).


signature.asc
Description: PGP signature

bug#39941: Disk-image size increase on core-updates.

[Ludovic Courtès]

Hi!

Congrats on this, Mathieu!

Mathieu Othacehe  skribis:

> You'll find a trimmed patch attached. I found the GCC patch upstream
> (pushed in January), after finding the option in the online manual.

[...]

> From d8c45710847b504912670ebccf319354746f06f9 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe 
> Date: Sat, 14 Mar 2020 11:39:52 +0100
> Subject: [PATCH] gnu: cross-gcc: Add a "lib" output.
>
> Add a "lib" output to cross-gcc. This requires an upstream GCC patch adding
> support for --with-toolexeclibdir configure option. This option allows to
> install cross-built GCC libraries in a specific location.
>
> This also fixes the computation of TOOLDIR_BASE_PREFIX, that fails when
> /gnu/store/... directories are involved.

Perhaps add “Fixes .”


[...]

> + ;; TOOLDIR_BASE_PREFIX is erroneous when using a separate "lib"
> + ;; output. Specify it correctly, otherwise GCC won't find its shared
> + ;; libraries installed in the "lib" output.

How erroneous is it?  Is there a bug report we could link to?

> +++ b/gnu/packages/patches/gcc-7-cross-toolexeclibdir.patch
> @@ -0,0 +1,2654 @@
> +This patch taken from GCC upstream adds support for overriding cross-compiled
> +shared libraries installation path.  This is needed to have a separate "lib"
> +output containing those shared libraries.

Could you add a link to the web view of the commit, if possible?

>From this patch, I think we should keep only the generated bit
(‘configure’ and ‘Makefile.in’ files) and discard everything else.  We
can probably also discard changes in bundled libraries (zlib, libgc,
etc.).

The comment should mention that we’ve stripped things compared to the
upstream commit.

Apologies for suggesting some more tedious work, but I think it’ll be
helpful!  :-)

Thank you!

Ludo’.

bug#40079: emacs-elpy-1.31.0: failed to build

[sirgazil via Bug reports for GNU Guix]

I couldn't upgrade the packages in my user profile because "emacs-elpy" check 
phase fails. 


## Steps to reproduce

1. guix pull
2. guix build emacs-elpy


## Unexpected result


The output of the check phase:

---
starting phase `check'

Can’t guess python-indent-offset, using defaults: 4


Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4


Can’t guess python-indent-offset, using defaults: 4


Can’t guess python-indent-offset, using defaults: 4


Can’t guess python-indent-offset, using defaults: 4
Shell native completion is enabled.

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4
Shell native completion is enabled.

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4
Type C-x 1 to delete the help window, C-M-v to scroll help.

Type C-x 1 to delete the help window, C-M-v to scroll help.

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4
Type C-x 1 to delete the help window, C-M-v to scroll help.


Can’t guess python-indent-offset, using defaults: 4
Type C-x 1 to delete the help window, C-M-v to scroll help.


Can’t guess python-indent-offset, using defaults: 4
Type C-x 1 to delete the help window, C-M-v to scroll help.

Can’t guess python-indent-offset, using defaults: 4
Type C-x 1 to delete the help window, C-M-v to scroll help.

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake test_foo.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake test_foo.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake foo.py]: Disabling backend flymake-proc-legacy-flymake because 
(error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake foo.py]: Disabling backend flymake-proc-legacy-flymake because 
(error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake foo.py]: Disabling backend flymake-proc-legacy-flymake because 
(error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake foo.py]: Disabling backend flymake-proc-legacy-flymake because 
(error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake foo.py]: Disabling backend flymake-proc-legacy-flymake because 
(error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake foo.py]: Disabling backend flymake-proc-legacy-flymake because 
(error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake module.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)
Can’t guess python-indent-offset, using defaults: 4
Warning [flymake test_module.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake test.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake test.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake test.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)

Type C-x 1 to delete the help window, C-M-v to scroll help.

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake test.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4
Warning [flymake test.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)
Warning [flymake test.py]: Disabling backend flymake-proc-legacy-flymake 
because (error Can’t find a suitable init function)

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, using defaults: 4

Can’t guess python-indent-offset, u

bug#40006: 31/31: DRAFT gnu: bootstrap: Add support for the Hurd.

[Jan Nieuwenhuizen]

Jan Nieuwenhuizen writes:

>> For the sake of reducing complexity and keeping supported systems as
>> close to one another as possible, would it be an option to keep using
>> 2.0 for GNU/Hurd, like on the other systems?
...
>> That would entail changing make-bootstrap.scm to use 2.0 instead of 2.2
>> as a first step.  And yeah, it’d also entail another full rebuild, which
>> I’m sorry for, but I think this kind of simplification pays off quickly.
>>
>> WDYT?
>
> Yes, let's do that.  I'll also want to look at using gcc-5, that may
> solve our libstdc++-boot0/gcc-boot0 problem.  I think it's weird that we
> build gcc-7 by default as bootstrap binary, while using that may not
> even work (and is certainly untested).

Yes; that worked and it simplifies things a lot.  So, wip-hurd is using
guile-2 and gcc-5 now.  Using gcc-5 allowed me to remove the puzzling
gcc-boot0 patch.

Just reset wip-hurd again; it was fully up to date with core-utils when
I started building the bootstrap-tarballs... Rebasing right now to
verify for a new round ;-)

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

bug#40082: guix offload error messages need improvements

[levenson]

Hi Guix,

guix offload error messages are cumbersome. With a help from guys on irc 
channel(many thanks), I finally manage it to work by installing guix and guile 
packages under the remote user.

--8<---cut here---start->8---
# local
aabramov@delta:~/factory/guix$ guix describe
Generation 340  Mar 12 2020 18:23:16(current)
  guix be78906
repository URL: file:///home/aabramov/factory/guix
branch: master
commit: be78906592c761aa2a67e979074561e459efdcac
# remote
[aabramov@minion100 ~]$ guix describe
Generation 2Mar 15 2020 17:42:04(current)
  guix be78906
repository URL: file:///home/aabramov/guix
branch: master
commit: be78906592c761aa2a67e979074561e459efdcac
--8<---cut here---end--->8---

machines.scm is ready, and here is my fist attempt to run offload test.

--8<---cut here---start->8---
aabramov@delta:~/factory/guix$ guix offload test
guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
guix offload: Guix is usable on 'minion100' (test returned 
"/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
guix offload: 'minion100' is running GNU Guile 3.0.1
guix offload: error: failed to connect to `#': Protocol error
--8<---cut here---end--->8---

There is no errors in my local guix-daemon nor remote one. --debugs doesn't 
help either

Same thing with copy.

--8<---cut here---start->8---
aabramov@delta:~/factory/guix$ guix copy --to=minion100 hello
guix copy: error: failed to connect to `#': Protocol error
aabramov@delta:~/factory/guix$ guix copy --from=minion100 hello
guix copy: error: failed to connect to `#': Protocol error
--8<---cut here---end--->8---

Guix says that my minion is running GNU Guile 3.0 which is for me a good sign, 
but apparently it is not.

I thought that guile 3.0 is an issues, so let's install guile-2. Here is my 
remote profile:

--8<---cut here---start->8---
[aabramov@minion100 ~]$ guix package -l
Generation 1Mar 09 2020 22:22:03
  glibc-locales 2.29out 
/gnu/store/03nvilh2x4z07dxv7h13gh986vvgpnsf-glibc-locales-2.29

Generation 2Mar 09 2020 22:28:46
 + emacs-next   27.0.50-0.36abf68   out 
/gnu/store/61bwd5sn4s25lm2m9shbrja5d6z1d17y-emacs-next-27.0.50-0.36abf68

Generation 3Mar 15 2020 16:54:24
 + sshuttle 0.78.5  out 
/gnu/store/13s2jadhdvpk99mnkf6y1r42mamijzrd-sshuttle-0.78.5

Generation 4Mar 15 2020 17:56:00
 + guile2.2.7   out 
/gnu/store/jgl9d4axpavsv83z2f1z1himnkbsxxqj-guile-2.2.7
--8<---cut here---end--->8---

guix offload test fails with a diffrent error. I also tried to use 
#:log-verbosity 'protocol, but it doesn't help.

--8<---cut here---start->8---
aabramov@delta:~/factory/guix$ guix offload test
guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
guix offload: Guix is usable on 'minion100' (test returned 
"/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
guix offload: 'minion100' is running GNU Guile 3.0.1
sending 1 store item (0 MiB) to 'minion100'...
exporting path `/gnu/store/wc2vv8kcf634gijak07sadwmkck903lq-export-test'
guix offload: error: unknown error while sending files over SSH
--8<---cut here---end--->8---

In the meantime copy fails differently:

--8<---cut here---start->8---
aabramov@delta:~/factory/guix$ guix copy --from=minion100 hello
guix copy: error: Guile modules not found on remote host 'minion100'
hint: Make sure `GUILE_LOAD_PATH' includes Guix' own module directory.  Run 
`ssh minion100 env | grep GUILE_LOAD_PATH' to check.

aabramov@delta:~/factory/guix$ guix copy --to=minion100 hello
sending 1 store item (0 MiB) to 'minion100'...
guix copy: error: unknown error while sending files over SSH
aabramov@delta:~/factory/guix$ ssh minion100 env | grep GUILE_LOAD_PATH
--8<---cut here---end--->8---

`copy from' check gives a hint, but even though I have GUIX_PROFILE defined in 
my .bash_profile:

--8<---cut here---start->8---
aabramov@delta:~/factory/guix$ ssh minion100 tail -n2 .bash_profile 
export GUIX_PROFILE=~/.guix-profile
source "${GUIX_PROFILE}/etc/profile"
--8<---cut here---end--->8---

for some reason I still don't have any GUILE_LOAD variables defined

--8<---cut here---start->8---
[aabramov@minion100 ~]$ cat .guix-profile/etc/profile
# Source this file to define all the relevant environment variables in Bash
# for this profile.  You may want to define the 'GUIX_PROFILE' environment
# variable to point to the "visible" name of the profile, like this:
#
#  GUIX_PROFILE=/path/to/pr

bug#39282: Rhythmbox does not start

[Leo Famulari]

On Sat, Jan 25, 2020 at 04:10:26PM -0500, sirgazil via Bug reports for GNU Guix 
wrote:
> I just installed Rhythmbox in the Guix System but it does not start.
> 
> Trying to launch it from a terminal gives the following error:
> 
> $ LANG=C rhythmbox
> 
> (.rhythmbox-real:3361): Rhythmbox-CRITICAL **: 16:07:19.138: Timeout was 
> reached

Hm... I wonder what timed out?

It works for me with Guix on Debian.

bug#40043: `guix pack --format=squashfs` fails on CentOS7

[Ludovic Courtès]

Hi Josh,

Josh Marshall  skribis:

> `guix pack --format=squashfs bash-minimal ...` fails on CentOS7 with SELinux 
> disabled.

The error message normally says something like:

  View build log at /var/log/guix/drvs/…

Could you post that file?

Also, what is the output of “uname -sr” on this machine?

Thanks in advance!

Ludo’.