bug#62491: [berlin] certbot renewal appears to be broken

Hi, Giovanni Biscuolo skribis: > Maxim Cournoyer writes: > > [...] > >>> AFAIU actually #56678 is (was?) caused by a duplicate certbot account: > > [...] > >>> The problem on berlin (#62491) is (was) due to a failed challenge: > > I'm almost sure those are different bugs and I'm almost sure the

bug#65720: Guile-Git-managed checkouts grow way too much

Ludovic Courtès skribis: > As reported by Tobias on IRC (in the context of ‘hpcguix-web’), > checkouts managed by Guile-Git appear to grow beyond reason. As an > example, here’s the same ‘.git’ managed with Guile-Git and with Git: > > $ du -hs > ~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikx

bug#46796: Cuirass & pointer finalization.

Hi, Mathieu Othacehe skribis: > I'm trying to fix a memory corruption in the remote-server process of > Cuirass since a few days. Even though I don't have a usable core dump > file yet, I'm pretty sure the error comes from the "zmq-msg-init" > procedure of Guile-Simple-ZMQ. I’m closing this old

bug#47543: “Repeated allocation of very large block” during ‘guix pull’

Ludovic Courtès skribis: > While running ‘guix pull’, sometime between the actual ‘git pull’ (via > Guile-Git) and channel authentication, I saw the dreaded libgc warning: > > Repeated allocation of very large block [...] > So it might rather be ‘update-cached-checkout’ that triggers it. I w

bug#67224: [Cuirass] ‘remote-server’ exits due to “Host unreachable”

Ludovic Courtès skribis: > This should be fixed by Cuirass commit > 38d864defc4ffe9aaada1aa36dadc311df08013a. Included in the ‘cuirass’ package update in Guix commit 300e9ad43d1f7a10013aa0724ed3aeb7d93500c1, now deployed on berlin and its x86 build nodes. Ludo’.

bug#67041: [cuirass] cuirass-web crash

Ludovic Courtès skribis: > This is fixed by Cuirass commit > 7c697ad7f15c13264615d2b6c9165b21abaf61dd. Included in the ‘cuirass’ package update in Guix commit 300e9ad43d1f7a10013aa0724ed3aeb7d93500c1, now deployed on berlin and its x86 build nodes. Ludo'.

bug#66980: [Cuirass] Uncaught exception in 'cuirass remote-worker'

Ludovic Courtès skribis: > This should be fixed by Cuirass commit > ba3ea7947ec67e9d9585e40a30d67dbd8115e73c. Included in the ‘cuirass’ package update in Guix commit 300e9ad43d1f7a10013aa0724ed3aeb7d93500c1, now deployed on berlin and its x86 build nodes. Ludo’.

bug#65725: guix pull fails on riscv64 (guix install openssl, too)

Hi all, I've worked around the issue for now by building from source and disabling all tests for now, using the following diff. diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm index f1e844b..1077c4b 100644 --- a/gnu/packages/tls.scm +++ b/gnu/packages/tls.scm @@ -494,4 +494,5 @@ (define-

bug#67292: emacs / emacs-transient collisions and bundling

Hello Maxime, 2023-11-20 13:39 maximede...@telenet.be: Op 20-11-2023 om 11:22 schreef Simon Tournier: > On Sun, 19 Nov 2023 at 23:44, Maxime Devos > > wrote: >> Bug 1: emacs bundles emacs-transient. >> (Likewise for quite a few other Emacs packages.) > This is not a bug. transient.el

bug#67292: emacs / emacs-transient collisions and bundling

On mar., 21 nov. 2023 at 19:01, Maxime Devos wrote: > Yes, it is official, but the question was how the bundling is not a bug (and > implicitly, whether it is bundling), not whether the bundling is official. The bundling is not a bug because it is how Emacs is developed. The term “bundle“ – whi

bug#63551: (no subject)

Hi, Guix now has cpp-mustanche 5.0 so I think we can close that bug. Denis. pgpwNDA_3cqCb.pgp Description: OpenPGP digital signature

bug#63736: [Shepherd] Loss of SIGCHLD notifications

Ludovic Courtès skribis: > Another possibility is lockup: one of the relevant fibers is either gone > or stuck in ‘put-message’ or ‘get-message’. > > I did two things: > > b9a37f3 shepherd: Make signal handling fiber an essential task. > 8ae2780 service: Do not attempt to restart transient se

bug#63116: control message

resolved by #62635

bug#64665: [Shepherd] Introduce a configurable respawn delay

Hello, Ludovic Courtès skribis: > The conclusion of the thread at > > seems to be that we should introduce a configurable respawn delay > (systemd makes that 100ms). Implemented in commit 1d3643f2576aff1869bba084c92684c81689a