On 4/27/26 12:49, Andreas Enge wrote:
Am Sun, Apr 26, 2026 at 10:59:20PM +0200 schrieb Hugo Buddelmeijer:
For reference, I think this line is the first error in the 2026-04-24
14:46:15 run:
https://data.qa.guix.gnu.org/job/19775
▶ 201/389 /filenamecompleter/basic -
GLib-GIO:ERROR:../glib-2.86.0/gio/tests/filenamecompleter.c:83:run_test_cases:
assertion failed (all_expected_completions == all_results_completions):
first differing element at index 0:
"/tmp/guix-build-glib-2.86.0.drv-0/test_filenamecompleter_89EGO3/filenamecompleter/basic/.dirs/home/file_1"
does not equal
"/tmp/guix-build-glib-2.86.0.drv-0/test_filenamecompleter_89EGO3/filenamecompleter/basic/.dirs/home/folder_1/"
FAIL
This is the derivation
/gnu/store/mn9ybb131n0kbhnhyjz7x42brvrm6v8s-glib-2.86.0.drv
which I have built locally; and I think it has gone through with the
latest evaluation of the python-team branch:
https://ci.guix.gnu.org/eval/2160600/log/raw
Ah yes, I was looking at QA:
https://data.qa.guix.gnu.org/job/19775
Because I find the "blocking-builds" the most useful interface to figure
out the most important package to fix.
Is it possible to restart the data.qa build as well?
Towards the end I see lots of
marked build of
/gnu/store/lcp0wbqhms4kxbilkfzzjs0x4fxm13jj-github-cli-2.83.2.drv as
'failed-dependency'
but do not see which dependency is meant.
I don't know what dependency they mean either, I'm trying to build some
locally. But I don't understand why those packages are being build at
all. Are they all necessary for the evaluation?
They are quite expensive, e.g. github-cli is marked as
'failed-dependency', but that is a rust package and thus requires the
entire rust toolchain to be built. So it will take days to do so.
And then there is the big blog
uncaught throw to %exception: (#<&inferior-exception arguments: (%exception #<inferior-object #<&formatted-message format: "failed to determine which compiler is used\n" arguments: ()>>) inferior: #<inferior pipe (0 1 1) 7f5af3badc40> stack: ((#f ("ice-9/boot-9.scm" 1830 13)) (raise-exception
("ice-9/boot-9.scm" 1702 22)) (raise-exception ("ice-9/boot-9.scm" 1704 22)) (lower* ("guix/transformations.scm" 599 8)) (thunk ("guix/packages.scm" 1829 22)) (package->bag ("guix/packages.scm" 1732 16)) (#f ("guix/packages.scm" 1462 39)) (#f ("guix/memoization.scm" 100 0))
(supported-package? ("guix/packages.scm" 1484 17)) (package->job ("gnu/ci.scm" 409 11)) (filter-map ("srfi/srfi-1.scm" 806 23)) (jobs ("gnu/ci.scm" 424 2)) (map1 ("srfi/srfi-1.scm" 701 17)) (map1 ("srfi/srfi-1.scm" 701 29)) (map1 ("srfi/srfi-1.scm" 701 29)) (map1
("srfi/srfi-1.scm" 701 29)) (map1 ("srfi/srfi-1.scm" 701 29)) (map1 ("srfi/srfi-1.scm" 701 29)) (map1 ("srfi/srfi-1.scm" 701 29)) (map1 ("srfi/srfi-1.scm" 701 29)) (map1 ("srfi/srfi-1.scm" 701 29)) (map1 ("srfi/srfi-1.scm" 701 29)) (map1 ("srfi/
...
over pages and pages of output, which is completely mysterious to me.
Is this the actual error that prevents the evaluation?
I don't understand the "701 29"s, I thought those might be line/column
numbers, but they seem not. There is a "map1" set with 'let' in the
definition of "map" in srfi-1.scm though. This seems to be the looping
part of the map; that is, map1 calls itself recursively.
I can imagine that it is looping over the packages, as that is kinda the
thing that the evaluation does. So if there are 30k packages, there
should be in the order of 30k repetitions there I guess.
(It seems this is tail call recursion, I thought this would mean that
there would not be such a huge stack trace, but I probably don't
understand tail call recursion well enough.)
My impression is that there has been progress, and that rebasing would
be an option (but I am weary of the rust crate conflicts; I think there
have been removals in master, which my standard conflict resolution
approach would risk adding back).
We need to resolve those conflicts at some point anyway right? I
wouldn't know how to do so though.
Hugo
