bug#50353: Excessive temproots size when running guix build
I spotted a problem with data.guix.gnu.org trying to process this old revision [1] 1: https://data.guix.gnu.org/revision/75dabac633bb9a33efbebf859f8aa4bb3b9582b2 The machine ran out of disk space, as a ~30GiB file had been created in /var/guix/temproots. I think I can reproduce the situation by running this command. guix time-machine --commit=75dabac633bb9a33efbebf859f8aa4bb3b9582b2 -- build --system=armhf-linux guix It's the build of the guix package that seems to be involved. For some reason though, I can't reproduce this on my local machine, I get a build failure for [2]. 2: /gnu/store/cz4sr5whzf3qhp8c47bzlfzcxxwl485i-python2-2.7.15.drv Any ideas? Is there a known issue (perhaps with grafts) for old revisions of Guix which could lead to excessive temproots file sizes in some situations? signature.asc Description: PGP signature
bug#49990: [core-updates-frozen] Ant-bootstrap broken by classpath-bootstrap
Hi there!
I pushed a variant of the patch proposed earlier, adding a similar
workaround to ‘Java_java_io_VMFile_exists’ and
‘Java_java_io_VMFile_isDirectory’:
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen&id=7f50543d55b20cd528b28d7e15f1bb81001a8da9
With this, I can build ‘ant-bootstrap’ just fine. \o/
Next up: icedtea 1.13.13 chokes on obscure C++ issues:
--8<---cut here---start->8---
In file included from
/tmp/guix-build-icedtea-1.13.13.drv-0/icedtea6-1.13.13/openjdk-ecj/hotspot/src/share/vm/asm/assembler.hpp:29,
from
/tmp/guix-build-icedtea-1.13.13.drv-0/icedtea6-1.13.13/openjdk-ecj/hotspot/src/share/vm/precompiled/precompiled.hpp:29:
/tmp/guix-build-icedtea-1.13.13.drv-0/icedtea6-1.13.13/openjdk-ecj/hotspot/src/share/vm/code/relocInfo.hpp:374:27:
error: friend declaration of ‘relocInfo prefix_relocInfo(int)’ specifies
default arguments and isn’t a definition [-fpermissive]
374 | inline friend relocInfo prefix_relocInfo(int datalen = 0);
| ^~~~
In file included from
/tmp/guix-build-icedtea-1.13.13.drv-0/icedtea6-1.13.13/openjdk-ecj/hotspot/src/share/vm/asm/assembler.hpp:29,
from
/tmp/guix-build-icedtea-1.13.13.drv-0/icedtea6-1.13.13/openjdk-ecj/hotspot/src/share/vm/precompiled/precompiled.hpp:29:
/tmp/guix-build-icedtea-1.13.13.drv-0/icedtea6-1.13.13/openjdk-ecj/hotspot/src/share/vm/code/relocInfo.hpp:472:18:
error: friend declaration of ‘relocInfo prefix_relocInfo(int)’ specifies
default arguments and isn’t the only declaration [-fpermissive]
472 | inline relocInfo prefix_relocInfo(int datalen) {
| ^~~~
--8<---cut here---end--->8---
Anyway, we’re making progress!
Ludo’.
bug#50203: binutils-mesboot0: configure: sed: command not found
Hi Carl, Carl Dong skribis: > After resolving bug#49985, a new build failure has stumped a community member > of mine. When building > /gnu/store/8kap9kj0ayhaqd4ay7n9lgpbcwankxrq-binutils-mesboot0-2.14.drv, the > build fails and the logs are as follows: > https://paste.sr.ht/~dongcarl/7fe559b338dfa9aa3cf3464dbdab8109487c9783#8kap9kj0ayhaqd4ay7n9lgpbcwankxrq-binutils-mesboot0-2.14.log-L5504 Here’s the relevant excerpt for posterity: --8<---cut here---start->8--- starting phase `configure' running ./configure --disable-nls --disable-shared --disable-werror --build=i386-unknown-linux --host=i386-unknown-linux --target=i386-unknown-linux --with-sysroot=/ --prefix=/gnu/store/jfa9b78rdniyw7qilsmw3bh02x8x68ly-binutils-mesboot0-2.14 ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 1: sed: command not found ./configure: line 456: rm: command not found ./configure: line 1: sed: command not found configure: error: can not find sources in or .. --8<---cut here---end--->8--- > We’ve tried the normal suspects: --cores=1, reboots, mounting tmpfs at /tmp, > etc. Heh. :-) > What’s also fascinating is that, when I inspect his keep-failed directory: > https://nextcloud.carl.homeserver.net/s/ZHmAbz3LwyPwcfL > We found that: > > 1. The $PATH in the environment-variables file contained > /gnu/store/2z4y0n547x7d566281isklk9ls2d8c9q-sed-mesboot0-1.18/bin, which in > turn contained a working sed: Could you go to the build directory, run “. ../environment-variables”, and run the configure script like so: sh -x ./configure … ? That way we’ll see if PATH is getting overridden somewhere. /gnu/store/2z4y0n547x7d566281isklk9ls2d8c9q-sed-mesboot0-1.18/bin/sed is a valid i386 static binary AFAICS. Thanks, Ludo’.
bug#50355: [core-updates-frozen] Building mozjs with rust@1.54 fails
Hello Guix! I'm nearly done updating the Rust bootstrap for core-updates-frozen; one of the changes is that only the current rust (1.54) gets exposed and used everywhere. This seems to be OK so far, except for mozjs, which fails to build like so: --8<---cut here---start->8--- error: aborting due to 8 previous errors Some errors have detailed explanations: E0432, E0557. For more information about an error, try `rustc --explain E0432`. The following warnings were emitted during compilation: warning: Cannot set `RUSTC_BOOTSTRAP=1` from build script of `packed_simd v0.3.3 (https://github.com/hsivonen/packed_simd?rev=3541e3818fdc7c2a24f87e3459151a4ce955a67a#3541e381)`. note: Crates cannot set `RUSTC_BOOTSTRAP` themselves, as doing so would subvert the stability guarantees of Rust for your project. error: could not compile `packed_simd` Caused by: process didn't exit successfully: `CARGO=/gnu/store/sgvw6h637pgw3mrn9wva29b8645z37m0-rust-1.54.0-cargo/bin/cargo CARGO_CRATE_NAME=packed_simd CARGO_MANIFEST_DIR=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/third_party/rust/packed_simd CARGO_PKG_AUTHORS='Gonzalo Brito Gadeschi ' CARGO_PKG_DESCRIPTION='Portable Packed SIMD vectors' CARGO_PKG_HOMEPAGE='https://github.com/rust-lang-nursery/packed_simd' CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=packed_simd CARGO_PKG_REPOSITORY='https://github.com/rust-lang-nursery/packed_simd' CARGO_PKG_VERSION=0.3.3 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=3 CARGO_PKG_VERSION_PATCH=3 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/release/deps:/gnu/store/89iv0hicjlmgdxk01sj9lc95xkdkb8f0-rust-1.54.0/lib' OUT_DIR=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/x86_64-unknown-linux-gnu/release/build/packed_simd-36a821efa8c03e42/out /gnu/store/89iv0hicjlmgdxk01sj9lc95xkdkb8f0-rust-1.54.0/bin/rustc --crate-name packed_simd --edition=2018 /tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/third_party/rust/packed_simd/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C panic=abort -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="into_bits"' -C metadata=220aa1d9e77763e7 -C extra-filename=-220aa1d9e77763e7 --out-dir /tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -C linker=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/build/cargo-linker -L dependency=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/x86_64-unknown-linux-gnu/release/deps -L dependency=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/release/deps --extern cfg_if=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/x86_64-unknown-linux-gnu/release/deps/libcfg_if-646d80c97708097e.rmeta --cap-lints warn -C opt-level=2 --cap-lints warn -Cembed-bitcode=yes -C codegen-units=1` (exit status: 1) --8<---cut here---end--->8--- If someone has an idea, please shout :-) Thanks, Maxim
bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64
Hi,
On +2021-09-02 18:41:12 -0400, Simon South wrote:
> Patching strace to add a "--trace-path" parameter to the two tests'
> definitions as in the patch below seems to fix this issue on both
> AArch64 and x86-64, and is less drastic than disabling the tests
> altogether.
>
> The changes limit strace's output during testing to only calls affecting
> files in the test directory itself, effectively filtering out the
> 'readlink("/proc/self/exe")' call from glibc that is throwing the tests
> currently. You can see a number of other places in gen_tests.in where
> this is done, presumably for similar reasons.
>
> Does this seem reasonable?
>
I worry about disabling tests in too general a way, since it creates
a hiding place which conceivably someone really clever may be able exploit.
So I wonder whether what you are doing is making it possible to
configure tests to have (narrow) context-sensitive expectations
(e.g., in this case making the test handle the error as an expected one,
as opposed to being made ignorant of it), or building in a static and
probably too general configuration.
A proper configurability, ISTM, would be preferable to any other form
of more general filtering.
Sorry if this is just noise from a lurker with insufficient knowledge
of the issue and discussions. If so please ignore ;/
of13> definitions as in the patch below seems to fix this issue on both
> --
> Simon South
> si...@simonsouth.net
>
>
> diff --git a/tests/gen_tests.in b/tests/gen_tests.in
> index 8b4e2e9..cc3ca63 100644
> --- a/tests/gen_tests.in
> +++ b/tests/gen_tests.in
> @@ -623,8 +623,8 @@ quotactl-xfs-v-v -e trace=quotactl
> read-write -a15 -eread=0,5 -ewrite=1,4 -e trace=read,write -P
> read-write-tmpfile -P /dev/zero -P /dev/null
> readahead-a1
> readdir -a16
> -readlink -xx
> -readlinkat -xx
> +readlink -xx --trace-path=test.readlink.link
> +readlinkat -xx --trace-path=test.readlinkat.link
> reboot -s 256
> recv-MSG_TRUNC -a26 -e trace=recv
> recvfrom -a35
>
>
>
--
Regards,
Bengt Richter
bug#50066: core-update: Raw origin tarballs are not handled correctly.
Hi Mathieu, Mathieu Othacehe writes: > Hello Maxim, > >>> 1. rustc bootstrap from 1.39 (the itch to make it faster comes back >>> everytime I have to build it ;-)). >> >> I'm nearing completion on this front. > > That will be a welcomed improvement! > >>> 2. fontconfig update that should allow per-profile fonts management via >>> XDG_DATA_DIRS (I have the commit ready, but failed to test it due to >>> having to build rust and getting distracted by 1. :-)) >> >> I'll propose a few patches to include in the 'frozen' core-updates >> branch since we've found a world-rebuilding change worthy of addressing >> anyway (the patch below). > > Great! As we are going for a full rebuild, maybe we should also consider > some of the Thiago fixes targeting core-updates-frozen such as > https://issues.guix.gnu.org/50239. > >> Sadly the plain .tar file was/is not covered by tests (and not easily >> so), but if his was my only omission, it should be correct (TM). >> Attentive review needed :-). > > This seems reasonable and I'm currently rebuilding the world to test > this fix and the Python fix. I should maybe apply your Rust bootstrap > patch if you have it around to gain some time. successfully built /gnu/store/vag2a53byhgrkpchviqz78lilall6412-emacs-org-contrib-20210519.drv /gnu/store/40hl0dli745i2ggs1aqhn2drh0fkmrbx-emacs-org-contrib-20210519 :-). I'm trying to fix one last thing with my local patch set (mozjs not building with rust@1.54), but if takes too much time, I'll send what I have and we can figure it out together. Thanks, Maxim
bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64
Bengt Richter writes: > A proper configurability, ISTM, would be preferable to any other form > of more general filtering. I agree with you on the need to be cautious around modifying test cases but I'm not sure I follow you otherwise. What would "proper configurability" look like in this case? The change I'm proposing here narrows the two test cases so they test only what appears to have been intended, i.e. that strace can capture readlink(at) system calls and that it reports them in the format expected by the developers. It does not affect other test cases or the test suite as a whole. The obvious alternative would be to modify the test cases' expected output to match what is actually generated, but this could have the side effect of tying the package to Linux and perhaps to specific versions of glibc. That said I'm still not sure why this additional syscall is being made in the first place, only that it appears to originate from glibc's "_dl_get_origin" function[0]. If I build strace from source "manually" the tests complete fine without modification. I presume the extra call has to do with the fact Guix builds strace inside a container; does anyone know how this could be affecting the way programs are loaded? -- Simon South si...@simonsouth.net [0] See e.g. glibc's sysdeps/unix/sysv/linux/dl-origin.c for the x86-64 case, as well as "_dl_non_dynamic_init" in elf/dl-support.c, which seems to be the only place it is called.
bug#50355: [core-updates-frozen] Building mozjs with rust@1.54 fails
Hi, Maxim Cournoyer writes: > Hello Guix! > > I'm nearly done updating the Rust bootstrap for core-updates-frozen; one > of the changes is that only the current rust (1.54) gets exposed and > used everywhere. This seems to be OK so far, except for mozjs, which > fails to build like so: > > error: aborting due to 8 previous errors > > Some errors have detailed explanations: E0432, E0557. > For more information about an error, try `rustc --explain E0432`. > The following warnings were emitted during compilation: > > warning: Cannot set `RUSTC_BOOTSTRAP=1` from build script of `packed_simd > v0.3.3 > (https://github.com/hsivonen/packed_simd?rev=3541e3818fdc7c2a24f87e3459151a4ce955a67a#3541e381)`. > note: Crates cannot set `RUSTC_BOOTSTRAP` themselves, as doing so would > subvert the stability guarantees of Rust for your project. > > error: could not compile `packed_simd` > > Caused by: > process didn't exit successfully: > `CARGO=/gnu/store/sgvw6h637pgw3mrn9wva29b8645z37m0-rust-1.54.0-cargo/bin/cargo > CARGO_CRATE_NAME=packed_simd > CARGO_MANIFEST_DIR=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/third_party/rust/packed_simd > CARGO_PKG_AUTHORS='Gonzalo Brito Gadeschi ' > CARGO_PKG_DESCRIPTION='Portable Packed SIMD vectors' > CARGO_PKG_HOMEPAGE='https://github.com/rust-lang-nursery/packed_simd' > CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE='' > CARGO_PKG_NAME=packed_simd > CARGO_PKG_REPOSITORY='https://github.com/rust-lang-nursery/packed_simd' > CARGO_PKG_VERSION=0.3.3 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=3 > CARGO_PKG_VERSION_PATCH=3 CARGO_PKG_VERSION_PRE='' > LD_LIBRARY_PATH='/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/release/deps:/gnu/store/89iv0hicjlmgdxk01sj9lc95xkdkb8f0-rust-1.54.0/lib' > > OUT_DIR=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/x86_64-unknown-linux-gnu/release/build/packed_simd-36a821efa8c03e42/out > /gnu/store/89iv0hicjlmgdxk01sj9lc95xkdkb8f0-rust-1.54.0/bin/rustc > --crate-name packed_simd --edition=2018 > /tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/third_party/rust/packed_simd/src/lib.rs > --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type > lib --emit=dep-info,metadata,link -C opt-level=2 -C panic=abort -C > embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="into_bits"' -C > metadata=220aa1d9e77763e7 -C extra-filename=-220aa1d9e77763e7 --out-dir > /tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/x86_64-unknown-linux-gnu/release/deps > --target x86_64-unknown-linux-gnu -C > linker=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/build/cargo-linker > -L > dependency=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/x86_64-unknown-linux-gnu/release/deps > -L > dependency=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/release/deps > --extern > cfg_if=/tmp/guix-build-mozjs-78.10.1.drv-0/firefox-78.10.1/run-configure-from-here/x86_64-unknown-linux-gnu/release/deps/libcfg_if-646d80c97708097e.rmeta > --cap-lints warn -C opt-level=2 --cap-lints warn -Cembed-bitcode=yes -C > codegen-units=1` (exit status: 1) Simply updating to latest version resolves it: successfully built /gnu/store/vbx2l76svqjbsz1dhgjr73kilgkk5ybv-mozjs-78.13.0.drv /gnu/store/112gxnbnnw89nfhi9z74i5pzlsk8l04r-mozjs-78.13.0 Maxim
bug#50105: [core-updates] Python sitecustomize issue.
Hi Mathieu, Mathieu Othacehe writes: > Hello, > > I tried to upgrade glade to the 3.38.2 release on core-update and > encountered the following test issue: > > 2/5 modules FAIL0.29s killed by signal 5 SIGTRAP GLADE_MODULE_SEARCH_PATH=/home/mathieu/glade-3.38.2/build/plugins/gtk+:/home/mathieu/glade-3.38.2/build/plugins/python:/home/mathieu/glade-3.38.2/build/plugins/gjs:/home/mathieu/glade-3.38.2/tests/modules MALLOC_PERTURB_=195 GLADE_TESTING=1 GLADE_CATALOG_SEARCH_PATH=/home/mathieu/glade-3.38.2/plugins/gtk+:/home/mathieu/glade-3.38.2/plugins/python:/home/mathieu/glade-3.38.2/plugins/gjs:/home/mathieu/glade-3.38.2/tests/catalogs GLADE_PIXMAP_DIR=/home/mathieu/glade-3.38.2/data/icons GLADE_ICON_THEME_PATH=/home/mathieu/glade-3.38.2/plugins/gtk+/icons/22x22 /home/mathieu/glade-3.38.2/build/tests/modules > ―― > ✀ > ――― > stdout: > # random seed: R02Sd222538bc9b76b6e424ec0cb17ee887c > # GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation > local (GLocalVfs) for ?gio-vfs? > Bail out! GladeUI-PYTHON-FATAL-WARNING: Error initializing Python > interpreter: could not import pygobject > stderr: > Error in sitecustomize; set PYTHONVERBOSE for traceback: > ValueError: '/home/mathieu/glade-3.38.2/build/lib/python3.9/site-packages' is > not in list > > (/home/mathieu/glade-3.38.2/build/tests/modules:4898): GladeUI-PYTHON-WARNING > **: 09:43:58.605: Error initializing Python interpreter: could not import > pygobject > > > I think the issue here lies in the sitecustomize.py file introduced with > cb72f9a773e0931ee3758c851d96007ded034e4c. [...] Is there a simple reproducer to test my fix? Would just building current Glade and its test suite trigger it? Thanks, Maxim
bug#50356: python-hy / python-funcparserlib / tox config file
Hi, python-hy fails to install for me - because there are issues with python-funcparserlib, as I understand (or tox - cf the end of the log below). Thanks in advance. -Andreas rx@dell ~$ guix package -i python-hy The following package will be installed: python-hy 0.18.0 substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/wca6ncmjf3lqc8xr68ghv3sll3z2pls1-python-funcparserlib-0.3.6.drv /gnu/store/xfj4rwrlhybj5f8dfg4g7pfqgaaa0w9y-python-hy-0.18.0.drv building /gnu/store/wca6ncmjf3lqc8xr68ghv3sll3z2pls1-python-funcparserlib-0.3.6.drv... / 'check' phasebuilder for `/gnu/store/wca6ncmjf3lqc8xr68ghv3sll3z2pls1-python-funcparserlib-0.3.6.drv' failed with exit code 1 build of /gnu/store/wca6ncmjf3lqc8xr68ghv3sll3z2pls1-python-funcparserlib-0.3.6.drv failed View build log at '/var/log/guix/drvs/wc/a6ncmjf3lqc8xr68ghv3sll3z2pls1-python-funcparserlib-0.3.6.drv.bz2'. guix package: error: build of `/gnu/store/wca6ncmjf3lqc8xr68ghv3sll3z2pls1-python-funcparserlib-0.3.6.drv' failed rx@dell ~$ bzcat '/var/log/guix/drvs/wc/a6ncmjf3lqc8xr68ghv3sll3z2pls1-python-funcparserlib-0.3.6.drv.bz2' starting phase `set-SOURCE-DATE-EPOCH' phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds starting phase `set-paths' environment variable `PATH' set to `/gnu/store/f8s95qc6dfhl0r45m70hczw5zip0xjxq-python-wrapper-3.8.2/bin:/gnu/store/p3alwjb35hrsx044194sngg8y7gd5hzx-python-tox-3.20.0/bin:/gnu/store/v6f44zccwh9z5zk3pjlywjybbi8n2hjh-tar-1.32/bin:/gnu/store/ncydgq2znms5n1d2k5yqshhf58nsixwv-gzip-1.10/bin:/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8/bin:/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4/bin:/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38/bin:/gnu/store/n4n560pfvvw50a9369axw5vj5rrqfj1n-diffutils-3.7/bin:/gnu/store/cd5qf3kcnlq35p9k392pjdpdzpsnds70-patch-2.7.6/bin:/gnu/store/hic7snhayfl7m6cpfqqr73nmm19bpqkg-findutils-4.7.0/bin:/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1/bin:/gnu/store/ishk7fswcs4gkwcp8mh788z4mvvl9bxh-sed-4.8/bin:/gnu/store/bhs4rj58v8j1narb2454raan2ps38xd8-grep-3.4/bin:/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin:/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3/bin:/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin:/gnu/store/mpa04aq8lblbcviyxywxcsb1zbi0mf39-ld-wrapper-0/bin:/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/bin:/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/bin:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/sbin:/gnu/store/9w9jvy3bgjg4qaqmrij01nbppiccqr7c-python-3.8.2/bin:/gnu/store/3r3mnnkzd3yq2qj43kv9j9f9n34b9j0p-python-virtualenv-20.2.1/bin' environment variable `PYTHONPATH' set to `/gnu/store/p3alwjb35hrsx044194sngg8y7gd5hzx-python-tox-3.20.0/lib/python3.8/site-packages:/gnu/store/9w9jvy3bgjg4qaqmrij01nbppiccqr7c-python-3.8.2/lib/python3.8/site-packages:/gnu/store/3r3mnnkzd3yq2qj43kv9j9f9n34b9j0p-python-virtualenv-20.2.1/lib/python3.8/site-packages:/gnu/store/caia95dd5c2bm9qigp2am4fx9xfkfhpz-python-toml-0.10.2/lib/python3.8/site-packages:/gnu/store/hjmz8ymac939ribn7g3jkgms4dk2az3a-python-six-1.14.0/lib/python3.8/site-packages:/gnu/store/avj1ma4bvfjnw86pd9ys64899b627f0x-python-py-1.8.1/lib/python3.8/site-packages:/gnu/store/nqi6xqx8h2fxldi3xbigkc24wfzzsy5j-python-pluggy-0.13.1/lib/python3.8/site-packages:/gnu/store/5zfrihl2sg0svssmac0l06hyq6zjik8b-python-packaging-20.0/lib/python3.8/site-packages:/gnu/store/f5x2dl22lkrm9l6m8a9n1f61wjadzxz7-python-filelock-3.0.12/lib/python3.8/site-packages:/gnu/store/hnxx25dg0pz64ykpz4d3667v9iancq62-python-importlib-metadata-1.5.0/lib/python3.8/site-packages:/gnu/store/mypg42bass5n61liwyq7llrwla4w8bny-python-distlib-0.3.1/lib/python3.8/site-packages:/gnu/store/iw4nff8b53cf65brf5bsxx3j8pn37fk3-python-appdirs-1.4.3/lib/python3.8/site-packages:/gnu/store/69lzz2dp87f896843jj05mw5z4hd9my2-python-pyparsing-2.4.6/lib/python3.8/site-packages:/gnu/store/fsr8dqg8irjvxajilhq3qf2myin5l9cv-python-zipp-1.0.0/lib/python3.8/site-packages:/gnu/store/bpbpmqwx2zvrw2h5k8c8fwk91xmzfym3-python-more-itertools-8.2.0/lib/python3.8/site-packages' environment variable `BASH_LOADABLES_PATH' unset environment variable `C_INCLUDE_PATH' set to `/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8/include:/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4/include:/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38/include:/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1/include:/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3/include:/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/include:/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include:/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include:/gnu/store/9w9jvy3bgjg4qaqmrij01nbppiccqr7c-python-3.8.2/include:/gnu/store/gfapkk5c6hvl1d94m4sqnhn7f9l5gqyh-linux-libr
bug#50105: [core-updates] Python sitecustomize issue.
Hi again, Maxim Cournoyer writes: [...] > Is there a simple reproducer to test my fix? Would just building > current Glade and its test suite trigger it? OK, nevermind, I found that the test case was deleting the 'fix-tests' build phase from glade3, and building the package. I confirm the fix works! I'll send that patch series I've been talking about. Thanks, Maxim
bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64
On +2021-09-03 10:00:33 -0400, Simon South wrote: > Bengt Richter writes: > > A proper configurability, ISTM, would be preferable to any other form > > of more general filtering. > > I agree with you on the need to be cautious around modifying test cases > but I'm not sure I follow you otherwise. What would "proper > configurability" look like in this case? > > The change I'm proposing here narrows the two test cases so they test > only what appears to have been intended, i.e. that strace can capture > readlink(at) system calls and that it reports them in the format > expected by the developers. It does not affect other test cases or the > test suite as a whole. > > The obvious alternative would be to modify the test cases' expected > output to match what is actually generated, but this could have the side > effect of tying the package to Linux and perhaps to specific versions of > glibc. Well, that would be the point :) I.e., to move the customizations into .conf files and out of test-suite sources. > > That said I'm still not sure why this additional syscall is being made > in the first place, only that it appears to originate from glibc's > "_dl_get_origin" function[0]. If I build strace from source "manually" > the tests complete fine without modification. I presume the extra call > has to do with the fact Guix builds strace inside a container; does > anyone know how this could be affecting the way programs are loaded? > I did not realize there were mods to strace itself affecting this. I thought it was about somehow filtering its output to fool tests, sorry. With strace variants maybe "proper configurability" should have to consider strace versions also, to tune test expectations ;/ > -- > Simon South > si...@simonsouth.net > > [0] See e.g. glibc's sysdeps/unix/sysv/linux/dl-origin.c for the x86-64 > case, as well as "_dl_non_dynamic_init" in elf/dl-support.c, which > seems to be the only place it is called. -- Regards, Bengt Richter
bug#50360: Linphone symbolic link for liblinphone hampers debugging
Hello,
I was trying to get a good backtrace for a segfault in linphone-desktop
(see http://issues.guix.gnu.org/47641). So I added a debug output for
liblinphone, and did the following:
--8<---cut here---start->8---
./pre-inst-env guix environment --ad-hoc linphone-desktop \
linphone-desktop:debug liblinphone liblinphone:debug --no-grafts
--8<---cut here---end--->8---
The --no-grafts is to workaround http://issues.guix.gnu.org/48907.
Then I did the usual dance to get the GDB symbols resolved:
--8<---cut here---start->8---
export GDB_DEBUG_FILE_DIRECTORY=$GUIX_ENVIRONMENT/lib/debug
[env]$ cat $GUIX_ENVIRONMENT/bin/linphone
#!/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash
export
XDG_DATA_DIRS="$XDG_DATA_DIRS${XDG_DATA_DIRS:+:}/gnu/store/jlzdmlrmsrgxqj9yw1i1zy4lrf3r9d1n-linphone-desktop-4.2.5/share:/gnu/store/k4vz4pk664fz4mf1amdzvd7w7315wwr6-liblinphone-4.4.34/share"
export
QT_PLUGIN_PATH="/gnu/store/b90sxi7aphibx6amwqx2nqljjv0yp5wg-qtbase-5.15.2/lib/qt5/plugins:/gnu/store/5s66rhnjys6qq8hdff9sy3dzy40fgxji-qtdeclarative-5.15.2/lib/qt5/plugins:/gnu/store/11vb2q2kbi8aym0fx52h5inish61mzp6-qtsvg-5.15.2/lib/qt5/plugins${QT_PLUGIN_PATH:+:}$QT_PLUGIN_PATH"
export
QML2_IMPORT_PATH="/gnu/store/5s66rhnjys6qq8hdff9sy3dzy40fgxji-qtdeclarative-5.15.2/lib/qt5/qml:/gnu/store/r8rpn1jclizv7a6s7c3ngblanmn9v52i-qtgraphicaleffects-5.15.2/lib/qt5/qml:/gnu/store/3rasi4dmffay6mkxhmy2xwdl1pr46wvr-qtquickcontrols-5.15.2/lib/qt5/qml:/gnu/store/baanczaq0s2yqdq7812ydkjmvnk7jl1z-qtquickcontrols2-5.15.2/lib/qt5/qml${QML2_IMPORT_PATH:+:}$QML2_IMPORT_PATH"
exec -a "$0"
"/gnu/store/jlzdmlrmsrgxqj9yw1i1zy4lrf3r9d1n-linphone-desktop-4.2.5/bin/.linphone-real"
"$@"
# Copying the exports
[env]$ export
XDG_DATA_DIRS="$XDG_DATA_DIRS${XDG_DATA_DIRS:+:}/gnu/store/jlzdmlrmsrgxqj9yw1i1zy4lrf3r9d1n-linphone-desktop-4.2.5/share:/gnu/store/k4vz4pk664fz4mf1amdzvd7w7315wwr6-liblinphone-4.4.34/share"
export
QT_PLUGIN_PATH="/gnu/store/b90sxi7aphibx6amwqx2nqljjv0yp5wg-qtbase-5.15.2/lib/qt5/plugins:/gnu/store/5s66rhnjys6qq8hdff9sy3dzy40fgxji-qtdeclarative-5.15.2/lib/qt5/plugins:/gnu/store/11vb2q2kbi8aym0fx52h5inish61mzp6-qtsvg-5.15.2/lib/qt5/plugins${QT_PLUGIN_PATH:+:}$QT_PLUGIN_PATH"
export
QML2_IMPORT_PATH="/gnu/store/5s66rhnjys6qq8hdff9sy3dzy40fgxji-qtdeclarative-5.15.2/lib/qt5/qml:/gnu/store/r8rpn1jclizv7a6s7c3ngblanmn9v52i-qtgraphicaleffects-5.15.2/lib/qt5/qml:/gnu/store/3rasi4dmffay6mkxhmy2xwdl1pr46wvr-qtquickcontrols-5.15.2/lib/qt5/qml:/gnu/store/baanczaq0s2yqdq7812ydkjmvnk7jl1z-qtquickcontrols2-5.15.2/lib/qt5/qml${QML2_IMPORT_PATH:+:}$QML2_IMPORT_PATH"
# Then invoking the actual binary
[env]$ gdb --args $GUIX_ENVIRONMENT/bin/.linphone-real --verbose
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
bug#50105: [core-updates] Python sitecustomize issue.
Hello Maxim, > OK, nevermind, I found that the test case was deleting the 'fix-tests' > build phase from glade3, and building the package. I confirm the fix > works! Great, that's exactly what I was trying to test but you beat me to it :). I'll be afk for a month so I won't be able to confirm that I have the same result locally. However, this fix looks good to me. Thanks, Mathieu
bug#50346: core-updates-frozen: strace 5.13 fails "make check" on AArch64
Bengt Richter writes: > Well, that would be the point :) > I.e., to move the customizations into .conf files and out of > test-suite sources. Given the limited flexibility of the test harness I'm not sure there's a solution that doesn't involve modifying the source, but on reflection you're right: We actually _do_ expect the test results to differ from what is provided in the source bundle, so a better solution would be to update the tests to reflect this rather than to change how they're run. I'll put together a patch that does that. Incidentally, the reason for the test failures appears to be the additional call to _dl_get_origin() added to glibc by the "glib-dl-cache" patch in commit 52564e9, which produces an additional readlink/readlinkat syscall strace's test driver isn't expecting. But this additional call _is_ expected on Guix systems, so the test cases ought to be modified to match. -- Simon South si...@simonsouth.net
