GNU bug report logs -
#75518
Request for merging "core-packages-team" branch
Previous Next
To reply to this bug, email your comments to 75518 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 12 Jan 2025 15:33:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Janneke Nieuwenhuizen <janneke <at> gnu.org>:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org.
(Sun, 12 Jan 2025 15:33:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 12 Jan 2025 15:38:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Janneke Nieuwenhuizen writes:
Closing this bug with wrong subject (missing double quotes around branch name).
--
Janneke Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sat, 18 Jan 2025 16:33:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello!
Janneke Nieuwenhuizen <janneke <at> 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).
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’.
[Message part 2 (text/x-patch, inline)]
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 <at> gnu.org>
+# Copyright © 2012-2025 Ludovic Courtès <ludo <at> gnu.org>
# Copyright © 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2022, 2023, 2024 Andreas Enge <andreas <at> enge.fr>
# Copyright © 2016 Mathieu Lirzin <mthl <at> gnu.org>
# Copyright © 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021 Mark H Weaver <mhw <at> 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 <at> gnu.org>
+;;; Copyright © 2012-2025 Ludovic Courtès <ludo <at> gnu.org>
;;; Copyright © 2014, 2019 Andreas Enge <andreas <at> enge.fr>
;;; Copyright © 2012 Nikita Karetnikov <nikita <at> karetnikov.org>
;;; Copyright © 2014, 2015, 2016, 2018 Mark H Weaver <mhw <at> 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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sat, 18 Jan 2025 16:51:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès writes:
Hi!
> Janneke Nieuwenhuizen <janneke <at> 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!
> 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 <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 19 Jan 2025 23:40:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
Janneke Nieuwenhuizen <janneke <at> gnu.org> skribis:
> 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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 31 Jan 2025 09:19:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello, I just merged 'xorg-updates', now this is the next in the queue.
Added blocking bug(s) 75658
Request was from
Ludovic Courtès <ludo <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Thu, 06 Feb 2025 15:18:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 06 Feb 2025 16:07:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi Liliana,
Liliana Marie Prikler <liliana.prikler <at> 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.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 06 Feb 2025 16:38:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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:
https://issues.guix.gnu.org/75658
and feel like we could merge after cleaning up the last two commits.
Is there anything else I could check?
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 06 Feb 2025 17:56:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo’
Am Donnerstag, dem 06.02.2025 um 17:06 +0100 schrieb Ludovic Courtès:
> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler <at> 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
[1] https://qa.guix.gnu.org/branch/gnome-team
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 07 Feb 2025 17:25:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 07 Feb 2025 17:51:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Andreas Enge <andreas <at> 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
>
> Andreas
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sat, 08 Feb 2025 13:06:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
# block the core-packages-team merge by gnome-team
block 75518 by 75676
thanks
[signature.asc (application/pgp-signature, inline)]
Added blocking bug(s) 75676
Request was from
Christopher Baines <mail <at> cbaines.net>
to
control <at> debbugs.gnu.org.
(Sat, 08 Feb 2025 13:13:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 09 Feb 2025 11:14:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi,
Z572 <z572 <at> z572.online> skribis:
> Andreas Enge <andreas <at> 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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 09 Feb 2025 17:15:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Sun, Feb 09, 2025 at 12:12:54PM +0100 schrieb Ludovic Courtès:
> 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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 13 Feb 2025 14:03:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 16 Feb 2025 06:01:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 21 Feb 2025 09:41:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi,
Andreas Enge <andreas <at> enge.fr> skribis:
> 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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 23 Feb 2025 19:22:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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 <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 24 Feb 2025 10:47:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello!
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
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 24 Feb 2025 14:36:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Andreas Enge writes:
Hello, [didn't i set a subject before?]
> 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
https://logs.guix.gnu.org/guix/2025-01-05.log#140930
and it's what they intended, so.
> 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...
> 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 <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Tue, 25 Feb 2025 17:40:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Janneke Nieuwenhuizen <janneke <at> gnu.org> writes:
> 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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 26 Feb 2025 09:57:01 GMT)
Full text and
rfc822 format available.
Message #72 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi Liliana,
Liliana Marie Prikler <liliana.prikler <at> 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/
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 27 Feb 2025 16:14:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi!
Janneke Nieuwenhuizen <janneke <at> 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.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 28 Feb 2025 11:42:01 GMT)
Full text and
rfc822 format available.
Message #78 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès writes:
> Hi!
>
> Janneke Nieuwenhuizen <janneke <at> 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 <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 28 Feb 2025 20:04:04 GMT)
Full text and
rfc822 format available.
Message #81 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Mittwoch, dem 26.02.2025 um 10:53 +0100 schrieb Ludovic Courtès:
> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler <at> 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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 28 Feb 2025 22:47:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello Liliana,
Am Fri, Feb 28, 2025 at 09:04:44PM +0100 schrieb Liliana Marie Prikler:
> I do need a rebase
you may already be aware of it, but I am just understanding that
https://data.qa.guix.gnu.org/repository/1/branch/master
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 28 Feb 2025 22:52:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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/
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 28 Feb 2025 23:13:03 GMT)
Full text and
rfc822 format available.
Message #90 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Freitag, dem 28.02.2025 um 23:51 +0100 schrieb Andreas Enge:
> 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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 02 Mar 2025 21:07:01 GMT)
Full text and
rfc822 format available.
Message #93 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Mittwoch, dem 26.02.2025 um 10:53 +0100 schrieb Ludovic Courtès:
> 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!
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 03 Mar 2025 15:00:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Tue, 04 Mar 2025 08:55:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
https://issues.guix.gnu.org/75658
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Tue, 04 Mar 2025 14:24:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi,
Andreas Enge <andreas <at> enge.fr> skribis:
> 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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Tue, 04 Mar 2025 16:47:01 GMT)
Full text and
rfc822 format available.
Message #105 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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?
Should we close this issue 75518, or how do we let the following 9 (!)
branches get ahead of us?
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sat, 08 Mar 2025 15:27:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Andreas Enge <andreas <at> enge.fr> skribis:
> 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.
> 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’.
Reply sent
to
Andreas Enge <andreas <at> enge.fr>:
You have taken responsibility.
(Wed, 12 Mar 2025 11:36:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Janneke Nieuwenhuizen <janneke <at> gnu.org>:
bug acknowledged by developer.
(Wed, 12 Mar 2025 11:36:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 75518-done <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sat, 22 Mar 2025 22:05:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
An update: I came up with Gash patches that fix the problem we were
seeing in <https://issues.guix.gnu.org/75658>.
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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 26 Mar 2025 21:00:03 GMT)
Full text and
rfc822 format available.
Message #119 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 26 Mar 2025 22:37:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Andreas Enge writes:
Hello,
> I have added the newest release for mpfr on top of the branch.
> Again I could build up to mpc.
Thanks!
> 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 <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 29 Mar 2025 11:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sat, 29 Mar 2025 11:26:02 GMT)
Full text and
rfc822 format available.
Message #127 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi,
Janneke Nieuwenhuizen <janneke <at> gnu.org> skribis:
> 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
the list at <https://qa.guix.gnu.org>.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 31 Mar 2025 09:09:03 GMT)
Full text and
rfc822 format available.
Message #130 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Sat, Mar 29, 2025 at 12:25:27PM +0100 schrieb Ludovic Courtès:
> 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
Reply sent
to
Andreas Enge <andreas <at> enge.fr>:
You have taken responsibility.
(Tue, 01 Apr 2025 14:16:12 GMT)
Full text and
rfc822 format available.
Notification sent
to
Janneke Nieuwenhuizen <janneke <at> gnu.org>:
bug acknowledged by developer.
(Tue, 01 Apr 2025 14:16:15 GMT)
Full text and
rfc822 format available.
Message #135 received at 75518-done <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 09 Apr 2025 08:41:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Tue, 06 May 2025 09:19:01 GMT)
Full text and
rfc822 format available.
Message #141 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello!
You might have seen that the Gash fix has now landed, via an
“unofficial” Gash branch:
https://issues.guix.gnu.org/75658#15
CI started evaluating it but this will probably take ~24h if everything
goes well:
https://ci.guix.gnu.org/eval/2056773
At any rate, we should now be able to finally move forward.
Perhaps we can reopen this issue?
Thanks,
Ludo’.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 06 May 2025 14:50:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Tue, 06 May 2025 14:55:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
Am Tue, May 06, 2025 at 11:18:14AM +0200 schrieb Ludovic Courtès:
> 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!
> 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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 11 May 2025 09:50:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
block 75518 by 76311
thanks
Leo Famulari <leo <at> famulari.name> writes:
> 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.
> 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.
Note that bluez looks to fail to build
https://data.qa.guix.gnu.org/gnu/store/8j5qlh703367i6lwmnfggsh2s7s5cwf8-bluez-5.79.drv
[signature.asc (application/pgp-signature, inline)]
Added blocking bug(s) 76311
Request was from
Christopher Baines <mail <at> cbaines.net>
to
control <at> debbugs.gnu.org.
(Sun, 11 May 2025 10:37:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 14 May 2025 13:03:03 GMT)
Full text and
rfc822 format available.
Message #154 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 14 May 2025 13:27:02 GMT)
Full text and
rfc822 format available.
Message #157 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Andreas Enge <andreas <at> enge.fr> writes:
> 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.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 14 May 2025 20:22:01 GMT)
Full text and
rfc822 format available.
Message #160 received at 75518 <at> debbugs.gnu.org (full text, mbox):
On Wed, May 14, 2025 at 9:10 AM Andreas Enge <andreas <at> 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).
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 14 May 2025 20:52:01 GMT)
Full text and
rfc822 format available.
Message #163 received at 75518 <at> debbugs.gnu.org (full text, mbox):
On Wed, May 14, 2025 at 4:20 PM Greg Hogan <code <at> greghogan.com> wrote:
>
> On Wed, May 14, 2025 at 9:10 AM Andreas Enge <andreas <at> 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:
--8<---------------cut here---------------start------------->8---
../../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
--8<---------------cut here---------------end--------------->8---
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 15 May 2025 11:39:02 GMT)
Full text and
rfc822 format available.
Message #166 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Wed, May 14, 2025 at 04:20:52PM -0400 schrieb Greg Hogan:
> 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
https://issues.guix.gnu.org/75518
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75518
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
Added blocking bug(s) 76640
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org.
(Thu, 15 May 2025 11:42:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 15 May 2025 11:47:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 15 May 2025 14:22:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi,
Rutherther <rutherther <at> ditigal.xyz> writes:
> 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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 25 May 2025 19:45:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Just testing. Ignore this message. Sorry if it pinged you somehow.
Added blocking bug(s) 76654
Request was from
Christopher Baines <mail <at> cbaines.net>
to
control <at> debbugs.gnu.org.
(Mon, 26 May 2025 07:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sat, 31 May 2025 20:33:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Added blocking bug(s) 76899
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org.
(Sun, 01 Jun 2025 09:32:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 01 Jun 2025 10:16:01 GMT)
Full text and
rfc822 format available.
Message #187 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 01 Jun 2025 21:31:05 GMT)
Full text and
rfc822 format available.
Message #190 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
Rutherther <rutherther <at> ditigal.xyz> writes:
> 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.
> 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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 02 Jun 2025 12:28:02 GMT)
Full text and
rfc822 format available.
Message #193 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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 <at> enge.fr> writes:
> 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?
>
> Andreas
Rutherther
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 02 Jun 2025 12:29:02 GMT)
Full text and
rfc822 format available.
Message #196 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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 <at> gnu.org> writes:
> Hello,
> Rutherther <rutherther <at> ditigal.xyz> writes:
[ 5 more citation lines. Click/Enter to show. ]
>
>> 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
branch, https://issues.guix.gnu.org/78308.
>> 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. ]
>> 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:
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.
Rutherther
> Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 02 Jun 2025 13:31:02 GMT)
Full text and
rfc822 format available.
Message #199 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 02 Jun 2025 13:36:02 GMT)
Full text and
rfc822 format available.
Message #202 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
> ../../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
[fbdpnax8z5d99fwxifp4rc22vamjid-libstdc++-11.5.0.drv.gz (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Rutherther
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 02 Jun 2025 13:37:02 GMT)
Full text and
rfc822 format available.
Message #205 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
> ../../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
[fbdpnax8z5d99fwxifp4rc22vamjid-libstdc++-11.5.0.drv.gz (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
Rutherther
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 02 Jun 2025 13:56:02 GMT)
Full text and
rfc822 format available.
Message #208 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
> to me it is probably failing because of gcc-14, so I wanted to try with
> gcc-11 to verify that.
$ guix refresh -l motif
Die folgenden 4 Pakete zu erstellen, würde zur Folge haben, dass 4 abhängige Pakete neu erstellt werden: snd <at> 25.2 ddd <at> 3.4.1 emacs-motif <at> 29.4 xnedit <at> 1.6.3
I wonder if one "solution" would be to remove motif and its dependent
packages?
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 02 Jun 2025 16:11:02 GMT)
Full text and
rfc822 format available.
Message #211 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
Rutherther <rutherther <at> ditigal.xyz> writes:
> 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.
I confirmed from <https://codeberg.org/guix/guix/settings> that
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:
https://savannah.nongnu.org/support/?111250
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 02 Jun 2025 16:11:02 GMT)
Full text and
rfc822 format available.
Message #214 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
Rutherther <rutherther <at> ditigal.xyz> writes:
> Hi, I've tried looking at one of the failing packages - motif.
The error looks like this:
--8<---------------cut here---------------start------------->8---
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’
--8<---------------cut here---------------end--------------->8---
This is easily addressed with the attached patch.
Unfortunately there are additional failures afterwards:
--8<---------------cut here---------------start------------->8---
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
| ^
--8<---------------cut here---------------end--------------->8---
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’.
[motif-missing-includes.patch (text/x-patch, inline)]
Add missing includes.
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,
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 02 Jun 2025 16:39:02 GMT)
Full text and
rfc822 format available.
Message #217 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Resending to Debbugs tracker without To/Cc headers with all users.
Andreas Enge <andreas <at> enge.fr> writes:
> Am Mon, Jun 02, 2025 at 03:35:38PM +0200 schrieb Rutherther:
>> Hi, I've tried looking at one of the failing packages - motif. It seems
[ 6 more citation lines. Click/Enter to show. ]
>> to me it is probably failing because of gcc-14, so I wanted to try with
>> gcc-11 to verify that.
>
> $ guix refresh -l motif
> Die folgenden 4 Pakete zu erstellen, würde zur Folge haben, dass 4 abhängige Pakete neu erstellt werden: snd <at> 25.2
> ddd <at> 3.4.1 emacs-motif <at> 29.4 xnedit <at> 1.6.3
>
> I wonder if one "solution" would be to remove motif and its dependent
> packages?
I suppose. Is it fine to not follow the deprecation policy though? I am
really expecting just putting gcc-11 to native-inputs will fix it.
Also just saw Ludovic sent a proposed patch - I really expected the file
to be generated based on the name, not something in the source, though I
didn't check, silly me :)
Apart from that I had a look at guile-for-guile-emacs: submitted patch
here https://codeberg.org/lyrra/guile/pulls/1. The source is broken. I
am not sure who lyrra is and why their source is. I hope they will
react, otherwise I suppose this would have to be a downstream patch?
Also on capnproto, fix for it is here:
https://github.com/capnproto/capnproto/commit/1ae1e9990c7603f0dc99e64470f96693f869b00a,
so update to v1.1.0 should do it. I've tried it, and got one test
failure. Attaching patch with update and log, currently it doesn't
build. I won't be able to understand the test now I think, so I am
unable to decide whether it makes sense to just disable the test or if
something is wrong.
[ wxpcmjnrxpcqx8mpibsg86izbi000i-capnproto-1.1.0.drv.gz: application/octet-stream ]
[ 0001-gnu-capnproto-Update-to-1.1.0.patch: text/x-patch ]
From b5776c2d8b453a661479729332fdcd119ef50cac Mon Sep 17 00:00:00 2001
Message-ID: <b5776c2d8b453a661479729332fdcd119ef50cac.1748881827.git.rutherther <at> ditigal.xyz>
From: Rutherther <rutherther <at> ditigal.xyz>
Date: Mon, 2 Jun 2025 18:09:11 +0200
Subject: [PATCH] gnu: capnproto: Update to 1.1.0
Fixes compilation for gcc 13+
* gnu/packages/serialization.scm (capnproto): Update to 1.1.0
Change-Id: Ie3d7a3dccf43aac1f20fdb80f2b7f4372b7cbca4
---
gnu/packages/serialization.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/serialization.scm b/gnu/packages/serialization.scm
index 5dbeb36929..da39cc3069 100644
--- a/gnu/packages/serialization.scm
+++ b/gnu/packages/serialization.scm
@@ -733,7 +733,7 @@ (define-public ckdl
(define-public capnproto
(package
(name "capnproto")
- (version "1.0")
+ (version "1.1.0")
(source (origin
(method url-fetch)
(uri (string-append
@@ -741,7 +741,7 @@ (define-public capnproto
version ".tar.gz"))
(sha256
(base32
- "03f1862ljdshg7d0rg3j7jzgm3ip55kzd2y91q7p0racax3hxx6i"))))
+ "0f89ll6rmyih2f8cal16c60p3v0nihiirbxjwchyixb3wn07a5h7"))))
(build-system gnu-build-system)
(arguments
`(#:phases
base-commit: c06805c59fce8ff951fe9e24029daa41caf07de9
--
2.49.0
[ text/plain ]
As for clisp, there are errors in tests, 2 in streams, 1 in
streamslong and 1 in ext-clisp categories. I found this issue from Ludovic
https://gitlab.com/gnu-clisp/clisp/-/issues/51, seems something like
that has already happened in past with newer glibc version. So how was
that resolved last time? There is a lot of dependents on clisp.
python-libarchive-c is failing on one test and I am quite clueless on
what to do with it. It is quite outdated. On the other hand there are a
lot of dependants and there have been breaking changes, so I would
expect breakage in dependants if this package was updated. Btw simple
update of this package fails with a different test error, I will take a
look at that.
The last failing is rust-enumflags2 that is failing even on master. So I
haven't looked at it at all.
Rutherther
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 05 Jun 2025 09:50:03 GMT)
Full text and
rfc822 format available.
Message #220 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Mon, Jun 02, 2025 at 06:35:06PM +0200 schrieb Rutherther:
> Andreas Enge <andreas <at> 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 <at> 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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 05 Jun 2025 14:26:02 GMT)
Full text and
rfc822 format available.
Message #223 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello Andreas,
Jun 5, 2025, 09:49 by andreas <at> enge.fr:
> Am Mon, Jun 02, 2025 at 06:35:06PM +0200 schrieb Rutherther:
>
>> Andreas Enge <andreas <at> 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.
> 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 <at> 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.
> QA feels a bit slow right now, so I was about to suggest watching CI
> instead, but this gives me 504 errors...
>
> Andreas
>
Yelninei
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 05 Jun 2025 15:57:07 GMT)
Full text and
rfc822 format available.
Message #226 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello Yelninei,
Am Thu, Jun 05, 2025 at 04:14:17PM +0200 schrieb yelninei <at> 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 <at> 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:
> clisp is blocking linux-libre
Ah, that is super surprising!
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 05 Jun 2025 16:37:06 GMT)
Full text and
rfc822 format available.
Message #229 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
Jun 5, 2025, 15:56 by andreas <at> enge.fr:
> Hello Yelninei,
>
> Am Thu, Jun 05, 2025 at 04:14:17PM +0200 schrieb yelninei <at> 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 <at> 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 <at> 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 <at> 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 <at> tutamail.com>
Date: Thu May 15 07:51:43 2025 +0000
gnu: hurd: Fix service socket activation.
Fixes <https://issues.guix.gnu.org/77610>.
* gnu/packages/patches/hurd-socket-activation.patch: New patch
* gnu/packages/hurd.scm (hurd): Add it.
* gnu/local.mk: Register it.
> 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.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 05 Jun 2025 16:57:01 GMT)
Full text and
rfc822 format available.
Message #232 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Thu, Jun 05, 2025 at 06:35:28PM +0200 schrieb yelninei <at> 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.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 05 Jun 2025 19:49:02 GMT)
Full text and
rfc822 format available.
Message #235 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
Jun 5, 2025, 16:56 by andreas <at> enge.fr:
> Am Thu, Jun 05, 2025 at 06:35:28PM +0200 schrieb yelninei <at> 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.
> Andreas
>
Yelninei
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 06 Jun 2025 20:11:02 GMT)
Full text and
rfc822 format available.
Message #238 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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:
https://codeberg.org/guix/guix/issues/448
I get five errors here as there.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 08 Jun 2025 13:27:01 GMT)
Full text and
rfc822 format available.
Message #241 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Added blocking bug(s) 77340
Request was from
Christopher Baines <mail <at> cbaines.net>
to
control <at> debbugs.gnu.org.
(Sun, 08 Jun 2025 21:07:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 11 Jun 2025 21:28:01 GMT)
Full text and
rfc822 format available.
Message #246 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 12 Jun 2025 09:14:02 GMT)
Full text and
rfc822 format available.
Message #249 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Wed, Jun 11, 2025 at 11:27:16PM +0200 schrieb Ludovic Courtès:
> 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
Removed blocking bug(s) 76899
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org.
(Thu, 12 Jun 2025 09:27:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 12 Jun 2025 14:19:01 GMT)
Full text and
rfc822 format available.
Message #254 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi,
Andreas Enge <andreas <at> 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.
We’ll have to squash or do something with the commits that read
“Partially revert …” at the beginning of this branch.
Thanks!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 13 Jun 2025 06:33:03 GMT)
Full text and
rfc822 format available.
Message #257 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès writes:
Hello,
> Andreas Enge <andreas <at> 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!
> 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 <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
Removed blocking bug(s) 77340
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org.
(Fri, 13 Jun 2025 09:12:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 13 Jun 2025 14:03:02 GMT)
Full text and
rfc822 format available.
Message #262 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Some failure on CI looks rather worrying:
https://ci.guix.gnu.org/build/11129758/details
https://ci.guix.gnu.org/build/11129758/log
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 13 Jun 2025 15:29:01 GMT)
Full text and
rfc822 format available.
Message #265 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
> 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.
https://codeberg.org/guix/guix/commit/e02992a8b095641717ffb1cc49a6fe4571afc667
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.
>
> We’re making progress!
>
> Ludo’.
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 13 Jun 2025 15:48:05 GMT)
Full text and
rfc822 format available.
Message #268 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi,
Janneke Nieuwenhuizen <janneke <at> gnu.org> writes:
>> 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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 13 Jun 2025 17:10:03 GMT)
Full text and
rfc822 format available.
Message #271 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Thu, Jun 05, 2025 at 04:14:17PM +0200 schrieb yelninei <at> tutamail.com:
> 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.
> 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.
> python-pyelftools is blocking genimage
This one is still open. It can be updated as well, but this is probably
not all.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 13 Jun 2025 17:23:01 GMT)
Full text and
rfc822 format available.
Message #274 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Fri, Jun 13, 2025 at 07:08:49PM +0200 schrieb Andreas Enge:
> > 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 <at> 0.32 (and @0.31) already fails its tests on
master. This is all very brittle...
> 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
Added blocking bug(s) 78257
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org.
(Sat, 14 Jun 2025 13:44:04 GMT)
Full text and
rfc822 format available.
Removed blocking bug(s) 76311, 76640, 76654, 75676, and 75658
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org.
(Sat, 14 Jun 2025 13:51:03 GMT)
Full text and
rfc822 format available.
Added blocking bug(s) 78676
Request was from
Andreas Enge <andreas <at> enge.fr>
to
control <at> debbugs.gnu.org.
(Mon, 16 Jun 2025 09:04:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 16 Jun 2025 09:07:02 GMT)
Full text and
rfc822 format available.
Message #283 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Rebased on ced31f8dd156e4202a2c7115fc003608a541388c .
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Wed, 18 Jun 2025 20:15:03 GMT)
Full text and
rfc822 format available.
Message #286 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 20 Jun 2025 12:48:02 GMT)
Full text and
rfc822 format available.
Message #289 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
Am Fri, Jun 20, 2025 at 05:38:25PM +0800 schrieb Z572:
> for now, these packages are blocking the bulid.
> (...)
thanks for the analysis!
> Now a lot of packages are stuck at qtlocation <at> 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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 20 Jun 2025 13:01:04 GMT)
Full text and
rfc822 format available.
Message #292 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
Andreas Enge <andreas <at> enge.fr> writes:
> 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”:
https://codeberg.org/guix/guix/milestone/21092
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:
--8<---------------cut here---------------start------------->8---
$ ./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 <at> 0.9.0 /gnu/store/hzagd9m598v98pkjiv36fvsxsa0sgwnf-r-bslib-0.9.0
1321 r-lubridate <at> 1.9.4 /gnu/store/m2308vskr9dikvp1ifj68rj8zyhfqc59-r-lubridate-1.9.4
1170 r-curl <at> 6.2.3 /gnu/store/gsi15zmxlynpp3l251lgm1c50fw4ypjl-r-curl-6.2.3
1100 r-textshaping <at> 1.0.1 /gnu/store/rcqcx8pi7vjb50j3635phhph95jd0bly-r-textshaping-1.0.1
925 r-promises <at> 1.3.3 /gnu/store/ihx2dpram1dl3ggq9xyzyxk8g7bf4r7c-r-promises-1.3.3
748 icedtea <at> 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 <at> 6.7.2 /gnu/store/0979n4c17yj90fr11bv2wr2y4lzsmz9z-qtbase-6.7.2-debug /gnu/store/l9wg5pmnlqlp67rzbzi50m74s4sqkgjv-qtbase-6.7.2
641 r-iranges <at> 2.42.0 /gnu/store/5bgr2llaxpkdjysrv60pfl19wdvwlldg-r-iranges-2.42.0
631 python-pandas <at> 2.2.3 /gnu/store/nybha0bgxpjdvkd4h3ybcwizc5d5ylmz-python-pandas-2.2.3
556 qtlocation <at> 5.15.15 /gnu/store/ky855m25nf7gdfzwd3ai8xr4wi7q0iv4-qtlocation-5.15.15-debug /gnu/store/a1jdz47x2lppjp0a3mbz3pfpzdzr6jfk-qtlocation-5.15.15
$ git log |head -1
commit bc724b046e089c7b8fd237f6eaae038ccaafaf08
--8<---------------cut here---------------end--------------->8---
Let’s keep track of everything at Codeberg.
We might still discover problems on other architectures afterwards.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 20 Jun 2025 21:15:03 GMT)
Full text and
rfc822 format available.
Message #295 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Rebased on 5d6604a88e1dae62f56a196d5a8140d272f8e78c .
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 03 Jul 2025 19:29:02 GMT)
Full text and
rfc822 format available.
Message #298 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 03 Jul 2025 20:04:03 GMT)
Full text and
rfc822 format available.
Message #301 received at 75518 <at> debbugs.gnu.org (full text, mbox):
And I have added the Qt patches of
https://codeberg.org/guix/guix/pulls/978#issuecomment-5704280
QA is broken, CI is 504, let us check with the first of them that comes
back...
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 03 Jul 2025 20:57:02 GMT)
Full text and
rfc822 format available.
Message #304 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello,
Andreas Enge <andreas <at> enge.fr> writes:
> 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
<https://ci.guix.gnu.org/jobset/core-packages-team>.
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 10 Jul 2025 21:07:02 GMT)
Full text and
rfc822 format available.
Message #307 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 11 Jul 2025 09:14:02 GMT)
Full text and
rfc822 format available.
Message #310 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Andreas Enge <andreas <at> enge.fr> writes:
> 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]).
1; https://forge.cbaines.net/cbaines/guile-knots/commit/d18b5b8d5de5beff3b9f84cfb359b73a4dcf2070
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Fri, 11 Jul 2025 10:12:01 GMT)
Full text and
rfc822 format available.
Message #313 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hello Chris,
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?
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sat, 12 Jul 2025 12:58:01 GMT)
Full text and
rfc822 format available.
Message #316 received at 75518 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Andreas Enge <andreas <at> enge.fr> writes:
> 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.
1: https://codeberg.org/guix/data-service/commit/2430bc4307a9a87c37d2de38fd3b4ce04ff7509d
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 13 Jul 2025 11:55:01 GMT)
Full text and
rfc822 format available.
Message #319 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Since we just pushed a lot of updates, I have profited from this and
rebased on commit b1438011b38199b674c6f3aea7ffd37a2886749e .
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Sun, 13 Jul 2025 17:23:01 GMT)
Full text and
rfc822 format available.
Message #322 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Am Sun, Jul 13, 2025 at 07:10:14PM +0200 schrieb Andreas Enge:
> 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? :-)
https://data.guix.gnu.org/gnu/store/j4xb684n5v4mszqpwfvz4n5gr8sac4pq-scron-0.4.tar.gz.drv
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
https://data.guix.gnu.org/gnu/store/xkwm8h3y1ak0akx57ns3rmycrw479bb7-scron-0.4.tar.gz
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Mon, 14 Jul 2025 21:08:02 GMT)
Full text and
rfc822 format available.
Message #325 received at 75518 <at> debbugs.gnu.org (full text, mbox):
I have added the last fixes from codeberg, rebased on commit
c1604c4c9578665e059b84fbec6257b6d168c6a2 and pushed again.
Andreas
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 17 Jul 2025 08:49:02 GMT)
Full text and
rfc822 format available.
Message #328 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 17 Jul 2025 15:29:01 GMT)
Full text and
rfc822 format available.
Message #331 received at 75518 <at> debbugs.gnu.org (full text, mbox):
Hi Andreas,
Andreas Enge <andreas <at> enge.fr> writes:
> 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’.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 17 Jul 2025 18:36:07 GMT)
Full text and
rfc822 format available.
Message #334 received at 75518 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jul 17, 2025 at 4:48 AM Andreas Enge <andreas <at> enge.fr> wrote:
>
> 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
https://codeberg.org/guix/guix/pulls/1304, which could also be applied
to master after the merge.
Information forwarded
to
guix-patches <at> gnu.org:
bug#75518; Package
guix-patches.
(Thu, 17 Jul 2025 20:38:02 GMT)
Full text and
rfc822 format available.
Message #337 received at 75518 <at> debbugs.gnu.org (full text, mbox):
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
Reply sent
to
Andreas Enge <andreas <at> enge.fr>:
You have taken responsibility.
(Fri, 18 Jul 2025 19:01:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Janneke Nieuwenhuizen <janneke <at> gnu.org>:
bug acknowledged by developer.
(Fri, 18 Jul 2025 19:01:02 GMT)
Full text and
rfc822 format available.
Message #342 received at 75518-done <at> debbugs.gnu.org (full text, mbox):
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
https://codeberg.org/guix/guix/issues/1234
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
This bug report was last modified 22 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.