I've been having trouble with curl on aarch64 again. Looking at this snippet from the build log: test 1477...[Verify that error codes in headers and libcurl-errors.3 are in sync] 1477: stdout FAILED:
I had berlin build for powerpc64le and that went without any problems. Locally I built for riscv64 and powerpc and those both built fine. I ran into an issue locally with curl on aarch64 and test 147
Hi, It is not a bug of ’guix show’ because ’guix show’ accesses to the fields of the package record. And Clément’s patch is an “abuse” of the G-expressions machinery. :-) Well, this is
Hi Clément, Right, it uses gexps but I think here the better and more explicit style would be to use inputs/native-inputs. Then instead of referencing directly like #$<package-variable-name> use thi
I agree about this. When I packaged passff-host locally some time ago, I saw it has a runtime dependency on python and also needs to be able to find the pass binary. I've attached the bare (unfinishe
• Gexps carry information about the packages or derivations they refer to, and these dependencies are automatically added as inputs to the build processes that use them. No it wasn't.
This passff-host package looks a bit odd to me, one thing to mention is that guix show says it has no dependencies, but I don't think that's correct: ./pre-inst-env guix show passff-host name: passff
I will note that the only big-endian architecture which we "support" is 32-bit powerpc, so we don't have to worry that much about wrong endianness. -- Efraim Flashner <efraim@flashner.co.il> רנשל
Hi Mathieu, [...] The build-systems renpy, dub is listed in “refuse“ but not then in Cross-compilation KO. Is it expected? The build-system asdf is listed as refuse but appears in the list Cross-
Hi, maybe build failures should be limited to certain platforms that can cause this treatment, such as (32-bit) x86, x86-64 and arm-64, so build failures on other platforms would not make a package r
Yes, honestly I only look for build failures from bug reports, not from CI if i'm not doing a "request for merge" from another branch. I found the dashboard inconvenient to use, it show failures for
Thanks for investigating further. There's maybe a secondary issue here about why changing the substitutibility of a package affects it's outputs. That doesn't make much sense to me, but maybe there's
I looked into it more. First I ran on master: './pre-inst-env guix build --no-grafts --system=armhf-linux openblas -d' /gnu/store/whi4yhiw2b0c0i3n6l8s0qfcphkvbzg4-openblas-0.3.20.drv Then I locally r
Ok, so the documentation does mention "rebuilding", and I do see that indeed ci.guix.gnu.org doesn't build not substitutable things. Although I think it doesn't apply recursively. Take qjson, guix re
It's not that it's triggered rebuilds, but that it's triggered builds. It's also triggered builds on powerpc64le and riscv64. Before any package which had openblas as a transitive dependency wasn't b
I've been looking at why armhf-linux substitute availability has been dropping recently, and I think this change triggered a lot of rebuilds. Could this have gone to core-updates? → guix refresh -l
Hi Andreas, I like your above ideas; I'd like to add: - I'd make the team branches permanent; e.g. the 'gnome-team' branch would always exist, and get synced periodically to master (when enough built
Hello, indeed someone™ should update the documentation to describe the new process. Probably we should agree on one before doing that as well... In principle all big updates should go through a fea
Dear Andreas and fellow Guix-ers, As others have said, a big thank you to you once again for leading the charge! Much appreciated! I've just submitted <https://issues.guix.gnu.org/63139> which does a