bug#41575: Container with openssh-service requires sshd user on the host

[conjaroy]

I've observed this error under similar circumstances: launching a guix
system container script with network sharing enabled, on a foreign disto
(Debian 10) with nscd running.

Using `strace -f /gnu/store/...-run-container`, we can observe the
container's lookup of user accounts via the foreign distro's nscd socket:

[pid 16582] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 11
[pid 16582] connect(11, {sa_family=AF_UNIX,
sun_path="/var/run/nscd/socket"}, 110) = 0
[pid 16582] sendto(11, "\2\0\0\0\0\0\0\0\t\0\0\0postgres\0", 21,
MSG_NOSIGNAL, NULL, 0) = 21
[pid 16582] poll([{fd=11, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1
([{fd=11, revents=POLLIN}])
[pid 16582] read(11,
"\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\377\377\377\377\0\0\0\0\0\0\0\0"...,
36) = 36
[pid 16582] close(11)   = 0

Since the user ("postgres") is indeed missing in the foreign disto, the
lookup fails. In this case, disabling nscd on the foreign distro allowed
the container script to run without error.

Based on comments in https://issues.guix.info/issue/28128, I see that it
was a deliberate choice to bind-mount the foreign distro's nscd socket
inside the container (instead of starting a separate containerized nscd
instance). But I'm having trouble seeing why it's acceptable to leak state
from the foreign distro's user space into the container. Is there something
I'm missing?

Cheers,

Jason

bug#43014: Install license files to all outputs

[Timothy Sample]

Ludovic Courtès  writes:

> Efraim Flashner  skribis:
>
>> It seems to me that the license file(s) should be installed to all the
>> outputs.
>
> Isn’t it already happening, at least with ‘gnu-build-system’?
>
> [...]
>
> Perhaps there are corner cases or an issue specific to
> ‘ghc-build-system’?

In the case of ‘git-annex’, it just needs a ‘license-file-regexp’
argument, which is easy enough to fix.  For ‘scroll’, it’s missing a
license file.  There is “GPL.hs”, but it doesn’t really count, IMO.  It
contains the text of the GPL (version 2), but as a Haskell string.  I
guess it’s better than nothing.

I think there is no bug here, just bad luck.  :)


-- Tim

bug#43011: unattended-upgrade fails and doesn't log why

[Ludovic Courtès]

Hi Jesse,

Jesse Gibbons  skribis:

> An example is the attached log. It says the process failed with status
> 1, but it doesn't say what failed or even reference a log in
> /var/log/guix. The only way to find out what could have caused it is
> to run the command, which might not fail the second time if it was a
> network error or (IIUC) if the issue was fixed between failure and
> retry.

The logging issue is fixed by commit
fe42e5f39c9b36f02beec246b376a50e41114b84.  At least you should now have
useful output in /var/log/unattended-upgrade.log.

Make sure to reconfigure and to ‘herd restart mcron’ by Sunday.  :-)

Let us know how it goes!

Thanks,
Ludo’.

bug#43014: Install license files to all outputs

[Ludovic Courtès]

Hi,

Efraim Flashner  skribis:

> It seems to me that the license file(s) should be installed to all the
> outputs.

Isn’t it already happening, at least with ‘gnu-build-system’?

--8<---cut here---start->8---
$ for i in $(guix build guile -v0) ; do ls -d $i/share/doc/*/* ; done
/gnu/store/wyflz3f6bvrmy68zjzay7s2liz4idkks-guile-3.0.4-debug/share/doc/guile-3.0.4/COPYING
/gnu/store/wyflz3f6bvrmy68zjzay7s2liz4idkks-guile-3.0.4-debug/share/doc/guile-3.0.4/COPYING.LESSER
/gnu/store/wyflz3f6bvrmy68zjzay7s2liz4idkks-guile-3.0.4-debug/share/doc/guile-3.0.4/LICENSE
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/share/doc/guile-3.0.4/COPYING
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/share/doc/guile-3.0.4/COPYING.LESSER
/gnu/store/ah16zr8mmfkqy23rr7jy5a842ca1q9h1-guile-3.0.4/share/doc/guile-3.0.4/LICENSE
--8<---cut here---end--->8---

Perhaps there are corner cases or an issue specific to
‘ghc-build-system’?

Ludo’.

bug#42543: lint failure for packages on load path specified with -L

[Jack Hill]

On Sun, 23 Aug 2020, Ludovic Courtès wrote:

I’ve fixed the root issue with d10474c38d58bdc676e64336769dc2e00cdfa8ed 
(avoiding ‘canonicalize-path’).


Awesome, thank you!

bug#37388: can lead to syntactically invalid configs

[Ludovic Courtès]

Hello!

Christopher Baines  skribis:

> Ludovic Courtès  writes:
>
>> It’s nice that we have  but I noticed that, unlike
>> most or all other configuration records that we have, it’s possible to
>> create an  record that leads to a syntactically
>> invalid nginx config file.
>>
>> For example, if you have a location block like this:
>>
>> (nginx-location-configuration
>>   (uri "/manual/")
>>   (body (list "alias /srv/guix-manual")))
>>
>> Guix will silently create an invalid nginx config file, which you’ll
>> only notice once you’ve reconfigured and nginx fails to start.
>
> I wonder if some errors could be caught at build time, before attempting
> to start the service.
>
> If in the derivation to build the configuration file, nginx is run
> against the built config file with -t, that might spot errors at
> derivation build time.

Inspired, I tried the attached patch to do that.  However, that fails in
real-world situations, for example due to out-of-band references to
certificates:

--8<---cut here---start->8---
building /gnu/store/5k7w1l5ixg5vx1z7sdyabhgkpvvj7a5z-nginx.conf.drv...
nginx: [alert] could not open error log file: open() "run/logs/error.log" 
failed (2: No such file or directory)
2020/08/24 15:32:43 [warn] 7#0: the "user" directive makes sense only if the 
master process runs with super-user privileges, ignored in 
/gnu/store/c6zkj7rw37hh5a8mab9g37ca2aa33py0-unchecked-nginx.conf:1
2020/08/24 15:32:43 [emerg] 7#0: cannot load certificate 
"/etc/letsencrypt/live/berlin.guixsd.org/fullchain.pem": BIO_new_file() failed 
(SSL: error:02001002:system library:fopen:No such file or 
directory:fopen('/etc/letsencrypt/live/berlin.guixsd.org/fullchain.pem','r') 
error:2006D080:BIO routines:BIO_new_file:no such file)
nginx: configuration file 
/gnu/store/c6zkj7rw37hh5a8mab9g37ca2aa33py0-unchecked-nginx.conf test failed
Backtrace:
   2 (primitive-load "/gnu/store/4kb8dz6f6w5g50h8qghl35r1da0?")
In ice-9/eval.scm:
619:8  1 (_ #f)
In guix/build/utils.scm:
654:6  0 (invoke _ . _)

guix/build/utils.scm:654:6: In procedure invoke:
ERROR:
  1. :
  program: 
"/gnu/store/549pl4ch0zi3jjinpf1dckhxb1i0wp8f-nginx-1.19.2/sbin/nginx"
  arguments: ("-c" 
"/gnu/store/c6zkj7rw37hh5a8mab9g37ca2aa33py0-unchecked-nginx.conf" "-p" "run" 
"-t")
  exit-status: 1
  term-signal: #f
  stop-signal: #f
builder for `/gnu/store/5k7w1l5ixg5vx1z7sdyabhgkpvvj7a5z-nginx.conf.drv' failed 
with exit code 1
build of /gnu/store/5k7w1l5ixg5vx1z7sdyabhgkpvvj7a5z-nginx.conf.drv failed
--8<---cut here---end--->8---

I’m not sure what can be done.  Thoughts?

Ludo’.

diff --git a/gnu/services/web.scm b/gnu/services/web.scm
index 3b9f9e40be..e47acfe118 100644
--- a/gnu/services/web.scm
+++ b/gnu/services/web.scm
@@ -629,7 +629,7 @@ of index files."
  modules
  global-directives
  extra-content)
-   (apply mixed-text-file "nginx.conf"
+   (apply mixed-text-file "unchecked-nginx.conf"
   (flatten
"user nginx nginx;\n"
"pid " run-directory "/pid;\n"
@@ -662,6 +662,19 @@ of index files."
extra-content
"\n}\n"
 
+(define (validated-nginx-configuration-file nginx file)
+  "Return a copy of FILE, an nginx config file, after checking that it is
+syntactically correct."
+  (computed-file "nginx.conf"
+ (with-imported-modules '((guix build utils))
+   #~(begin
+   (use-modules (guix build utils))
+
+   (mkdir "run")
+   (invoke #+(file-append nginx "/sbin/nginx")
+   "-c" #$file "-p" "run" "-t")
+   (copy-file #$file #$output)
+
 (define %nginx-accounts
   (list (user-group (name "nginx") (system? #t))
 (user-account
@@ -694,8 +707,10 @@ of index files."
(mkdir-p (string-append #$run-directory "/logs"))
;; Check configuration file syntax.
(system* (string-append #$nginx "/sbin/nginx")
-"-c" #$(or file
-   (default-nginx-config config))
+"-c" #$(validated-nginx-configuration-file
+nginx
+(or file
+(default-nginx-config config)))
 "-p" #$run-directory
 "-t"
 
@@ -709,8 +724,10 @@ of index files."
(lambda args
  #~(lambda _
  (invoke #$nginx-binary "-c"
- #$(or file
-   (default-nginx-config config))
+ #$(validated-nginx-configuration-file
+nginx
+(or file
+(default-nginx-config config)))
  #$@args)
  (match '#$args
(("-s" . _) 

bug#43023: clang++ in a {clang-toolchain + gcc-toolchain} environment

[Emmanuel Agullo]

Hello, 

A typical "hello world" C++ fails in an environment with both 
`gcc-toolchain' and `clang-toolchain', apperently due to the setup of 
the `CPLUS_INCLUDE_PATH' environment variable (used because of the 
`#include ' instruction), when compiling with `clang++'. 

I do not know if this is a bug or the expected behaviour. Obviously one 
is not likely to explicitly load an environment with both `gcc-toolchain' 
and `clang-toolchain' but migth do so implictly (and possibly not being 
aware of it) for instance having `gcc-toolchain' globally installed and 
at some point loading `clang-toolchain' in an environment. 

Note that it is not critical at all in practice in my case, and I do 
not know whether it it is desirable to fix it in some way, or, maybe 
mention the incompatibility somewhere 
( ?) if not 
already done so – in which case I am sorry for the noise. 

Please find below: 
1. a simplified C++ "hello world" hello.cpp program 
2. an expected g++ behaviour in a `gcc-toolchain' environment 
3. an expected clang++ behaviour in a `clang-toolchain' environment 
4. an environment with both `gcc-toolchain' & `clang-toolchain' 
- 4.1. with an expected behaviour using `g++' 
- 4.2. with an (expected or not?) error using `clang++' 
- 4.3. a (non desirable) fix of the `CPLUS_INCLUDE_PATH' (removing 
`/gnu/store/…/include/c++') 
5. the employed channels if it may help 

Thanks much for the continous development and support, and once 
again sorry for the possible noise if this is a known expected 
behaviour. 

With best regards, 

Emmanuel 


1 simplified (no newline) C++ "hello world" hello.cpp program 
═ 

┌ 
│ #include  
│ 
│ int main() { 
│ std::cout << "Hello World!"; 
│ return 0; 
│ } 
└ 


2 `gcc-toolchain' environment 
═ 

┌ 
│ guix environment -C --ad-hoc gcc-toolchain coreutils grep 
│ env | grep CPLUS_INCLUDE_PATH 
│ g++ hello.cpp 
│ ./a.out 
└ 


 
CPLUS_INCLUDE_PATH=/gnu/store/gsylxn8q06w6y7622nw159f3q1vvcx2i-profile/include/c++:/gnu/store/gsylxn8q06w6y7622nw159f3q1vvcx2i-profile/include
 
Hello World! 

 


3 `clang-toolchain' environment 
═══ 

┌ 
│ guix environment -C --ad-hoc clang-toolchain coreutils grep 
│ env | grep CPLUS_INCLUDE_PATH 
│ clang++ hello.cpp 
│ ./a.out 
└ 


 
CPLUS_INCLUDE_PATH=/gnu/store/8qlafmilvc0g1yv8lmilpjmps3p4nrmq-profile/include 
Hello World! 

 


4 environment with both `gcc-toolchain' & `clang-toolchain' 
═══ 

4.1 compilation with `g++' 
── 

`g++' in an environment with both gcc and clang toolchains is fine: 
┌ 
│ guix environment -C --ad-hoc gcc-toolchain clang-toolchain coreutils grep 
│ env | grep CPLUS_INCLUDE_PATH 
│ g++ hello.cpp 
│ ./a.out 
└ 


 
CPLUS_INCLUDE_PATH=/gnu/store/3ka3a9wgx5sk6ac84nldx7ldpxppn29z-profile/include/c++:/gnu/store/3ka3a9wgx5sk6ac84nldx7ldpxppn29z-profile/include
 
Hello World! 

 


4.2 compilation with `clang++' (FAIL) 
─ 

But `clang++' in the same environment (with both gcc and clang 
toolchains) breaks, raising the following error: 
┌ 
│ guix environment -C --ad-hoc gcc-toolchain clang-toolchain coreutils grep 
│ clang++ hello.cpp 
└ 

Error obtained during the `clang++ hello.cpp' step: 
┌ 
│ In file included from hello.cpp:1: 
│ In file included from 
/gnu/store/3ka3a9wgx5sk6ac84nldx7ldpxppn29z-profile/include/c++/iostream:39: 
│ In file included from 
/gnu/store/3ka3a9wgx5sk6ac84nldx7ldpxppn29z-profile/include/c++/ostream:38: 
│ In file included from 
/gnu/store/3ka3a9wgx5sk6ac84nldx7ldpxppn29z-profile/include/c++/ios:39: 
│ 
/gnu/store/3ka3a9wgx5sk6ac84nldx7ldpxppn29z-profile/include/c++/exception:105:3:
 error: unknown type name '_GLIBCXX17_DEPRECATED' 
│ _GLIBCXX17_DEPRECATED 
│ ^ 
│ In file included from hello.cpp:1: 
│ In file included from 
/gnu/store/3ka3a9wgx5sk6ac84nldx7ldpxppn29z-profile/include/c++/iostream:39: 
│ In file included from 
/gnu/store/3ka3a9wgx5sk6ac84nldx7ldpxppn29z-profile/include/c++/ostream:38: 
│ 

bug#42595: conflicts in propagated imports must be resolved manually

[Ludovic Courtès]

Hi Arne & Efraim,

efraim Flashner  skribis:

> On Wed, Jul 29, 2020 at 09:54:07AM +0200, Dr. Arne Babenhauserheide wrote:
>> Hi,
>> 
>> When I get conflicts in propagated imports, I must follow a mechanical
>> multi-step process to resolve them manually.

[...]

>> LANG=C guix package -i guile-gi python-pycairo dbus-glib cairo 
>> guile-charting libsoup poppler pango
>> The following packages will be upgraded:
>>python-pycairo (dependencies or package changed)
>>dbus-glib  (dependencies or package changed)
>>cairo  (dependencies or package changed)
>>guile-charting (dependencies or package changed)
>>libsoup(dependencies or package changed)
>>poppler(dependencies or package changed)
>>pango  (dependencies or package changed)
>> 
>> The following package will be installed:
>>guile-gi 0.3.0
>> 
>> guix package: error: profile contains conflicting entries for glib
>> guix package: error:   first entry: glib@2.62.6 
>> /gnu/store/xr6zfqxklmr7skalljn5i071xmgqxbrm-glib-2.62.6
>> guix package: error:... propagated from cairo@1.16.0
>> guix package: error:... propagated from pango@1.44.7
>> guix package: error:   second entry: glib@2.62.6 
>> /gnu/store/q4100sjqcsdi6b232ndr93vxfzv9bzij-glib-2.62.6
>> guix package: error:... propagated from libnotify@0.7.7
>> 
>> 
>> This should be automated, so there would be just one step to add all
>> updates I need.
>
> Are all of the packages from the same guix commit? What if you try
> running 'guix package -u' to upgrade all your packages first and then
> installing new ones?

Also, Arne, it seems to me that Guix alone cannot decide how to solve
that conflict; it’s up to the user.  Thoughts?

Ludo’.

bug#26302: Multilingual web site is on-line!

[Ludovic Courtès]

Hallo!

"pelzflorian (Florian Pelz)"  skribis:

> On Sun, Aug 23, 2020 at 05:55:21PM +0200, Ludovic Courtès wrote:
>> Sorry for the long delay—vacations… so sweet. ;-)
>
> Sounds nice.  I wasn’t home either and the guix-website.pot is not
> online yet, but I believe the wheels are in motion already.
>
>
>> This version also LGTM.  Perhaps you can commit it tomorrow around noon,
>> when it’s more likely to be noticed than on a sunny (?) Sunday.
>
> I will wait for around noon on the day the TP publishes
> guix-website.pot.

Alright, makes sense!

Ludo’.

bug#26302: Multilingual web site is on-line!

[pelzflorian (Florian Pelz)]

On Sun, Aug 23, 2020 at 05:55:21PM +0200, Ludovic Courtès wrote:
> Sorry for the long delay—vacations… so sweet. ;-)

Sounds nice.  I wasn’t home either and the guix-website.pot is not
online yet, but I believe the wheels are in motion already.


> This version also LGTM.  Perhaps you can commit it tomorrow around noon,
> when it’s more likely to be noticed than on a sunny (?) Sunday.

I will wait for around noon on the day the TP publishes
guix-website.pot.

Regards,
Florian

bug#42996: icecat can escape from `guix environment --container`

[Julien Lepiller]

Then, closing. Thank you :)

Le 23 août 2020 21:15:55 GMT-04:00, luhux  a écrit :
>On Sun, Aug 23, 2020 at 11:38:47AM -0400, Julien Lepiller wrote:
>> One possibility is that you're seeing the virtual root filesystem,
>that thwuld only have a few direccories and the structure up to the
>directory you created your container in. Are you sure you can access
>files outside of the directory you started icecat in?
>> 
>> Another possiblity is that you had a running icecat outside of the
>container. In that case, calling icecat from tge container only opens a
>new window in the un-containerized icecat. Could it be what's
>happening?
>> 
>
>It is my fault.
>
>The icecat in the container is connected to the icecat outside the
>container, and then a new window is opened using the icecat outside the
>container
>
>Close the icecat outside the container, and then open the icecat inside
>the container, everything is correct.
>
>The problem is solved, thank you very much.
>
>luhux

bug#43015: git-fetched packages' working copy is not writable

[Efraim Flashner]

On Mon, Aug 24, 2020 at 11:13:59AM +0200, Danny Milosavljevic wrote:
> Hi,
> 
> the working copy of a package build when the package was git-fetched is not
> writable.
> 
> On the other hand, if it's url-fetched, it's perfectly writable.
> 
> Shall we fix this on core-updates ?

(ins)efraim@E5400 ~/workspace/guix$ git grep make-files-writable | grep unpack 
| grep gnu/packages
gnu/packages/bioinformatics.scm: (add-after 'unpack 'make-files-writable
gnu/packages/code.scm:(add-after 'unpack 
'make-files-writable
gnu/packages/djvu.scm: (add-after 'unpack 'make-files-writable
gnu/packages/java.scm: (add-after 'unpack 'make-files-writable
gnu/packages/java.scm: (add-after 'unpack 'make-files-writable
gnu/packages/java.scm: (add-after 'unpack 'make-files-writable
gnu/packages/java.scm: (add-after 'unpack 'make-files-writable
gnu/packages/machine-learning.scm: (add-after 'unpack 
'make-files-writable
gnu/packages/ocaml.scm: (add-after 'unpack 'make-files-writable
gnu/packages/ruby.scm:(add-after 'unpack 
'make-files-writable

My only concern would be if there were files which weren't supposed to
be writable. We're building the package, not making changes to be
submitted upstream or anything, so I don't see that as being a reason to
hold back.

I'm in favor



-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#43015: git-fetched packages' working copy is not writable

[Danny Milosavljevic]

Hi,

the working copy of a package build when the package was git-fetched is not
writable.

On the other hand, if it's url-fetched, it's perfectly writable.

Shall we fix this on core-updates ?


pgpQWtJOqkW8K.pgp
Description: OpenPGP digital signature

bug#43012: Scroll fails to produce expected output directory

[Efraim Flashner]

I've added something to the static output so the build no longer fails.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#43014: Install license files to all outputs

[Efraim Flashner]

It seems to me that the license file(s) should be installed to all the
outputs.

As a side effect, this would help mitigate the missing static output
with some of the haskell packages.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#42702: closed (Re: bug#42702: catch2 build failure on ARM)

[Efraim Flashner]

Closing this bug :)


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#43013: System reconfigure: expection reached when executing `start` on "file-system-/sys/kernel/debug" // and an unrelated "nouveau"-bug?

[o . rojon]

Hello everyone,

I'm recently running into problems updating my system. I had not 
reconfigured for a while (1~2 months) and now, when I reconfigure, I get 
the error message below.
At first I thought it might be related to a specific guix commit, but I 
have now tried four times over the course of 2 weeks, and I always get 
the same error.


Strangely enough, the only reason why I noticed something is not right 
is that nouveau's displaying behaviour would be weird after updating.
That is, it seems to either have changed my desktop resolution or 
applied a form of magnification on all text displayed (sddm, terminal, 
...)
I have no actual clue if these two things are related to each other AT 
ALL. I was just confused, because if they were totally unrelated,
I would struggle to understand why these two things happen concurrently 
;-)



While the error message is in german, I believe to have translated the 
more important chunks in the Subject field.


# error message #
guix system: Bootloader erfolgreich auf „/dev/sdb“ installiert
guix system: error: Ausnahme aufgetreten bei der Ausführung von „start“ 
auf Dienst „file-system-/sys/kernel/debug“:
Throw to key `match-error' with args `("match" "no matching pattern" 
("none" "/sys/kernel/debug" "debugfs" () #f #f #f))'.

###

As always, any help is appreciated. One good thing is that I finally 
learn the virtues of roll-back and switch-generation :)


Have a good day,
Olivier

bug#43005: make dist fails: "store file names embedded in the distribution"

[Jan Nieuwenhuizen]

Vagrant Cascadian writes:

Hello!

> When I tried to run make dist, it fails:
>
> guix-1.0.1.21330-a8c8f-dirty/gnu/packages/commencement.scm:
>   // 
> /gnu/store/cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a:
>  error: 'sigprocmask' defined t
>   error: store file names embedded in the distribution
>
> The attached patch triggers pretty extensive rebuilds, but should fix
> the problem.

Oops; your patch is fine (see nit-pick) for core-updates; but as you
noticed, on master we need to add an indirection to avoid rebuilds.
What about something like

--8<---cut here---start->8---
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index aa30e3fa18..48f9a47c6b 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -788,14 +788,16 @@ $MES -e '(mescc)' module/mescc.scm -- \"$@\"
  (substitute* "config.h"
(("#define GETCWD_BROKEN 1") "#undef GETCWD_BROKEN"))
  (let ((config.h (open-file "config.h" "a")))
-   (display (string-append "
+   ;; TODO: remove ,(string-append hack in next rebuild cycle
+   ;; together with store file name
+   (display (string-append ,(string-append "
 // tcc: error: undefined symbol 'enable_hostname_completion'
 #define enable_hostname_completion(on_or_off) 0
 
-// 
/gnu/store/cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a:
 error: 'sigprocmask' defined twice
+// /gnu/store/" 
"cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a: error: 
'sigprocmask' defined twice
 #define HAVE_POSIX_SIGNALS 1
 #define endpwent(x) 0
-")
+"))
 config.h)
(close config.h))
  #t))
--8<---cut here---end--->8---

Thanks for catching this!

Greetings,
Janneke

> From 6e77f342c0deca73fa608365bbceb14aaf675b21 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Sun, 23 Aug 2020 14:10:57 -0700
> Subject: [PATCH] gnu: commencement: bash-mesboot0: Remove store file name.

[..]

> diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
> index aa30e3fa18..617a12016f 100644
> --- a/gnu/packages/commencement.scm
> +++ b/gnu/packages/commencement.scm
> @@ -792,7 +792,7 @@ $MES -e '(mescc)' module/mescc.scm -- \"$@\"
>  // tcc: error: undefined symbol 'enable_hostname_completion'
>  #define enable_hostname_completion(on_or_off) 0
>  
> -// 
> /gnu/store/cq0cmv35s9dhilx14zaghlc08gpc0hwr-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a:
>  error: 'sigprocmask' defined twice
> +// /gnu/store/…-tcc-boot0-0.9.26-6.c004e9a/lib/libc.a: error: 'sigprocmask' 
> defined twice
>  #define HAVE_POSIX_SIGNALS 1
>  #define endpwent(x) 0
>  ")
^

This is the closing parenthesis of a string-append that has only this
one big string; what about removing that string-append altogether?

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