bug#36546: herd restart mcron appears to wipe /var/log/mcron.log

[Maxim Cournoyer]

Hello,

Robert Vollmert  writes:

> It appears that old mcron log output is lost when the service is
> restarted. That’s not good.
>
> See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36510 for
> another issue related to mcron logging.

I couldn't reproduce this with current mcron (1.2.1).

Closing.

Thank you,

Maxim

bug#49940: IceCat crashes when attempting to activate 'reader view' via shortcut

[Maxim Cournoyer]

Hello,

I can reproduce this for some time, currently using IceCat
78.12.0-guix0-preview1.

Repro:

1. Open a web page in IceCat.
2. Press the 'Control + Alt + r' keys altogether to enable the 'reader
view' mode.
3. Observe a crash.

Thank you,

Maxim

bug#40997: [raid] The bootloader can only be installed to a single drive

[Maxim Cournoyer]

Hello,

maxim.courno...@gmail.com writes:

> Using Guix System, the bootloader declaration doesn't currently seem to
> support being installed to multiple drives:
>
> (bootloader (bootloader-configuration
>  (bootloader grub-bootloader)
>  (target "/dev/sda")
>  (terminal-outputs '(console
>  --8<---cut here---end--->8---
>
> I suggest to change it so that target can be passed a list like
>
> (bootloader (bootloader-configuration
>  (bootloader grub-bootloader)
>  (target '("/dev/sda" "/dev/sdb"))
>  (terminal-outputs '(console
>  --8<---cut here---end--->8---
>
> This is useful when trying to boot a degraded RAID array.

The following patches do exactly this (target becomes the plural
targets).  I tested it on my system, disconnecting the first drive of my
RAID1 array, and could at least boot to GRUB fine (although full boot
failed due to https://issues.guix.gnu.org/40999).

Booting a VM using an image generated from the bare-bones.tmpl template
also worked fine.

>From a14403fdabbe987cb94a75977e7e62a0e0954e6b Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer 
Date: Fri, 6 Aug 2021 16:33:02 -0400
Subject: [PATCH 1/2] gnu: bootloader: Support multiple targets.

Fixes .

* gnu/bootloader.scm (): New 'targets' field.
(%bootloader-configuration-target): New procedure.
(bootloader-configuration-target): Add deprecation warning.
(bootloader-configuration-targets): New procedure.
* guix/scripts/system.scm (install): Access targets via
bootloader-configuration-targets.
(perform-action)[bootloader-target]: Remove unused argument and update doc.
Access targets via bootloader-configuration-targets and fix indentation.
(process-action): Access targets via bootloader-configuration-targets.
Do not provide the unused BOOTLOADER-TARGET argument when applying
`perform-action'.
* guix/scripts/system/reconfigure.scm (install-bootloader-program): Rename
DEVICE argument to DEVICES.  Adjust doc and comment.  Apply `installer' and
`disk-installer' for every DEVICES.
(install-bootloader): Access targets via bootloader-configuration-targets and
rename variable from DEVICE to DEVICES.
* gnu/tests/install.scm: Adjust accordingly.
* tests/guix-system.sh: Likewise.
* gnu/tests/reconfigure.scm (run-install-bootloader-test): Adjust the DEVICES
argument so that it is a list.
* doc/guix.texi: Update doc.
---
 doc/guix.texi   | 91 +++--
 gnu/bootloader.scm  | 22 ++-
 gnu/tests/install.scm   | 26 -
 gnu/tests/reconfigure.scm   |  2 +-
 guix/scripts/system.scm | 20 +++
 guix/scripts/system/reconfigure.scm | 22 ---
 tests/guix-system.sh|  6 +-
 7 files changed, 108 insertions(+), 81 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index a826171f34..a9309d4d0c 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2567,14 +2567,15 @@ in particular:
 
 @itemize
 @item
-Make sure the @code{bootloader-configuration} form refers to the target
-you want to install GRUB on.  It should mention @code{grub-bootloader} if
-you are installing GRUB in the legacy way, or @code{grub-efi-bootloader}
-for newer UEFI systems.  For legacy systems, the @code{target} field
-names a device, like @code{/dev/sda}; for UEFI systems it names a path
-to a mounted EFI partition, like @code{/boot/efi}; do make sure the path is
-currently mounted and a @code{file-system} entry is specified in your
-configuration.
+Make sure the @code{bootloader-configuration} form refers to the targets
+you want to install GRUB on.  It should mention @code{grub-bootloader}
+if you are installing GRUB in the legacy way, or
+@code{grub-efi-bootloader} for newer UEFI systems.  For legacy systems,
+the @code{targets} field contain the names of the devices, like
+@code{(list "/dev/sda")}; for UEFI systems it names the paths to mounted
+EFI partitions, like @code{(list "/boot/efi")}; do make sure the paths
+are currently mounted and a @code{file-system} entry is specified in
+your configuration.
 
 @item
 Be sure that your file system labels match the value of their respective
@@ -13478,7 +13479,7 @@ the @code{bootloader} field should contain something along these lines:
 @lisp
 (bootloader-configuration
   (bootloader grub-efi-bootloader)
-  (target "/boot/efi"))
+  (targets '("/boot/efi")))
 @end lisp
 
 @xref{Bootloader Configuration}, for more information on the available
@@ -14693,7 +14694,7 @@ configuration would look like:
   (keyboard-layout (keyboard-layout "tr"))  ;for the console
   (bootloader (bootloader-configuration
 (bootloader grub-efi-bootloader)
-(target "/boot/efi")
+(targets '("/boot/efi"))
 (keyboard-layout keyboard-layout))) ;for GRUB
   (services (cons 

bug#40858: Cargo in Guix

[Maxim Cournoyer]

Hello,

Julien Lepiller  writes:

> Le 25 avril 2020 18:17:16 GMT-04:00, Jan Ole Zabel  a 
> écrit :
>>Hi,
>>
>>I just installed the rust package on guix-system and realized I have no
>>idea of how to use `cargo` to build something. First, cargo is not in
>>my
>>search path after installing `rust`, because there is no link in
>>`.guix-profile`. There is no dedicated package either. 
>
> The rust package has multiple outputs. Its default output doesn't
> contain cargo, but it has a cargo output which you found in the
> store. You can install it with:
>
> guix install rust:cargo
>
>>Second, the
>>cargo binary installed in `/gnu/store/` throws the following:
>>
>>  $ /gnu/store/*-rust-1.39.0-cargo/bin/cargo install ripgrep
>>  error: failed to download from
>>`https://crates.io/api/ripgrep/12.0.1/download`
>>  
>>  Caused by:
>>[60] SSL peer certificate or SSH remote key not found (server
>>certificate verification failed. CAfile: none CRLFile: none)
>>
>>A `curl https://crates.io` works normally, so it's not an issue with
>>the
>>system certificates.
>
> My guess is that curl comes from your foreign system? Guix packages
> don't read the global location. Have you performed these additional
> steps after installing guix?
>
> http://guix.gnu.org/manual/en/html_node/X_002e509-Certificates.html#X_002e509-Certificates
>
>>
>>Am I doing something wrong? Is this even the right place to report or
>>ask?
>
> guix-help would have been a better place for this one I think.
>
> I hope this helped a bit :)

Thanks to Julien for the assistance.

Closing this forgotten issue.

Maxim

bug#40966: Missing substitutes on ci.guix.gnu.org?

[Maxim Cournoyer]

Hi Leo,

Leo Famulari  writes:

> I've noticed that certain packages never seem to have substitutes
> available from ci.guix.gnu.org.
>
> This is not about packages that consistently fail to build, like Vigra
> (LibreOffice) [0], but packages that never seem to be attempted at all,
> and are not found when searching on the CI results.
>
> For example, ncmpcpp has not been built since February 2020:
>
> https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+ncmpcpp
>
> And Borg has apparently never been built:
>
> https://ci.guix.gnu.org/search?query=spec%3Aguix-master+system%3Ax86_64-linux+borg
>
> By the way, the dates that are shown in this interface do not display
> the year (can we fix that?):
>
> https://ci.guix.gnu.org/build/2275489/details
>
> [0] 

Do you still encounter these issues with current Cuirass?

If not, let's close this issue!

Thanks,

Maxim

bug#31825: guix offload fails with guix-authenticate error

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Just as a follow-up; I've managed to fall into this trap again,
> attempting to authorize the keys by adding them to the 'authorize-keys'
> field of guix-configuration record.
>
> On the local machine:
>
> guix offload test /etc/guix/machines.scm 127.0.0.1
> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
> guix offload: Guix is usable on '127.0.0.1' (test returned 
> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
> guix offload: '127.0.0.1' is running GNU Guile 3.0.0
> sending 1 store item (0 MiB) to '127.0.0.1'...
> exporting path `/gnu/store/l9mph3k5l26nm8mb50imsklbsz0bji0b-export-test'
> guix offload: error: program 
> `/gnu/store/amjsgks2n05k9lkck78z64nphad1dkqr-guix-1.0.1-13.50299ad/bin/guix' 
> failed with exit code 1
>
>
> On the remote machine:
>
> sudo strace -p 15683 -p 15716 -f -s345 -o /tmp/log
>
> And found within /tmp/log:
>
> 16120 write(2, "guix authenticate: error: error: unauthorized public
> key: (public-key \n (ecc \n (curve Ed25519)\n (q #MY-PUBLIC-KEY#)\n
> )\n )\n", 176) = 176
>
> So, still actual :-)
>
> Maxim

I think many things have been improved in the diagnostics of guix
offload since the original report.  The last gotcha I had hit described
above appears to had been caused by the keys added to the
'authorized-keys' field of the 'guix-configuration' record not being
taken into account when a /etc/guix/acl file was already populated (it
used to not be declarative).

Closing this forgotten issue.

Thanks,

Maxim

bug#39738: ffmpeg-4.2.2 fails to build on native i686-linux

[Maxim Cournoyer]

Hi,

Jan Nieuwenhuizen  writes:

> Hi,
>
> When building ffmpeg-4.2.2 (current master, 
> 8d1b22b27fba3d1e4310f02a5897d231b42ca117)
> natively on 32bit hardware, the build fails because of two failing tests
> (full log attached)
>
> --- ./tests/ref/fate/filter-pixdesc-grayf32be 2019-12-31 21:35:25.0 
> +
> +++ tests/data/fate/filter-pixdesc-grayf32be  2020-02-22 15:15:50.209912771 
> +
> @@ -1 +1 @@
> -pixdesc-grayf32be   9b23c74e8e8ffae5d7c7e82bbf5929da
> +pixdesc-grayf32be   01816b882016239d0cf84241818926a4
> --- ./tests/ref/fate/filter-pixdesc-grayf32le 2019-12-31 21:35:25.0 
> +
> +++ tests/data/fate/filter-pixdesc-grayf32le  2020-02-22 15:15:50.253914049 
> +
> @@ -1 +1 @@
> -pixdesc-grayf32le   291f074a24c44799a1f437d1c6f1
> +pixdesc-grayf32le   1b234318d06d5a76e980c376ad8764e5
> Test filter-pixdesc-grayf32be failed. Look at 
> tests/data/fate/filter-pixdesc-grayf32be.err for details.
> make: *** [tests/Makefile:238: fate-filter-pixdesc-grayf32be] Error 1
> make: *** Waiting for unfinished jobs
> Test filter-pixdesc-grayf32le failed. Look at 
> tests/data/fate/filter-pixdesc-grayf32le.err for details.
> make: *** [tests/Makefile:238: fate-filter-pixdesc-grayf32le] Error 1
>
> Test suite failed, dumping logs.
> command "make" "fate" "-j" "2" failed with status 2
>
> How to attempt fixing this?
>
> Building it on 64 bit hardware (much faster!) works for me, i.e. this
>
> guix build --system=i686-linux ffmpeg
>
> works for me and can be used as a substitute...

I don't have real 32 bits hardware to test on, but could you please test
ffmpeg 4.4 on such hardware if you have a chance and see if the issues
still exist?

Thanks,

Maxim

bug#49935: [PATCH] gnu: gcc-4.8: Fix build with GCC 6 and later

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Versions of GCC earlier than 6 need this change in order to be built by GCC
6 and later. At the time, the fix was backported to GCC 4.9 and GCC 5 but
not GCC 4.8.

Therefore, backport the fix from GCC 4.9 to GCC 4.8.

* gnu/packages/gcc.scm (gcc-4.8)[source]: Apply
gcc-4.8-fix-build-with-newer-gcc.patch.
* gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add new file.
---

Hi,

This is the patch I mentioned in my previous email. Despite the subject
and the name of the patch file, this change is necessary but unfortunately
not sufficient to make GCC 4.8 build with GCC 6 or later.

This patch solves the same problem as gcc-4-compile-with-gcc-5.patch and
gcc-4.6-gnu-inline.patch (which are actually the exact same patch).

Regards,
Thiago

 gnu/local.mk  |   1 +
 gnu/packages/gcc.scm  |   4 +-
 .../gcc-4.8-fix-build-with-newer-gcc.patch| 181 ++
 3 files changed, 185 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 61ac39618a73..663f48f1833c 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1059,6 +1059,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/gcc-cross-environment-variables.patch   \
   %D%/packages/patches/gcc-fix-texi2pod.patch  \
   %D%/packages/patches/gcc-4.8-libsanitizer-fix.patch  \
+  %D%/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch  \
   %D%/packages/patches/gcc-4.9-libsanitizer-fix.patch  \
   %D%/packages/patches/gcc-4.9-libsanitizer-ustat.patch\
   %D%/packages/patches/gcc-libsanitizer-ustat.patch\
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index 2fe30b13210e..586673042a1c 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -383,7 +383,9 @@ Go.  It also includes runtime support libraries for these 
languages.")
   (patches (search-patches "gcc-arm-link-spec-fix.patch"
"gcc-4.8-libsanitizer-fix.patch"
"gcc-asan-missing-include.patch"
-   "gcc-fix-texi2pod.patch"))
+   "gcc-fix-texi2pod.patch"
+   ;; See 
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-02/msg01409.html
+   
"gcc-4.8-fix-build-with-newer-gcc.patch"))
   (modules '((guix build utils)))
   ;; This is required for building with glibc-2.26.
   ;; https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81712
diff --git a/gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch 
b/gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch
new file mode 100644
index ..e2fe2af03d08
--- /dev/null
+++ b/gnu/packages/patches/gcc-4.8-fix-build-with-newer-gcc.patch
@@ -0,0 +1,181 @@
+From 4c212bc2507fc8ab8caba7c5afc1257707572c45 Mon Sep 17 00:00:00 2001
+From: Bernd Edlinger 
+Date: Thu, 25 Feb 2016 15:36:41 +
+Subject: [PATCH] backport: Make-lang.in: Invoke gperf with -L C++.
+
+2016-02-25  Bernd Edlinger  
+
+Backported from mainline
+2016-02-19  Jakub Jelinek  
+Bernd Edlinger  
+
+* Make-lang.in: Invoke gperf with -L C++.
+* cfns.gperf: Remove prototypes for hash and libc_name_p
+inlines.
+* cfns.h: Regenerated.
+* except.c (nothrow_libfn_p): Adjust.
+
+From-SVN: r233721
+---
+
+Obtained from:
+
+https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=4c212bc2507fc8ab8caba7c5afc1257707572c45
+
+The gcc/cp/ChangeLog hunk was modified to apply on top of gcc-4.8's 
gcc/cp/ChangeLog.
+
+ gcc/cp/ChangeLog| 12 
+ gcc/cp/Make-lang.in |  2 +-
+ gcc/cp/cfns.gperf   | 10 ++
+ gcc/cp/cfns.h   | 41 ++---
+ gcc/cp/except.c |  3 ++-
+ 5 files changed, 31 insertions(+), 37 deletions(-)
+
+diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
+index 02776465da7..8d014bef83c 100644
+--- a/gcc/cp/ChangeLog
 b/gcc/cp/ChangeLog
+@@ -1,3 +1,15 @@
++2016-02-25  Bernd Edlinger  
++
++  Backported from mainline
++  2016-02-19  Jakub Jelinek  
++  Bernd Edlinger  
++
++  * Make-lang.in: Invoke gperf with -L C++.
++  * cfns.gperf: Remove prototypes for hash and libc_name_p
++  inlines.
++  * cfns.h: Regenerated.
++  * except.c (nothrow_libfn_p): Adjust.
++
+ 2015-06-23  Release Manager
+ 
+   * GCC 4.8.5 released.
+diff --git a/gcc/cp/Make-lang.in b/gcc/cp/Make-lang.in
+index bd1c1d78f88..a0ea0d48359 100644
+--- a/gcc/cp/Make-lang.in
 b/gcc/cp/Make-lang.in
+@@ -111,7 +111,7 @@ else
+ # deleting the $(srcdir)/cp/cfns.h file.
+ $(srcdir)/cp/cfns.h:
+ endif
+-  gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L ANSI-C \
++  

bug#49935: gcc-4.8 fails to build with recent GCC versions

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hello,

According to the CI results, gcc-4.8 hasn’t built successfuly in a while:

https://ci.guix.gnu.org/search?query=gcc-4.8

I was able to fix the current build failure:

--8<---cut here---start->8---
In file included from ../../gcc-4.8.5/gcc/cp/except.c:1008:0:
cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’:
cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ 
redeclared inline with ‘gnu_inline’ attribute
cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’ 
previously declared here
--8<---cut here---end--->8---

by backporting a patch from GCC 4.9 (which I will send in the next email),
but then I hit another failure:

--8<---cut here---start->8---
In file included from 
/tmp/guix-build-gcc-4.8.5.drv-0/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/cstdlib:72:0,
 from ../../../../gcc-4.8.5/libstdc++-v3/libsupc++/del_op.cc:38:
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:38:12:
 error: ‘std::abort’ has not been declared
 using std::abort;
^
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:39:12:
 error: ‘std::atexit’ has not been declared
 using std::atexit;
^
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:40:12:
 error: ‘std::exit’ has not been declared
 using std::exit;
^
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:51:12:
 error: ‘std::div_t’ has not been declared
 using std::div_t;
^
/gnu/store/358n1m2c8fbn6nr1mib4racjh7wfqfmy-gcc-10.3.0/include/c++/stdlib.h:52:12:
 error: ‘std::ldiv_t’ has not been declared
 using std::ldiv_t;
^
⋮
--8<---cut here---end--->8---

and so on, for several `std::` functions. Unlike the other old GCC build
failures I’ve investigated recently, I couldn’t find anyone else hitting
this specific problem. So we would have to create our own patch to fix it.

This message from Jakub Jelinek about a similar error in some unspecified
package:

https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/Q2U4JFUB5RL7DU2XJZ4BDTRE4PVULOMG/

makes me think that there’s something in GCC 4.8’s libstdc++ (probably
in libsupc++) doing something wrong with  which trips GCC 6
and later.

However, I don’t think it’s worth making GCC 4.8 build again. It’s not
supported upstream anymore and if it’s needed in some bootstrap path,
it’s better to move it to ‘(gnu packages commencement)’ instead. In that
case, instead of fixing this build issue it’s likely better to just build
it with a GCC older than version 6.

Is it needed for bootstrap though? The definition of ‘%bootstrap-gcc’
suggests that it’s needed at least for armhf-linux but since aarch64-linux,
powerpc64le-linux and even i586-hurd use GCC 5.5, I suspect it would also
work for armhf-linux as well.

Therefore, my suggestion is to simply remove gcc-4.8.

-- 
Thanks,
Thiago

bug#49815: Upcoming timekeeping failure in gpsd

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hi Sarah,

Em sábado, 7 de agosto de 2021, às 00:13:16 -03, Sarah Morgensen escreveu:

> > @@ -259,6 +261,7 @@ such as elevation, speed, heart rate, power,
> > temperature, and gear shifts.")> 
> > (modify-phases %standard-phases
> > 
> >   (add-after 'unpack 'fix-build
> >   
> > (lambda* (#:key outputs #:allow-other-keys)
> > 
> > + (setenv "TAR" "noop")
> > 
> >   (substitute* "SConstruct"
> 
>   ^ Should be "SConscript"
> 
> This fixes the build.

Nice!

> > (("envs = \\{\\}")
> >  "envs = os.environ"))

IIUC this takes care of propagating $C_INCLUDE_PATH to gcc. I should have 
noticed it before. :facepalm:

> Hope that helps!

Thank you!

-- 
Thanks,
Thiago

bug#49815: Upcoming timekeeping failure in gpsd

[Leo Famulari]

On Fri, Aug 06, 2021 at 08:13:16PM -0700, Sarah Morgensen wrote:
> >   (substitute* "SConstruct"
>   ^ Should be "SConscript"
> 
> This fixes the build.
> 
> > (("envs = \\{\\}")
> >  "envs = os.environ"))
> 
> Hope that helps!

Aha!

Thanks to you and Thiago for your help with this!

Fixed with 178cbc30d4e4f4a5d718ae220894544709483ef7.

bug#49913: python-networkx test failing

[Maxime Devos]

Hi,

> > networkx/algorithms/shortest_paths/tests/test_weighted.py:29: AssertionError
> > === 1 failed, 3517 passed, 182 skipped in 246.61s (0:04:06) 
> > 
> > command "pytest" "-vv" "--pyargs" "networkx" failed with status 1
> 
> I've the following setup:
> 
> Host distribution: Parabola i686 with an x86_64 kernel (linux-libre-64)
> Guix: Guix i686

I can reproduce on i686 (--system=i686-linux) but not x86_64.
The test failure appears to be determenistic but architecture-dependent.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#49771: [bug#49804] [PATCH] services: pam-limits: fix limits.conf location

[Julien Lepiller]

Le Sun, 01 Aug 2021 06:14:00 +0300,
muradm  a écrit :

> * gnu/services/base.scm: fix limits.conf location
> 
> This fixes #49771
> 

Pushed as 29883f113087edaf24570fbd7f1113df907f1099, thank you!

bug#49916: etc/committer: backtrace on gexp

[Ricardo Wurmus]

Maxime Devos  writes:


Sarah Morgensen schreef op vr 06-08-2021 om 12:18 [-0700]:

Hello Guix,

(Ricardo, I've Cc'd you since it seems etc/committer.scm is 
mostly your

work.)

It looks like etc/committer.scm is choking on gexps on 
core-updates-frozen:

[...]


The patch  should fix this.


I’ve just pushed that one.  Thank you!

--
Ricardo

bug#49910: Fwd: Re: [website] script generating POT files broken with guile@3.0.7

[pelzflorian (Florian Pelz)]

On Fri, Aug 06, 2021 at 02:16:16PM +0200, Leo Prikler wrote:
> > guile -c '(with-input-from-string ",@" (lambda () (read)))'
> The trick that I'm applying is to call syntax->datum on the return
> value of (read).

This must be a different error because guile errors out without return
value, but thank you for making me read the guile NEWS file again.  I
had forgotten there was a rewrite of (read).

I have pushed a workaround to guix-artwork as
f66b87373b33974751d2567f8c433ce44d07f10a and will take another look at
guile’s behavior now.

Regards,
Florian

bug#49916: etc/committer: backtrace on gexp

[Maxime Devos]

Sarah Morgensen schreef op vr 06-08-2021 om 12:18 [-0700]:
> Hello Guix,
> 
> (Ricardo, I've Cc'd you since it seems etc/committer.scm is mostly your
> work.)
> 
> It looks like etc/committer.scm is choking on gexps on core-updates-frozen:
> [...]

The patch  should fix this.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part