IRC channel logs
2025-08-03.log
back to list of logs
<vhns>has anyone comeup with way to offload `make` and such under the guix source tree through guix-offload? or distcc? <vhns>it seems that the config generator is expecting an alist of lists and not an alist <vhns>I'm not sure if I should try to fix the documentation or the code <vhns>That is, such that the code matches the documentation in that the user must provide a pair or make it such that the documentation tells the user to just provide a list <ieure>vhns, One of is confused. Your working configuration has the exact (simple-service) the issue says doesn't work. And I don't know what you mean by "alist of lists." <vhns>ieure: my example is no the exact simple-service <vhns>notice the difference in the (mapping ... line <vhns>one provides a pair (a . b) <vhns>while the other is just (a b) <vhns>you can even try my config with `guix system vm` vs his <lockbox____>vhns: if you guix build the source tree then your guix offload can pick it up, the blocker for compile times here tho (on my builds where I make -j40) is that the guile compilation has a hand rolled attempt at batching compile jobs which waits until the entire batch is complete before starting the next aiui. Though if it ain't broke... <lockbox____>I keep having a pipe dream of using meson+ninja to do the guilec jobs for guix but never having the time to poc it out <Ribby_>Hi, is it normal to see a purple screen when installing guix? Tried it with 64bit version, but now with 32bit version. I know that 32bit version will be much slower. I am thinking to wait for 40+ minutes to a few hours? <Ribby_>I would like to know what would the usage size be after default guix os installation. Trying 32bit on a 32bit machine. <Ribby_>I almost forgot, installing Guix 32bit with a DVD-ROM. <Ribby_>Is it me, or that Guix installation is just better off on a 64bit machine, regardless of its 32 or 64 bit version? <gilaro>I think something is “broken” in OpenWrt Buildroot when using Guix. <csantosb>Hello Guix ! What is the right way to `#:bootstrap-scripts #~("autogen.sh" "autogen-common.sh")` ? <csantosb>This is obviously not accepted "Unrecognized keyword: #:bootstrap-scripts" <ekaitz>csantosb: take a look to gnu-build-system did you? <ekaitz>it should be somehow accepted, the bootstrap phase accepts that keyword <m4xxed>Hey people, anyone else had issues with `python-pyyaml@5.4.1` ? I cannot even start `guix shell python-pyyaml@5.4.1` and I cannot figure out which of my packages pulls in this older version of `python-pyyaml` as a dependency.... <ekaitz>csantosb: maybe some other phase you have you don't #:allow-other-keys <ekaitz>m4xxed: `guix shell python python-pyyaml -- python -c "import yaml"` works? <m4xxed>ekaitz but using `python-pyyaml@5.4.1` instead fails: "1 dependencies couldn't be built" <m4xxed>ekaitz: don't pull in that specific version in my config and cannot figure out which of my included packages pulls this older version in <ekaitz>m4xxed: that was part of other conversation, we are multitasking here <m4xxed>Ah my bad, sorry :D not used to IRC yet <ekaitz>m4xxed: the problem you have is the python-pyyaml@5.4.1 is broken, it doesn't pass the `sanity-check` phase <ekaitz>ModuleNotFoundError: No module named '_yaml' <ekaitz>csantosb: hmmmm now you need to find the phase that doesn't accept that key and fix it i believe <ekaitz>csantosb: or give it a list, btw <ekaitz>csantosb: did you try with #:bootstrap-scripts #~(list "autogen.sh" "autogen-common.sh") <ekaitz>m4xxed: great! so we are already working on ti <m4xxed>ekaitz: yep, and I can dodge that bullet by removing `docker` from my config for now (which apparently pulls in `python-pyyaml-5` ) since I don't use it currently. Thank you very much for your help :) <csantosb>ekaitz: Same, "Unrecognized keyword: #:bootstrap-scripts" ... thing is I have no phases, only a list of arguments <csantosb>Maybe because I'm using glib-or-gtk-build-system ? <ekaitz>csantosb: you have the phases, but you don't see them <ekaitz>oh i didn't think about that, so yes, probably <ekaitz>csantosb: look in guix/build/... <ekaitz>those are the buildsystems, and they define the phases <ekaitz>how familiar are you with that? i have time to explain <csantosb>phases are simple to understand; just check the code <csantosb>What's difficult with guix is to understand who, where and when calls these phases, from which context, etc. <ekaitz>csantosb: think about this thing in two parts guix/build-system/* defines how to convert a package to a bag, that is later processed further <ekaitz>csantosb: the second part is guix/build/* which is the guile code that is imported and run for the package to be built <luca>Hi, libesmtp fails to build right now (gcc 14 issue?), and this can be fixed with a patch that is already in upstream master. Is this something that should be backported to guix, or is it better to wait for upstream to release a new version? <csantosb>gabber: Would you mind having a quick look at #1273 ? I think it is ready now. <identity>luca: if there was no major changes between the last release and the commit fixing the build, then updating to that commit seems more sensible than backporting the fix, to me <luca>so maybe I should take only the bare minimum to fix the build? <luca>(or leave it as it is of course, that's also valid) <ekaitz>PabloFerreira: there's people from brazil here often, but maybe not now <Kolev>Thinking of switching from Guix to Ansible for my home server. <Kolev>Can't figure out Radicale on Guix. <sham1>I mean, I suppose that in some sense Ansible is "easier" due to it being used more. I dunno, I'd figure that Guix is quite orthogonal to Ansible <nikolar>ansible is a way to manage running commands on multiple servers <nikolar>it's indeed quite orthogonal to guix <sham1>Yeah. Like I suppose that Guix can also be used to orchestrate server stuff, but in that case it'd be more orchestrating your deployments than anything <sham1>So if anything, I'd compare Guix more to Terraform/OpenTofu in that sense, and even then you can't *really* define your infrastructure in Guix except in very specific cases <Kolev>I want my server to be reproducible but I don't like how foreign Guix is. <Kolev>Documentation and help with Guix is sparse. <sham1>In that sense it's very similar to the Nix community (although IIRC Guix has better docs, still) where you're expected to get familiar with the system and basically figure out things for yourself and start contributing to the system <sham1>The system being highly hackable makes this approach quite "obvious" <Kolev>I didn't know you had to be a hacker to use Guix. I thought the hacking was optional. <sham1>Yeah. It's only for hackers the same way that a car that you can maintain yourself is only for mechanics <sham1>Like yeah, the hackable approach of the system does *push* people towards experimenting and playing around with the system (configuration being done in a general-purpose programming language helps with that) but it's not a pre-requisite of using guix <ieure>Kolev, I don't think your problems with radicale on Guix are really Guix-specific.