Merging ‘core-updates’ real soon

Merging ‘core-updates’ real soon

[Ludovic Courtès]

Hello Guix!

I’d like to propose merging ‘core-updates’ real soon, say by next week,
Friday 30th.


But first, this branch started about a year ago (!), and it’s hard for
someone who’s not following IRC 7 days a week to figure out what the
status is—something we should definitely improve on.

An overview in terms of package coverage can be found here:

  https://qa.guix.gnu.org/branch/core-updates

To view “blocking builds” (packages that fail to build and thus “block”
all those that depend on it), say for i686-linux, see:

  https://data.qa.guix.gnu.org/revision/aab1fe98574e1cd4c7911c1e5571b3733fb71d67/blocking-builds?system=i686-linux&target=none&limit_results=50

or run:

  ./pre-inst-env guix weather -s i686-linux -c 200

from a ‘core-updates’ checkout.  This gives an idea where to focus our
efforts.  You can also browse individual ci.guix builds at:

  https://ci.guix.gnu.org/eval/latest/dashboard?spec=core-updates

Currently, we’re at ~95% on x86_64-linux, 80–90% on the other *-linux
systems, and ~2% on i586-gnu (GNU/Hurd; that’s more or less where we
were before.)  Note that ci.guix is still struggling with aarch64-linux
build and hasn’t even attempted armhf-linux builds, but bordeaux.guix is
doing well.

I’m aware of at least one important issue that prevents use of Guix
System on i686-linux:

  https://issues.guix.gnu.org/72725

To me, that’s the last blocker, even though there’s room for improvement
here and there (for instance, FFmpeg currently fails to build on
i686-linux).

Anything else?


A number of people already provided feedback informally after
reconfiguring their systems on ‘core-updates’.  Please share your
experience, positive or negative, here!

Ludo’.

Re: Merging ‘core-updates’ real soon

[Kaelyn]

On Wednesday, August 21st, 2024 at 1:43 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> 
> 
> Hello Guix!
> 
> I’d like to propose merging ‘core-updates’ real soon, say by next week,
> Friday 30th.

Woohoo! I look forward to it. My thanks and congratulations to all who helped with 'core-updates'! :)

> 
> 
> But first, this branch started about a year ago (!), and it’s hard for
> someone who’s not following IRC 7 days a week to figure out what the
> status is—something we should definitely improve on.
> 
> An overview in terms of package coverage can be found here:
> 
> https://qa.guix.gnu.org/branch/core-updates
> 
> To view “blocking builds” (packages that fail to build and thus “block”
> all those that depend on it), say for i686-linux, see:
> 
> https://data.qa.guix.gnu.org/revision/aab1fe98574e1cd4c7911c1e5571b3733fb71d67/blocking-builds?system=i686-linux&target=none&limit_results=50
> 
> or run:
> 
> ./pre-inst-env guix weather -s i686-linux -c 200
> 
> from a ‘core-updates’ checkout. This gives an idea where to focus our
> efforts. You can also browse individual ci.guix builds at:
> 
> https://ci.guix.gnu.org/eval/latest/dashboard?spec=core-updates
> 
> Currently, we’re at ~95% on x86_64-linux, 80–90% on the other *-linux
> systems, and ~2% on i586-gnu (GNU/Hurd; that’s more or less where we
> were before.) Note that ci.guix is still struggling with aarch64-linux
> build and hasn’t even attempted armhf-linux builds, but bordeaux.guix is
> doing well.
> 
> I’m aware of at least one important issue that prevents use of Guix
> System on i686-linux:
> 
> https://issues.guix.gnu.org/72725
> 
> To me, that’s the last blocker, even though there’s room for improvement
> here and there (for instance, FFmpeg currently fails to build on
> i686-linux).

My three 'core-updates' patches (which thank you for sprucing the remaining two up and committing them!) were from me addressing the main build failures I encountered while building my system and home configs against core-updates: wine64 and wine64-staging not building due to their dependence on the 32-bit (i686-linux) wine and wine-staging packages--the three patches fixed the wine64 build for me, although building wine-staging (for wine64-staging) hit the FFmpeg build failure. After two weeks of bisecting, I tracked it down to commit 8025d419db which updates binutils from 2.38 to 2.41. I haven't figured out how to address the bug but it seems to be from a change between 2.38 and 2.39, as I also found a Gentoo bug report hitting the same FFmpeg build error (https://bugs.gentoo.org/893118) and downgraded binutils to 2.39 to confirm the error is present with that version.

Otherwise, IIRC I didn't encounter any other build failures for x86_64-linux.

Cheers,
Kaelyn

> 
> Anything else?
> 
> 
> A number of people already provided feedback informally after
> reconfiguring their systems on ‘core-updates’. Please share your
> experience, positive or negative, here!
> 
> Ludo’.

Re: Merging ‘core-updates’ real soon

[Ludovic Courtès]

Hi!

Kaelyn <kaelyn.alexi@protonmail.com> skribis:

> hit the FFmpeg build failure. After two weeks of bisecting, I tracked it down to commit 8025d419db which updates binutils from 2.38 to 2.41. I haven't figured out how to address the bug but it seems to be from a change between 2.38 and 2.39, as I also found a Gentoo bug report hitting the same FFmpeg build error (https://bugs.gentoo.org/893118) and downgraded binutils to 2.39 to confirm the error is present with that version.

Oh, interesting.  I wonder how Binutils affects openal detection (which
is what’s causing ‘configure’ to error out).

Ludo’.

Re: Merging ‘core-updates’ real soon

[Andreas Enge]

Am Wed, Aug 21, 2024 at 10:43:05PM +0200 schrieb Ludovic Courtès:
> To me, that’s the last blocker, even though there’s room for improvement
> here and there (for instance, FFmpeg currently fails to build on
> i686-linux).

Just so that others do not have to repeat my check: ffmpeg fails to find
openal in the configure phase for i686:
ld: /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.o: in function `check_alGetError':
test.c:(.text+0x1): undefined reference to `alGetError'
collect2: error: ld returned 1 exit status
check_lib openal AL/al.h alGetError -lopenal
check_func_headers AL/al.h alGetError -lopenal
test_ld cc -lopenal
test_cc
BEGIN /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.c
    1   #include <AL/al.h>
    2   #include <stdint.h>
    3   long check_alGetError(void) { return (long) alGetError; }
    4   int main(void) { int ret = 0;
    5    ret |= ((intptr_t)check_alGetError) & 0xFFFF;
    6   return ret; }
END /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.c

Openal is already at its latest version, updating ffmpeg to its latest
version 6.1.2 does not solve the problem.

Andreas

Re: Merging ‘core-updates’ real soon

[André Batista]

Hi Andreas,

qui 22 ago 2024 às 11:50:56 (1724338256), andreas@enge.fr enviou:
> Am Wed, Aug 21, 2024 at 10:43:05PM +0200 schrieb Ludovic Courtès:
> > To me, that’s the last blocker, even though there’s room for improvement
> > here and there (for instance, FFmpeg currently fails to build on
> > i686-linux).
> 
> Just so that others do not have to repeat my check: ffmpeg fails to find
> openal in the configure phase for i686:
> ld: /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.o: in function `check_alGetError':
> test.c:(.text+0x1): undefined reference to `alGetError'
> collect2: error: ld returned 1 exit status
> check_lib openal AL/al.h alGetError -lopenal
> check_func_headers AL/al.h alGetError -lopenal
> test_ld cc -lopenal
> test_cc
> BEGIN /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.c
>     1   #include <AL/al.h>
>     2   #include <stdint.h>
>     3   long check_alGetError(void) { return (long) alGetError; }
>     4   int main(void) { int ret = 0;
>     5    ret |= ((intptr_t)check_alGetError) & 0xFFFF;
>     6   return ret; }
> END /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.c
> 

This is not the whole story.

ffmpeg's configure script tries different library search paths
incantations and this error refers to when it tries with no
command line arguments.

On some other tries it actually finds openal and alGetError, but then
it aborts with the following linking error:

ld: /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.fLOeyoSu/test.o: non-canonical reference to canonical protected function `alGetError' in /gnu/store/j4qdsqxb95yllkby0w2dx6d9lib24zmn-openal-1.23.1/lib/libopenal.so
ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

Searching for it, it seems this was previously a runtime error, that
now fails at compile time[1] and is due to the pointer type cast
when referencing alGetError on line 5 above and the segmented memory
model of x86.

Notice that this code snippet is run for all libraries and on the ones
I've checked that have no issues linking the protection is default:

$ LANG=C readelf -a /gnu/store/3b65jkdm5ip7j9j0xarzpp8iyqfgq0m7-x265-3.5/lib/libx265.so.199 | grep x265_api_get
   827: 0009d500   322 FUNC    GLOBAL DEFAULT   12 x265_api_get_199

or

$ LANG=C readelf -a /gnu/store/8f9irjzk1zcg8z97p4zw239hnqn0plqk-xvid-1.3.7/lib/libxvidcore.so.4.3 | grep xvid_global
    33: 00015790  4010 FUNC    GLOBAL DEFAULT   12 xvid_global

while on openal it is 'protected':

$ LANG=C readelf -a /gnu/store/j4qdsqxb95yllkby0w2dx6d9lib24zmn-openal-1.23.1/lib/libopenal.so.1.23.1 | grep alGetErro
000fd45c  0000f001 R_386_32          00026a80   alGetError
   240: 00026a80   246 FUNC    GLOBAL PROTECTED   12 alGetError

Since, however, pointer equality is not needed as the above code only
tries to check if it can get a non null pointer to the given function
and the code is not meant to be run, I believe it would be safe in this
case to bypass this safety check[2] and force configure to succeed
(we already now that openal was found).

So I've bypassed this check here by adding a 'true' clause and then it
configures and builds fine.

However, when running tests it fails the checkasm_audiodsp test with
the following error:

checkasm: using random seed 3387428695
SSE:
 - audiodsp.audiodsp [OK]
SSE2:
 - audiodsp.audiodsp [OK]
SSSE3:
   audiodsp.vector_clip_int32_ssse3 (audiodsp.c:112)
 - audiodsp.audiodsp [FAILED]
checkasm: 1 of 4 tests have failed
threads=1

This _could_ be a hardware error here, but line 112 of audiodsp.c is
also doing some pointer comparison and, well it's doing some audio
vector thingy so afaik it could also be related.

So what I'm tending to now is to create a separate openal-for-ffmpeg
package definition, patching its CMakeLists.txt at line 350 whe it
tries to check if gcc has protected or default visibility support,
remove that setting and conditionaly enable this alternate package
when building on i686.

Does that make sense?

I'll try that and report back if no one shows a better solution[3].

Cheers,

1. https://sourceware.org/bugzilla/show_bug.cgi?id=28875
2. https://sourceware.org/bugzilla/show_bug.cgi?id=29512
3. AKA, is there a similar simple and effetive test for dynamic
symbols that does not rely on pointer references?

Re: Merging ‘core-updates’ real soon

[André Batista]

Hi guix,

seg 26 ago 2024 às 11:33:56 (1724682836), nandre@riseup.net enviou:
> 
> However, when running tests it fails the checkasm_audiodsp test with
> the following error:
> 
> checkasm: using random seed 3387428695
> SSE:
>  - audiodsp.audiodsp [OK]
> SSE2:
>  - audiodsp.audiodsp [OK]
> SSSE3:
>    audiodsp.vector_clip_int32_ssse3 (audiodsp.c:112)
>  - audiodsp.audiodsp [FAILED]
> checkasm: 1 of 4 tests have failed
> threads=1
> 
> This _could_ be a hardware error here, but line 112 of audiodsp.c is
> also doing some pointer comparison and, well it's doing some audio
> vector thingy so afaik it could also be related.
> 
> So what I'm tending to now is to create a separate openal-for-ffmpeg
> package definition, patching its CMakeLists.txt at line 350 whe it
> tries to check if gcc has protected or default visibility support,
> remove that setting and conditionaly enable this alternate package
> when building on i686.
> 
> Does that make sense?

No this does not make much sense. Openal is not included on that
specific test and it links fine, it's the test per se that failed. So it
was probably a hardware error after all. Offloading the build to another
machine succeded after applying the patch on #72838 which I've sent for
your appreciation.

Cheers,

PS: my i686 system reconfigure is still ongoing right now. I'll report
back if any other issue comes around (fingers crossed).

Re: Merging ‘core-updates’ real soon

[André Batista]

Hi again,

ter 27 ago 2024 às 16:04:43 (1724785483), nandre@riseup.net enviou:
> 
> PS: my i686 system reconfigure is still ongoing right now. I'll report
> back if any other issue comes around (fingers crossed).
> 

Unfortunately, I've had no luck. System reconfiguration fails when trying
to build 'binutils-64-bit-bfd-2.41' with a more cryptic error message:

$ zcat /var/log/guix/drvs/01/yl5wdsb4v16l7dphvr37090qmr7li8-binutils-64-bit-bfd-2.41.drv.gz
ice-9/read.scm:126:4: In procedure read-expr*:
/gnu/store/34j6xzczp0291qvrggzcfqnbqks1djz1-binutils-64-bit-bfd-2.41-builder:1:2744: Unknown # object: "#<"

This builder has only one occurrence of '#<' which is a '#<gexp ...>':

$ cat /gnu/store/34j6xzczp0291qvrggzcfqnbqks1djz1-binutils-64-bit-bfd-2.41-builder
(begin (use-modules (guix build gnu-build-system) (guix build utils)) (begin (define %build-inputs (quote (("source" . "/gnu/store/gfw3m9f9jz1m36f1sz1vqnqvfrqsb2k1-binutils-2.41.tar.zst") ("bison" . "/gnu/store/jng0ydhr8xw28svcgm1dzbykli29wxih-bison-3.8.2") ("tar" . "/gnu/store/m8h0hv6g549nh9n9xfjphjrzqg8g2r2w-tar-1.34") ("gzip" . "/gnu/store/b3mdz7n6j9dzkyi0scdbldnzrwcc3nlg-gzip-1.13") ("bzip2" . "/gnu/store/2aqa6wi5y81yprflz59cjk91pgwvy48w-bzip2-1.0.8") ("file" . "/gnu/store/k4ycd4b9zqrzxmdivjbhakjjymg8bfsv-file-5.45") ("diffutils" . "/gnu/store/ra6mdl923hpjw0yyrrj3j1snhibs32z0-diffutils-3.10") ("patch" . "/gnu/store/p76jj9sv007cj4hmfskjjsscy9z0vrc6-patch-2.7.6") ("findutils" . "/gnu/store/p1g6q2qnp1m0iza4d09mknyqx1xspws3-findutils-4.9.0") ("gawk" . "/gnu/store/mbgs4jl3vbhi6vya4p64hjfyj3739qzi-gawk-5.3.0") ("zstd" . "/gnu/store/542d6rh6ci06ngcgiprnambqfws09i4f-zstd-1.5.2") ("sed" . "/gnu/store/mqb37w640rg4hx9nx00274r2kz54kc3w-sed-4.8") ("grep" . "/gnu/store/wpykxc5blf6vcw7bmqa4k21sqs44p8as-grep-3.11") ("xz" . "/gnu/store/cnv0rzdrdmlb3c43sr9n5vagjh3qn0k1-xz-5.4.5") ("coreutils" . "/gnu/store/yxcrwcdd7blcczlc50i6lgcnj2w7nlja-coreutils-9.1") ("make" . "/gnu/store/c6i7ihy40368732m574lpgvygikd4ql9-make-4.4.1") ("bash" . "/gnu/store/ak41ci13apcxh5ahd8lc9rv6l7bqnwym-bash-minimal-5.1.16") ("ld-wrapper" . "/gnu/store/d7ayy457nq3a42myfgqs2mc2zbx7z406-ld-wrapper-0") ("binutils" . "/gnu/store/zf310q29z3apmkp3g6hck29z1d39ajly-binutils-2.41") ("gcc" . "/gnu/store/xgqbv2lkh6z9x6wgyfjvcpr8paw0zd9a-gcc-11.4.0") ("libc" . "/gnu/store/g88kcslhrdmd0b5bap2f2ghj26i7jdlm-glibc-2.39") ("libc:static" . "/gnu/store/3wg51p14zipq2rl2k59pw7i8hirbdnb5-glibc-2.39-static") ("m4" . "/gnu/store/xam8sj9hdr7y0rgqv138xvlbxrqp348f-m4-1.4.19") ("kernel-headers" . "/gnu/store/hpcf3359y90qb3c8c1x5syr0ivrj54bg-linux-libre-headers-5.15.49")))) (define %outputs (list (cons "out" ((@ (guile) getenv) "out")))) (define %output (assoc-ref %outputs "out")) (gnu-build #:source "/gnu/store/gfw3m9f9jz1m36f1sz1vqnqvfrqsb2k1-binutils-2.41.tar.zst" #:system "i686-linux" #:build "i686-unknown-linux-gnu" #:outputs %outputs #:inputs %build-inputs #:search-paths (quote (("BASH_LOADABLES_PATH" ("lib/bash") ":" directory #f) ("C_INCLUDE_PATH" ("include") ":" directory #f) ("CPLUS_INCLUDE_PATH" ("include/c++" "include") ":" directory #f) ("OBJC_INCLUDE_PATH" ("include") ":" directory #f) ("OBJCPLUS_INCLUDE_PATH" ("include/c++" "include") ":" directory #f) ("LIBRARY_PATH" ("lib" "lib64") ":" directory #f) ("GUIX_LOCPATH" ("lib/locale") ":" directory #f) ("TZDIR" ("share/zoneinfo") #f directory #f))) #:phases %standard-phases #:locale "C.UTF-8" #:separate-from-pid1? #t #:bootstrap-scripts %bootstrap-scripts #:configure-flags (cons "--enable-64-bit-bfd" #<gexp (quote ("LDFLAGS=-static-libgcc" "--enable-new-dtags" "--with-lib-path=/no-ld-lib-path" "--enable-install-libbfd" "--enable-deterministic-archives" "--enable-64-bit-bfd" "--enable-compressed-debug-sections=all" "--enable-lto" "--enable-separate-code" "--enable-threads")) gnu/packages/base.scm:661:28 a765d108>) #:make-flags (quote ("MAKEINFO=true")) #:out-of-source? #t #:tests? #t #:test-target "check" #:parallel-build? #t #:parallel-tests? #t #:patch-shebangs? #t #:license-file-regexp "^(COPYING.*|LICEN[CS]E.*|[Ll]icen[cs]e.*|Copy[Rr]ight(\\.(txt|md))?)$" #:strip-binaries? #t #:validate-runpath? #t #:make-dynamic-linker-cache? #t #:license-file-regexp "^(COPYING.*|LICEN[CS]E.*|[Ll]icen[cs]e.*|Copy[Rr]ight(\\.(txt|md))?)$" #:strip-flags (quote ("--strip-unneeded" "--enable-deterministic-archives")) #:strip-directories (quote ("lib" "lib64" "libexec" "bin" "sbin")))))

Thoughts?

Cheers,

Re: Merging ‘core-updates’ real soon

[Kaelyn]

On Wednesday, August 28th, 2024 at 9:48 AM, André Batista <nandre@riseup.net> wrote:

> 
> 
> Hi again,
> 
> ter 27 ago 2024 às 16:04:43 (1724785483), nandre@riseup.net enviou:
> 
> > PS: my i686 system reconfigure is still ongoing right now. I'll report
> > back if any other issue comes around (fingers crossed).
> 
> 
> Unfortunately, I've had no luck. System reconfiguration fails when trying
> to build 'binutils-64-bit-bfd-2.41' with a more cryptic error message:
> 
> $ zcat /var/log/guix/drvs/01/yl5wdsb4v16l7dphvr37090qmr7li8-binutils-64-bit-bfd-2.41.drv.gz
> ice-9/read.scm:126:4: In procedure read-expr*:
> /gnu/store/34j6xzczp0291qvrggzcfqnbqks1djz1-binutils-64-bit-bfd-2.41-builder:1:2744: Unknown # object: "#<"
> 
> This builder has only one occurrence of '#<' which is a '#<gexp ...>':
> 
> 
> $ cat /gnu/store/34j6xzczp0291qvrggzcfqnbqks1djz1-binutils-64-bit-bfd-2.41-builder
> (begin (use-modules (guix build gnu-build-system) (guix build utils)) (begin (define %build-inputs (quote (("source" . "/gnu/store/gfw3m9f9jz1m36f1sz1vqnqvfrqsb2k1-binutils-2.41.tar.zst") ("bison" . "/gnu/store/jng0ydhr8xw28svcgm1dzbykli29wxih-bison-3.8.2") ("tar" . "/gnu/store/m8h0hv6g549nh9n9xfjphjrzqg8g2r2w-tar-1.34") ("gzip" . "/gnu/store/b3mdz7n6j9dzkyi0scdbldnzrwcc3nlg-gzip-1.13") ("bzip2" . "/gnu/store/2aqa6wi5y81yprflz59cjk91pgwvy48w-bzip2-1.0.8") ("file" . "/gnu/store/k4ycd4b9zqrzxmdivjbhakjjymg8bfsv-file-5.45") ("diffutils" . "/gnu/store/ra6mdl923hpjw0yyrrj3j1snhibs32z0-diffutils-3.10") ("patch" . "/gnu/store/p76jj9sv007cj4hmfskjjsscy9z0vrc6-patch-2.7.6") ("findutils" . "/gnu/store/p1g6q2qnp1m0iza4d09mknyqx1xspws3-findutils-4.9.0") ("gawk" . "/gnu/store/mbgs4jl3vbhi6vya4p64hjfyj3739qzi-gawk-5.3.0") ("zstd" . "/gnu/store/542d6rh6ci06ngcgiprnambqfws09i4f-zstd-1.5.2") ("sed" . "/gnu/store/mqb37w640rg4hx9nx00274r2kz54kc3w-sed-4.8") ("grep" . "/gnu/store/wpykxc5blf6vcw7bmqa4k21sqs44p8as-grep-3.11") ("xz" . "/gnu/store/cnv0rzdrdmlb3c43sr9n5vagjh3qn0k1-xz-5.4.5") ("coreutils" . "/gnu/store/yxcrwcdd7blcczlc50i6lgcnj2w7nlja-coreutils-9.1") ("make" . "/gnu/store/c6i7ihy40368732m574lpgvygikd4ql9-make-4.4.1") ("bash" . "/gnu/store/ak41ci13apcxh5ahd8lc9rv6l7bqnwym-bash-minimal-5.1.16") ("ld-wrapper" . "/gnu/store/d7ayy457nq3a42myfgqs2mc2zbx7z406-ld-wrapper-0") ("binutils" . "/gnu/store/zf310q29z3apmkp3g6hck29z1d39ajly-binutils-2.41") ("gcc" . "/gnu/store/xgqbv2lkh6z9x6wgyfjvcpr8paw0zd9a-gcc-11.4.0") ("libc" . "/gnu/store/g88kcslhrdmd0b5bap2f2ghj26i7jdlm-glibc-2.39") ("libc:static" . "/gnu/store/3wg51p14zipq2rl2k59pw7i8hirbdnb5-glibc-2.39-static") ("m4" . "/gnu/store/xam8sj9hdr7y0rgqv138xvlbxrqp348f-m4-1.4.19") ("kernel-headers" . "/gnu/store/hpcf3359y90qb3c8c1x5syr0ivrj54bg-linux-libre-headers-5.15.49")))) (define %outputs (list (cons "out" ((@ (guile) getenv) "out")))) (define %output (assoc-ref %outputs "out")) (gnu-build #:source "/gnu/store/gfw3m9f9jz1m36f1sz1vqnqvfrqsb2k1-binutils-2.41.tar.zst" #:system "i686-linux" #:build "i686-unknown-linux-gnu" #:outputs %outputs #:inputs %build-inputs #:search-paths (quote (("BASH_LOADABLES_PATH" ("lib/bash") ":" directory #f) ("C_INCLUDE_PATH" ("include") ":" directory #f) ("CPLUS_INCLUDE_PATH" ("include/c++" "include") ":" directory #f) ("OBJC_INCLUDE_PATH" ("include") ":" directory #f) ("OBJCPLUS_INCLUDE_PATH" ("include/c++" "include") ":" directory #f) ("LIBRARY_PATH" ("lib" "lib64") ":" directory #f) ("GUIX_LOCPATH" ("lib/locale") ":" directory #f) ("TZDIR" ("share/zoneinfo") #f directory #f))) #:phases %standard-phases #:locale "C.UTF-8" #:separate-from-pid1? #t #:bootstrap-scripts %bootstrap-scripts #:configure-flags (cons "--enable-64-bit-bfd" #<gexp (quote ("LDFLAGS=-static-libgcc" "--enable-new-dtags" "--with-lib-path=/no-ld-lib-path" "--enable-install-libbfd" "--enable-deterministic-archives" "--enable-64-bit-bfd" "--enable-compressed-debug-sections=all" "--enable-lto" "--enable-separate-code" "--enable-threads")) gnu/packages/base.scm:661:28 a765d108>) #:make-flags (quote ("MAKEINFO=true")) #:out-of-source? #t #:tests? #t #:test-target "check" #:parallel-build? #t #:parallel-tests? #t #:patch-shebangs? #t #:license-file-regexp "^(COPYING.|LICEN[CS]E.|[Ll]icen[cs]e.|Copy[Rr]ight(\\.(txt|md))?)$" #:strip-binaries? #t #:validate-runpath? #t #:make-dynamic-linker-cache? #t #:license-file-regexp "^(COPYING.|LICEN[CS]E.|[Ll]icen[cs]e.|Copy[Rr]ight(\\.(txt|md))?)$" #:strip-flags (quote ("--strip-unneeded" "--enable-deterministic-archives")) #:strip-directories (quote ("lib" "lib64" "libexec" "bin" "sbin")))))
> 
> 
> Thoughts?

Do you have any modifications to e.g. the binutils package definition? It looks like the error is coming from using "cons" to append a configure flag; from the output above:

#:configure-flags (cons "--enable-64-bit-bfd" #<gexp (quote ("LDFLAGS=-static-libgcc" "--enable-new-dtags" "--with-lib-path=/no-ld-lib-path" "--enable-install-libbfd" "--enable-deterministic-archives" "--enable-64-bit-bfd" "--enable-compressed-debug-sections=all" "--enable-lto" "--enable-separate-code" "--enable-threads")) gnu/packages/base.scm:661:28 a765d108>)

I'd encountered a similar error in the past after more packages were migrated to use gexps because I hadn't yet learned of the gexp-aware helpers like "substitute-keyword-arguments". Basically the configure flags need to be extended using gexp operations instead of basic list operations like "cons". An example can be seen in the definition of "binutils-boot0" in gnu/packages/commencement.scm:

(substitute-keyword-arguments (package-arguments binutils)
  ((#:configure-flags cf)
   #~(append (list #$(string-append "--target="
                                    (boot-triplet))
                   "--disable-gprofng") ;requires Bison
             #$cf)))))

HTH,
Kaelyn

> 
> Cheers,

Re: Merging ‘core-updates’ real soon

[André Batista]

Hi,

qua 28 ago 2024 às 18:56:45 (1724882205), kaelyn.alexi@protonmail.com enviou:
> > 
> > Thoughts?
> 
> Do you have any modifications to e.g. the binutils package definition? It looks like the error is coming from using "cons" to append a configure flag; from the output above:

Not local, no.

> #:configure-flags (cons "--enable-64-bit-bfd" #<gexp (quote ("LDFLAGS=-static-libgcc" "--enable-new-dtags" "--with-lib-path=/no-ld-lib-path" "--enable-install-libbfd" "--enable-deterministic-archives" "--enable-64-bit-bfd" "--enable-compressed-debug-sections=all" "--enable-lto" "--enable-separate-code" "--enable-threads")) gnu/packages/base.scm:661:28 a765d108>)
> 
> I'd encountered a similar error in the past after more packages were migrated to use gexps because I hadn't yet learned of the gexp-aware helpers like "substitute-keyword-arguments". Basically the configure flags need to be extended using gexp operations instead of basic list operations like "cons". An example can be seen in the definition of "binutils-boot0" in gnu/packages/commencement.scm:
> 
> (substitute-keyword-arguments (package-arguments binutils)
>   ((#:configure-flags cf)
>    #~(append (list #$(string-append "--target="
>                                     (boot-triplet))
>                    "--disable-gprofng") ;requires Bison
>              #$cf)))))

But your comment put me on the right track and it seems both grub and
ipxe-qemu use inherited binutils' definitions which were trying to set
configure-flags using simple list procedures. I've sent a patch fixing
that on #72882, but I guess that patch can wait and be merged on master
right after core-updates?

Cheers,

Re: Merging ‘core-updates’ real soon

[Ricardo Wurmus]

I noticed a regression for x86_64 since the rebasing of core-updates
onto master.  epiphany no longer builds due to a build failure in
webkitgtk.

I hadn't reported it yet, because there's a chance it's due to limited
resources on my laptop; ci.guix.gnu.org is still a large number of
builds behind.

-- 
Ricardo

Re: Merging ‘core-updates’ real soon

[Andreas Enge]

Am Thu, Aug 22, 2024 at 02:07:32PM +0200 schrieb Ricardo Wurmus:
> I noticed a regression for x86_64 since the rebasing of core-updates
> onto master.  epiphany no longer builds due to a build failure in
> webkitgtk.
> I hadn't reported it yet, because there's a chance it's due to limited
> resources on my laptop; ci.guix.gnu.org is still a large number of
> builds behind.

It is apparently there now:
   https://ci.guix.gnu.org/nar/lzip/z173y7hp4r8mclmalac0l10s3nadlszg-epiphany-44.8

Andreas

Re: Merging ‘core-updates’ real soon

[Roman Scherer]

[-- Attachment #1: Type: text/plain, Size: 4903 bytes --]

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

Hello,

I tried the core-updates on an Apple M1 aarch64 and can't build
libcamera. I sent a patch (bug#69178) that fixes this a while ago.

This is the log from the failing tests:

```
53/70 libcamera / file                                           FAIL            0.01s   (exit status 255 or signal 127 SIGinvalid)
>>> MALLOC_PERTURB_=33 LD_LIBRARY_PATH=/tmp/guix-build-libcamera-0.1.0.drv-0/build/src/libcamera:/tmp/guix-build-libcamera-0.1.0.drv-0/build/src/libcamera/base /tmp/guix-build-libcamera-0.1.0.drv-0/build/test/file
――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
stderr:
Mapping of file region failed
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

54/70 libcamera / flags                                          OK              0.00s
55/70 libcamera / hotplug-cameras                                SKIP            0.01s   exit status 77
56/70 libcamera / message                                        OK              0.23s
57/70 libcamera / object                                         OK              0.01s
58/70 libcamera / object-delete                                  OK              0.01s
59/70 libcamera / object-invoke                                  OK              0.01s
60/70 libcamera / pixel-format                                   OK              0.01s
61/70 libcamera / shared-fd                                      OK              0.01s
62/70 libcamera / signal-threads                                 OK              0.11s
63/70 libcamera / threads                                        OK              0.51s
64/70 libcamera / timer                                          OK              8.66s
65/70 libcamera / timer-thread                                   OK              0.41s
66/70 libcamera / unique-fd                                      OK              0.01s
67/70 libcamera / utils                                          OK              0.01s
68/70 libcamera / yaml-parser                                    OK              0.01s
69/70 libcamera / fence                                          SKIP            0.01s   exit status 77
70/70 libcamera / mapped-buffer                                  SKIP            0.01s   exit status 77

Summary of Failures:

53/70 libcamera / file                                           FAIL            0.01s   (exit status 255 or signal 127 SIGinvalid)

Ok:                 35  
Expected Fail:      0   
Fail:               1   
Unexpected Pass:    0   
Skipped:            34  
Timeout:            0   
```

Could we please include this patch?

Thanks, Roman.

> Hello Guix!
>
> I’d like to propose merging ‘core-updates’ real soon, say by next week,
> Friday 30th.
>
>
> But first, this branch started about a year ago (!), and it’s hard for
> someone who’s not following IRC 7 days a week to figure out what the
> status is—something we should definitely improve on.
>
> An overview in terms of package coverage can be found here:
>
>   https://qa.guix.gnu.org/branch/core-updates
>
> To view “blocking builds” (packages that fail to build and thus “block”
> all those that depend on it), say for i686-linux, see:
>
>   https://data.qa.guix.gnu.org/revision/aab1fe98574e1cd4c7911c1e5571b3733fb71d67/blocking-builds?system=i686-linux&target=none&limit_results=50
>
> or run:
>
>   ./pre-inst-env guix weather -s i686-linux -c 200
>
> from a ‘core-updates’ checkout.  This gives an idea where to focus our
> efforts.  You can also browse individual ci.guix builds at:
>
>   https://ci.guix.gnu.org/eval/latest/dashboard?spec=core-updates
>
> Currently, we’re at ~95% on x86_64-linux, 80–90% on the other *-linux
> systems, and ~2% on i586-gnu (GNU/Hurd; that’s more or less where we
> were before.)  Note that ci.guix is still struggling with aarch64-linux
> build and hasn’t even attempted armhf-linux builds, but bordeaux.guix is
> doing well.
>
> I’m aware of at least one important issue that prevents use of Guix
> System on i686-linux:
>
>   https://issues.guix.gnu.org/72725
>
> To me, that’s the last blocker, even though there’s room for improvement
> here and there (for instance, FFmpeg currently fails to build on
> i686-linux).
>
> Anything else?
>
>
> A number of people already provided feedback informally after
> reconfiguring their systems on ‘core-updates’.  Please share your
> experience, positive or negative, here!
>
> Ludo’.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

Merging ‘core-updates’ real soon

[nathan via Development of GNU Guix and the GNU System distribution.]

Do we have time to merge the vulkan loading fix into core-updates because there isn't a mesa-updates branch for it to go with right now? [bug#71109]

Re: Merging ‘core-updates’ real soon

[John Kehayias]

Hi,

I did see that patch but didn't have a chance to do anything with it. I just started (locally) on updating mesa to the latest version, so I was going to rebase on core-updates (or master if core-updates is merged) and get that ready to go.

So I would say it is up to whoever is leading on core-updates, based on the current substitute coverage. I would guess if it is ready to be merged, a rebuild of ~5k packages due to vulkan would set things back a while. And I can have a mesa-updates branch with that patch building everything soon after.

Apologies for the delay! I was away for a bit but getting back to it now. I better make a formal mesa/graphics team and get some others too.

John

On Thu, Aug 22, 2024 at 07:12 PM, nathan via \"Development of GNU Guix and the GNU System distribution.\" wrote:

> Do we have time to merge the vulkan loading fix into core-updates
> because there isn't a mesa-updates branch for it to go with right now?
> [bug#71109]

Re: Merging ‘core-updates’ real soon

[Ludovic Courtès]

Hi,

John Kehayias <john.kehayias@protonmail.com> skribis:

> I did see that patch but didn't have a chance to do anything with it. I just started (locally) on updating mesa to the latest version, so I was going to rebase on core-updates (or master if core-updates is merged) and get that ready to go.
>
> So I would say it is up to whoever is leading on core-updates, based on the current substitute coverage. I would guess if it is ready to be merged, a rebuild of ~5k packages due to vulkan would set things back a while. And I can have a mesa-updates branch with that patch building everything soon after.

A dedicated branch right after ‘core-updates’ is merged sounds like the
way forward to me.

Thanks,
Ludo’.

Re: Merging ‘core-updates’ real soon

[Ludovic Courtès]

Hello Guix!

I rebased ‘core-updates’ on ‘master’ hours ago; so far, so good, though
there are a few new build failures:

  https://ci.guix.gnu.org/eval/1586727?status=newly-failed

Nothing too bad, except for icedove:

  https://ci.guix.gnu.org/build/5510567/details

and perf:

  https://ci.guix.gnu.org/build/5509604/details

Prior to that, I applied the ffmpeg i686 fix and libcamera aarch64 fix
that others provided:

  https://ci.guix.gnu.org/eval/1586636?status=succeeded

If there are no objections, I’d like us to go ahead and rebase/merge
‘core-updates’ tomorrow, Friday 30th, after adding an entry in
‘etc/news.scm’ (I can do that but I won’t mind if somebody else does; we
can coordinate on IRC and/or here.)

Thoughts?

Ludo’.

Re: Merging ‘core-updates’ real soon

[Ludovic Courtès]

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

> If there are no objections, I’d like us to go ahead and rebase/merge
> ‘core-updates’ tomorrow, Friday 30th, after adding an entry in
> ‘etc/news.scm’ (I can do that but I won’t mind if somebody else does; we
> can coordinate on IRC and/or here.)

Here’s a proposed news entry:

 (entry (commit "XXX")
        (title
         (en "Core packages updated"))
        (body
         (en "Core packages have been updated, in particular those that
are used to build every other package in the distribution.  Noteworthy
upgrades include:

@itemize
@item @code{glibc} 2.39 (was 2.35);
@item @code{gcc} 11.4.0 as the default compiler (was 11.3.0);
@item @code{binutils} 2.41 (was 2.38);
@item @code{make} 4.4.1 (was 4.3);
@item TeX@tie{}Live 2024.2 (was 20230313);
@end itemize

Additional improvements were made to the build system and related
packages and tools:

@itemize
@item
the @code{glibc} package now includes the @code{C.UTF-8} locale,
suitable for use when a UTF-8-capable is necessary regardless of any
language or regional convention;
@item
origins that include patches are now repacked with zstd instead of xz,
which uses less CPU power and memory, both when compressing and when
decompressing;
@item
@code{copy-recursively} has a new @code{#:select?} parameter.
@end itemize

If you encounter any problem, please check
@url{https://issues.guix.gnu.org} for existing reports and resolutions;
email @email{bug-guix@@gnu.org} to report new bugs.")))

Did I forget anything important here?

If not, translations welcome!

Ludo’.

Re: Merging ‘core-updates’ real soon

[Kaelyn]

On Thursday, August 29th, 2024 at 12:53 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> 
> 
> Ludovic Courtès ludo@gnu.org skribis:
> 
> > If there are no objections, I’d like us to go ahead and rebase/merge
> > ‘core-updates’ tomorrow, Friday 30th, after adding an entry in
> > ‘etc/news.scm’ (I can do that but I won’t mind if somebody else does; we
> > can coordinate on IRC and/or here.)
> 
> 
> Here’s a proposed news entry:
> 
> (entry (commit "XXX")
> (title
> (en "Core packages updated"))
> (body
> (en "Core packages have been updated, in particular those that
> are used to build every other package in the distribution. Noteworthy
> upgrades include:
> 
> @itemize
> @item @code{glibc} 2.39 (was 2.35);
> @item @code{gcc} 11.4.0 as the default compiler (was 11.3.0);
> @item @code{binutils} 2.41 (was 2.38);
> @item @code{make} 4.4.1 (was 4.3);
> @item TeX@tie{}Live 2024.2 (was 20230313);
> @end itemize
> 
> Additional improvements were made to the build system and related
> packages and tools:
> 
> @itemize
> @item
> the @code{glibc} package now includes the @code{C.UTF-8} locale,
> suitable for use when a UTF-8-capable is necessary regardless of any

Overall the news entry looks good to me. However, you have a missing word on the above line--it reads "when a UTF-8-capable is necessary", and I believe it should read "when a UTF-8-capable locale is necessary".

Cheers,
Kaelyn

> language or regional convention;
> @item
> origins that include patches are now repacked with zstd instead of xz,
> which uses less CPU power and memory, both when compressing and when
> decompressing;
> @item
> @code{copy-recursively} has a new @code{#:select?} parameter.
> @end itemize
> 
> If you encounter any problem, please check
> @url{https://issues.guix.gnu.org} for existing reports and resolutions;
> email @email{bug-guix@@gnu.org} to report new bugs.")))
> 
> Did I forget anything important here?
> 
> If not, translations welcome!
> 
> Ludo’.

Re: Merging ‘core-updates’ real soon

[Nicolas Goaziou via Development of GNU Guix and the GNU System distribution.]

Hello,

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

> @item TeX@tie{}Live 2024.2 (was 20230313);
> @end itemize

You may want to mention that the versioning scheme for TeX Live has
changed and, unless I'm mistaken, users will need to force upgrade for
these packages. Indeed, I doubt "guix pull && guix upgrade" will update
willingly, e.g., `texlive-context' from version "66594" (old scheme) to
"2024.2" (new scheme). I didn't check, tho.

Also, the news entry might mention that compiling documents with modular
TeX Live is no longer slower than expected.

Regards,
-- 
Nicolas Goaziou

Re: Merging ‘core-updates’ real soon

[Ludovic Courtès]

Hello!

Here’s the updated news entry based on everyone’s feedback:

 (entry (commit "XXX")
        (title
         (en "Core packages updated"))
        (body
         (en "Core packages have been updated, in particular those that
are used to build every other package in the distribution.  Noteworthy
upgrades include:

@itemize
@item @code{glibc} 2.39 (was 2.35);
@item @code{gcc} 11.4.0 as the default compiler (was 11.3.0);
@item @code{binutils} 2.41 (was 2.38);
@item @code{make} 4.4.1 (was 4.3);
@item TeX@tie{}Live 2024.2 (was 20230313; note that due to the new
versioning scheme, @command{guix upgrade} will consider the new packages
as ``older'' than the previous ones so you may need to use
@command{guix install} to upgrade them).
@end itemize

Additional improvements were made to the build system and related
packages and tools:

@itemize
@item
the @code{glibc} package now includes the @code{C.UTF-8} locale,
suitable for use when a UTF-8 locale is necessary regardless of
any language or regional convention;
@item
origins that include patches are now repacked with zstd instead of xz,
which uses less CPU power and memory, both when compressing and when
decompressing;
@item
performance issues with the modular TeX@tie{}Live package set have
been fixed.
@end itemize

If you encounter any problem, please check
@url{https://issues.guix.gnu.org} for existing reports and resolutions;
email @email{bug-guix@@gnu.org} to report new bugs.")))

I can do the French translation but feel free to send other
translations.

Thanks,
Ludo’.