IRC channel logs
2026-07-13.log
back to list of logs
<jresich>is bordeaux down in the KiB/s today for anyone else? <jresich>is there a way to tell guix "build this package (set), but substitute only the non-leaf nodes"? <jresich>i have a really slow connection and i suspect it'd be faster to build qtbase@6's 352mib of debug info than to download it at 30kib/s <jresich>btw, is that intentional? the rest of qtbase@6 is only ~13mib <psycotica0>I don't know the full answer, but it shouldn't substitute anything it already has, so you could `guix build --no-substitutes` the ones you don't want to download, then when that's done, you should be able to use a normal `guix build` for the rest and it should use the one it built. <ieure>psycotica0, That'll build all the dependents of qtbase, though. <psycotica0>Oh.. or maybe you actually want `guix build -D PACKAGE` which builds the dependencies. <psycotica0>Yeah, I think I missed that part. So in that case the two phase would be normal `-D`, then `--no-substitutes` for the main package once that's done? <gabber>how can i run `gnu/tests/mail.scm`? is there a `make check` like equivalent to run these? my attempts all return `0 tests run` <sham1>Have you look at what's inside mail.scm <sham1>Okay, I'll be a bit more helpful. You need to load the gnu/tests/mail.scm into a guile repl (or more likely the guix repl) and then do stuff like (run-opensmtpd-test) <gabber>sham1: thanks for the hint. so we do not have facilities to run these tests automatically? <dariqq>gabber: 'make check-system TESTS="opensmtpd ...."' <dariqq>the name is the name field of the sytem-test record <gabber>is it possible we lack adequate documentation for that mechanism or did i just miss it ? <dariqq>There is a bit in (info "(guix) Running the test suite") but it just says that it exists <gabber>I've seen that bit but was somewhat puzzled on how to run which tests. I was not sure whether the ones in `gnu/tests` are *also* system tests, not just the ones in `tests/`. Guess I'll open an issue (: <dariqq>i think in tests/ are the normal tests (make check) and gnu/tests are the system tests <gabber>dariqq: and by `normal' you mean unit- and module- tests? <dariqq>not sure what you mean by moduletests <gabber>unit tests testing the smallest units (simpler functions), module tests bigger functions, system tests whole systems and e2e tests the whole thing. at least that's how terminology is used in functional safety applications (V-model) <dariqq>`make check` is using tests/ and `make system-check` is using gnu/tests. I dont know how the system-test term as used in guix maps to the usage in other areas <PotentialUser-23>Hello, normal guix pull tries to build guile-3.0.11 on aarch64 and fails. This prevents every single guix pull <gabber>if it fails to build there can not be a substitute <gabber>is there a bug report already (on Codeberg)? <gabber>would you mind checking (and opening one if necessary)? <PotentialUser-23>I see someone reported it on x86, so it might be not an aarch64 problem. But I tried it 4 times already, so retry is not a fix <sham1>That seems like it'd be very irritating to debug <sham1>Since these apparently also affect AMD64, no pulling for me :( <PotentialUser-23>it fails in the check phase of guile. Maybe a concurrency or timeout problem <Saorsa>For some reason, DNS isn't working for me on Guix through home-manager with resolv.conf only containing "#placeholder". <Saorsa>Was wondering where anyone here could lend me a hand to fix it. <identity>Saorsa: did you read the --news when you guix pulled? <Saorsa>Can't seem to pull it up as it can't find the previous generation on my system. <Saorsa>Can you fill me in one what it said? <identity>Saorsa: you can probably find the entry at ~/.cache/guix/checkouts/…/etc/news.scm:217, but in short, Openresolv updated and you need to rm /etc/resolv.conf&&herd restart NetworkManager as root <human_equivalent>I've been trying to do a system reconfigure for a week now using --no-substitutes, but it's not too easy. The latest attempt is currently building the eleventh version of rust (1.75.0 to 1.85.1). It's a minimal-ish desktop system, with the nonfree kernel. Any advice? I guess `guix graph -t package rust linux-libre` explains it (for the libre kernel) but.. yeah. <samplet>FWIW, I ended up doing a ‘guix pull’ with ‘--no-substitutes’, and then manually started that daemon to update the rest of my system with (apparently safe) substitutes. <samplet>After giving up trying to compile my own system. (And idly threatening to become a NetBSD user or some such.) <samplet>ACTION has never tried compiling NetBSD, but hopes at least that would still be feasible in 2026 <human_equivalent>The blog post doesn't say that's the way to do it tho, does it? (just checking so I haven't misunderstood something) <samplet>I used the check script to vet my approach and it passed. <human_equivalent>I'm probably going to keep trying for a few days, I don't mind putting some time into this as I kind of want this to be a reliable way to set up the system anyway. <identity>samplet: i tried threatening to become a NetBSD user, but neither the threats nor becoming a NetBSD user worked (graphics were utterly broken on every machine i tried, somehow). i recommend threatening to become a Chimera user instead <samplet>I wonder if it’s feasible to build Chimera on regular person hardware without too much stress. I guess they wouldn’t try to bootstrap Rust, so that would go faster (but it’s not very satisfying). <identity>samplet: depends on what is implied by «regular person hardware», but building Chimera is probably feasible <vermiculous>I've edited ~/.cache/guix/checkouts/[hash]/gnu/packages/python-xyz.scm to include "test_interrupt" in the list of tests to exclude. Using guix build allows python-pexpect to complete but is there a way to get system reconfigure to use this modified file? <vermiculous>To include "test_interrupt" in the list of tests to exclude for python-pexpect * <samplet>Five months ago mrustc learned to compile Rust 1.90, so things will much improve when that is integrated into Guix. <identity>vermiculous: you probably should not touch that and instead pull from a local repository <civodul>📢 deliberation on GCD 008 has started <vermiculous>identity: theoretically, could I build it from the cached file without having to clone guix? <identity>vermiculous: theoretically: yes; practically: i expect everything to go wrong <ieure>vermiculous, Is python-pexpect a leaf package? <ieure>It seems like something that another package would depend on. <vermiculous>I'm not sure. I just know that commenting out calibre from my home packages stops it from being pulled it and allows me to reconfigure my home. I'm not sure what is pulling it in from the system level. Maybe searxng, but I'm using a docker image in a rootless-podman-service so I'm not sure if that has to pull in dependencies or if the docker image contains everything it needs. I never used Docker before Guix. I just started in order to <vermiculous>I also, obviously, didn't have this issue before disabling substitutes. After the initial upgrade is it fine to re-enable substitutes? <ieure>vermiculous, Okay, it is not a leaf package, it's a dependent of calibre. Your best option is to create a package variant of python-pexpect in you home configuration, then create a variant of calibre which uses the fixed python-pexpect variant. <old>anybody has a one line or .envrc for entering an environment to develop the linux kernel? <PotentialUser-23>The failing pull was due to a failing tests of guile 3.0.11 related to sparse files. Disabling tmpfs helped on Fedora <ieure>vermiculous, OCI images ("docker images") aren't going to be referencing Guix store items, so it is not that. <vermiculous>ieure: It's a dependent of Calibre in Guix home. As I said, I'm not sure what is pulling it in with Guix system. I submitted a PR and commented out Calibre for now but I'd like to be able to reconfigure my Guix system. <vermiculous>Is there a command that will tell me which packages depend on X? <vermiculous>Also, is it all right to re-enable substitutions again? <ieure>vermiculous, `guix gc --referrers some-package'. <ieure>vermiculous, If an input fails to build, the leaf package that needs it should be in the output where it says what stuff it's building. <vermiculous> ~ → % guix gc --referrers /gnu/store/2h12cbn5ipbh3144flfmig0z5d0gdlv3-python-pexpect-4.9.0.drv <vermiculous>/gnu/store/2mllrhrf5lwhgw41h5s14mb32d2kqf71-python-pytest-timeout-2.4.0.drv <vermiculous>Aptly, since the tests times out after 3,600 seconds of silence. ':\ <csantosb>Ey, I'm trying to fix a couple of "TCL readline header/library: NOT FOUND" warnings, do we have this in Guix ? <csantosb>There is nothing below tcl, tcllib, and guix locate returns nothing <gabber>i rebased a patch (a guile package addition). is it normal that at the start of many phases it says: "sh: warning: setlocale: LC_ALL: cannot change locale (C.UTF-8): No such file or directory"? <jresich>why does deleting a generation trigger substitution? <lavandula>howdy all does anyone on go-team know how to resolve recursive dependency cycles? im trying to add crowdsec, and it depends on go-github-com-google-winbox which depends on go-github-com-google-glazier which depends on winbox again. does anyone know how i can resolve this? do i need to put them in separate files or something? <psycotica0>It's my understanding that guix holds all packages in memory as a tree, because package definitions are code, and so I _think_ that means there can be no cycles. <lavandula>hmm does than mean this is a problem that has to be resolved upstream? alternatively i suppose because guix isnt on windows i could just patch out that package tree...