bug#55649: Feature request: filter channel on "guix pull"

[Maxime Devos]

severity 55649 wishlist
thanks



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

bug#55441: [cuirass] hang in "In progress..."; runs out of pgsql connections

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> Maybe the store connection caching could be optional when calling
> inferior-eval-with-store, and that could also switch between using
> open-pipe* and primitive-fork for starting the inferior process.

I don’t think that’s desirable as an interface.  To me, the proper fix
will be to use an interface like ‘posix_spawn’ so we can have both
correctness and speed, rather than let users choose.

Ludo’.

bug#33094: latex-koma-script: scrlttr2: ERROR: Argument of \strip@prefix has an extra }.

[Lars-Dominik Braun]

Hi Ricardo,

this problem is biting me too now.

> > % This line is new.  Set the language!
> > \usepackage[british]{babel}
> 
> It is in fact sufficient to add only this line
> 
>\def\languagename{english}
> 
This workaround only works fine for scrlttr2, but unfortunately not for
scrbook, scrartcl, … Any idea?

Cheers,
Lars

bug#55441: [cuirass] hang in "In progress..."; runs out of pgsql connections

[Ludovic Courtès]

Ludovic Courtès  skribis:

> For now, I’m going to go with the solution below, which is to use an
> older revision of Guix (one where ‘open-inferior’ was using
> ‘open-pipe*’) as the dependency of the ‘cuirass’ package.
>
> I’m running “cuirass evaluate” manually on berlin to make sure it
> actually works.  If everything goes well, I’ll push it and reconfigure
> berlin later today or tomorrow.

Pushed commit as dcb7ce1eb6911f9d503e7cd2bfe380058cee956b.

I reconfigured berlin a couple of hours ago:

--8<---cut here---start->8---
ludo@berlin ~/src/maintenance/hydra$ guix system describe
Generation 576  May 26 2022 12:50:31(current)
  file name: /var/guix/profiles/system-576-link
  canonical file name: /gnu/store/dd4p4cw67p5wbwwv7szgz0zxsvkq78zb-system
  label: GNU with Linux-Libre 5.17.9
  bootloader: grub
  root device: label: "my-root"
  kernel: /gnu/store/si7fz3pxwq5aiqpdwkw0qs4jmsqh89n5-linux-libre-5.17.9/bzImage
  channels:
guix:
  repository URL: https://git.savannah.gnu.org/git/guix.git
  branch: master
  commit: 2262ee2c63fd92a17836ff7450623db76ed39d92
  configuration file: 
/gnu/store/sd59z8h741jilaa3cdf16441f84xghil-configuration.scm
ludo@berlin ~/src/maintenance/hydra$ git log |head -5
commit 07f587cb266f284dee6ac2e744161973d3512b04
Author: Ludovic Courtès 
Date:   Tue May 24 14:57:36 2022 +0200

hydra: Add missing service type 'description' field.
--8<---cut here---end--->8---

There’s been a couple of evaluations (346596 and 346651 in the ‘master’
jobset) and so far things seem to work smoothly.

Let’s keep monitoring.

Ludo’.

bug#55480: Search sort order

[Ludovic Courtès]

Hi Greg,

Greg Hogan  skribis:

> 'guix search' should sort by score, name, and version so that, for
> example, 'guix search llvm' returns llvm@14.0.1 before llvm@9.0.1.
> Currently the versions are sorted lexicographically rather than by
> numerical value.

Done in 4e13ee4b573f1829fbf41147febac9ca8b919034, thanks.

Ludo’.

bug#55657: libgccjit is unusable

[Liliana Marie Prikler]

Hi Guix,

with the release of Emacs 28.1, there has been some demand to enable
native-compilation.  While trying to set that up, I've come to realize
that no matter how I slice it, I can't make libgccjit usable.

My test:

$ cd /tmp
$ # fetch the "Hello World" [1] and insert it into gccjit-test.c
$ guix shell --pure gcc-toolchain@9 libgccjit@9 -- \
  gcc gccjit-test.c -o gccjit-test -lgccjit
$ ./gccjit-test
x86_64-unknown-linux-gnu-gcc-9.4.0: fatal error: cannot execute 'as':
execvp: No such file or directory
compilation terminated.

Welp, okay, so maybe testing gccjit outside of its installation does
not work.  What if we try it inside the shell (we can always propagate
libgccjit, no?)

guix shell gcc-toolchain@9 libgccjit@9 -- ./gccjit-test
ld: cannot find crtbeginS.o: Datei oder Verzeichnis nicht gefunden
ld: cannot find -lgcc
ld: cannot find -lgcc
collect2: Fehler: ld gab 1 als Ende-Status zurück
libgccjit.so: error: error invoking gcc driver
NULL result

For the record, Emacs 28 fails with a different error during
configuration, though interestingly they use a smaller program and
appear to omit -lgccjit.
./conftest: error while loading shared libraries: libgccjit.so.0:
cannot open shared object file: No such file or directory

I'm at a loss.  Is there any way to make libgccjit actually usable?

[1] https://gcc.gnu.org/onlinedocs/jit/intro/tutorial01.html

bug#55587: bug#55596: Guix/Guile segfaults on `guix import texlive`

[Jack Hill]

On Wed, 25 May 2022, Hugo wrote:


Ludovic Courtès  writes:


Jack, Hugo: What does “type -P svn” say?

Does the bug occur within ‘guix shell subversion’ as shown above?


Well, I feel kind of silly now, after actually installing subversion the
command works as expected :)


Same for me, and I feel equally silly :)


But I suppose the silent failure is still something that could/should be
improved.


+1 for this. Maybe some day we'll have have guile-svn, but until then an 
error message would be fine.


Best,
Jack

bug#55359: How do I extend openssh-service-type ?

[Ludovic Courtès]

Hi,

Oleg Pykhalov  skribis:

>> (service-extension openssh-service-type
>>(const `(("charlie"
>>  ,(local-file "charlie.pub")
>> #+end_quote
>
> […]
>
> Seems like extend-openssh-authorized-keys procedure does not use keys
> argument. We could fix it like:

For the record, this bug (dismissing the ‘keys’ argument) was introduced
in b4b2bbf4fb74c9f3e93d64863ab9b38957494b49 (Oct. 2021).

How come nobody noticed then?

The reason is that starting from
b4b2bbf4fb74c9f3e93d64863ab9b38957494b49, ‘authorized-key-directory’
would create an empty directory.  That directory would then be copied by
‘openssh-activation’ to /etc/ssh/authorized_keys.d; since
/etc/ssh/authorized_keys.d would typically already contain the relevant
keys, nothing bad would happen.

Oleg’s commit 1f29ed4a812f86c45e2d9c37fd9f80f6d0418293 introduced
another bug though: we’d create an authorized-key directory that
included keys brought by extensions, but each of these files would be
empty (because ‘extend-openssh-authorized-keys’ would dismiss key files
associated with user names), which could lock yourself out.

Fixed in 0dc63ce519c5f98b2186d1871176e2fac3a6926b.  Reconfiguration
recommended before you’re locked out!

Thanks,
Ludo’.

bug#55661: /etc/ssh/authorized_keys.d contains keys that have been removed

[Ludovic Courtès]

In the wake of , I realized that
/etc/ssh/authorized_keys.d is stateful: we copy files from the
authorized-key directory there, but files already present remain.
IOW, keys remain authorized.

Why are we copying that directory instead of making a symlink to the
directory computed by ‘authorized-key-directory’ that’s in /gnu/store?

This is explained in ‘openssh-activation’:

;; 'sshd' complains if the authorized-key directory and its parents
;; are group-writable, which rules out /gnu/store.  Thus we copy the
;; authorized-key directory to /etc.

Anyway, that code does intend remove the directory before copying it,
but there’s a typo:

  (delete-file-recursively "/etc/authorized_keys.d")

Can you spot it?

Ludo’.

bug#55638: time-machine: backtrace about maybe-remove-expired-cache-entries

[Ludovic Courtès]

Hi,

zimoun  skribis:

> In guix/cache.scm:
> 39:10  3 (maybe-remove-expired-cache-entries "/home/sitour/.cac…" …)
> In srfi/srfi-19.scm:
>287:16  2 (time-normalize! #)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure <: Wrong type argument in position 2: #
>
>
> Then ~/.cache/guix/inferiors/last-expiry-cleanup is empty
>
> $ cat ~/.cache/guix/inferiors/last-expiry-cleanup 

This file was empty when you ran the command instead of containing an
integer (could have been a file system corruption or something like
that).

Solution:

  rm ~/.cache/guix/inferiors/last-expiry-cleanup

HTH!

Ludo’.

bug#55638: time-machine: backtrace about maybe-remove-expired-cache-entries

[Maxime Devos]

Ludovic Courtès schreef op do 26-05-2022 om 17:05 [+0200]:
> This file was empty when you ran the command instead of containing an
> integer (could have been a file system corruption or something like
> that).
> 
> Solution:
> 
>   rm ~/.cache/guix/inferiors/last-expiry-cleanup

It's a work-around, but there's still an underlying problem: 
guix/cache.scm doesn't do 'fsync+rename', so the file is not created
atomically, so in case of an abrupt shutdown or C-c at the wrong time,
the file becomes corrupted without fault of the file system.

As such, WDYT of making last-expiry-date more robust, by treating
invalid contents as time=0 or something like that?

Greetings,
Maxime.


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

bug#55661: /etc/ssh/authorized_keys.d contains keys that have been removed

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Anyway, that code does intend remove the directory before copying it,
> but there’s a typo:
>
>   (delete-file-recursively "/etc/authorized_keys.d")

Fixed in 4577f3c6b60ea100e521c246fb169d6c05214b20.

Ludo'.

bug#55664: emacs-deferred: hangs during build

[Christopher Howard]

emacs-deferred build hangs - during the check phase, I think:

```
starting phase `check'
ert-runner test/deferred-test.el
emacs -batch -L . -f batch-byte-compile deferred.el
ert-runner test/concurrent-test.el
Loading 
/gnu/store/vmqx1zhw3gn2xzslzzgdgbmk15ry6347-emacs-ert-expectations-0.2/share/emacs/site-lisp/ert-expectations-0.2/ert-expectations-autoloads...
Loading 
/gnu/store/sqq9wb1fmmfpqnliz2zslh1j12ppib53-emacs-ert-runner-0.8.0/share/emacs/site-lisp/ert-runner-0.8.0/ert-runner-autoloads...
Loading 
/gnu/store/hxmwyw6vfla0c5z2b7w1h59yym0739vs-emacs-undercover-0.8.1/share/emacs/site-lisp/undercover-0.8.1/undercover-autoloads...
Loading 
/gnu/store/sh2bgdrxpzgdkr5nlyh6q2xw02vj5zk4-emacs-shut-up-0.3.3/share/emacs/site-lisp/shut-up-0.3.3/shut-up-autoloads...
Loading 
/gnu/store/v8faj6q8qx6zmb6cg63zfgpzryflkdw4-emacs-dash-2.19.1/share/emacs/site-lisp/dash-2.19.1/dash-autoloads...

In deferred:cancelTimeout:
deferred.el:118:8: Warning: docstring wider than 80 characters

In deferred:status:
deferred.el:427:8: Warning: docstring wider than 80 characters

In deferred:nextc:
deferred.el:459:8: Warning: docstring wider than 80 characters

In deferred:error:
deferred.el:464:8: Warning: docstring wider than 80 characters

In deferred:watch:
deferred.el:469:8: Warning: docstring wider than 80 characters

In deferred:earlier-main:
deferred.el:675:33: Warning: value returned from (length (car-safe
(internal-get-closed-var 3))) is unused
ert-runner test/deferred-test.el -l deferred.elc
Test Finished : 2022/05/26 17:45:34
Tests Fails: 0 / 13
cc:test-dataflow-simple2 : OK
cc:test-semaphore1 : OK
cc:test-signal1 : OK
cc:test-dataflow-simple1 : OK
cc:test-dataflow-parent1 : OK
cc:test-dataflow-simple3 : OK
cc:test-dataflow-simple4 : OK
cc:test-dataflow-parent2 : OK
cc:test-signal2 : OK
cc:test-dataflow-signal : OK
cc:test-semaphore2 : OK
cc:test-fib-gen : OK
cc:test-thread : OK

.

Ran 1 test in 4.432 seconds

deferred error : (wrong-number-of-arguments (3 . 3) 4)

deferred error : (wrong-number-of-arguments (3 . 3) 4)
```

After printing that, nothing else happens on the terminal output until I hit 
Cntl-C. There does not seem to be any significant amount of CPU activity going 
on. I've tried adding '-M 1 -c 1' but that doesn't make a difference. My system 
information:

```
christopher@theoden ~$ neofetch --stdout
christopher@theoden 
--- 
OS: Guix System x86_64 
Host: OptiPlex 9020 00 
Kernel: 5.17.5-gnu 
Uptime: 7 days, 3 hours, 20 mins 
Packages: 92 (guix-system), 165 (guix-user) 
Shell: bash 5.1.8 
Resolution: 1920x1080 
DE: GNOME 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: .gnome-terminal 
CPU: Intel i5-4570 (4) @ 3.600GHz 
GPU: Intel HD Graphics 
GPU: AMD ATI Radeon HD 8490 / R5 235X OEM 
Memory: 4491MiB / 7867MiB 
```

-- 
📛 Christopher Howard
🚀 gemini://gem.librehacker.com
🌐 https://portal.mozz.us/gemini/gem.librehacker.com

בראשית ברא אלהים את השמים ואת הארץ

bug#55664: emacs-deferred: hangs during build

[Maxime Devos]

merge 55504 55664
thanks

Duplicate of .
For future reference, you can use the search interface at
https://issues.guix.gnu.org/search?query=emacs-deferred
to look if an issue has already been reported.

Greetings,
MMaxime


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

bug#55441: [cuirass] hang in "In progress..."; runs out of pgsql connections

[Josselin Poiret via Bug reports for GNU Guix]

Hello everyone,

With all the recent platform changes, I was looking at `make
cuirass-jobs` for the first time and it left some deadlocked inferiors
as well, so I figured I could try my own solution, since I've already
dabbled in Guile POSIX internals!  Here's a patch that rewrites
open-bidirectional-pipe with a more thread-safe alternative,
`piped-process`, but this also requires some Guile patches, that I will
post as well.  With these, `make cuirass-jobs` doesn't hang at all
anymore for me.

Let me know what you think of these

Best,
-- 
Josselin Poiret

bug#55441: [PATCH 1/2] Fix child spawning closing standard fds prematurely

[Josselin Poiret via Bug reports for GNU Guix]

* libguile/posix.c (renumber_file_descriptor): Refactor it as
dup_handle_error.
(dup_handle_error, dup2_handle_error): New functions that wrap around
dup and dup2 by retrying on EINTR or EBUSY, as well as erroring out on
other errors.
(start_child): Close standard file descriptors only
after all of them have been dup2'd.
---
 libguile/posix.c | 82 +++-
 1 file changed, 53 insertions(+), 29 deletions(-)

diff --git a/libguile/posix.c b/libguile/posix.c
index 3ab12b99e..dc3080b3c 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -1280,14 +1280,14 @@ SCM_DEFINE (scm_fork, "primitive-fork", 0, 0, 0,
 #endif /* HAVE_FORK */
 
 #ifdef HAVE_FORK
-/* 'renumber_file_descriptor' is a helper function for 'start_child'
-   below, and is specialized for that particular environment where it
-   doesn't make sense to report errors via exceptions.  It uses dup(2)
-   to duplicate the file descriptor FD, closes the original FD, and
-   returns the new descriptor.  If dup(2) fails, print an error message
-   to ERR and abort.  */
+/* 'dup_handle_error' is a helper function for 'start_child' below, and
+   is specialized for that particular environment where it doesn't make
+   sense to report errors via exceptions.  It uses dup(2) to duplicate
+   the file descriptor FD, does *not* close the original FD, and returns
+   the new descriptor.  If dup(2) fails, print an error message to ERR
+   and abort.  */
 static int
-renumber_file_descriptor (int fd, int err)
+dup_handle_error (int fd, int err)
 {
   int new_fd;
 
@@ -1304,7 +1304,33 @@ renumber_file_descriptor (int fd, int err)
   _exit (127);  /* Use exit status 127, as with other exec errors. */
 }
 
-  close (fd);
+  return new_fd;
+}
+
+/* 'dup2_handle_error' is a helper function for 'start_child' below, and
+   is specialized for that particular environment where it doesn't make
+   sense to report errors via exceptions.  It uses dup2(2) to duplicate
+   the file descriptor FD, does *not* close the original FD, and returns
+   the new descriptor.  If dup2(2) fails, print an error message to ERR
+   and abort.  */
+static int
+dup2_handle_error (int fd, int to, int err)
+{
+  int new_fd;
+
+  do
+new_fd = dup2 (fd, to);
+  while (new_fd == -1 && (errno == EINTR || errno == EBUSY));
+
+  if (new_fd == -1)
+{
+  /* At this point we are in the child process before exec.  We
+ cannot safely raise an exception in this environment.  */
+  const char *msg = strerror (errno);
+  fprintf (fdopen (err, "a"), "start_child: dup failed: %s\n", msg);
+  _exit (127);  /* Use exit status 127, as with other exec errors. */
+}
+
   return new_fd;
 }
 #endif /* HAVE_FORK */
@@ -1357,27 +1383,25 @@ start_child (const char *exec_file, char **exec_argv,
   if (err == -1)
 err = open ("/dev/null", O_WRONLY);
 
-  if (in > 0)
-{
-  if (out == 0)
-out = renumber_file_descriptor (out, err);
-  if (err == 0)
-err = renumber_file_descriptor (err, err);
-  do dup2 (in, 0); while (errno == EINTR);
-  close (in);
-}
-  if (out > 1)
-{
-  if (err == 1)
-err = renumber_file_descriptor (err, err);
-  do dup2 (out, 1); while (errno == EINTR);
-  close (out);
-}
-  if (err > 2)
-{
-  do dup2 (err, 2); while (errno == EINTR);
-  close (err);
-}
+  /* Dup each non-yet-dup2'd fd that's in the way to the next available fd,
+ so that we can safely dup2 to 0/1/2 without potentially overwriting
+ in/out/err.  Note that dup2 doesn't do anything if its arguments are
+ equal. */
+  if (out == 0)
+out = dup_handle_error (out, err);
+  if (err == 0)
+err = dup_handle_error (err, err);
+  dup2_handle_error (in, 0, err);
+
+  if (err == 1)
+err = dup_handle_error (err, err);
+  dup2_handle_error (out, 1, err);
+
+  dup2_handle_error (err, 2, err);
+
+  if (in > 2) close (in);
+  if (out > 2) close (out);
+  if (err > 2) close (err);
 
   execvp (exec_file, exec_argv);
 
-- 
2.36.0

bug#55441: [PATCH 2/2] Improve thread safety of piped-process.

[Josselin Poiret via Bug reports for GNU Guix]

* libguile/posix.c (scm_piped_process): Avoid double close.
---
 libguile/posix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libguile/posix.c b/libguile/posix.c
index dc3080b3c..e134408e3 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -1486,7 +1486,7 @@ scm_piped_process (SCM prog, SCM args, SCM from, SCM to)
   SCM_SYSERROR;
 }
 
-  if (reading)
+  if (reading && !(writing && c2p[1] == p2c[0]))
 close (c2p[1]);
   if (writing)
 close (p2c[0]);
-- 
2.36.0

bug#55441: [PATCH] guix: inferior: Make open-bidirectional-pipe use piped-process.

[Josselin Poiret via Bug reports for GNU Guix]

* guix/inferior.scm: Load up scm_init_popen extension to be able to
use piped-process.
(open-bidirectional-pipe): Remove custom fork+exec code and use
piped-process instead.
---
 guix/inferior.scm | 39 ++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/guix/inferior.scm b/guix/inferior.scm
index 54200b75e4..a4a4c1d40e 100644
--- a/guix/inferior.scm
+++ b/guix/inferior.scm
@@ -134,6 +134,10 @@ (define (write-inferior inferior port)
 
 (set-record-type-printer!  write-inferior)
 
+(eval-when (expand load eval)
+  (load-extension (string-append "libguile-" (effective-version))
+  "scm_init_popen"))
+
 (define (open-bidirectional-pipe command . args)
   "Open a bidirectional pipe to COMMAND invoked with ARGS and return it, as a
 regular file port (socket).
@@ -147,27 +151,20 @@ (define (open-bidirectional-pipe command . args)
   ;; the REPL process wouldn't get EOF on standard input.
   (match (socketpair AF_UNIX (logior SOCK_STREAM SOCK_CLOEXEC) 0)
 ((parent . child)
- (match (primitive-fork)
-   (0
-(dynamic-wind
-  (lambda ()
-#t)
-  (lambda ()
-(close-port parent)
-(close-fdes 0)
-(close-fdes 1)
-(dup2 (fileno child) 0)
-(dup2 (fileno child) 1)
-;; Mimic 'open-pipe*'.
-(unless (file-port? (current-error-port))
-  (close-fdes 2)
-  (dup2 (open-fdes "/dev/null" O_WRONLY) 2))
-(apply execlp command command args))
-  (lambda ()
-(primitive-_exit 127
-   (pid
-(close-port child)
-(values parent pid))
+ (let* ((proc
+ (lambda ()
+   (piped-process command args
+  ;; Use port->fdes on child to increase the
+  ;; revealed count, so that the fd does not get
+  ;; closed again when child gets gc'd, as
+  ;; piped-process already closes it.
+  (cons (fileno parent) (port->fdes child))
+  (cons (fileno child) (fileno parent)
+(pid
+ (if (file-port? (current-error-port))
+ (proc)
+ (with-error-to-file "/dev/null" proc
+   (values parent pid)
 
 (define* (inferior-pipe directory command error-port)
   "Return two values: an input/output pipe on the Guix instance in DIRECTORY
-- 
2.36.0

bug#55441: [PATCH 1/2] Fix child spawning closing standard fds prematurely

[Maxime Devos]

Josselin Poiret via Bug reports for GNU Guix schreef op do 26-05-2022
om 22:50 [+0200]:
> +  fprintf (fdopen (err, "a"), "start_child: dup failed: %s\n", msg);

fdopen can fail due to out-of-memory problems, so you'll have to check
the return value, or use dprintf instead which accepts a file
descriptor.

Greetings,
Maxime.


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

bug#55441: [cuirass] hang in "In progress..."; runs out of pgsql connections

[Maxime Devos]

Josselin Poiret via Bug reports for GNU Guix schreef op do 26-05-2022
om 22:49 [+0200]:
> Hello everyone,
> 
> With all the recent platform changes, I was looking at `make
> cuirass-jobs` for the first time and it left some deadlocked inferiors
> as well, so I figured I could try my own solution, since I've already
> dabbled in Guile POSIX internals!  Here's a patch that rewrites
> open-bidirectional-pipe with a more thread-safe alternative,
> `piped-process`, but this also requires some Guile patches, that I will
> post as well.  With these, `make cuirass-jobs` doesn't hang at all
> anymore for me.
> 
> Let me know what you think of these
> 
> Best,

The process opening code looks fragile, so I think some tests are
required to avoid causing regressions later.

Greetings,
Maxime.


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

bug#55441: [PATCH] guix: inferior: Make open-bidirectional-pipe use piped-process.

[Maxime Devos]

Josselin Poiret via Bug reports for GNU Guix schreef op do 26-05-2022
om 22:50 [+0200]:
> * guix/inferior.scm: Load up scm_init_popen extension to be able to
> use piped-process.

Can we export the procedure instead from (ice-9 popen) + use @@ for
now, instead of doing this low-level thing?

Greetings,
Maxime.


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

bug#55504: Test suite of emacs-deferred does not progress

[Liliana Marie Prikler]

Am Mittwoch, dem 25.05.2022 um 19:09 +0200 schrieb Giovanni Biscuolo:
> I'm not able to find what's the call with the wrong number of
> arguments but what about to (temporary) disable the failing tests
> like for example in 0ae9e75c31b22ea55093f4cd05954f366b1f8bcc (emacs-
> eply)?
That's unlikely to work as it'll just bring dependent packages to hang.
Anyway, I fixed the actual bug, so it's no longer necessary to debate
workarounds.

Cheers