GNU bug report logs - #75518
Request for merging "core-packages-team" branch

Previous Next

Full log

Message #217 received at 75518 <at> debbugs.gnu.org (full text, mbox):

From: Rutherther <rutherther <at> ditigal.xyz>
To: 75518 <at> debbugs.gnu.org
Subject: Re: Request for merging "core-packages-team" branch
Date: Mon, 02 Jun 2025 18:38:16 +0200

Resending to Debbugs tracker without To/Cc headers with all users.

Andreas Enge <andreas <at> enge.fr> writes:

> Am Mon, Jun 02, 2025 at 03:35:38PM +0200 schrieb Rutherther:
>> Hi, I've tried looking at one of the failing packages - motif. It seems
[ 6 more citation lines. Click/Enter to show. ]
>> to me it is probably failing because of gcc-14, so I wanted to try with
>> gcc-11 to verify that.
>
> $ guix refresh -l motif
> Die folgenden 4 Pakete zu erstellen, würde zur Folge haben, dass 4 abhängige Pakete neu erstellt werden: snd <at> 25.2
> ddd <at> 3.4.1 emacs-motif <at> 29.4 xnedit <at> 1.6.3
>
> I wonder if one "solution" would be to remove motif and its dependent
> packages?

I suppose. Is it fine to not follow the deprecation policy though? I am
really expecting just putting gcc-11 to native-inputs will fix it.
Also just saw Ludovic sent a proposed patch - I really expected the file
to be generated based on the name, not something in the source, though I
didn't check, silly me :)

Apart from that I had a look at guile-for-guile-emacs: submitted patch
here https://codeberg.org/lyrra/guile/pulls/1. The source is broken. I
am not sure who lyrra is and why their source is. I hope they will
react, otherwise I suppose this would have to be a downstream patch?

Also on capnproto, fix for it is here:
https://github.com/capnproto/capnproto/commit/1ae1e9990c7603f0dc99e64470f96693f869b00a,
so update to v1.1.0 should do it. I've tried it, and got one test
failure. Attaching patch with update and log, currently it doesn't
build. I won't be able to understand the test now I think, so I am
unable to decide whether it makes sense to just disable the test or if
something is wrong.
[ wxpcmjnrxpcqx8mpibsg86izbi000i-capnproto-1.1.0.drv.gz: application/octet-stream ]
[ 0001-gnu-capnproto-Update-to-1.1.0.patch: text/x-patch ]
From b5776c2d8b453a661479729332fdcd119ef50cac Mon Sep 17 00:00:00 2001
Message-ID: <b5776c2d8b453a661479729332fdcd119ef50cac.1748881827.git.rutherther <at> ditigal.xyz>
From: Rutherther <rutherther <at> ditigal.xyz>
Date: Mon, 2 Jun 2025 18:09:11 +0200
Subject: [PATCH] gnu: capnproto: Update to 1.1.0

Fixes compilation for gcc 13+

* gnu/packages/serialization.scm (capnproto): Update to 1.1.0

Change-Id: Ie3d7a3dccf43aac1f20fdb80f2b7f4372b7cbca4
---
gnu/packages/serialization.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/serialization.scm b/gnu/packages/serialization.scm
index 5dbeb36929..da39cc3069 100644
--- a/gnu/packages/serialization.scm
+++ b/gnu/packages/serialization.scm
@@ -733,7 +733,7 @@ (define-public ckdl
(define-public capnproto
  (package
    (name "capnproto")
-    (version "1.0")
+    (version "1.1.0")
    (source (origin
              (method url-fetch)
              (uri (string-append
@@ -741,7 +741,7 @@ (define-public capnproto
                    version ".tar.gz"))
              (sha256
                (base32
-                "03f1862ljdshg7d0rg3j7jzgm3ip55kzd2y91q7p0racax3hxx6i"))))
+                "0f89ll6rmyih2f8cal16c60p3v0nihiirbxjwchyixb3wn07a5h7"))))
    (build-system gnu-build-system)
    (arguments
      `(#:phases

base-commit: c06805c59fce8ff951fe9e24029daa41caf07de9
-- 
2.49.0

[ text/plain ]

As for clisp, there are errors in tests, 2 in streams, 1 in
streamslong and 1 in ext-clisp categories. I found this issue from Ludovic
https://gitlab.com/gnu-clisp/clisp/-/issues/51, seems something like
that has already happened in past with newer glibc version. So how was
that resolved last time? There is a lot of dependents on clisp.

python-libarchive-c is failing on one test and I am quite clueless on
what to do with it. It is quite outdated. On the other hand there are a
lot of dependants and there have been breaking changes, so I would
expect breakage in dependants if this package was updated. Btw simple
update of this package fails with a different test error, I will take a
look at that.

The last failing is rust-enumflags2 that is failing even on master. So I
haven't looked at it at all.

Rutherther

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.