IRC channel logs
2026-11-12.log
back to list of logs
<cizra>mmkay, thanks, this gives me hope! <bjc>i use a tmpfs root on both systems, which makes it pretty clean. ymmv if you have the same root for everything <ieure>Uh, huh. guix master commit 94bbecec92475689df5b9056720795d40e0198a3 is failing to build for me: <ieure>make[2]: *** No rule to make target 'gnu/packages/patches/libvpx-CVE-2026-2447.patch', needed by 'all-am'. Stop. <ieure>Hmm, I think I have some stale build artifacts. <mra>which, i guess, is distinct from the package used when i as a user just run the "guix" command <mra>how does one go about changing the latter? <mra>unless i've now managed to double-misunderstand the docs <ieure>mra, You probably need to `guix pull -C channels.scm' with a channel definition that points at a fork. What changes are you making? <mra>ieure: I'm trying to build a custom guix which includes hako's zfs patches and use it as my user's guix <mra>it's not too hard to build a patched guix package, but I can't seem to get it to act as my user guide command <ieure>mra, A user's `guix' comes from its own profile with its own generations. You have to point `guix pull' at a different source if you want to run a fork. <ieure>mra, The guix command's current profile generation is in ~/.config/guix/current <mra>hm, interesting. it's orthogonal to system configuration, in a sense? <ieure>Yes, it has to be, otherwise it would be impossible to update the system. <mra>right, so what "guix pull" does is kind of analogous to what something like "guix system reconfigure" does, but acting on the guix profile instead of the system profile <ieure>mra, These things use the same mechanism, yes. As does the per-user-profile (what `guix install' and co. use), and Guix Home profiles. <mra>okay, that is very cool! that clarifies a lot in my mind. would I be correct to say that the reason that the "system guix" can be configured within the system configuration is because it's only responsible for running the daemon which builds the packages <mra>whereas guix pull updates the actual package definitions <ieure>Yes. And package definitions are built into the `guix' <ieure>Profiles are everywhere in Guix when you know where to look. I think the manual could do a better job discussing them. <ieure>`guix shell' creates a profile for the packages you specify, for example. <mra>that makes sense! i think i can make this work on my system, just running into an authentication issue <mra>guix system reconfigure says that i can just pass `--disable-authentication', but it doesn't actually accept that argument? <jlicht>ieure: did bootstrap, configure, make work for you? I changed patch file handling recently, hope I didn’t break anything <bytesurfer>but then, we need to rewrite it to work with hurd <sham1>We'd also probably want to rewrite it in Scheme anyhow <sham1>Although I think this kind of thing should be doable with Plymouth <stampede_>can anyone else build maturin? build is failing over here <futurile>stampede_: I can see it build 1.8.1 in May - but it also seems to be failing on some other branches at the moment <stampede_>well that's odd. I am trying to update an unrelated package (noctalia-shell) but build is failing because maturin fails to build <csantosb>successfully built /gnu/store/5772k3jk412mw7ywf2vpr15zh2arpxbb-maturin-1.15.0.drv <csantosb>/gnu/store/f21qwqx9xr3ydy0lzva7917vhr1jwhvb-maturin-1.15.0 <csantosb>I did a `./pre-inst-env guix build --no-grafts --check maturin` in current master <stampede_>hmm, there was a recent change to local.mk and patches or smth, do i have to rerun ./configure? <stampede`>that did not fix it. `./pre-inst-env guix build maturin` doesn't work, whether with --no-grafts or not. <stampede`>what the... so apparently guix build is building 1.11 instead of 1.15 even though i just did guix and make, seems it was an issue with stale cache cuz i ran git restore-mtime a while ago. <futurile>stampede`: do you definitely have the 1.15 in your checkout (just making sure) <stampede`>when i run ./pre-inst-env guix build it starts building 1.11.5 instead of 1.15 <stampede`>building /gnu/store/5kqb2yfc26a12nx3lizf9lvlcrkdv844-maturin-1.11.5.tar.zst.drv... <stampede`>and yes futurile i have it on my checkout, i just did git pull <graywolf>stampede`: you can try ./pre-inst-env guix edit maturin <stampede`>this is honestly weird, because that maturin update is a while ago, and i wasn't even using guix back then <graywolf>to make sure the right package is picked up <stampede`>yeah graywolf i have it open in my code editor and it's 1.15 <sneek>civodul, you have 3 messages! <sneek>civodul, jlicht says: I don't really understand how, but the suspicious change I've seen recently is that we clear the "object cache"(?) due to the transformations <sneek>civodul, jlicht says: could it be that it was always broken, but clearing the cache allows us to (sometimes) see the breakage? <graywolf>Hello :) the issue on the package cache is an interesting one to follow; keeps reminding me that some things are just beyond me :D <civodul>i’m so grateful jlicht found the culprit! <graywolf>civodul: Governance question: People are voting with "I support" etc. on Codeberg, does that actually cast a valid vote? <graywolf>Reading thought GCD001 I do not think so, but you seem like a qualified person to know for sure. <csantosb>graywolf: The "patch-tracking entry of the GCD" refers both to the mail list, or the codeberg pr. <graywolf>That is really not obvious from "The deliberation period starts when the authors publish a final version of the GCD at info-guix@gnu.org." <civodul>clearly, we should have updated GCD 001 to change references to Debbugs <civodul>like all things governance related in this project :-)