Request for merging "core-packages-team" branch

  • Done
  • quality assurance status badge
Details
11 participants
  • Andreas Enge
  • Greg Hogan
  • 宋文武
  • Janneke Nieuwenhuizen
  • Liliana Marie Prikler
  • Ludovic Courtès
  • Christopher Baines
  • Rutherther
  • yelninei
  • Z572
  • Z572
Owner
unassigned
Submitted by
Janneke Nieuwenhuizen
Severity
normal
Blocked by

Debbugs page

Janneke Nieuwenhuizen wrote 1 years ago
(address . guix-patches@gnu.org)(address . 74676@debbugs.gnu.org)(address . 75517@debbugs.gnu.org)
87jzb0dp41.fsf@gnu.org
Hi!

Cuirass says we're at 81% success rate for i686-linux and x86_64-linux,
and possibly my #74676, meant as an old style "please help with the
gcc-14 transition", should have been named "Request for merging" already
anyway. Hard to keep up with all the changes but more formality is a
good thing I guess :)

Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
Janneke Nieuwenhuizen wrote 1 years ago
Re: bug#75517: Request for merging core-packages-team branch
(address . 75517-done@debbugs.gnu.org)(address . 74676@debbugs.gnu.org)(address . 75518@debbugs.gnu.org)
87ed18dow8.fsf_-_@gnu.org
Janneke Nieuwenhuizen writes:

Closing this bug with wrong subject (missing double quotes around branch name).

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
Ludovic Courtès wrote 1 years ago
Re: bug#75518: Request for merging "core-packages-team" branch
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(address . 74676@debbugs.gnu.org)(address . 75517@debbugs.gnu.org)(address . 75518@debbugs.gnu.org)
8734hgulpy.fsf@gnu.org
Hello!

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

Toggle quote (6 lines)
> Cuirass says we're at 81% success rate for i686-linux and x86_64-linux,
> and possibly my #74676, meant as an old style "please help with the
> gcc-14 transition", should have been named "Request for merging" already
> anyway. Hard to keep up with all the changes but more formality is a
> good thing I guess :)

I’m testing the patch below to upgrade glibc to 2.40 (I’m at
‘gcc-mesboot-4.9.4’ so there are still quite a few hours before I get
around to building glibc).

I think we must upgrade glibc in this branch because (1) we want to get
rid of this graft and more generally get the latest fixes, and (2) we
cannot just ungraft since the graft uses ‘git-fetch’, which cannot be
relied on in ‘commencement.scm’ (we still assume that
‘builtin:git-download’ may be unavailable, and when it’s unavailable, we
have a circular dependency).

Thoughts?

Ludo’.
Toggle diff (229 lines)
diff --git a/gnu/local.mk b/gnu/local.mk
index f4d04c4abb..3b123cba1d 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1,5 +1,5 @@
# GNU Guix --- Functional package management for GNU
-# Copyright © 2012-2024 Ludovic Courtès <ludo@gnu.org>
+# Copyright © 2012-2025 Ludovic Courtès <ludo@gnu.org>
# Copyright © 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2022, 2023, 2024 Andreas Enge <andreas@enge.fr>
# Copyright © 2016 Mathieu Lirzin <mthl@gnu.org>
# Copyright © 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021 Mark H Weaver <mhw@netris.org>
@@ -1437,6 +1437,7 @@ dist_patch_DATA = \
%D%/packages/patches/glibc-2.33-riscv64-miscompilation.patch \
%D%/packages/patches/glibc-2.39-git-updates.patch \
%D%/packages/patches/glibc-2.39-fmod-libm-a.patch \
+ %D%/packages/patches/glibc-2.40-dl-cache.patch \
%D%/packages/patches/glibc-CVE-2019-7309.patch \
%D%/packages/patches/glibc-CVE-2019-9169.patch \
%D%/packages/patches/glibc-CVE-2019-19126.patch \
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index fc48c9d844..95c237e140 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -1,5 +1,5 @@
;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012-2024 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2012-2025 Ludovic Courtès <ludo@gnu.org>
;;; Copyright © 2014, 2019 Andreas Enge <andreas@enge.fr>
;;; Copyright © 2012 Nikita Karetnikov <nikita@karetnikov.org>
;;; Copyright © 2014, 2015, 2016, 2018 Mark H Weaver <mhw@netris.org>
@@ -879,10 +879,9 @@ (define* (make-ld-wrapper name #:key
(license gpl3+)))
(define %glibc-patches
- (list "glibc-2.39-git-updates.patch"
- "glibc-ldd-powerpc.patch"
+ (list "glibc-ldd-powerpc.patch"
"glibc-2.38-ldd-x86_64.patch"
- "glibc-dl-cache.patch"
+ "glibc-2.40-dl-cache.patch"
"glibc-2.37-versioned-locpath.patch"
;; "glibc-allow-kernel-2.6.32.patch"
"glibc-reinstate-prlimit64-fallback.patch"
@@ -898,18 +897,17 @@ (define-public glibc
;; version 2.28, GNU/Hurd used a different glibc branch.
(package
(name "glibc")
- (version "2.39")
+ (version "2.40")
(source (origin
(method url-fetch)
(uri (string-append "mirror://gnu/glibc/glibc-" version ".tar.xz"))
(sha256
(base32
- "09nrwb0ksbah9k35jchd28xxp2hidilqdgz7b8v5f30pz1yd8yzp"))
+ "18h50b0zm8dkpzj81w033v99rbxiykk3v697yr4dfqwjbqbr1a0r"))
(patches (map search-patch %glibc-patches))))
(properties `((lint-hidden-cve . ("CVE-2024-2961"
"CVE-2024-33601" "CVE-2024-33602"
"CVE-2024-33600" "CVE-2024-33599"))))
- (replacement glibc/fixed)
(build-system gnu-build-system)
;; Glibc's <limits.h> refers to <linux/limit.h>, for instance, so glibc
@@ -1187,28 +1185,6 @@ (define-public glibc
(license lgpl2.0+)
(home-page "https://www.gnu.org/software/libc/")))
-(define glibc/fixed
- (package
- (inherit glibc)
- (name "glibc")
- (version (package-version glibc))
- (source (origin
- (method git-fetch)
- (uri (git-reference
- (url "git://sourceware.org/git/glibc.git")
- ;; This is the latest commit from the
- ;; 'release/2.39/master' branch, where CVEs and other
- ;; important bug fixes are cherry picked.
- (commit "2c882bf9c15d206aaf04766d1b8e3ae5b1002cc2")))
- (file-name (git-file-name name version))
- (sha256
- (base32
- "111yf24g0qcfcxywfzrilmjxysahlbkzxfimcz9rq8p00qzvvf51"))
- (patches (map search-patch
- (fold (cut delete <...>)
- %glibc-patches
- '("glibc-2.39-git-updates.patch"))))))))
-
;; Define a variation of glibc which uses the default /etc/ld.so.cache, useful
;; in FHS containers.
(define-public glibc-for-fhs
@@ -1220,7 +1196,7 @@ (define-public glibc-for-fhs
;; directories, re-enabling the default /etc/ld.so.cache
;; behavior.
(patches
- (delete (search-patch "glibc-dl-cache.patch")
+ (delete (search-patch "glibc-2.40-dl-cache.patch")
(origin-patches (package-source glibc)))))))))
;; Below are old libc versions, which we use mostly to build locale data in
@@ -1444,7 +1420,6 @@ (define-public glibc-2.29
"glibc-ldd-x86_64.patch"
"glibc-CVE-2019-7309.patch"
"glibc-CVE-2019-9169.patch"
- "glibc-2.29-git-updates.patch"
"glibc-hidden-visibility-ldconfig.patch"
"glibc-versioned-locpath.patch"
"glibc-allow-kernel-2.6.32.patch"
diff --git a/gnu/packages/patches/glibc-2.40-dl-cache.patch b/gnu/packages/patches/glibc-2.40-dl-cache.patch
new file mode 100644
index 0000000000..d41faa5225
--- /dev/null
+++ b/gnu/packages/patches/glibc-2.40-dl-cache.patch
@@ -0,0 +1,113 @@
+Read the shared library cache relative to $ORIGIN instead of reading
+from /etc/ld.so.cache. Also arrange so that this cache takes
+precedence over RUNPATH.
+
+diff --git a/elf/dl-cache.c b/elf/dl-cache.c
+index 7c7dc587..19d1d79a 100644
+--- a/elf/dl-cache.c
++++ b/elf/dl-cache.c
+@@ -374,6 +374,52 @@ _dl_cache_libcmp (const char *p1, const char *p2)
+ return *p1 - *p2;
+ }
+
++/* Special value representing the lack of an ld.so cache. */
++static const char ld_so_cache_lacking[] = "/ld.so cache is lacking";
++
++/* Return the per-application ld.so cache, relative to $ORIGIN, or NULL if
++ that fails for some reason. Do not return the system-wide LD_SO_CACHE
++ since on a foreign distro it would contain invalid information. */
++static const char *
++ld_so_cache (void)
++{
++ static const char *loader_cache;
++
++ if (loader_cache == NULL)
++ {
++ static const char store[] = @STORE_DIRECTORY@;
++ const char *origin = _dl_get_origin ();
++
++ /* Check whether ORIGIN is something like "/gnu/store/…-foo/bin". */
++ if (origin != (char *) -1 /* _dl_get_origin reported failure */
++ && strncmp (store, origin, strlen (store)) == 0
++ && origin[sizeof store - 1] == '/')
++ {
++ char *store_item_end = strchr (origin + sizeof store, '/');
++
++ if (store_item_end != NULL)
++ {
++ static const char suffix[] = "/etc/ld.so.cache";
++ size_t store_item_len = store_item_end - origin;
++
++ /* Note: We can't use 'malloc' because it can be interposed.
++ Likewise, 'strncpy' is not available. */
++ char *cache = alloca (strlen (origin) + sizeof suffix);
++
++ strcpy (cache, origin);
++ strcpy (cache + store_item_len, suffix);
++
++ loader_cache = __strdup (cache) ?: ld_so_cache_lacking;
++ }
++ else
++ loader_cache = ld_so_cache_lacking;
++ }
++ else
++ loader_cache = ld_so_cache_lacking;
++ }
++
++ return loader_cache;
++}
+
+ /* Look up NAME in ld.so.cache and return the file name stored there, or null
+ if none is found. The cache is loaded if it was not already. If loading
+@@ -387,12 +433,15 @@ _dl_load_cache_lookup (const char *name)
+ {
+ /* Print a message if the loading of libs is traced. */
+ if (__glibc_unlikely (GLRO(dl_debug_mask) & DL_DEBUG_LIBS))
+- _dl_debug_printf (" search cache=%s\n", LD_SO_CACHE);
++ _dl_debug_printf (" search cache=%s\n", ld_so_cache ());
++
++ if (__glibc_unlikely (ld_so_cache () == ld_so_cache_lacking))
++ return NULL;
+
+ if (cache == NULL)
+ {
+ /* Read the contents of the file. */
+- void *file = _dl_sysdep_read_whole_file (LD_SO_CACHE, &cachesize,
++ void *file = _dl_sysdep_read_whole_file (ld_so_cache (), &cachesize,
+ PROT_READ);
+
+ /* We can handle three different cache file formats here:
+diff --git a/elf/dl-load.c b/elf/dl-load.c
+index 8a89b710..b8802e74 100644
+--- a/elf/dl-load.c
++++ b/elf/dl-load.c
+@@ -2038,14 +2038,6 @@ _dl_map_object (struct link_map *loader, const char *name,
+ loader ?: GL(dl_ns)[LM_ID_BASE]._ns_loaded,
+ LA_SER_LIBPATH, &found_other_class);
+
+- /* Look at the RUNPATH information for this binary. */
+- if (fd == -1 && loader != NULL
+- && cache_rpath (loader, &loader->l_runpath_dirs,
+- DT_RUNPATH, "RUNPATH"))
+- fd = open_path (name, namelen, mode,
+- &loader->l_runpath_dirs, &realname, &fb, loader,
+- LA_SER_RUNPATH, &found_other_class);
+-
+ #ifdef USE_LDCONFIG
+ if (fd == -1
+ && (__glibc_likely ((mode & __RTLD_SECURE) == 0)
+@@ -2104,6 +2096,14 @@ _dl_map_object (struct link_map *loader, const char *name,
+ }
+ #endif
+
++ /* Look at the RUNPATH information for this binary. */
++ if (fd == -1 && loader != NULL
++ && cache_rpath (loader, &loader->l_runpath_dirs,
++ DT_RUNPATH, "RUNPATH"))
++ fd = open_path (name, namelen, mode,
++ &loader->l_runpath_dirs, &realname, &fb, loader,
++ LA_SER_RUNPATH, &found_other_class);
++
+ /* Finally, try the default path. */
+ if (fd == -1
+ && ((l = loader ?: GL(dl_ns)[nsid]._ns_loaded) == NULL
Janneke Nieuwenhuizen wrote 1 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 74676@debbugs.gnu.org)(address . 75517@debbugs.gnu.org)(address . 75518@debbugs.gnu.org)
878qr8awy6.fsf@gnu.org
Ludovic Courtès writes:

Hi!

Toggle quote (12 lines)
> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>
>> Cuirass says we're at 81% success rate for i686-linux and x86_64-linux,
>> and possibly my #74676, meant as an old style "please help with the
>> gcc-14 transition", should have been named "Request for merging" already
>> anyway. Hard to keep up with all the changes but more formality is a
>> good thing I guess :)
>
> I’m testing the patch below to upgrade glibc to 2.40 (I’m at
> ‘gcc-mesboot-4.9.4’ so there are still quite a few hours before I get
> around to building glibc).

Oh, I didn't realise 2.40 was out already!

Toggle quote (9 lines)
> I think we must upgrade glibc in this branch because (1) we want to get
> rid of this graft and more generally get the latest fixes, and (2) we
> cannot just ungraft since the graft uses ‘git-fetch’, which cannot be
> relied on in ‘commencement.scm’ (we still assume that
> ‘builtin:git-download’ may be unavailable, and when it’s unavailable, we
> have a circular dependency).
>
> Thoughts?

That would be lovely, especially if it builds :)

Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
Ludovic Courtès wrote 1 years ago
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(address . 74676@debbugs.gnu.org)(address . 75517@debbugs.gnu.org)(address . 75518@debbugs.gnu.org)
87y0z6ml02.fsf_-_@gnu.org
Hello,

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

Toggle quote (2 lines)
> That would be lovely, especially if it builds :)

It actually does! :-) I went a bit further and tried “guix build
coreutils”. It’s close to completion right now, but I’m going to bed.

I’m confident: unlike previous upgrades, there are no major deprecations
like the removal of Sun RPC, libutil.so, libcrypt.so, etc. (there’s not
much left to remove :-)).

So, pushed. The one thing that still needs to be tested is
(cross-)compilation to GNU/Hurd. There are probably patches that can be
dropped there.

Thanks,
Ludo’.
宋文武 wrote 1 years ago
Re: [bug#75518] Request for merging "core-packages-team" branch
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 74676@debbugs.gnu.org)(address . 75517@debbugs.gnu.org)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87frkzl4q5.fsf@envs.net
Hello, I just merged 'xorg-updates', now this is the next in the queue.
Ludovic Courtès wrote 1 years ago
control message for bug #75518
(address . control@debbugs.gnu.org)
877c636r2f.fsf@gnu.org
block 75518 by 75658
quit
Ludovic Courtès wrote 1 years ago
Re: bug#75676: Request for merging "gnome-team" branch
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Andreas Enge)(address . andreas@enge.fr)(address . 75518@debbugs.gnu.org)(address . 75676@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
8734gr6ost.fsf@gnu.org
Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

Toggle quote (6 lines)
> with most of its packages bumped to 46 and 65% substitute availability
> (same as master), I think gnome-team is on a good track to be merged
> eventually. At the same time 65% isn't *that* high and there are other
> branches to merge before that, so I'd like our collective intelligence
> to help contributing fixes for various bugs, non-x86 arches, the usual.

“core-packages-team” is officially next in queue, before “gnome-team”:


However, since that branch is not ready, I would suggest letting you go
first, as was just discussed on IRC, unless you’re not ready to merge it
in the coming days.

Ludo’.
Andreas Enge wrote 1 years ago
Builds
(address . 75518@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Z6TlNUp8UzI0XU6k@jurong
Hello,

I went up to "guix build mpc" in this branch, with success; and the
resulting library is linked with glibc-2.40.

So I did not see the non-deterministic gnash error:
and feel like we could merge after cleaning up the last two commits.

Is there anything else I could check?

Andreas
Liliana Marie Prikler wrote 1 years ago
Re: bug#75676: Request for merging "gnome-team" branch
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Andreas Enge)(address . andreas@enge.fr)(address . 75518@debbugs.gnu.org)(address . 75676@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
3d4c2e1068521e1338e4b101d7ad4c50d3ac34db.camel@gmail.com
Hi Ludo’

Am Donnerstag, dem 06.02.2025 um 17:06 +0100 schrieb Ludovic Courtès:
Toggle quote (19 lines)
> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
>
> > with most of its packages bumped to 46 and 65% substitute
> > availability (same as master), I think gnome-team is on a good
> > track to be merged eventually.  At the same time 65% isn't *that*
> > high and there are other branches to merge before that, so I'd like
> > our collective intelligence to help contributing fixes for various
> > bugs, non-x86 arches, the usual.
>
> “core-packages-team” is officially next in queue, before “gnome-
> team”:
>
>   https://qa.guix.gnu.org/
>
> However, since that branch is not ready, I would suggest letting you
> go first, as was just discussed on IRC, unless you’re not ready to
> merge it in the coming days.
It's a tough call. QA looks red for gnome-team on everything but
x86_64 [1] and I will be away for a few days starting tomorrow with no
access to my commit machine. We could still merge today and fix the
breakages later, but I fully understand if that's not what we want.

Cheers

Andreas Enge wrote 1 years ago
Re: Builds
(address . 75518@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)
Z6ZBqbOm3rJXNCUD@jurong
Hello,

just another data point, I managed to "guix build mpc" with
Zheng Junjie's added commits, again without any gash problems.

If we push, we should reorder the commits and un-DRAFT the ones marked
as in the works.

Andreas
Z572 wrote 1 years ago
Re: [bug#75518] Builds
(name . Andreas Enge)(address . andreas@enge.fr)(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87seopr6eh.fsf@z572.online
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (8 lines)
> Hello,
>
> just another data point, I managed to "guix build mpc" with
> Zheng Junjie's added commits, again without any gash problems.
>
> If we push, we should reorder the commits and un-DRAFT the ones marked
> as in the works.


During the irc discussions, we decided to let gnome-team merge first

Toggle quote (2 lines)
>
> Andreas
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfr6klGDOXiwIdX/bO1qpk+Gi3/AFAmemR9YACgkQO1qpk+Gi
3/Aa+w/9GW8cXqO9iHhQp9AH8U38mmm9Td5iVaUXfmvBIl7JpLP9pUqHFpyqvkdk
pC2hGZb0bIKz7YTcmHd3Awzfyix46vBJdz8l7uA/Hs/fZwBNb0POnqmoKX5TIjpy
kWWhgYyxSlQtGQ6PcBnVJsdh4J1YGn/EQSbIEMlRh7q5RuBsOtU8fqQovew24E6z
rZSEa2Tk3ezFHzwYyqxiCxKWZIHf4vmOKahIqzCQGvH0uvwuYQ/XY4jPGTqnhnhk
rhqeluzs4Sx1fpp0IqJFcuu6GNYIRnEDoJG4QIvX/kO3t2eeNAkmuK0HL+jLdKb7
Ls5psMapZGRSzGFumQCSYqfpQJtjiYnPIw7pLu7zAuBh242sEg0+aA3GyPMzaZ5R
+kqFvRigJbZnSp0WdJ3QMjt6XvDx5FwEonZHD6F1p4YE3ZXDs0afNom4RQ1d654Q
exjMFXQTTvPF958VCUVwEe/0Ibc6d/Lu8Wq99dvZ7dNt7QV8ved41wwUTZRvRKzx
bHneM7yvQ+3OGe4ep1fIsEoEOx5gAJOqyPq9iFSSNB7SlAMoZXwnJLL5dTqlk7IQ
Ni8K2kcLKuFcDAVDVEUmJX+kUOzJ9yyOEkd/9V8x9OnjVwMysfMURGVEifbkr6ly
v8dNLzvp4ogWeqJLJBxwK8EjlUX4BdX7cORVfpwjpsas6cZLvDM=
=XZzb
-----END PGP SIGNATURE-----

Christopher Baines wrote 1 years ago
Re: [bug#75676] Request for merging "gnome-team" branch
(address . control@debbbugs.gnu.org)(address . 75518@debbugs.gnu.org)(address . 75676@debbugs.gnu.org)
87pljslh7l.fsf@cbaines.net
# block the core-packages-team merge by gnome-team
block 75518 by 75676
thanks
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmenVp5fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XeuGg/+KoaKtw7WXI+O36SXHyNVIm451OAjJAIT
fUh4rmi5cJr5sLetp+l1rqy/vKogw6xkPJPGXbAOnfyiBdTITMN5Cv3q9C251DDp
OiCopKlcNlTRhpHH8CNPyLKuEnkB9A5o9Dz6CjBkQt6WxF8eJ7qHCCfaYvVc2Rc/
tRETnqZfkw97i14BuTHtzjX4OEyBS+FVGchlveGL6/e8WCwrQbzn4t98hteoICbx
hi8TRCqSObLCp42cyfMo2fEvfVOs1TcUM4lbZLrcaL8meMYgUKn5W1aJ2HB4VknF
Q+vKF4kP1v0We2w8DCmanMoyvu1X1oWWLqFJx7yi/C6voUHJtsMWePtWcCaRbgix
6TK9+gcyCeumheWOFMbpnN0U0WGKttwPXV3EXFeIqMzAIoMRKGmIUZLnPUEeUaIk
Jw46zqV37HkyixXf/bIuhk9ASyIFtYsrQZp3sNB/A154feC3QGsdXPwNF7wkwpbj
vreyfKcc2NAEm1tEnhPcJD2UQHxZ8giPgVdE5pj3oCz3eH6TFMnuTaJFSBoFr2pg
VqR06CC75e2TOglbkEZKRql8wKB3tP8FaH5P+E7ahSRAp5tVWWA/ThWM6vOGW2AC
yW6JxqnLe2PzSL+234h+84v/rslsWGzqAdFryaS6TZzlcYkEQg1bWyIoD61bwiP5
SamDUqmcFB8=
=fsDA
-----END PGP SIGNATURE-----

Christopher Baines wrote 1 years ago
(no subject)
(address . control@debbugs.gnu.org)
87lduglgwy.fsf@cbaines.net
# block the core-packages-team merge by gnome-team
block 75518 by 75676
thanks
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmenWB1fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xfu7xAAlHlh/xZ6p2GDTkpDQlLMJ1XNiEUkEM1L
DFIU+03XvlO5oZg/xEp/0FEACSaaGbcdifSsl/ouHJV0NCEoQTrLcJizEMIqcmVp
TU3DOyA9hnfNf9XuzpUEJMh262vvosAXWzj0FjIgeE8ifNFzc3zrDBU+e64h+cgT
00gAUdZ7Dtmbo91A7lCfqDQC8gyuDHDdU1n0LAI2xPY768UuPgaNXagcTLIME5hQ
nxugwdZS7BovjG1HK3pqIW32RGtN8xODw3mvJe9gd77zBHejmQ4StSELI4SYcTId
8GZOxsPYeYXLAwJwTG/Qz94+4vPH2i2Vp0iho0bEATDQhXhtPkb0Wq/uCgInE6ni
7YeZ6ssOGwYZcXWYgQMVDMNp8SOWwHJN42IEjrpKIJFIxJyLx3qGr7TbL6B6NHxc
jiNpU1yPfCzDTtvvOy+xKTZi6ezTzmxsM257Qr86DgOmKNyokWN13u3xIELKtdAz
Molh5rB7kAaFzbT2G+V3VJxzRNaosakqCSKTsv29pGdnYsaXTL2/++12+2GaIWLF
ZsM1aoXRgbIJPARLuEdzIap75vzx3kMAFvjLCu9m+hkR5hKrYxsxbbqOP4UfaEnC
3DHYhvKjJ2kbePaEmm+3tP1J45ijuInhY8u2hu5tDs4lsDmVn8M9vGVk+llxaY6M
ZRBkDAIoSZc=
=TKou
-----END PGP SIGNATURE-----

Ludovic Courtès wrote 1 years ago
Re: [bug#75518] Builds
(name . Z572)(address . z572@z572.online)(name . Andreas Enge)(address . andreas@enge.fr)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87cyfrtlqh.fsf@gnu.org
Hi,

Z572 <z572@z572.online> skribis:

Toggle quote (15 lines)
> Andreas Enge <andreas@enge.fr> writes:
>
>> Hello,
>>
>> just another data point, I managed to "guix build mpc" with
>> Zheng Junjie's added commits, again without any gash problems.
>>
>> If we push, we should reorder the commits and un-DRAFT the ones marked
>> as in the works.
>
> see https://logs.guix.gnu.org/guix/2025-02-06.log#160426 and
> https://issues.guix.gnu.org/75676#1
>
> During the irc discussions, we decided to let gnome-team merge first

I’ve also been looking at the Gash issue, to no avail so far. But I
think it would be bad to ignore it as it could come to haunt us later.

Ludo’.
Andreas Enge wrote 1 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Z6jibawZRNMt4GGV@jurong
Am Sun, Feb 09, 2025 at 12:12:54PM +0100 schrieb Ludovic Courtès:
Toggle quote (3 lines)
> I’ve also been looking at the Gash issue, to no avail so far. But I
> think it would be bad to ignore it as it could come to haunt us later.

Well, I have once again built out this branch up to mpc, and still not
seen the issue. So from my point of view, it is unreproducible to the
point of apparently not occurring in my setting :)

Andreas
Andreas Enge wrote 1 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Z637VZgRwz3Ml02t@jurong
Janneke, I agree with your comment in the latest commit that we should
coordinate through this bug (rather than IRC, where one misses the
action when one is not online).

Andreas
yelninei wrote 1 years ago
Re: [bug#75518] Issues on i586-gnu
(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
OIvxipo--Z-9@tutamail.com
Hello,

I was trying to build the branch with -s i586-gnu and offloading to a hurd vm:

- gcc-boot0 was failing because of libstdc++

The default libstdc++ (4.9) is too old and the currently used libstdc++ (14) is to new. 
I had success with libstdc++-5 (which is already used for aarch64 and ppc64) 

- gnumach-headers-boot0 failed because of automake-1.17

The gnumach configure script adds a patch to Makefile.in at the end of configure.
However the patch is incompatible with automake-1.17. The normal gnumach package got fixed to use automake-1.16.5.

I downgraded automake-boot0 to 1.16.5 (i think this is fine because only the mach packages require automake)
Alternatively there is an upstream patch to fix the build with automake-1.17:https://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=71d7945e298bc4077d4817eccd6c5cd7656942a2

After that i was able to build gcc-final in ~4h

Then I had some failing gnulib tests in coreutils/grep/libunistring. All these currently succeed on master on i586-gnu. 

FAIL: test-once1
================
# Segfault
FAIL test-once1 (exit status: 139)

FAIL: test-pthread_sigmask1
===========================

test-pthread_sigmask1.c:69: assertion 'sigint_occurred == 0' failed
FAIL test-pthread_sigmask1 (exit status: 134)

FAIL: test-symlink
==================

test-symlink.h:70: assertion 'errno == EEXIST || errno == EINVAL || errno == ENOENT' failed
FAIL test-symlink (exit status: 134)

FAIL: test-symlinkat
====================

test-symlink.h:70: assertion 'errno == EEXIST || errno == EINVAL || errno == ENOENT' failed
FAIL test-symlinkat (exit status: 134)


Hope this helps.
Ludovic Courtès wrote 1 years ago
Re: [bug#75518] Builds
(name . Andreas Enge)(address . andreas@enge.fr)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87frk7eivr.fsf@gnu.org
Hi,

Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (4 lines)
> Well, I have once again built out this branch up to mpc, and still not
> seen the issue. So from my point of view, it is unreproducible to the
> point of apparently not occurring in my setting :)

Like I wrote, the problem is non-deterministic and on top of that, it
sometimes has no impact (some ac_cv_* variable gets the wrong value but
that doesn’t affect the build result).

I think it’s important to address it since it’s so low in the stack, but
I haven’t been able to spend time on it lately.

Ludo’.
Janneke Nieuwenhuizen wrote 1 years ago
(no subject)
(address . 75518@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(name . Andreas Enge)(address . andreas@enge.fr)
87plj8sc1f.fsf@gnu.org
Hi!

I've just updated core-packages-team.

I merged my glibc-2.40 patches that raced with Zheng's amazing
glibc-2.41 work (it would be nice to align such changes on IRC?),
squashed squash! and fixup! commits, incorporated yelninei's feedback
about native i586-gnu builds from IRC, and rebased on latest master.

Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
Andreas Enge wrote 1 years ago
Re:
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)
Z7xN_gHoOyanBAOd@jurong
Hello!

Am Sun, Feb 23, 2025 at 08:20:44PM +0100 schrieb Janneke Nieuwenhuizen:
Toggle quote (2 lines)
> I've just updated core-packages-team.

Thanks for cleaning it all up!
I am a bit wary about some email-length commit messages such as
commit 3f0f24ec76002fefd0a20e9aea33ed646664f153
commit feb56748faa07c457654187e3cd154b26f7e6b2a

Is this not usually handled on guix-devel, or maybe by comments in the
code, with the commit message limited to what is actually changed
(the lines starting with "*") and sometimes one or two sentences about
the rationale?

As before, "./pre-inst-env guix build mpc" works like a charm for me.
So I wonder if the non-deterministic failure Ludovic wanted to work on
may actually be deterministic and explained by a hidden variable.

Andreas
Janneke Nieuwenhuizen wrote 1 years ago
Re: core-packages-team updated
(name . Andreas Enge)(address . andreas@enge.fr)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)
87y0xvquki.fsf_-_@gnu.org
Andreas Enge writes:

Hello, [didn't i set a subject before?]

Toggle quote (7 lines)
> Am Sun, Feb 23, 2025 at 08:20:44PM +0100 schrieb Janneke Nieuwenhuizen:
>> I've just updated core-packages-team.
>
> Thanks for cleaning it all up!
> I am a bit wary about some email-length commit messages such as
> commit 3f0f24ec76002fefd0a20e9aea33ed646664f153

Yeah, I chatted with Tomas on IRC


and it's what they intended, so.

Toggle quote (2 lines)
> commit feb56748faa07c457654187e3cd154b26f7e6b2a

and this would be on Ludo :)

Toggle quote (5 lines)
> Is this not usually handled on guix-devel, or maybe by comments in the
> code, with the commit message limited to what is actually changed
> (the lines starting with "*") and sometimes one or two sentences about
> the rationale?

Yes, usually I would agree. A too long message could be a sign of need
for documentation (code or manual) or a missing test...

Toggle quote (4 lines)
> As before, "./pre-inst-env guix build mpc" works like a charm for me.
> So I wonder if the non-deterministic failure Ludovic wanted to work on
> may actually be deterministic and explained by a hidden variable.

Thanks!

Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
Z572 wrote 1 years ago
Re: [bug#75518] core-packages-team updated
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 75518@debbugs.gnu.org)(name . Andreas Enge)(address . andreas@enge.fr)
87ldttrkjy.fsf@z572.online
Janneke Nieuwenhuizen <janneke@gnu.org> writes:

Toggle quote (11 lines)
> Hi!
>
> I've just updated core-packages-team.
>
> I merged my glibc-2.40 patches that raced with Zheng's amazing
> glibc-2.41 work (it would be nice to align such changes on IRC?),
> squashed squash! and fixup! commits, incorporated yelninei's feedback
> about native i586-gnu builds from IRC, and rebased on latest master.
>
> Greetings,
> Janneke
Thanks!
I found rebase have a little problem, accidental introduction of >>>>>>>
fixed as 3d37134ad6e6edac0a95ee1761ce0cfcad4bc7c9,
and adjust binutils-mingw-w64-timestamp.patch on
512d573b99d856433b7ffd2922433f54deef697a
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfr6klGDOXiwIdX/bO1qpk+Gi3/AFAme+ADEACgkQO1qpk+Gi
3/Cj2BAAm1uEv6eo5teN0IrQ9SipALqyW23fpqpO/+0bBSENdKeYRhWtZc6p9mD+
wJTnF4z4XyZXHlGCa2hKpIaMe2r/B0OyAqZtiK4gJH/RtYgSMXBdukSQRjXEhfsU
RBBiOiaQVdVy1HS2HNDyZWM/7DdTjzxCaAVOTBpsQz2rR4zMQm9hj4CN++PYsUJv
+dDq57ON6oGJOPdZf6Fvp2NIdcujb6ttHEI7ynQdO+U1lgThJPnjQm9QaIyuKp4y
0zLaXeVvVnGBITeJo2k3GuA34jLVmL974jLx2UoGb2eVeDdMdDCocLAzZmJ3JqIB
j9wIkKOr2fe2BuNnwl/WXUftUtKFvWTz5/zpEvMm0FgiRTDR8Xay8uivvnezvtQQ
UuDtVEHpCI3/JcVuvk0cmBTXeoeBcltk9oPF5vXuJTChkCfW66bOqN+/2voXFY/j
OmDhhpwb18XcSWOCjUlPupRGNnnfddOCjqn+7fpUhVHpEfSoBFyrLVhQpEC+4Es8
QoUhxtBZARg5krr8Mv9XOhQDFGZBDC5wWbIX/fBJY3Gu9EUhoq4WOkOm5nBDeh+3
iSiaNgPvR5tpCoUMcLWZcTCoTGffaC36854fri5nF7AHIzuW7J95Na3NpTicvkCH
LmsAZDSrf6ia+Fox5g9u0QLBUwC3+DVddZZFRb8QwK9wq3T8UHc=
=F9qU
-----END PGP SIGNATURE-----

Ludovic Courtès wrote 1 years ago
Re: bug#75676: Request for merging "gnome-team" branch
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Andreas Enge)(address . andreas@enge.fr)(address . 75518@debbugs.gnu.org)(address . 75676@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87ikox3uci.fsf_-_@gnu.org
Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

Toggle quote (5 lines)
> It's a tough call. QA looks red for gnome-team on everything but
> x86_64 [1] and I will be away for a few days starting tomorrow with no
> access to my commit machine. We could still merge today and fix the
> breakages later, but I fully understand if that's not what we want.

What’s the status of the branch?

There seems to be a growing list of branches waiting to be merged after
this one:


Ludo’.
Ludovic Courtès wrote 1 years ago
Re: core-packages-team updated
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(name . Andreas Enge)(address . andreas@enge.fr)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)
87h64fwemr.fsf@gnu.org
Hi!

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

Toggle quote (12 lines)
>> commit feb56748faa07c457654187e3cd154b26f7e6b2a
>
> and this would be on Ludo :)
>
>> Is this not usually handled on guix-devel, or maybe by comments in the
>> code, with the commit message limited to what is actually changed
>> (the lines starting with "*") and sometimes one or two sentences about
>> the rationale?
>
> Yes, usually I would agree. A too long message could be a sign of need
> for documentation (code or manual) or a missing test...

I agree too. The common way is to describe the problem in detail in the
bug report or cover letter, and then simply refer to it in the commit
message. We could do that here.

Ludo’.
Janneke Nieuwenhuizen wrote 1 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Andreas Enge)(address . andreas@enge.fr)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)
87cyf2qotk.fsf@gnu.org
Ludovic Courtès writes:

Toggle quote (20 lines)
> Hi!
>
> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>
>>> commit feb56748faa07c457654187e3cd154b26f7e6b2a
>>
>> and this would be on Ludo :)
>>
>>> Is this not usually handled on guix-devel, or maybe by comments in the
>>> code, with the commit message limited to what is actually changed
>>> (the lines starting with "*") and sometimes one or two sentences about
>>> the rationale?
>>
>> Yes, usually I would agree. A too long message could be a sign of need
>> for documentation (code or manual) or a missing test...
>
> I agree too. The common way is to describe the problem in detail in the
> bug report or cover letter, and then simply refer to it in the commit
> message. We could do that here.

I've pushed two empty squash! commits with sanitized commit messages for
these two, so that we won't forget and it's easy to fix.

Thanks Andreas for reviewing!

Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
Liliana Marie Prikler wrote 1 years ago
Re: bug#75676: Request for merging "gnome-team" branch
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Andreas Enge)(address . andreas@enge.fr)(address . 75518@debbugs.gnu.org)(address . 75676@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
e88fe59657fe9f6d6a6e1610b28379160a47a2ba.camel@gmail.com
Am Mittwoch, dem 26.02.2025 um 10:53 +0100 schrieb Ludovic Courtès:
Toggle quote (16 lines)
> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
>
> > It's a tough call.  QA looks red for gnome-team on everything but
> > x86_64 [1] and I will be away for a few days starting tomorrow with
> > no access to my commit machine.  We could still merge today and fix
> > the breakages later, but I fully understand if that's not what we
> > want.
>
> What’s the status of the branch?
>
> There seems to be a growing list of branches waiting to be merged
> after this one:
>
>   https://qa.guix.gnu.org/
Substitutes look good atm – I particularly like that we have 49% armhf
packages over on bordeaux – but there's no comparison to the merge
base, I do need a rebase and if possible I'd like to know that the
branch is good to go for ARM/RISC-V users too.

Cheers
Andreas Enge wrote 1 years ago
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 75518@debbugs.gnu.org)(address . 75676@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Z8I82ClyR78g3lNN@jurong
Hello Liliana,

Am Fri, Feb 28, 2025 at 09:04:44PM +0100 schrieb Liliana Marie Prikler:
Toggle quote (2 lines)
> I do need a rebase

you may already be aware of it, but I am just understanding that
has a list of commits on master handled by the data service.
You may want to choose the upmost commit that has a green tick
for rebasing.

Andreas
Andreas Enge wrote 1 years ago
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 75518@debbugs.gnu.org)(address . 75676@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Z8I94NU5_fwOU867@jurong
Am Fri, Feb 28, 2025 at 09:04:44PM +0100 schrieb Liliana Marie Prikler:
Toggle quote (3 lines)
> if possible I'd like to know that the
> branch is good to go for ARM/RISC-V users too.

PS: Given our lack of build power for these two architectures, I do not
think we can afford waiting for them and thereby delaying the next
topic branches. Currently we have 10 of them queued up!
Liliana Marie Prikler wrote 1 years ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 75518@debbugs.gnu.org)(address . 75676@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
b3bb7835049fb0fd07487cac5a6adaed03bca03a.camel@gmail.com
Am Freitag, dem 28.02.2025 um 23:51 +0100 schrieb Andreas Enge:
Toggle quote (9 lines)
> Am Fri, Feb 28, 2025 at 09:04:44PM +0100 schrieb Liliana Marie
> Prikler:
> > if possible I'd like to know that the branch is good to go for
> > ARM/RISC-V users too.
>
> PS: Given our lack of build power for these two architectures, I do
> not think we can afford waiting for them and thereby delaying the
> next topic branches. Currently we have 10 of them queued up!
> https://qa.guix.gnu.org/
I am waiting for human feedback more so than machine feedback.
I've rebased on 3c6bcbad213ad88e7574da14ed005a8b764e2d7e now, which
should yield a comparison soon.

Cheers
Liliana Marie Prikler wrote 1 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Andreas Enge)(address . andreas@enge.fr)(address . 75518@debbugs.gnu.org)(address . 75676-done@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
6d2998f6fe4c4b88e3a0b742ae347b08cf4c7dfb.camel@gmail.com
Am Mittwoch, dem 26.02.2025 um 10:53 +0100 schrieb Ludovic Courtès:
Toggle quote (6 lines)
> What’s the status of the branch?
>
> There seems to be a growing list of branches waiting to be merged
> after this one:
>
>   https://qa.guix.gnu.org/
The wait is over!
Z572 wrote 1 years ago
some new commits for core-packages-team
(address . 75518@debbugs.gnu.org)
87senukvn9.fsf@iscas.ac.cn
Hi, i push some commits to core-packages-team.

002291d6e3d gnu: pciutils: Use new style.
217b2e2add4 gnu: pciutils: Update to 3.13.0.
d15c58bb821 gnu: hwdata: Update to 0.392.
c000135ea60 gnu: linux-libre-headers: Update to 6.12.17.
091c0287523 gnu: libiconv: Update to 1.18.
2ca7789abdd gnu: diffutils: Update to 3.11.
588528c0f3a gnu: tar: Update to 1.35.
86bd1d058d0 gnu: findutils: Update to 4.10.0.
3ba2d9f5457 gnu: util-linux: Update to 2.40.4.

i trying build hello from riscv64-linux, some package's new versions
need <asm/hwprobe.h>, is include on linux 6.4 (as i known). so i update
linux-libre-headers to the latest LTS.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfr6klGDOXiwIdX/bO1qpk+Gi3/AFAmfFw8oACgkQO1qpk+Gi
3/CyQQ//ZR6fBC5qvXIGqa8S85LqEPyC/oSMjmlGMWVsRbcszgEIUcLq3zUwTp3t
Eq67LWvDjhqHuDfwSxO3Be6p0c3j2iXM4QaeSTBRQ8k5+UPKLH5pw3WV8NOfwMTW
jFsAnR2iLft075y2Ku8LMwb3YC51ZMV8m3U/Q39K4x7RzeVQGFEjfd+lKoEGVLp9
vV0aVHOFP71VTk/c0biJaWPJ0ZliJO+o4eCgVldgkpH44dt0kyF635iBAyib7jfU
43hHpCu/q3FdpGrRmg4b8FGL9kK4vPtFf8HeyUwV7GiSc4u6l+mr+W6tUXKJwU3f
cnpBPyrp1bX2C8MxugMMX1ZH2MKkuPjqf9mEagEpeTzcQIbxqQ/+oDFEZjaGGCIs
3LOSk/0qQ0jc/vx5zbCZwzVrEDVXm3qVKFZmMoAPu4P1tVcGUMmmcb99KLoxlyBN
6fTt2LEAe5joPL11HpnKXGUBommamuWmHdcRnGnVxblC1xv9y/udJ7XvkkWJVpbq
gTRK3MmrY6R5P13kZBJUJbvX5+Gs+HUMw+1+BY3E9XrVhGjdWaZ/dVDconbv5moy
qHLyqMTqwig4XVU6AEnB9ZsUYtHJeBfoli1lnS92Llsavpr3e039RGT6Lzj7DoJL
ddJbNBIoWjzL2Ubv2wA7VS9sSM2wXg+bNmdB2EwuUQKj1Tm/gW4=
=UvIV
-----END PGP SIGNATURE-----

Andreas Enge wrote 1 years ago
Re: core-packages-team updated
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)
Z8a_vuMcEdUWZqBb@jurong
Hello!

it is our turn now to be merged. Should we do so once the branch is
built, or somehow pass it (which might mean we would need to close this
bug first)? Not having seen it in my builds, I am not going to look at

Andreas
Ludovic Courtès wrote 1 years ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87sensc1st.fsf@gnu.org
Hi,

Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (5 lines)
> it is our turn now to be merged. Should we do so once the branch is
> built, or somehow pass it (which might mean we would need to close this
> bug first)? Not having seen it in my builds, I am not going to look at
> https://issues.guix.gnu.org/75658

I would love to look into it but I’ve been failing to do so for weeks,
due to other commitments. I think we cannot merge with such a bug
looming though, because it would come to haunt us.

I’ll see if I can get some time to investigate but I think we need more
eyeballs. First step is to get a small reproducer and see whether it’s
limited to Guile 2.0 (which is used here) or not.

Ludo’.
Andreas Enge wrote 1 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Z8cuXWvxs7oQyI5u@jurong
Am Tue, Mar 04, 2025 at 03:23:30PM +0100 schrieb Ludovic Courtès:
Toggle quote (4 lines)
> I would love to look into it but I’ve been failing to do so for weeks,
> due to other commitments. I think we cannot merge with such a bug
> looming though, because it would come to haunt us.

Is there actually any indication that the problem is new, and not
already present in the current code on the master branch?

Should we close this issue 75518, or how do we let the following 9 (!)
branches get ahead of us?

Andreas
Ludovic Courtès wrote 12 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87ecz7tufs.fsf@gnu.org
Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (8 lines)
> Am Tue, Mar 04, 2025 at 03:23:30PM +0100 schrieb Ludovic Courtès:
>> I would love to look into it but I’ve been failing to do so for weeks,
>> due to other commitments. I think we cannot merge with such a bug
>> looming though, because it would come to haunt us.
>
> Is there actually any indication that the problem is new, and not
> already present in the current code on the master branch?

I don’t know.

Toggle quote (3 lines)
> Should we close this issue 75518, or how do we let the following 9 (!)
> branches get ahead of us?

We can let at least the next one.

Sorry again for not being more available!

Ludo’.
Andreas Enge wrote 12 months ago
Close
(address . 75518-done@debbugs.gnu.org)
Z9Fxcs3K1Jep-LPa@jurong
As the only way I see of "giving way", I am closing this issue for now;
we can reopen it once the branch is ready to be merged (or open a new
issue).

Andreas
Closed
Ludovic Courtès wrote 12 months ago
Re: bug#75518: Request for merging "core-packages-team" branch
(name . Andreas Enge)(address . andreas@enge.fr)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
8734f467ug.fsf_-_@gnu.org
Hello,

An update: I came up with Gash patches that fix the problem we were

Once a Gash release is tagged with these patches, we can move forward
with the ‘core-packages-team’ branch.

In the meantime, we can keep updating the branch and fixing issues.

Thanks,
Ludo’.
Andreas Enge wrote 11 months ago
Re: core-packages-team updated
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Z-RqoW1y0IKuRC7P@jurong
Hello all,

I have added the newest release for mpfr on top of the branch.
Again I could build up to mpc.

Before we merge, we still need to modify some commits having an
"XXX" in the commit message.

Andreas
Janneke Nieuwenhuizen wrote 11 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)
877c4b4dz3.fsf@gnu.org
Andreas Enge writes:

Hello,

Toggle quote (3 lines)
> I have added the newest release for mpfr on top of the branch.
> Again I could build up to mpc.

Thanks!

Toggle quote (3 lines)
> Before we merge, we still need to modify some commits having an
> "XXX" in the commit message.

Right, I have collapsed the two squashes and the fixup, thus fixing the
two overly long commit messages with their XXX. Also I've rebased onto
latest master, which involved resolving some 25 odd conflicts and also
skipping a few commits. The previous core-packages-team branch is saved
as core-packages-team-old.

Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
Ludovic Courtès wrote 11 months ago
Re: bug#75518: Request for merging "core-packages-team" branch
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(name . Andreas Enge)(address . andreas@enge.fr)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)
87o6xkf594.fsf_-_@gnu.org
Hi,

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

Toggle quote (6 lines)
> Right, I have collapsed the two squashes and the fixup, thus fixing the
> two overly long commit messages with their XXX. Also I've rebased onto
> latest master, which involved resolving some 25 odd conflicts and also
> skipping a few commits. The previous core-packages-team branch is saved
> as core-packages-team-old.

Thank you!

I’ve reopened this issue. I don’t know if that’ll be enough to update

Ludo’.
Andreas Enge wrote 11 months ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Z-pbaPAOFpqu6DPH@jurong
Am Sat, Mar 29, 2025 at 12:25:27PM +0100 schrieb Ludovic Courtès:
Toggle quote (3 lines)
> I’ve reopened this issue. I don’t know if that’ll be enough to update
> the list at <https://qa.guix.gnu.org>.

It is enough, and we have even taken the front of the queue!
I have rebased the branch on the latest commit treated by QA, but QA has
not picked it up over night.

Maybe you can try to build out the branch on cuirass.

I can still build mpc :)

Andreas
Andreas Enge wrote 11 months ago
Close temporarily
(address . 75518-done@debbugs.gnu.org)
Z-v08PYb059VW-WK@jurong
Hello,

as we are holding up the queue and waiting for the gash bug to be fixed,
I am closing this bug again.

As we have seen, as soon as we are ready, we can reopen it and jump to
the front of the QA queue.

Andreas
Closed
Andreas Enge wrote 11 months ago
Re: bug#75518: Request for merging "core-packages-team" branch
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
Z_YyfdzePhbhB6Nx@jurong
Hello all,

while waiting for the external gash fix, I have tried updating coreutils
on this branch (we are hopelessly out of date!), but got build failures
in gcc-mesboot@4.something or so. This looks a lot like the bug that is
holding up our branch, so I have given up for the moment.

Andreas
Ludovic Courtès wrote 10 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87ikmexfl5.fsf_-_@gnu.org
Hello!

You might have seen that the Gash fix has now landed, via an
“unofficial” Gash branch:


CI started evaluating it but this will probably take ~24h if everything
goes well:


At any rate, we should now be able to finally move forward.

Perhaps we can reopen this issue?

Thanks,
Ludo’.
Andreas Enge wrote 10 months ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aBoilpfwNBr2Zsm5@jurong
Hello,

Am Tue, May 06, 2025 at 11:18:14AM +0200 schrieb Ludovic Courtès:
Toggle quote (4 lines)
> You might have seen that the Gash fix has now landed, via an
> “unofficial” Gash branch:
> https://issues.guix.gnu.org/75658#15

thanks for the temporary workaround!

Toggle quote (2 lines)
> Perhaps we can reopen this issue?

I have rebased the branch on master, with quite a few merge conflicts;
the branch now compiles, but I am not sure I have correctly merged in
the cases where a package has been altered at the same time on master
and on this branch. Apologies in advance for any mistake.

I have also reopened this issue, so that the branch will hopefully be
built on QA as well as CI.

Andreas
Christopher Baines wrote 10 months ago
Re: [bug#76311] Request for merging "kernel-team" branch
(name . Leo Famulari)(address . leo@famulari.name)(address . control@debbbugs.gnu.org)(name . Z572)(address . z572@z572.online)(name . Julian Flake)(address . flake@uni-koblenz.de)(address . 75518@debbugs.gnu.org)(address . 76311@debbugs.gnu.org)
875xi71npl.fsf@cbaines.net
block 75518 by 76311
thanks

Leo Famulari <leo@famulari.name> writes:

Toggle quote (15 lines)
> On Sat, May 10, 2025 at 07:49:21PM +0100, Christopher Baines wrote:
>> QA for once hasn't actually stalled, it's just busy submitting builds
>> for the core-packages-team branch.
>>
>> Given there are so many builds for that branch, and it still looks to
>> require quite a bit of work (currently the ARM bootstrap is broken), I'd
>> suggest making a decision on whether the kernel-team changes should be
>> merged before or after core-packages-team. Personally I think it makes
>> sense to shuffle round the order so that kernel-team can be built and
>> merged while core-packages-team is being fixed.
>
> I'm optimistic that the changes on the 'kernel-team' branch are limited
> enough in scope that things will work, and that it won't be a waste of
> time to run its builds before that of the core-packages-team.

Ok, I've gone ahead and put core-packages-team behind kernel-team.

Toggle quote (3 lines)
> I'll rebuild my system based on it now, although I can only meaningfully
> test the changes to kexec-tools, and not to bluez / Bluetooth.

-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmggcrZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xd1MA/+NmWrD8ani68dKOGT6EifSphL84nEz3R4
6QmHK/WKvFhs1x4WLFlFc1uSjrPLgIBN7F8yA7tNeWWGFyQmVPtGfAsy13XcPy05
aYPxKl59H1POBpZR1DWYeQSiD51YR+sTwxcebrss95BSaKmmVtnAy1EsFMFn8vRR
+aVDfAzjRoc3EkTzLdXUwtIOGDBamERci+yh2Ltu0lCbczAIcL4p/Nry9B3wmKJq
ubkLA/eKx2hT/4IDvxRL2gRbJGIpy5HrUEk/OOt7hUtPWw/LfHtA+e/HBV/wttS/
dFY5EYwxqPQsJRdlBM7uPugA0ZD60mgIrXq23pBYK+pCJdbk6Azw34PnY8NvtAqD
imuyEl+w6MMYzX8FnsgrnEk9jQfUKI790La9bfDf3sSH0GxqDdsX7shzFwqqr/fV
GjguSBTEwPjm9Zxz+jZEW2uo4Qhx6p+NQCWbsQ6uf2jyZWEH1cVKWhg+e7wVDnun
4bpX/OZHSn8njK9HMIbJTQOzyd8Yn8g598/AC/r+YELE2fZUnZ0XWUW3hWWv9VGH
MqMtAOUe92Yimh5SJNlTj+CPV29888ziQAOwDouKU3NxF5HeggZy+TKOqv+3s4eA
uZW+tIXWXtinrxmWh5CrP5BGqwkZvw2JXaLUA7F+Prk0d7qxEnngiGgM2DiczEcT
BdRbeyJFJMQ=
=w0su
-----END PGP SIGNATURE-----

Christopher Baines wrote 10 months ago
(no subject)
(address . control@debbugs.gnu.org)
87zffjzb5v.fsf@cbaines.net
block 75518 by 76311
thanks
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmggfbxfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XeMlA//TEHeVMOlPbaQMk0YLhHvu9J/xDPhTMAS
PAZEmut54FtrQpjoucoO437iz9AWyKkFSkg7kBBTotQ9R6ESUVw5pr0Wfd/YmkxB
FyM8bUEi7z38xsewRUr0ocm9CIiRH6uwreT7ktv1yV27XNbHmdWCIZ/p+wHWeXAE
n+8hmEHOGbPi2MjwJiCKIscLOOTG096+ExHUHdHPBrp44fAPy2j6oSYZxzwMVdIu
4BbgDX6m14HfFY00AQe3RenQ7i6i8z//5YP8hGzRAmJS7hRd4qBNwAXGp8601uvx
IN4LossrGLJddfFmbr+d1uPDhsGswmZ75NSjVD+2fHG2vYqAEpyytGLOooI8ryu/
mx9F0g5iSc8WmoYY9zMyVt1v3fymOPSwgPovyltaDlhl4xQdG3NKwTtu/OAT5is0
jMrtMpSS4L9wiBtwSqKhTcbAMpPirYCvW9ccl43AaPYGmYrhYkcIsVaDEL1FxlR7
zF8Yuco3e0D/TYsHkTVR9uW/2PlRYA3GivJysSE2fX9uJwGF7d7Sykuou4yK0Heg
ztI1UNsxNBe2Lh/fhyr278+a4aSx9g0kpQkJ2dSokydNsBBx7LR40P6b5y2JX8kX
qHsBU/B5SlvaRT/jmvyZlouPJg1Meo4DH4PDy+raTlNZT7Bv6TVuqbskG8Z8TiPv
Oc7qJLi7vdQ=
=0ML9
-----END PGP SIGNATURE-----

Andreas Enge wrote 10 months ago
Re: bug#75518: Request for merging "core-packages-team" branch
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aCSUbkaTk8Ro8ryj@jurong
Hello all,

I have rebased on a recent master commit and "fixup!"-ed Chris's commit
message so that it will not be forgotten under added commits.

Given Rutherter's comment and that neither CI, nor QA, nor I can build
the branch, should we disable parallel builds on xz-mesboot, and maybe
other mesboot packages as the need arises?

Andreas
Christopher Baines wrote 10 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87ldqzwcft.fsf@cbaines.net
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (3 lines)
> I have rebased on a recent master commit and "fixup!"-ed Chris's commit
> message so that it will not be forgotten under added commits.

My intent with that commit was to fixup the referenced commit, I just
didn't want to rebase the whole branch there and then for such a small
change.

With the previous commit message, I think Git would have done this
automatically if rebased with autosquash.
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmgkmgZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9Xe8shAAkI7c9yjt5u4alTnKJGOn3z0KOW0ThX2u
d1dY/8IN7UAHcgropv+XF3lGFFg16+CadiyabeYLZCILVQek4B+2SslbfZEWqa01
4+LfW6GP2nzFL/mumnzLQ3U5//xUHDsbyX34BQEN4bPd+cBrntkMGHdRHFBiYlRz
tgPghkhv749Q+Rjng4yFxCYI+xmaOXt0NwMPYnN8S7hVnND4x6/TGZzHgsA2iGIi
Xb857WOTikdoKXKotOHIwMmUUq/rkPE/wALmTJxKQMPh0FGZtBhAYxXiY1D84OBo
b6i7gulJkTudctVgTC70ldmZ+tSV3urNSKg9f9zDoaQoSvouepr4OiRuB03cjzYU
C8IpDDoFpZz2Xm6Wsys1i9cHGTGzhjgzQm+IQhMlRTo0UHzooOICQK8ecTyvxvtw
fozhVaxi37Y5qJ3K5mAZkn0Ctx202RQ0sVx0dIlWoibC2N5aijCJPzxEv6mVQ1GJ
/jQagey9K7yANq9CWxHTir3mp3z+IC7d3fZrgLP4hD0ZGBKJzccoOZ6TNQmx+Qo9
y4MhC5TdBx/TaMUINFXA5webIDlpe6T2dofZ7YoFV3dWAZ62kleYVpaabDqQeWUq
EaiywTAG0apcGvlVVIUKocHSOBtu1po9CnvD3jLmnLCJ3sWsblu/SVks4VFlJO90
XIYvw3hklSs=
=69Rs
-----END PGP SIGNATURE-----

Greg Hogan wrote 10 months ago
Re: [bug#75518] Request for merging "core-packages-team" branch
(name . Andreas Enge)(address . andreas@enge.fr)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
CA+3U0Zm+cGktqp-Z785TX+2MTHvMtYvqgh59YrCwxA+Ufy6S9w@mail.gmail.com
On Wed, May 14, 2025 at 9:10 AM Andreas Enge <andreas@enge.fr> wrote:
Toggle quote (12 lines)
>
> Hello all,
>
> I have rebased on a recent master commit and "fixup!"-ed Chris's commit
> message so that it will not be forgotten under added commits.
>
> Given Rutherter's comment and that neither CI, nor QA, nor I can build
> the branch, should we disable parallel builds on xz-mesboot, and maybe
> other mesboot packages as the need arises?
>
> Andreas

Where was the issue reported? I am able to build the bootstrap after
reverting the diffutils update, which reliably breaks automake for me
(and when disabling the failed tests, other tests then fail like
playing whac-a-mole).
Greg Hogan wrote 10 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
CA+3U0Zn8yZaHfNvAswjMqXdixnk700DqjJ8oOZkjzpzefwY5qg@mail.gmail.com
On Wed, May 14, 2025 at 4:20 PM Greg Hogan <code@greghogan.com> wrote:
Toggle quote (19 lines)
>
> On Wed, May 14, 2025 at 9:10 AM Andreas Enge <andreas@enge.fr> wrote:
> >
> > Hello all,
> >
> > I have rebased on a recent master commit and "fixup!"-ed Chris's commit
> > message so that it will not be forgotten under added commits.
> >
> > Given Rutherter's comment and that neither CI, nor QA, nor I can build
> > the branch, should we disable parallel builds on xz-mesboot, and maybe
> > other mesboot packages as the need arises?
> >
> > Andreas
>
> Where was the issue reported? I am able to build the bootstrap after
> reverting the diffutils update, which reliably breaks automake for me
> (and when disabling the failed tests, other tests then fail like
> playing whac-a-mole).

Also, the libstdc++ builds (and therefore gcc-toolchains) are broken
for me for versions other than 14 since 32348316 "gnu: gcc-6: Use
libstdc++ headers appropriate for each GCC." Is this seen elsewhere?
for libstdc++-13.3.0:

Toggle snippet (41 lines)
../../libstdc++-v3/libsupc++/eh_call.cc:39:1: warning: new declaration
‘void __cxa_call_terminate(_Unwind_Exception*)’ ambiguates built-in
declaration ‘void __cxa_call_terminate(void*)’
[-Wbuiltin-declaration-mismatch]
39 | __cxa_call_terminate(_Unwind_Exception* ue_header) throw ()
| ^~~~~~~~~~~~~~~~~~~~
../../libstdc++-v3/libsupc++/eh_call.cc: In function ‘void
__cxa_call_terminate(_Unwind_Exception*)’:
../../libstdc++-v3/libsupc++/eh_call.cc:39:1: internal compiler error:
in gimple_build_eh_must_not_throw, at gimple.cc:730
0x7ffff7ced956 __libc_start_call_main
???:0
0x7ffff7ceda14 __libc_start_main_alias_1
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [Makefile:777: eh_call.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory
'/tmp/guix-build-libstdc++-13.3.0.drv-0/gcc-13.3.0/build/libsupc++'
make[1]: *** [Makefile:576: all-recursive] Error 1
make[1]: Leaving directory
'/tmp/guix-build-libstdc++-13.3.0.drv-0/gcc-13.3.0/build'
make: *** [Makefile:501: all] Error 2
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("-j" "4"
"--max-load=4") exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 0.5 seconds
command "make" "-j" "4" "--max-load=4" failed with status 2
build process 6 exited with status 256
builder for `/gnu/store/9kzg29k5ldm4x2mw3hsl7scvcgvr41v9-libstdc++-13.3.0.drv'
failed with exit code 1
build of /gnu/store/9kzg29k5ldm4x2mw3hsl7scvcgvr41v9-libstdc++-13.3.0.drv failed
View build log at
'/var/log/guix/drvs/9k/zg29k5ldm4x2mw3hsl7scvcgvr41v9-libstdc++-13.3.0.drv.gz'.
guix build: error: build of
`/gnu/store/9kzg29k5ldm4x2mw3hsl7scvcgvr41v9-libstdc++-13.3.0.drv'
failed
Andreas Enge wrote 10 months ago
(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aCXSJg4g-GpsLYzJ@jurong
Am Wed, May 14, 2025 at 04:20:52PM -0400 schrieb Greg Hogan:
Toggle quote (2 lines)
> Where was the issue reported?

It is visible on QA (well, until the latest push to this branch, we now
have to wait and see whether the problem is still here - only 3 packages
were built for x86_64), and on CI.

Strangely Rutherther's message did not make it to

I am copy-pasting it again:
"I was looking into why xz-mesboot build is failing. According to
Christopher it gets timeouted. I tried building locally, first with no
arguments added and it got stuck. Then I tried building with --jobs=1,
and it took just 45 minutes to do the build.
According to Efraim there have already been problems with mesboot
packages on riscv64 bootstrap so he disabled all parallel builds there."

Andreas
Andreas Enge wrote 10 months ago
Block
(address . control@debbugs.gnu.org)
aCXS5jSHXAs8MtWi@jurong
block 75518 by 76640
thanks
Andreas Enge wrote 10 months ago
Re: [bug#75518] Request for merging "core-packages-team" branch
(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Zheng Junjie)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aCXUD_JI8OCoH9TP@jurong
I have had the issue blocked by games-updates, since this branch is
clearly not ready. Maybe we should also let go-team to the front, but it
would be nice to first have QA evaluate the latest commits.

Andreas
Ludovic Courtès wrote 10 months ago
Re: Request for merging "core-packages-team" branch
(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Andreas Enge)(address . andreas@enge.fr)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87cycavttl.fsf@gnu.org
Hi,

Rutherther <rutherther@ditigal.xyz> writes:

Toggle quote (8 lines)
> I was looking into why xz-mesboot build is failing. According to
> Christopher it gets timeouted. I tried building locally, first with no
> arguments added and it got stuck. Then I tried building with --jobs=1,
> and it took just 45 minutes to do the build.
>
> According to Efraim there have already been problems with mesboot
> packages on riscv64 bootstrap so he disabled all parallel builds there.

Could you open an issue for this? Please make sure to include the
command the reproduce the bug and the commit that exhibits it.

Thanks,
Ludo’.
Rutherther wrote 9 months ago
Request for merging "core-packages-team" branch
(address . 75518@debbugs.gnu.org)
87plfwwk4c.fsf@ditigal.xyz
Just testing. Ignore this message. Sorry if it pinged you somehow.
Christopher Baines wrote 9 months ago
(no subject)
(name . GNU Debbugs)(address . control@debbugs.gnu.org)
87plfvn6zk.fsf@cbaines.net
block 75518 by 76654
thanks
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmg0Hd9fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XcqEg//eu7ZAUSzMWICJXksXNSadWd/w29v+1kl
BvLyHw738ohPwUkmxuk6ymb86a2a8buGDmxV+ZVn9MBVQpjku3mF9W8tG8pyu8Mi
8YhpiHYomN2OAeYK4gw9rJ0bvixldOvsAM0WlLthz2EdyGUcb5NFT378YwRkHTcC
kf9Jl0cpEoM0ZFu8/MnacAsRR3Tr7B7f1XmMoD8rcq0bhSfWmaPcf0cZNYGpwNze
/5ypYyvmXou9nYlJcsgsCaD5VQMJpii1sE9E4fNDIozz+lDK8V3XG9SeEhMLsjQ/
5bVwXz1kkZbH1POr8D0I42MPhwpHJjWUPa4F52v4S+R4kP+20kJVttrzwvn3FHgt
CMGa2VpCdD8SlqDTxTg7Fxi1eDDClOcLdTCSFySjmOXgDY7HhLOUA2rEjrn+AtKD
Uv50x7D2VzDNdjS7dGehaCtjbCxciB4WHJdsDlew6O0yV8jXPyC8utywjZOGQyAw
Y12JidW26+/MX4Ea2mUDjakg88ayA34523OTeIUS3DItLFcQemcv+uYhFMWRF0Gx
CqX94QSxOVnYWoJQLTG1fbvEvXJp19usPUlTJu+CUP5PzMvvBvEdvwh2fByNslhe
fBZDABg4ZttcoGISiMN/rcDzW41E0EJWvYT0DFP8pphqbO/9L3B69RWFsIrgLtJ7
6ecl5JIbTSA=
=rhN5
-----END PGP SIGNATURE-----

Rutherther wrote 9 months ago
Re: Request for merging "core-packages-team" branch
(address . 75518@debbugs.gnu.org)
87ecw48qsq.fsf@ditigal.xyz
Hi,
I had a chance to look at one of the failing packages - kexec-tools. It
doesn't build because it tries to build something for i386 on x64 and it
fails on that, not sure why. Updating to latest (2.0.31) resolves the issue.

Rutherther
Andreas Enge wrote 9 months ago
Block
(address . control@debbugs.gnu.org)
aDwd2BD7K4ILZDmP@jurong
block 75518 by 76899
thanks
Andreas Enge wrote 9 months ago
Re: Request for merging "core-packages-team" branch
(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Greg Hogan)(address . code@greghogan.com)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aDwoPzJXovr3ZU1h@jurong
Thanks for the report and solution, I have pushed an update.

It would be nice if someone could rebase the branch on a recent master
commit known to the data service; I get a merge conflict related to a
graft of bash and do not feel confident enough to resolve it.

Andreas
Ludovic Courtès wrote 9 months ago
(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Andreas Enge)(address . andreas@enge.fr)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87a56r40f0.fsf@gnu.org
Hello,

Rutherther <rutherther@ditigal.xyz> writes:

Toggle quote (5 lines)
> FYI graft of bash has been added a part of series that adds support for
> /etc/profile.d and /etc/bashrc.d,
> the graft makes bash source /etc/bashrc on its own,
> it had to be sourced manually from ~/.profile previously.

Uh. I think we should avoid keep grafts for security updates that need
to happen quickly.

Toggle quote (4 lines)
> Btw how do rebases work currently? As far as I know the mirror bot
> cannot remove branches so it won't sync the branches to savannah, but QA
> takes the branches from savannah. Or am I mistaken somewhere?

I’m not sure if the “mirror bot” (actually Forgejo) can remove branches
or not. But I believe that if we rebase and force-push, Savannah should
follow. So I would assume that this work and if it doesn’t, we’ll see
how to fix it.

Ludo’.
Rutherther wrote 9 months ago
(address . 75518@debbugs.gnu.org)
8734cifhw9.fsf@ditigal.xyz
Resending my e-mail without headers for Debbugs (not sure what To/Cc
address causes the issue of not appearing e-mails...)

Andreas Enge <andreas@enge.fr> writes:

Toggle quote (6 lines)
> Thanks for the report and solution, I have pushed an update.
>
> It would be nice if someone could rebase the branch on a recent master
> commit known to the data service; I get a merge conflict related to a
> graft of bash and do not feel confident enough to resolve it.

FYI graft of bash has been added a part of series that adds support for
/etc/profile.d and /etc/bashrc.d,
the graft makes bash source /etc/bashrc on its own,
it had to be sourced manually from ~/.profile previously.

As far as I can tell the resolution itself should be just to use bash
updated to 5.2.37 source and add replacement. Although it might also
make sense to ungraft this soon, where it would mean adding the flag
to cppflags.

Btw how do rebases work currently? As far as I know the mirror bot
cannot remove branches so it won't sync the branches to savannah, but QA
takes the branches from savannah. Or am I mistaken somewhere?

Toggle quote (3 lines)
>
> Andreas

Rutherther
Rutherther wrote 9 months ago
(address . 75518@debbugs.gnu.org)
87y0uae39r.fsf@ditigal.xyz
Resending my e-mail without headers for Debbugs (not sure what To/Cc
address causes the issue of not appearing e-mails...)

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (2 lines)
> Hello,
> Rutherther <rutherther@ditigal.xyz> writes:
[ 5 more citation lines. Click/Enter to show. ]
Toggle quote (9 lines)
>
>> FYI graft of bash has been added a part of series that adds support for
>> /etc/profile.d and /etc/bashrc.d,
>> the graft makes bash source /etc/bashrc on its own,
>> it had to be sourced manually from ~/.profile previously.
>
> Uh. I think we should avoid keep grafts for security updates that need
> to happen quickly.

Agreed, I was also trying to propose to just put the change on a team

Toggle quote (2 lines)
>> Btw how do rebases work currently? As far as I know the mirror bot
>> cannot remove branches so it won't sync the branches to savannah, but QA
[ 3 more citation lines. Click/Enter to show. ]
Toggle quote (7 lines)
>> takes the branches from savannah. Or am I mistaken somewhere?
>
> I’m not sure if the “mirror bot” (actually Forgejo) can remove branches
> or not. But I believe that if we rebase and force-push, Savannah should
> follow. So I would assume that this work and if it doesn’t, we’ll see
> how to fix it.

Hm, I am not a commiter, so I wouldn't know for sure, but from what I
picked up I thought that Savannah doesn't support forced-pushes, but
requires to remove and add a branch. I would assume that is unsupported
behavior.

Looking into it, I remembered podiki said they rebased mesa-updates:
is 6e9de, committed yesterday.

At savannah, last commit is 6c210:
almost month old.

I think this is caused by the rebase and by the bot being unable to
remove and push the branch.

Rutherther

Toggle quote (1 lines)
> Ludo’.
yelninei wrote 9 months ago
(name . 75518)(address . 75518@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . Greg Hogan)(address . code@greghogan.com)(name . Andreas Enge)(address . andreas@enge.fr)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
ORkoi10--F-9@tutamail.com
Hello,

I have been running a minimal server on core-packages team for a while to test the hurd stuff.

To able to reconfigure the system I encountered the following issues on x86_64-linux:
- dtc: Test issues
- fakeroot: build issues, fixed by updating
- python-pyelftools: test issues- nvi: A missing #~ for the #:make-flags
- clisp: test issues
- openbios: Build failure, Updated to newer commit to include this patch : https://github.com/openbios/openbios/commit/d5faa80713d25a8c8d47a3fb4d215d6c96e338ba ,
There is currently an issue with every gcc that is not gcc-14 https://issues.guix.gnu.org/75620#2
I have not looked at all into these yet and and would appreciate some help
Yelninei
Rutherther wrote 9 months ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Andreas Enge)(address . andreas@enge.fr)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87tt4ye05x.fsf@ditigal.xyz
Hi, I've tried looking at one of the failing packages - motif. It seems
to me it is probably failing because of gcc-14, so I wanted to try with
gcc-11 to verify that.

(The error it fails with is implicit declaration of strncmp in seemingly
generated file. I think some kind of generation/copy of C code is failing in
the package with gcc-14 source, but I haven't really checked further and
didn't want to spend too much time on it)

That leads to a build of libstdc++-11.5.0 as libstdc++ is built for the
gcc version used in updates to core-packages-team. (since 323483163e1453498f25caf254851a1f6fb817c7)
But this is failing for me locally. Specifically with
internal compiler error! :(

Any ideas? I am completely lost. Attaching the log.

Toggle quote (14 lines)
> ../../libstdc++-v3/libsupc++/eh_call.cc:39:1: warning: new declaration ‘void __cxa_call_terminate(_Unwind_Exception*)’ ambiguates built-in declaration ‘void __cxa_call_terminate(void*)’ [-Wbuiltin-declaration-mismatch]
> 39 | __cxa_call_terminate(_Unwind_Exception* ue_header) throw ()
> | ^~~~~~~~~~~~~~~~~~~~
> ../../libstdc++-v3/libsupc++/eh_call.cc: In function ‘void __cxa_call_terminate(_Unwind_Exception*)’:
> ../../libstdc++-v3/libsupc++/eh_call.cc:39:1: internal compiler error: in gimple_build_eh_must_not_throw, at gimple.cc:730
> libtool: compile: g++ -I/tmp/guix-build-libstdc++-11.5.0.drv-0/gcc-11.5.0/libstdc++-v3/../libgcc -I/tmp/guix-build-libstdc++-11.5.0.drv-0/gcc-11.5.0/build/include/ -I/tmp/guix-build-libstdc++-11.5.0.drv-0/gcc-11.5.0/build/include -I/tmp/guix-build-libstdc++-11.5.0.drv-0/gcc-11.5.0/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=hash_bytes.lo -fcf-protection -mshstk -c ../../libstdc++-v3/libsupc++/hash_bytes.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o hash_bytes.o
> 0x7ffff7cedbd6 __libc_start_call_main
> ???:0
> 0x7ffff7cedc94 __libc_start_main_alias_1
> ???:0
> Please submit a full bug report, with preprocessed source (by using -freport-bug).
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.
> make[2]: *** [Makefile:769: eh_call.lo] Error 1
Rutherther
Rutherther wrote 9 months ago
(address . 75518@debbugs.gnu.org)
87r002e04x.fsf@ditigal.xyz
Resending my e-mail for Debbugs tracker, again.

Hi, I've tried looking at one of the failing packages - motif. It seems
to me it is probably failing because of gcc-14, so I wanted to try with
gcc-11 to verify that.

(The error it fails with is implicit declaration of strncmp in seemingly
generated file. I think some kind of generation/copy of C code is failing in
the package with gcc-14 source, but I haven't really checked further and
didn't want to spend too much time on it)

That leads to a build of libstdc++-11.5.0 as libstdc++ is built for the
gcc version used in updates to core-packages-team. (since 323483163e1453498f25caf254851a1f6fb817c7)
But this is failing for me locally. Specifically with
internal compiler error! :(

Any ideas? I am completely lost. Attaching the log.

Toggle quote (14 lines)
> ../../libstdc++-v3/libsupc++/eh_call.cc:39:1: warning: new declaration ‘void __cxa_call_terminate(_Unwind_Exception*)’ ambiguates built-in declaration ‘void __cxa_call_terminate(void*)’ [-Wbuiltin-declaration-mismatch]
> 39 | __cxa_call_terminate(_Unwind_Exception* ue_header) throw ()
> | ^~~~~~~~~~~~~~~~~~~~
> ../../libstdc++-v3/libsupc++/eh_call.cc: In function ‘void __cxa_call_terminate(_Unwind_Exception*)’:
> ../../libstdc++-v3/libsupc++/eh_call.cc:39:1: internal compiler error: in gimple_build_eh_must_not_throw, at gimple.cc:730
> libtool: compile: g++ -I/tmp/guix-build-libstdc++-11.5.0.drv-0/gcc-11.5.0/libstdc++-v3/../libgcc -I/tmp/guix-build-libstdc++-11.5.0.drv-0/gcc-11.5.0/build/include/ -I/tmp/guix-build-libstdc++-11.5.0.drv-0/gcc-11.5.0/build/include -I/tmp/guix-build-libstdc++-11.5.0.drv-0/gcc-11.5.0/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=hash_bytes.lo -fcf-protection -mshstk -c ../../libstdc++-v3/libsupc++/hash_bytes.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o hash_bytes.o
> 0x7ffff7cedbd6 __libc_start_call_main
> ???:0
> 0x7ffff7cedc94 __libc_start_main_alias_1
> ???:0
> Please submit a full bug report, with preprocessed source (by using -freport-bug).
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.
> make[2]: *** [Makefile:769: eh_call.lo] Error 1
Rutherther
Andreas Enge wrote 9 months ago
(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aD2tKoR4qE9H9hs0@jurong
Am Mon, Jun 02, 2025 at 03:35:38PM +0200 schrieb Rutherther:
Toggle quote (4 lines)
> Hi, I've tried looking at one of the failing packages - motif. It seems
> 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@25.2 ddd@3.4.1 emacs-motif@29.4 xnedit@1.6.3

I wonder if one "solution" would be to remove motif and its dependent
packages?

Andreas
Ludovic Courtès wrote 9 months ago
Savannah mirroring and force-push
(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Andreas Enge)(address . andreas@enge.fr)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
871ps2p48f.fsf@gnu.org
Hello,

Rutherther <rutherther@ditigal.xyz> writes:

Toggle quote (11 lines)
> Looking into it, I remembered podiki said they rebased mesa-updates:
> https://codeberg.org/guix/guix/commits/branch/mesa-updates, last commit
> is 6e9de, committed yesterday.
>
> At savannah, last commit is 6c210:
> https://cgit.git.savannah.gnu.org/cgit/guix.git/commit/?h=mesa-updates&id=6c210c6ac61499ebf2f3b3b4ca2607b50418d699,
> almost month old.
>
> I think this is caused by the rebase and by the bot being unable to
> remove and push the branch.

mirroring some of the branches (gnome-team, kernel-updates, mesa-update,
etc.) was rejected due to updates being “non-fast forward”.

I filed an support request at Savannah:


Thanks,
Ludo’.
Ludovic Courtès wrote 9 months ago
Motif build failure
(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Andreas Enge)(address . andreas@enge.fr)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87plfmnneq.fsf@gnu.org
Hi,

Rutherther <rutherther@ditigal.xyz> writes:

Toggle quote (2 lines)
> Hi, I've tried looking at one of the failing packages - motif.

The error looks like this:

Toggle snippet (30 lines)
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../include -I.. -I./.. -DXMBINDDIR_FALLBACK=\"/gnu/store/lm1p1w0x29w2ypvc8g8nj6k7vharz927-motif-2.3.8-0.59858b0/lib/X11/bindings\" -DINCDIR=\"/gnu/store/lm1p1w0x29w2ypvc8g8nj6k7vharz927-motif-2.3.8-0.59858b0/include/X11\" -DLIBDIR=\"/gnu/store/lm1p1w0x29w2ypvc8g8nj6k7vharz927-motif-2.3.8-0.59858b0/lib/X11\" -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -g -O2 -Wall -g -fno-strict-aliasing -Wno-unused -Wno-comment -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -MT XpmWrFFrDat.lo -MD -MP -MF .deps/XpmWrFFrDat.Tpo -c XpmWrFFrDat.c -fPIC -DPIC -o .libs/XpmWrFFrDat.o
XpmCrBufFrI.c: In function ‘XmeXpmCreateBufferFromXpmImage’:
XpmCrBufFrI.c:155:5: error: implicit declaration of function ‘strcpy’ [-Wimplicit-function-declaration]
155 | strcpy(ptr, buf);
| ^~~~~~
XpmCrBufFrI.c:47:1: note: include ‘<string.h>’ or provide a declaration of ‘strcpy’
46 | #include "XpmI.h"
+++ |+#include <string.h>
47 |
XpmCrBufFrI.c:155:5: warning: incompatible implicit declaration of built-in function ‘strcpy’ [-Wbuiltin-declaration-mismatch]
155 | strcpy(ptr, buf);
| ^~~~~~
XpmCrBufFrI.c:155:5: note: include ‘<string.h>’ or provide a declaration of ‘strcpy’
XpmCrBufFrI.c: In function ‘WriteColors’:
XpmCrBufFrI.c:292:9: error: implicit declaration of function ‘strncpy’ [-Wimplicit-function-declaration]
292 | strncpy(s, *defaults++, cpp);
| ^~~~~~~
XpmCrBufFrI.c:292:9: note: include ‘<string.h>’ or provide a declaration of ‘strncpy’
XpmCrBufFrI.c:292:9: warning: incompatible implicit declaration of built-in function ‘strncpy’ [-Wbuiltin-declaration-mismatch]
XpmCrBufFrI.c:292:9: note: include ‘<string.h>’ or provide a declaration of ‘strncpy’
XpmCrBufFrI.c:312:9: warning: incompatible implicit declaration of built-in function ‘strcpy’ [-Wbuiltin-declaration-mismatch]
312 | strcpy(s, "\",\n");
| ^~~~~~
XpmCrBufFrI.c:312:9: note: include ‘<string.h>’ or provide a declaration of ‘strcpy’
XpmCrBufFrI.c:316:45: error: implicit declaration of function ‘strlen’ [-Wimplicit-function-declaration]
316 | (*data_size + l - *used_size) <= strlen(buf))
| ^~~~~~
XpmCrBufFrI.c:316:45: note: include ‘<string.h>’ or provide a declaration of ‘strlen’

This is easily addressed with the attached patch.

Unfortunately there are additional failures afterwards:

Toggle snippet (19 lines)
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../include -I.. -I./.. -DXMBINDDIR_FALLBACK=\"/gnu/store/jww518240g0h9ffmbn1c3069ly829mhw-motif-2.3.8-0.59858b0/lib/X11/bindings\" -DINCDIR=\"/gnu/store/jww518240g0h9ffmbn1c3069ly829mhw-motif-2.3.8-0.59858b0/include/X11\" -DLIBDIR=\"/gnu/store/jww518240g0h9ffmbn1c3069ly829mhw-motif-2.3.8-0.59858b0/lib/X11\" -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -g -O2 -Wall -g -fno-strict-aliasing -Wno-unused -Wno-comment -I/gnu/store/cm3gmdiv2dmwnld2v5zngc5amsaxnf2b-freetype-2.13.0/include/freetype2 -I/gnu/store/1dlwzyjk51xbn1k7v7b010gidrxxvida-libpng-1.6.39/include/libpng16 -MT DrawUtils.lo -MD -MP -MF .deps/DrawUtils.Tpo -c DrawUtils.c -fPIC -DPIC -o .libs/DrawUtils.o
In file included from TabStack.c:43:
TabStack.c: In function ‘QueryGeometry’:
../Xm/TabStackP.h:140:66: error: passing argument 1 of ‘_XmTabBoxStackedGeometry’ from incompatible pointer type [-Wincompatible-pointer-types]
140 | #define XmTabStack_tab_box(w) (((XmTabStackWidget)(w))->tab_stack.tab_box)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
| |
| Widget {aka struct _WidgetRec *}
TabStack.c:1641:42: note: in expansion of macro ‘XmTabStack_tab_box’
1641 | _XmTabBoxStackedGeometry(XmTabStack_tab_box(tab), width,
| ^~~~~~~~~~~~~~~~~~
TabStack.c:74:45: note: expected ‘XmTabBoxWidget’ {aka ‘struct _XmTabBoxRec *’} but argument is of type ‘Widget’ {aka ‘struct _WidgetRec *’}
74 | extern void _XmTabBoxStackedGeometry _ARGS((XmTabBoxWidget, int, XRectangle *));
| ^~~~~~~~~~~~~~
TabStack.c:60:18: note: in definition of macro ‘_ARGS’
60 | #define _ARGS(a) a
| ^

I tried to build with ‘-std=c99’ (which is supposedly lower than the
default for GCC 14) but that didn’t help.

We could also check what other distros are doing.

Ludo’.
Add missing includes.

Toggle diff (20 lines)
diff --git a/lib/Xm/XpmI.h b/lib/Xm/XpmI.h
index 5d690fa1..61767865 100644
--- a/lib/Xm/XpmI.h
+++ b/lib/Xm/XpmI.h
@@ -401,6 +401,7 @@ FUNC(xpmstrdup, char *, (char *s1));
#else
#undef xpmstrdup
#define xpmstrdup strdup
+#include <string.h>
#endif
#ifdef NEED_STRCASECMP
@@ -408,6 +409,7 @@ FUNC(xpmstrcasecmp, int, (char *s1, char *s2));
#else
#undef xpmstrcasecmp
#define xpmstrcasecmp strcasecmp
+#include <strings.h>
#endif
FUNC(xpmatoui, unsigned int,
Rutherther wrote 9 months ago
Re: Request for merging "core-packages-team" branch
(address . 75518@debbugs.gnu.org)
87jz5udrpj.fsf@ditigal.xyz
Resending to Debbugs tracker without To/Cc headers with all users.

Andreas Enge <andreas@enge.fr> writes:

Toggle quote (2 lines)
> 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. ]
Toggle quote (10 lines)
>> 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@25.2
> ddd@3.4.1 emacs-motif@29.4 xnedit@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:
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@ditigal.xyz>
From: Rutherther <rutherther@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(-)

Toggle diff (46 lines)
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
Andreas Enge wrote 9 months ago
(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aEFoMC9WI4EWl7YJ@jurong
Am Mon, Jun 02, 2025 at 06:35:06PM +0200 schrieb Rutherther:
Toggle quote (6 lines)
> Andreas Enge <andreas@enge.fr> writes:
> > 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.

Okay, fine as well. If not, as this branch is concerned, I am getting
desperate, and think that any approach to getting it merged would be
good :)

Concerning clisp, there is a fix for some test problem on master.

I have rebased again on master, dropped the bash replacement and added the
CPPFLAG to the bash package itself, and pushed.

It would be good to get this merged, the branch sends out strong
core-updates vibes - we made the merge request almost five months ago!
This is quite incompatible with our goal of making a release once per
year, or maybe even twice.
Also qt-team is waiting for the switch to gcc@14.

Are the remaining problems critical, or something that could be fixed
later on master?

QA feels a bit slow right now, so I was about to suggest watching CI
instead, but this gives me 504 errors...

Andreas
yelninei wrote 9 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
OS-O9Li--N-9@tutamail.com
Hello Andreas,


Jun 5, 2025, 09:49 by andreas@enge.fr:

Toggle quote (19 lines)
> Am Mon, Jun 02, 2025 at 06:35:06PM +0200 schrieb Rutherther:
>
>> Andreas Enge <andreas@enge.fr> writes:
>> > 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.
>>
>
> Okay, fine as well. If not, as this branch is concerned, I am getting
> desperate, and think that any approach to getting it merged would be
> good :)
>
> Concerning clisp, there is a fix for some test problem on master.
>
> I have rebased again on master, dropped the bash replacement and added the
> CPPFLAG to the bash package itself, and pushed.
>

It seems like the merge conflict I caused for hurd has been resolved incorrectly: hurd still has the "hurd-64bit.patch" that I removed when updating hurd for core-packages-team.

Toggle quote (9 lines)
> It would be good to get this merged, the branch sends out strong
> core-updates vibes - we made the merge request almost five months ago!
> This is quite incompatible with our goal of making a release once per
> year, or maybe even twice.
> Also qt-team is waiting for the switch to gcc@14.
>
> Are the remaining problems critical, or something that could be fixed
> later on master?
>
having every gcc that is not gcc-14 broken seems bad.

Here is where where the packages I reported come from:
clisp is blocking linux-libre
dtc and openbios are blocking grub
nvi is in %base-packages-interactive
python-pyelftools is blocking genimage
fakeroot is needed for system-disk-image

You cannot currently run guix system image gnu/system/examples/bare-bones.tmpl from core packages team.


Toggle quote (5 lines)
> QA feels a bit slow right now, so I was about to suggest watching CI
> instead, but this gives me 504 errors...
>
> Andreas
>
Yelninei
Andreas Enge wrote 9 months ago
(address . yelninei@tutamail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aEG-D9jLz_R8ZtaP@jurong
Hello Yelninei,

Am Thu, Jun 05, 2025 at 04:14:17PM +0200 schrieb yelninei@tutamail.com:
Toggle quote (2 lines)
> It seems like the merge conflict I caused for hurd has been resolved incorrectly: hurd still has the "hurd-64bit.patch" that I removed when updating hurd for core-packages-team.

thanks for pointing out a mistake!

But I do not get it. Do you mean

commit 729b5a9bde18c06b1d62befc4f401a3aed11c84a
Author: Yelninei <yelninei@tutamail.com>
Date: Sun May 18 11:41:44 2025 +0100
gnu: libxcrypt: Remove now unnecessary Hurd64 patch.
* gnu/packages/crypto.scm (libxcrypt)[arguments]: Remove
‘apply-hurd64-patch’ phase.
* gnu/packages/patches/libxcrypt-hurd64.patch: Remove.
* gnu/local.mk (dist_patch_DATA): Remove it.
Change-Id: Id98b268426ef22219e2bfc5041e7d7965c5f9275
?

This is the only merge conflict that I remember related to hurd.
And
git show 729b5a9bde18c06b1d62befc4f401a3aed11c84a
and
git show c2f95bf22849ae0a6f3a37d4d4cca54b799afc0f
(which I think is the head of the previous state of core-packages-team)
look just the same.

What did I overlook?

Andreas

PS:
Toggle quote (1 lines)
> clisp is blocking linux-libre
Ah, that is super surprising!
yelninei wrote 9 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
OS-wdAS--F-9@tutamail.com
Hello,

Jun 5, 2025, 15:56 by andreas@enge.fr:

Toggle quote (32 lines)
> Hello Yelninei,
>
> Am Thu, Jun 05, 2025 at 04:14:17PM +0200 schrieb yelninei@tutamail.com:
>
>> It seems like the merge conflict I caused for hurd has been resolved incorrectly: hurd still has the "hurd-64bit.patch" that I removed when updating hurd for core-packages-team.
>>
>
> thanks for pointing out a mistake!
>
> But I do not get it. Do you mean
>
> commit 729b5a9bde18c06b1d62befc4f401a3aed11c84a
> Author: Yelninei <yelninei@tutamail.com>
> Date: Sun May 18 11:41:44 2025 +0100
> gnu: libxcrypt: Remove now unnecessary Hurd64 patch.
> * gnu/packages/crypto.scm (libxcrypt)[arguments]: Remove
> ‘apply-hurd64-patch’ phase.
> * gnu/packages/patches/libxcrypt-hurd64.patch: Remove.
> * gnu/local.mk (dist_patch_DATA): Remove it.
> Change-Id: Id98b268426ef22219e2bfc5041e7d7965c5f9275
> ?
>
> This is the only merge conflict that I remember related to hurd.
> And
> git show 729b5a9bde18c06b1d62befc4f401a3aed11c84a
> and
> git show c2f95bf22849ae0a6f3a37d4d4cca54b799afc0f
> (which I think is the head of the previous state of core-packages-team)
> look just the same.
>
> What did I overlook?
>
This removed hurd-64bit.patch (it is not needed after updating) however after the rebase hurd still references the deleted hurd-64bit.patch.

Commit 9f2ea76b8aecb47c43bd43934b9706ceaf3e308a
Author: Yelninei <yelninei@tutamail.com>
Date:   Sun May 4 11:25:02 2025 +0000

    gnu: hurd: Update to 0.9.git20250420.
    
    * gnu/packages/commencement.scm (hurd-headers-boot0): Update to
    0.9.git20250420.
    * gnu/packages/hurd.scm (hurd-headers): Same.
    (hurd): Remove hurd-64bit.patch.
    [native-inputs]: Use texinfo instead of texinfo@4.
    * gnu/packages/patches/hurd-64bit.patch: Remove patch.
    gnu/local.mk: Deregister patch.

The conflict comes from this commit from master which added another patch. This is still needed on core-packages-team.

commit e98153b96c9a90d91db5421fe431b384602d1c9d
Author: Yelninei <yelninei@tutamail.com>
Date:   Thu May 15 07:51:43 2025 +0000

    gnu: hurd: Fix service socket activation.
    
    
    * gnu/packages/patches/hurd-socket-activation.patch: New patch
    * gnu/packages/hurd.scm (hurd): Add it.
    * gnu/local.mk: Register it.



Toggle quote (9 lines)
> Andreas
>
> PS:
>
>> clisp is blocking linux-libre
>>
> Ah, that is super surprising!
>

This comes from linux-libre-source -> patch -> gnulib -> clispGnulib depends on clisp for some tests i think.
Note that patch #+ includes gnulib so you dont see it with the usual tools.
Andreas Enge wrote 9 months ago
(address . yelninei@tutamail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aEHMPLPuRQum4uPU@jurong
Am Thu, Jun 05, 2025 at 06:35:28PM +0200 schrieb yelninei@tutamail.com:
Toggle quote (2 lines)
> This removed hurd-64bit.patch (it is not needed after updating) however after the rebase hurd still references the deleted hurd-64bit.patch.

Oh, I get it now, thanks a lot! I do not understand how this could have
slipped through, I remember touching the lines referencing the patch.

This should be corrected now.

Andreas
yelninei wrote 9 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
OS0cp6j--F-9@tutamail.com
Hello,
Jun 5, 2025, 16:56 by andreas@enge.fr:

Toggle quote (11 lines)
> Am Thu, Jun 05, 2025 at 06:35:28PM +0200 schrieb yelninei@tutamail.com:
>
>> This removed hurd-64bit.patch (it is not needed after updating) however after the rebase hurd still references the deleted hurd-64bit.patch.
>>
>
> Oh, I get it now, thanks a lot! I do not understand how this could have
> slipped through, I remember touching the lines referencing the patch.
>
> This should be corrected now.
>

Thank you, I think the change is now on the wrong commit. 

You added it to 915de4be51 * gnu: libxcrypt: Remove now unnecessary Hurd64 patch. 
but it should be 9f2ea76b8a * gnu: hurd: Update to 0.9.git20250420.


Toggle quote (2 lines)
> Andreas
>
Yelninei
Andreas Enge wrote 9 months ago
(address . yelninei@tutamail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aENLOsfEhaBypd7k@jurong
I have rebased on master commit d2d961b76a5be75cb715dd9445afd65f44da616f
in the hope that it would fix the clisp build, but it does not;
the problem is apparently also there on master:

I get five errors here as there.

Andreas
Andreas Enge wrote 9 months ago
(address . yelninei@tutamail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aEWPeaKjwi8_iV-H@jurong
Hello,

thanks a lot for the fixes in #474, which I have applied to this branch.

I have also rebased on commit 199fd26ab268d4f26cebcb39e844fe4ff9bea9bc
and pushed.

Andreas
Christopher Baines wrote 9 months ago
(no subject)
(address . control@debbugs.gnu.org)
87a56ieye8.fsf@cbaines.net
block 75518 by 77340
thanks
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmhF+19fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XdwchAApUZ7c+FZpXhk88Wj2/v1uKD1b8/toiqU
KcmccMDp5uWiqc+XBWw/wo8vzaYGMknIhLnMkIdWiy7Afgf8YzGLDAkPApNucqDx
LAY38vnhLs7S5y927SbrHKV2ddOtN/pr2rCc9OsWwysCcetPollWiDcEt5p/spsU
rtu6qlZgtc8+caPzsN5QP7ssCdlWvnej16HCWpRKIMK8aDg9QBwUSjFnd2VKCUjT
7NJBoaW/SW1qiVyKjvjifVz+9+mGNWHV+cO1NZRKjfLN2f6kfr8gVZ9XjaH46OOD
DwqQW+cqBtvdAJ3J3oM1j4ZJhw1FxdwcRhrCxiRONnUFgB3XenyTrxKxsufxu4DA
Z5bp7HvNFPeZHzXY4WV4fZcbaG8ggd4fd8QPIDLH/rWTFoODwWZApR+mQpXrfaCA
EmSOzo7ca+RqBfv9BddeALTBUh0nmAdjeAZ6lhT+TWIFiX12jwUOMFXDqX4dnHR+
TfN6dGluLQ+3uwcq1K3DG/nJFLfTfIeCy65smCvNKo9k1VAj9qhCetr8fjaEjSz8
vtfZ5+DNxzVBJz0YWNytLxyd5Vk268cXR68fm4zLLpX8LG3ibKSXCKsx6AryAsyT
FlO29dO6c+wqxWyMOwSzZZTQDHZuMXmM9ED0E24FkXkprBd41fQEyrJ3AFPYRS38
TNiH8/FNqPg=
=dOT2
-----END PGP SIGNATURE-----

Ludovic Courtès wrote 9 months ago
Re: Motif build failure
(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Andreas Enge)(address . andreas@enge.fr)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87msaeezpn.fsf@gnu.org
An update: I have just pushed these commits to ‘core-packages-team’:

0a9e9e158b gnu: motif: Build with GCC 11.
93d5c354c4 gnu: gcc: Fix compilation of libstdc++ for GCC 7 to 13.

They fix all these GCC versions (except GCC 13, which has other build
problems) and the infamous Motif problem, using GCC 11 as Rutherther
suggested before.

We’re making progress!

Ludo’.
Andreas Enge wrote 9 months ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aEqaK-KznXm9mUGB@jurong
Am Wed, Jun 11, 2025 at 11:27:16PM +0200 schrieb Ludovic Courtès:
Toggle quote (2 lines)
> We’re making progress!

Thanks for that!

I have rebased on commit 601ed9166ea264f7ee49d55f3a7f2a24a9cb8746 ,
which is known to the data service and follows the mesa-updates merge.

Andreas
Andreas Enge wrote 9 months ago
Block
(address . control@debbugs.gnu.org)
aEqdSr9NbHgeZP7R@jurong
block 76899 by 78527
unblock 75518 by 76899
thanks

# As a result, core-packages-team should be unblocked,
# and c++-team should be blocked by emacs-team.
Ludovic Courtès wrote 9 months ago
Re: Motif build failure
(name . Andreas Enge)(address . andreas@enge.fr)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
878qlxdp0o.fsf@gnu.org
Hi,

Andreas Enge <andreas@enge.fr> writes:

Toggle quote (3 lines)
> I have rebased on commit 601ed9166ea264f7ee49d55f3a7f2a24a9cb8746 ,
> which is known to the data service and follows the mesa-updates merge.

building the full package set, for x86_64-linux-only for now.

We’ll have to squash or do something with the commits that read
“Partially revert …” at the beginning of this branch.

Thanks!

Ludo’.
Janneke Nieuwenhuizen wrote 9 months ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Andreas Enge)(address . andreas@enge.fr)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Rutherther)(address . rutherther@ditigal.xyz)
875xh0m9sn.fsf@gnu.org
Ludovic Courtès writes:

Hello,

Toggle quote (8 lines)
> Andreas Enge <andreas@enge.fr> writes:
>
>> I have rebased on commit 601ed9166ea264f7ee49d55f3a7f2a24a9cb8746 ,
>> which is known to the data service and follows the mesa-updates merge.
>
> Nice; <https://ci.guix.gnu.org/jobset/core-packages-team> is now
> building the full package set, for x86_64-linux-only for now.

Yay!

Toggle quote (3 lines)
> We’ll have to squash or do something with the commits that read
> “Partially revert …” at the beginning of this branch.

I don't think so; these are re-applies of [bits of] cleanups that were
applied and [partially] reverted much earlier, because these bits led
to world rebuilds (for non-x86 archictectures iirc).

Greetings,
Janneke

--
Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com
Andreas Enge wrote 9 months ago
(Un-)block
(address . control@debbugs.gnu.org)
aEvrH2Fdg1eXX20E@jurong
unblock 76899 by 77340
unblock 75518 by 77340
unblock 76899 by 78527
block 76899 by 78257
thanks

# Thanks to Chris Baines for spotting the mistake.
Andreas Enge wrote 9 months ago
Re: Request for merging "core-packages-team" branch
(address . yelninei@tutamail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aEwvcnRhuOARaesL@jurong
Some failure on CI looks rather worrying:
starting phase `configure'
grep: warning: stray \ before -
grep: warning: stray \ before -
Created "Makefile" in /tmp/guix-build-gcc-2.95.3.drv-0/gcc-2.95.3 using "mt-frag"
Cannot find the GNU C library minor version number.
error: in phase 'configure': uncaught exception:
%exception #<&invoke-error program: "./configure" arguments: ("--prefix=/gnu/store/sdpfmwzgdjgm4abgdqb9y233v9dmqikn-gcc-2.95.3" "--build=i686-unknown-linux-gnu" "--host=i686-unknown-linux-gnu" "--disable-werror") exit-status: 1 term-signal: #f stop-signal: #f>
phase `configure' failed after 1.0 seconds
command "./configure" "--prefix=/gnu/store/sdpfmwzgdjgm4abgdqb9y233v9dmqikn-gcc-2.95.3" "--build=i686-unknown-linux-gnu" "--host=i686-unknown-linux-gnu" "--disable-werror" failed with status 1
build process 18 exited with status 256
builder for `/gnu/store/siw9s516qxab9vqbmhmc6d5j3w0pn4wy-gcc-2.95.3.drv' failed with exit code 1

Does it mean that bootstrapping GCC fails on i686?

Andreas
Z572 wrote 9 months ago
Re: Motif build failure
(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(name . Andreas Enge)(address . andreas@enge.fr)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87ecvnacfx.fsf@iscas.ac.cn
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (9 lines)
> An update: I have just pushed these commits to ‘core-packages-team’:
>
> 0a9e9e158b gnu: motif: Build with GCC 11.
> 93d5c354c4 gnu: gcc: Fix compilation of libstdc++ for GCC 7 to 13.
>
> They fix all these GCC versions (except GCC 13, which has other build
> problems) and the infamous Motif problem, using GCC 11 as Rutherther
> suggested before.


The problems of gcc 13 seem to be the same as those of gcc 14. So I also
applied the patch-tzdb.cc phase to gcc 13. I build clang-runtime-18
and it seems there is no problem.

Toggle quote (4 lines)
>
> We’re making progress!
>
> Ludo’.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEfr6klGDOXiwIdX/bO1qpk+Gi3/AFAmhMQ4IACgkQO1qpk+Gi
3/C4sxAAmiikAN3SoIN3LU7vaPtPQS7ayslmIRNiJ8iJ6Lcv+Yc7MlqCtJViCkvl
hoQ+hoTwDGVISiaGHa60/2ArmAExUuzN4OaHOlvVFQhTUmurkLpkwewYQNDAvxmN
hWYa8PDvcSKkqJG524b0KORJthVykuydjJATXiSM0FqMCmVb9QedGkukuKZBEbv5
M/MPLyIHY3fEZ4xK78sDNJb1ogLvY5Ymg0U9mLKAvvnLHmOTpk9j0So0MyYwxb+R
kUvJwfw84O8Phit5e/iLjuT/e8efpAscV+OV7xMFm+J93ykvHinOQZqybVPuVO4E
Go7zDEs847rUcJ9nEn+4TqMOULeBNMBM8PSPeFFwEOUzi811bkv/95KQP2EDoOn0
r4g3Ctv/fWx3vZpCawf7BM3EXO+wlCbWcFJm1PNreqM0ptWoZrJRE2eoyHGf53Wz
2thjPZqd0MEzffQU4QL9w9spLxH2yvCF9EHfMqSwlfpDLFdCRYe44iu/RO9v5q8k
icKVYymvl5sQcSjB/kwG2wrCUH4AyjQg4rORNaf6dWMogpm0lB/RUHcBliYZiyCo
oW2FZkrNLevLeG/FL8KplLR35fQkRCJ6FipfMmsIbAHYAhBkp/XpqJqZDOqahVYI
Y9YGjvV8PT2+SIDRH8Y1FdbU/FgEglbwvM63GL+i0itfoehWRdA=
=0BnU
-----END PGP SIGNATURE-----

Ludovic Courtès wrote 9 months ago
(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(address . iyzsong@envs.net)(name . Andreas Enge)(address . andreas@enge.fr)(name . Z572)(address . z572@z572.online)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Rutherther)(address . rutherther@ditigal.xyz)
87zfeb8xnf.fsf@gnu.org
Hi,

Janneke Nieuwenhuizen <janneke@gnu.org> writes:

Toggle quote (7 lines)
>> We’ll have to squash or do something with the commits that read
>> “Partially revert …” at the beginning of this branch.
>
> I don't think so; these are re-applies of [bits of] cleanups that were
> applied and [partially] reverted much earlier, because these bits led
> to world rebuilds (for non-x86 archictectures iirc).

Oh OK, then we’re good (I thought they were leftovers from the initial
work on the branch).

Thanks!

Ludo’.
Andreas Enge wrote 9 months ago
Re: Request for merging "core-packages-team" branch
(address . yelninei@tutamail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aExbISGyyF0ctNer@jurong
Am Thu, Jun 05, 2025 at 04:14:17PM +0200 schrieb yelninei@tutamail.com:
Toggle quote (3 lines)
> Here is where where the packages I reported come from:
> clisp is blocking linux-libre

This suddenly has a substitute, it looks like some non-deterministic
test failure. Maybe if we notice it again, we can disable these tests.

Toggle quote (2 lines)
> dtc and openbios are blocking grub

I have updated dtc in master from 1.7.0 to 1.7.2; all dependencies at
distance 1 still build pn x86_64, except for one that also currently
does not build.

If I remember well, it still does not build on core-packages-team,
but at least this is a little bit of progress, since there is not much
point in repairing outdated packages.

Toggle quote (2 lines)
> python-pyelftools is blocking genimage

This one is still open. It can be updated as well, but this is probably
not all.

Andreas
Andreas Enge wrote 9 months ago
(address . yelninei@tutamail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aExePI8mZicnsp3F@jurong
Am Fri, Jun 13, 2025 at 07:08:49PM +0200 schrieb Andreas Enge:
Toggle quote (4 lines)
> > python-pyelftools is blocking genimage
> This one is still open. It can be updated as well, but this is probably
> not all.

Well, python-pyelftools@0.32 (and @0.31) already fails its tests on
master. This is all very brittle...

Toggle quote (3 lines)
> I have updated dtc in master from 1.7.0 to 1.7.2
> If I remember well, it still does not build on core-packages-team

Tested and confirmed.

Andreas
Andreas Enge wrote 9 months ago
Block
(address . control@debbugs.gnu.org)
aE18dpTvsnhrEVMT@jurong
block 75518 by 78257
thanks

# block core-packages-team by emacs-team
Andreas Enge wrote 9 months ago
Unblock
(address . control@debbugs.gnu.org)
aE1-MSPdv-Gw88uh@jurong
unblock 75518 by 76311,76654,76640,75676,75658
thanks

# unblock by closed bugs; this makes no practical difference,
# but clarifies the situation
Andreas Enge wrote 9 months ago
Block core-packages-team by ruby-team
(address . control@debbugs.gnu.org)
aE_d8F7fmI01_1bd@jurong
block 75518 by 78676
thanks
Andreas Enge wrote 9 months ago
Re: Request for merging "core-packages-team" branch
(address . yelninei@tutamail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aE_efH5tTvnvsMBZ@jurong
Rebased on ced31f8dd156e4202a2c7115fc003608a541388c .

Andreas
Andreas Enge wrote 9 months ago
(address . yelninei@tutamail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aFMeCgQ0CGXCSGpo@jurong
Hello all,

right now I have let the ruby-team branch go before core-packages-team,
as it was clear we were not ready yet. At the same time, we cannot
postpone the branch forever! So I would suggest that we refrain from
major changes to get the branch in a mergeable state, and limit
ourselves to merging in master, repairing broken things and maybe making
updates close to the leaves. This will also avoid that QA builds this
branch over and over again.

Last time I checked and the branch was almost built, I could update my
home profile; but yelninei has found a number of blockers to system
reconfiguration. If anyone of you could make progress there, this would
be perfect.

Andreas
Andreas Enge wrote 9 months ago
Re: [bug#75518] Request for merging "core-packages-team" branch
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Iyzsong)(address . iyzsong@envs.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(address . yelninei@tutamail.com)(name . 75518)(address . 75518@debbugs.gnu.org)
aFVYQiUkiZWzcMI2@jurong
Hello,

Am Fri, Jun 20, 2025 at 05:38:25PM +0800 schrieb Z572:
Toggle quote (3 lines)
> for now, these packages are blocking the bulid.
> (...)

thanks for the analysis!

Toggle quote (6 lines)
> Now a lot of packages are stuck at qtlocation@5, but I think it doesn 't
> make sense to just fix it. It needs to be upgraded later, The new
> version of qt5 seems to fix some compilation issues for new version gcc,
> so I think it' s possible to upgrade qt5 on core-packages-team. What do
> you think?

Definitely everything that does not build now can be repaired/updated,
since we lose no work. You could have a look at the (dormant and waiting
for core-packages-team) qt-team branch if the problem is already solved
there. If possible, it would be nice to be "conservative" and to change
as little as possible so as to avoid adding breakage somewhere.

Andreas
Ludovic Courtès wrote 9 months ago
Re: Request for merging "core-packages-team" branch
(name . Andreas Enge)(address . andreas@enge.fr)(name . Greg Hogan)(address . code@greghogan.com)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
877c16vacr.fsf@gnu.org
Hello,

Andreas Enge <andreas@enge.fr> writes:

Toggle quote (4 lines)
> right now I have let the ruby-team branch go before core-packages-team,
> as it was clear we were not ready yet. At the same time, we cannot
> postpone the branch forever!

Agreed!

In an attempt to clarify the situation, I created a “milestone”:


Z572 already filed individual issues for “important” packages that fail
to build (thank you!).

Here’s an overview of where we’re at on x86_64-linux:

Toggle snippet (38 lines)
$ ./pre-inst-env guix weather -c500 --substitute-urls=https://ci.guix.gnu.org
computing 34,968 package derivations for x86_64-linux...
looking for 40,473 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org ☀
81.9% substitutes available (33,155 out of 40,473)
at least 119,977.2 MiB of nars (compressed)
208,935.7 MiB on disk (uncompressed)
0.002 seconds per request (88.9 seconds in total)
451.6 requests per second

0.1% (4 out of 7,318) of the missing items are queued
at least 1,000 queued builds
riscv64-linux: 993 (99.3%)
x86_64-linux: 4 (.4%)
powerpc64le-linux: 1 (.1%)
aarch64-linux: 2 (.2%)
build rate: 45.68 builds per hour
i686-linux: 6.76 builds per hour
x86_64-linux: 29.04 builds per hour
powerpc64le-linux: 4.16 builds per hour
aarch64-linux: 3.33 builds per hour
riscv64-linux: 3.55 builds per hour
i586-gnu: 0.14 builds per hour
1047 packages are missing from 'https://ci.guix.gnu.org' for 'x86_64-linux', among which:
1463 r-bslib@0.9.0 /gnu/store/hzagd9m598v98pkjiv36fvsxsa0sgwnf-r-bslib-0.9.0
1321 r-lubridate@1.9.4 /gnu/store/m2308vskr9dikvp1ifj68rj8zyhfqc59-r-lubridate-1.9.4
1170 r-curl@6.2.3 /gnu/store/gsi15zmxlynpp3l251lgm1c50fw4ypjl-r-curl-6.2.3
1100 r-textshaping@1.0.1 /gnu/store/rcqcx8pi7vjb50j3635phhph95jd0bly-r-textshaping-1.0.1
925 r-promises@1.3.3 /gnu/store/ihx2dpram1dl3ggq9xyzyxk8g7bf4r7c-r-promises-1.3.3
748 icedtea@2.6.13 /gnu/store/ly0hdxlan3wqii5jpj3awh6jmysanjf1-icedtea-2.6.13-doc /gnu/store/4dp9kf58jxf9cxb1bkvn5ns3910scyxf-icedtea-2.6.13-jdk /gnu/store/ra9vg3gaxjzdbgdsdskkdwm8dcybja4d-icedtea-2.6.13
651 qtbase@6.7.2 /gnu/store/0979n4c17yj90fr11bv2wr2y4lzsmz9z-qtbase-6.7.2-debug /gnu/store/l9wg5pmnlqlp67rzbzi50m74s4sqkgjv-qtbase-6.7.2
641 r-iranges@2.42.0 /gnu/store/5bgr2llaxpkdjysrv60pfl19wdvwlldg-r-iranges-2.42.0
631 python-pandas@2.2.3 /gnu/store/nybha0bgxpjdvkd4h3ybcwizc5d5ylmz-python-pandas-2.2.3
556 qtlocation@5.15.15 /gnu/store/ky855m25nf7gdfzwd3ai8xr4wi7q0iv4-qtlocation-5.15.15-debug /gnu/store/a1jdz47x2lppjp0a3mbz3pfpzdzr6jfk-qtlocation-5.15.15
$ git log |head -1
commit bc724b046e089c7b8fd237f6eaae038ccaafaf08

Let’s keep track of everything at Codeberg.

We might still discover problems on other architectures afterwards.

Ludo’.
Andreas Enge wrote 9 months ago
Re: [bug#75518] Request for merging "core-packages-team" branch
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Iyzsong)(address . iyzsong@envs.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(address . yelninei@tutamail.com)(name . 75518)(address . 75518@debbugs.gnu.org)
aFXPSD1fmsPJk-AN@jurong
Rebased on 5d6604a88e1dae62f56a196d5a8140d272f8e78c .

Andreas
Andreas Enge wrote 8 months ago
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Iyzsong)(address . iyzsong@envs.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(address . yelninei@tutamail.com)(name . 75518)(address . 75518@debbugs.gnu.org)
aGbZ2QF1PEoeORzl@jurong
Hello all,

I have rebased once again. Unfortunately QA is out of service right now;
so I have opted for commit f66eaab175c9df3f17824f24d82f9556a68f6690 ,
which has been handled by data.guix.gnu.org.

Andreas
Andreas Enge wrote 8 months ago
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Iyzsong)(address . iyzsong@envs.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(address . yelninei@tutamail.com)(name . 75518)(address . 75518@debbugs.gnu.org)
aGbh7duFXQI1Pg25@jurong
And I have added the Qt patches of

QA is broken, CI is 504, let us check with the first of them that comes
back...

Andreas
Ludovic Courtès wrote 8 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . Iyzsong)(address . iyzsong@envs.net)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)(address . yelninei@tutamail.com)(name . 75518)(address . 75518@debbugs.gnu.org)
87ms9lrqcm.fsf@gnu.org
Hello,

Andreas Enge <andreas@enge.fr> writes:

Toggle quote (4 lines)
> I have rebased once again. Unfortunately QA is out of service right now;
> so I have opted for commit f66eaab175c9df3f17824f24d82f9556a68f6690 ,
> which has been handled by data.guix.gnu.org.

Nice, thanks! It’s also visible at

Ludo’.
Andreas Enge wrote 8 months ago
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Iyzsong)(address . iyzsong@envs.net)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aHArRJmQ7QNoHK09@jurong
Am Thu, Jul 10, 2025 at 10:49:54PM +0800 schrieb Z572:
Toggle quote (2 lines)
> It seems that there is a problem with the database on ci. Some drvs no longer exist, and all the current eval has failed.

I have seen this, but have no idea what to do about it. Our tooling
situation is despairingly dire: Only Chris is able to look after QA, and
only Ludovic (and one or two more persons?) is able to look after CI.
QA had not evaluated a single commit in almost the last two weeks, whereas
the main page of ci.guix.gnu.org was almost permanently not reachable over
the last days with a 504 error; other pages did appear with a bit of
patience. We urgently need to reach a situation with working tools, and
with bus factors larger than 1, but I do not know how to do so.

I see that data.qa and bayfront have been reconfigured today, supposedly by
Chris. The guix-data-service and guix-data-service-process-jobs services
were marked in bold, so I have restarted them. I think QA started to work
again before that: There are evaluations visible at
https://data.qa.guix.gnu.org/, on master and core-updates.

I have rebased core-packages-team on one of the processed master commits
from today, added the akonadi and kwin fixes by Z572, and pushed.
Hopefully data.qa will pick up this commit and start processing the branch
again. But I suppose it will take a few days until the build farm has
finished the branch, so it would clearly be desirable to also repair CI.

Andreas
Christopher Baines wrote 8 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . 75518)(address . 75518@debbugs.gnu.org)
87tt3j5bv8.fsf@cbaines.net
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (24 lines)
> Am Thu, Jul 10, 2025 at 10:49:54PM +0800 schrieb Z572:
>> It seems that there is a problem with the database on ci. Some drvs no longer exist, and all the current eval has failed.
>
> I have seen this, but have no idea what to do about it. Our tooling
> situation is despairingly dire: Only Chris is able to look after QA, and
> only Ludovic (and one or two more persons?) is able to look after CI.
> QA had not evaluated a single commit in almost the last two weeks, whereas
> the main page of ci.guix.gnu.org was almost permanently not reachable over
> the last days with a 504 error; other pages did appear with a bit of
> patience. We urgently need to reach a situation with working tools, and
> with bus factors larger than 1, but I do not know how to do so.
>
> I see that data.qa and bayfront have been reconfigured today, supposedly by
> Chris. The guix-data-service and guix-data-service-process-jobs services
> were marked in bold, so I have restarted them. I think QA started to work
> again before that: There are evaluations visible at
> https://data.qa.guix.gnu.org/ , on master and core-updates.
>
> I have rebased core-packages-team on one of the processed master commits
> from today, added the akonadi and kwin fixes by Z572, and pushed.
> Hopefully data.qa will pick up this commit and start processing the branch
> again. But I suppose it will take a few days until the build farm has
> finished the branch, so it would clearly be desirable to also repair CI.

With QA, things look like they might be starting to work again today,
but it's not been a fun several weeks.

There's been correctness issues with the derivations in the database for
both data.guix.gnu.org and data.qa.guix.gnu.org, and finding, fixing and
trying to figure out how those might have happened took a bunch of time.

There's also been a couple of issues where the symptom was excessive
time doing garbage collection. One in the data service web server, which
turned out to be due to empty revisions I think (as a result of another
bug), and another affecting processing jobs which turned out to be an
issue in Guile Knots (fixed in [1]).

-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmhw1atfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XfZ0RAAotEQUqeGb74J1SJhndK02b58VC69OIoJ
DKNv80w7u9qKoequeK4PSEbxThh9CCkdUPBHolsZgU/gPiipPYQTUl5n/yn39xrw
s6C08lY4xmrOvTQLnapKH0DSDDiie1xXFPZtCMB2oLeub+IkxVEp1+TShMfuOTqw
MwZBGE64l9jAVw6XdD65VqljS9H9T3jwmIPd1q2pR7F+IonW6gzX1GhiWMxzxyrX
VHVzR9yb/hqg2BwzoQ/2BeMAQNrb5P4jkZ7hAsd8kYKO9Oq+C3iQUb5T+6w9Y9Vw
hq3FaUc+hwI2/yU6eUffx/q2k/KVytYOnctX0bPKmjLTVbQVM6elToonFyJrYsJO
OvnLzlkFl85mVSjt23da/eESAjvBbgRGDvAD5kHbLGHYvWoVPYGfM1G9PnO+TR8S
7Bl19yWH5UnDH+9FbCBbMR5zUwRtra9upQJ0HJcE0Udv2N//7PhSzy2jRF0EMivY
KO0X/G0I4Cq+nFFx6F/om8HCTsQrgzLa2H9WNL/GzP+N9lqeUmEs5kJKOdqLIUz7
+xe0hBBs0yMEjWAA76ZJ88GlDO519LQxSShmtM4pgKlJ8/aynqVwyEzsGFbhUG97
+qGO0ksi7RuhYN/KZ8KR1RUyC8LcSwPU+5ZVf99ZISrKFY2003VOazJlMuSl4rPH
cvKYtctGfGs=
=3P7W
-----END PGP SIGNATURE-----

Andreas Enge wrote 8 months ago
(name . Christopher Baines)(address . mail@cbaines.net)(name . 75518)(address . 75518@debbugs.gnu.org)
aHDjRWmt-xd2sJzu@jurong
Hello Chris,

thanks for your feedback!

Am Fri, Jul 11, 2025 at 10:13:15AM +0100 schrieb Christopher Baines:
Toggle quote (4 lines)
> There's been correctness issues with the derivations in the database for
> both data.guix.gnu.org and data.qa.guix.gnu.org, and finding, fixing and
> trying to figure out how those might have happened took a bunch of time.

is there a "post mortem" to be shared, things we need to consider, could
do, or whatever, in the future to prevent or repair such issues?

Andreas
Christopher Baines wrote 8 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . 75518)(address . 75518@debbugs.gnu.org)
87o6tp5zyx.fsf@cbaines.net
Andreas Enge <andreas@enge.fr> writes:

Toggle quote (10 lines)
> thanks for your feedback!
>
> Am Fri, Jul 11, 2025 at 10:13:15AM +0100 schrieb Christopher Baines:
>> There's been correctness issues with the derivations in the database for
>> both data.guix.gnu.org and data.qa.guix.gnu.org, and finding, fixing and
>> trying to figure out how those might have happened took a bunch of time.
>
> is there a "post mortem" to be shared, things we need to consider, could
> do, or whatever, in the future to prevent or repair such issues?

Not really, I've put safeguards in place to avoid acidentally nesting
transactions [1] and there's code now to fix at least some of these
issues after they happen, but I'm still not confident that they won't
happen again.

-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmhyW6ZfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XfSAQ/8CXSZhoahvMqXeR15bYtur9KTDrlaFxKb
RJGCexmbhrbXgWoAqto8ucHkUh1UtTgXM6c0dGBMpodU8FzJdiUw35Whkk+mJJ0i
G7jCEzLvuizRMoBykw+EEuVm4LrocFZlIOzHhLgHhAaEfNzZy8Y9kWFO+7OSTGBC
rzqJ9QxxYmTvZ+r+krnG343R8GL19bpr+ZS8+KnmwiKxcyxMuAqyKmxMA5sAd8d9
YpwDAWePF2xpwo/7iveN7tDh4wXNZ/nsuydQhXUDhVj/MKTKvS660YJODnJjcBmE
DyX4bjMudebliw44LwMbuovICRuanS0z3N3/WXrlwYibtLAnoAZIMmyEQPBQZAoq
L7IMwohMEPZDfQyaJ3XBcKGo8wK/Q7kjUCIO6Z/yxI9MJUKCK1D/j/p/3YvNqujq
c8BNd20hctDDP9PG/282q2kaS2ZjDQnpIIvma+yT7r0KCXNsCs9VUZ/4UcW0z1Is
t+TS7awrYiS0m0xvss+Z0du8DU+8lejjy0BIaAP1exQeEZ6uFbC4yxhlsL98m9Bj
GDvTjJ8dzaK3f2GZazaMMHRmKuicHGItWvFw6GtWZCF5fOOjzFZi1UZUAoiVyYQK
D3+ie76iXSPBaex+/cutxZUQfJZ98VY/VZcq3pswpzEzgCLsbrhdGiUVnOq+2IF1
/enQRWe79Mw=
=rbxa
-----END PGP SIGNATURE-----

Andreas Enge wrote 8 months ago
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Iyzsong)(address . iyzsong@envs.net)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aHOeeO_9hKT0CFYv@jurong
Since we just pushed a lot of updates, I have profited from this and
rebased on commit b1438011b38199b674c6f3aea7ffd37a2886749e .

Andreas
Andreas Enge wrote 8 months ago
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Iyzsong)(address . iyzsong@envs.net)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aHPrXPCoKd04js6h@jurong
Am Sun, Jul 13, 2025 at 07:10:14PM +0200 schrieb Andreas Enge:
Toggle quote (3 lines)
> uncaught throw to %exception: (#<&store-protocol-error message: "reading file `/gnu/store/j4xb684n5v4mszqpwfvz4n5gr8sac4pq-scron-0.4.tar.gz.drv': No such file or directory" status: 1>)
> Registering builds for evaluation 2071001.

Ah, but do we not have the data service for this? :-)

shows a successful build, so I suppose the file must be in the store of
the data service.

However, it is not on data.qa, and I do not know how to access data
(without qa).

The result of the derivation is
the same as for the (different) derivation I see on my machine,
and "./pre-inst-env guix build scron" on berlin downloads the scron
source into the store. Maybe this is enough?

I have tried to restart the evaluation through the web interface.

But this has no effect - the page immediately comes back with the failed
evaluation from two hours ago and an unchanged log file.

Help needed!

Andreas
Andreas Enge wrote 8 months ago
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Iyzsong)(address . iyzsong@envs.net)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aHVxk49pbSPVDfTR@jurong
I have added the last fixes from codeberg, rebased on commit
c1604c4c9578665e059b84fbec6257b6d168c6a2 and pushed again.

Andreas
Andreas Enge wrote 8 months ago
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Iyzsong)(address . iyzsong@envs.net)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aHi41_0_xXSqfalO@jurong
Hello all,

I have locally merged #1283 by Jelle and rebased on the latest master.

Looking at the milestone
and QA my impression is that we are ready to merge; we would lose
ungoogled-chromium (which anyway is very outdated and nobody dares to
touch it) and r-sparsearray and dependents (which I suppose some R
people will correct at some point in time, but it can be done on master).

Whatever else is missing is probably sufficiently close to the leaves
that it can be repaired directly on master.

What do you think? I would be happy to merge tonight :)

Andreas
Ludovic Courtès wrote 8 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . 75518)(address . 75518@debbugs.gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . Iyzsong)(address . iyzsong@envs.net)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
87bjpietdr.fsf@gnu.org
Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

Toggle quote (7 lines)
> Looking at the milestone
> https://codeberg.org/guix/guix/milestone/21092
> and QA my impression is that we are ready to merge; we would lose
> ungoogled-chromium (which anyway is very outdated and nobody dares to
> touch it) and r-sparsearray and dependents (which I suppose some R
> people will correct at some point in time, but it can be done on master).

I haven’t been able to do some real testing as I was hoping to, but I
trust your judgment.

Thanks for tirelessly working on this branch!

Ludo’.
Greg Hogan wrote 8 months ago
(name . Andreas Enge)(address . andreas@enge.fr)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
CA+3U0ZnxJOqeFAxzacovBPB3X5FZqv2Yj=sz-XUEJ3=k0S6zuQ@mail.gmail.com
On Thu, Jul 17, 2025 at 4:48 AM Andreas Enge <andreas@enge.fr> wrote:
Toggle quote (19 lines)
>
> Hello all,
>
> I have locally merged #1283 by Jelle and rebased on the latest master.
>
> Looking at the milestone
> https://codeberg.org/guix/guix/milestone/21092
> and QA my impression is that we are ready to merge; we would lose
> ungoogled-chromium (which anyway is very outdated and nobody dares to
> touch it) and r-sparsearray and dependents (which I suppose some R
> people will correct at some point in time, but it can be done on master).
>
> Whatever else is missing is probably sufficiently close to the leaves
> that it can be repaired directly on master.
>
> What do you think? I would be happy to merge tonight :)
>
> Andreas

Thank you for shepherding this to completion, Andreas. I have
submitted a patch for two failing packages at
to master after the merge.
Andreas Enge wrote 8 months ago
(name . Greg Hogan)(address . code@greghogan.com)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Iyzsong)(address . iyzsong@envs.net)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Z572)(address . z572@z572.online)(name . 75518)(address . 75518@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aHle88icQ2o8LgVj@jurong
Rebased on master commit eb73b0336d18918e50bffea5ad4d38e3d5b89dfe,
applied commits that were ready (including these ones and a fix for
r-sparsearray), and pushed. Hopefully QA will pick it up over night.

Andreas
Andreas Enge wrote 8 months ago
(name . Z572)(address . z572@z572.online)(name . Ludovic Courtès)(address . ludo@gnu.org)(name . Christopher Baines)(address . mail@cbaines.net)(name . Z572)(address . zhengjunjie@iscas.ac.cn)(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)(name . Greg Hogan)(address . code@greghogan.com)(name . Rutherther)(address . rutherther@ditigal.xyz)(name . Iyzsong)(address . iyzsong@envs.net)(address . guix-devel@gnu.org)(address . 75518-done@debbugs.gnu.org)(address . yelninei@tutamail.com)(name . Janneke Nieuwenhuizen)(address . janneke@gnu.org)
aHqZu1RdemRm4KTy@jurong
Hello all,

I have just rebased and pushed the branch to master. This one had a
certain vibe of the former core-updates branches: The merge request was
opened 6 months ago.

Many thanks to all who have contributed, from starting the branch to
help running QA to providing fixes up to the last minute.
The branch is not perfect, in particular some packages do not build on i686;
for these, I have kept the issue

I am cc-ing guix-devel, since the next "guix pull" can result in a lot
of updates, and maybe still breakage; please open pull requests and
issues on Codeberg for this.

Time to celebrate!

Andreas
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 75518@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 75518
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help