IRC channel logs
2025-04-30.log
back to list of logs
<juanpabl`>Hi everyone, I'm having some troubles with icons on guix (installed as a full system). They look broken in emacs and browser (e.g emojis, emacs icons like warnings, chinese characters, etc.) Am I missing a package to support icons? <lechner>Hi, how may I build files from gexps in the REPL again? I thought it was ,build but that's not so <lechner>juanpabl` / do you have emacs-nerd-icons installed? <apteryx>Tadhgmister re python and cross compilation, I had enabled that in a patch series, but haven't revisited it since (it's tangled-up/blocked with a contentious change) <apteryx>sneek: later tell Tadhgmister it was bug#60847 <apteryx>Kabouik: I haven't had issues with my Btrfs file system, but it strengthened by being in a RAID 1, so it can self-heal if only one copy gets corrupted. <juanpabl`>lechner: no I will check the icons you're suggesting <apteryx>it looks like shepherd is holding logs of services even when not using a log file? (e.g. 'herd status spice-vdagentd') <apteryx>I don't see these logs in /var/log/messages; do they go somewhere else? <apteryx>nevermind, they *are* in /var/log/messages, my grep had a typo <tom2342342311>I'm confused by what it means for a service to be "disabled". I had set up `hostapd-service-type` in my `config.scm` and reconfigured, but it failed to start because of a config error. I fixed the error and reconfigured, but now it looks like the service is permanently disabled and herd won't try starting it (with no errors in the logs): <hako>tom2342342311: herd enable ... && herd start ... <apteryx>are there any other elogind-based distributions to try? <jA_cOp>I think Void Linux uses both elogind and eudev? <sham1>You can configure Gentoo to do that as well <apteryx>something I can download and run in a VM <apteryx>jA_cOp: managed to install Void Linux with virt-manager <apteryx>they are using the same eudev 3.2.14 as us; it'll be a good test <jA_cOp>neat :) IIRC it can be pretty minimal <apteryx>strangely our eudev service doesn't detect CDROMs or DVDROMs <apteryx>while every other OSes print a couple line like: KERNEL[2401.365251] change /devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sr0 (block) <apteryx>including Void Linux, which uses the same software <jA_cOp>huh. Well, I have both Guix and Void systems, but I don't have any CD or DVD drives right now to help test <jA_cOp>oh, but, I guess you can test that in qemu/libvirt <apteryx>that's why I'm in a VM :-) it's easy to attach a .iso to a virtual CDROM and check things <apteryx>the issue I'm investigating is this old bug#35584 <jA_cOp>I'm not very familiar with the udev/kernel separation, but would it be worth testing with the nongnu kernel to narrow it down? <apteryx>jA_cOp: it looks like the kernel sr_mod is not being loaded on Guix System <apteryx>which is responsible for handling the cdrom/dvdrom devices <apteryx>I see it's there on Void Linux with lsmod | grep sr_mod <apteryx>looks fine, but our cdrom support is builtin, why that of void linux is built as a module, that explains why we don't see it in lsmod <apteryx>fedora also has it builtin and it works there <apteryx>lechner: hi! do you know if the 'udevadm' command behaves normally on Guix System post the recent fixes? I'm trying to use 'udevadm monitor' and it prints nothing, I'm wondering perhaps it's just not working on Guix System. <ZhaoM>never mind, 'wget -r --no-parent' is what I need <PotentialUser-16>`guix pull` often gives me an http status code: 502 for git.savannah.gnu.org. Could someone try to guess what is not working right? <cbaines>There's not really a need to guess, the problem is with git.savannah.gnu.org <PotentialUser-16>"Bad gateway" is quite generic to me. I could be on my ISP. I did not want to assume the problem was at the other end. <Kabouik>PotentialUser-16, you could alter your channels configuration at least temporarily to use the mirror. Here's what I did (I don't use %default-channels, I directly listed the guix one so replacing it with the mirror is straightforward): https://0x0.st/8WRs.txt <Kabouik>Maybe there are better ways to use mirrors that I don't know of, primarily trying the main one, and falling back to the mirror. Not sure. <cbaines>I'm pretty sure this 502 is coming from the NGinx in front of cgit on git.savannah.gnu.org, so it shouldn't be anything to do with your ISP <PotentialUser-16>Kabouik I know very little about Guix, but I see benefits in providing a list of servers. It could fall back to the next one, if one is mentioned. It could do parallel operations when possible. And we could add a shuffle operation to the list to spread the load. Oh, the nice things of configuration as code! <PotentialUser-16>There is a `guix gc --delete-generations` and a `guix pull --delete-generations`, and the argument they receive are not the same. Is there any other difference? Why have two? <solstag>PotentialUser-16: `pull` operates on the current profile ; `gc` will operate on all reacheable profiles. <solstag>PotentialUser-16: there's also `package --delete-generations`, which lets you specify which profile to operate on. <PotentialUser-16>solstag Hmm... I see... So, when I run `guix pull`, what it downloads and updates is restricted to that profile only? And if I change profile and run it again, does it download everything again or does it re-use what is in the store? <tae>What/where is Guix's dependency manager? Some comments say that each package has to be its own dependency manager. Is that correct? Guix doesn't have/need something like PubGrub? <PotentialUser-16>If I want to run some scripts at log-in (e.g., setting the screen disposition and brightness, for example), what file should I edit? <azval>whats the algorithm behind `guix hash` by default ? I tried sha256 and base32 but it didnt yield the same result <solstag>potatoespotatoes: running guix pull only modifies the current guix, not any packages, so this will rarely make use of the store; but yes, operations including guix pull check the store for existing outputs. <identity>azval: the --help output says nix-base32 (not base32) <solstag>PotentialUser-16: sorry my previous message was meant for you ^ not potatoespotatoes. <apteryx>andreas-e: thanks for the tidying of the debbugs backlog <solstag>PotentialUser-16: however, note that the same package version can correspond to different items in the store, and therefore multiple builds/substitutes, if any detail of the package implementation or of its dependencies changed. <tae>azval: It's nix-base32, which is "0123456789abcdfghijklmnpqrsvwxyz". <PotentialUser-16>solstag I assume you mean, for example, the "dependencies or package changed" I see when I run the `guix package --upgrade`, for example. <azval>oooh ok that makese more sense xD <solstag>tae: There is no 'dependency manager' in the sense of usual distros because there is nothing to manage about the dependencies. Every dependency is explicitly specified in a package's formula using Guile's module loading logic. <Kabouik>PotentialUser-16: Re: running scripts at log-in: unless you change WM/DE often, I guess you could execute your scripts when your DE starts. For instance in Sway, I just added the script executions in my Sway config file. If you need something more complex. I'm no Guix guru though. <tae>solstag: OK, so if I say (propagated-inputs (list python-numpy python-pandas)), how does it figure out versions? <solstag>tae: in other words, there is no "version of this package", there is only the "version of Guix" you're running, which contains all the formulas for all the packages and their explicit relationships. <tae>So if I upgrade Guix, then my packages will defer to the newly pulled Guix? In other words, python-numpy and python-pandas must be there in main? <Kabouik>s/If you need something more complex.//. I was going to suggest services or cron jobs there but I wouldn't be capable of detailing much. <solstag>tae: Running guix --pull only updates Guix, not any packages you have in your profile. However if you install a package, or update an existing one, new Guix will use the new formulas which may have included new package versions. <PotentialUser-16>Kabouik How nice is Wayland and Sway? I am using i3, and I was recalling there is an .xinit and .xfree86config or similar files at $HOME, but I was not sure when those would execute. <identity>PotentialUser-16: Sway is no less nice than i3, and Wayland is ready for most use-cases at this point. you might have to adjust some of your configuration though <PotentialUser-16>I was looking for something more agnostic or "proper", but I don't really need it, to be honest. What you propose seems good enough. <tae>solstag: I usually update with "guix package -m ../myconfig.scm" after a pull. So, your point is that versions are fixed in the generation I am on. And versions are managed by the packages themselves only if they are fixed. Which means suppose I have (list python-x python-y@1.2.3) then this could break if python-x is updated with Guix? <identity>PotentialUser-16: in Sway, you just put exec "program arg arg ..." line into .config/sway/config (or use the sway-home-service if you use guix home) <tae>This makes me wonder about my main manifest, because I have cmake@3.25 there. I suppose this could break things if the newest Guix pull doesn't support it? <xelxebar>Others getting 502 from git.savannah.gnu.org? <tae>I understand that packages will defer to the main dependency graph, but I don't understand how it would then be possible to specify a version at all. <tae>Shouldn't all packages then have fixed versions? <PotentialUser-16>xelxebar Yes! It eventually went through, so I would suggest you just keep trying. <tae>I also have glibc@2.35 for example in myconfig.scm. <xelxebar>PotentialUser-16: Thanks for the confirmation. <xelxebar>Been seeing 502 about half the time for a week or two. <identity>xelxebar: you can pull from the codeberg mirror with the --url option <solstag>tae: If inside `myconfig.scm` you have a package name that depends on something within main Guix, and that thing gets removed from main Guix, yes there will be an issue. You might need to use "inferiors" or copy over into your configuration the old formula needed. <identity>PotentialUser-16: it gets me away from x.org :) <tae>solstag: So this means that cmake and cmake@x.y are explicitly in the main dependency graph? <tae>For every x.y.z that are currently "supported"? <Kabouik>The transition from i3 to Sway was relatively smooth for me PotentialUser-16. I do have to deal with some peculiarities remnant from X though, like a .XCompose file where I can set ' as a dead key capable of producint a cedilla. I know no Wayland-specific way to do that. <tae>solstag: Thanks. I suppose in some sense this means that the package handling is deferred to atomic definitions that have been checked before either directly or by some other means. And when you build you are then reproducing whatever was fixed by the packager. <identity>tae: unless the build is not reproducible, which is a different story... <tae>identity: What happens then? <andreas-e>apteryx: Thanks for noticing :) It is a bit disheartening, we have over 4000 bugs, if I close 10 per day, it will take over a year... And not all of them can just be closed. <identity>tae: well, if you build you might get something that isn't exactly the same as the thing the packager built, if you are even building and not using binary substitutes <andreas-e>apteryx: Yes, bugs and patches. Some "guix pull" bugs, which are essentially spurious. Some updates that have since been superseded. But also package additions. <apteryx>there's something like 1370 PATCH titled entries <andreas-e>For some of them, I have contacted the authors to ask them whether they want to work on them again. If not, I think I will close them after waiting for about one month, like for package removals. <andreas-e>I think we will need some orchestrated action when moving to Codeberg. <andreas-e>Well, if the bugs are "I could not install on this or that platform" from years ago, I think we can close the bugs most of the time. <andreas-e>I am thinking of asking people to clear their tag:team-xyz backlog. <andreas-e>Or the issues where they have already commented; how do we filter for them? <andreas-e>Or simply search for a topic or package they are interested in. <partosqq>i'm want to use (scandir ".") inside package definition <partosqq> 0 (%resolve-variable (7 . scandir) #<directory (guile-use?>) <gabber>partosqq: where inside the package definition? <gabber>would you mind showing us the code you wrote (with the use of a paste bin as described in the header)? <andreas-e>Right now it looks as if the motion will succeed. In any case, tidying up the issue tracker would be a useful thing. <tae>The main guix.git repo uses SHA1 for commits, right? Any plans to use SHA256? <apteryx>partosqq: you'll need to use the 'modules' field, take care to list the standard modules used for the build system the package uses, and add '(ice-9 ftw)', which provides scandir <apteryx>it's builtin Guile, so there's no need to extend the '#:imported-modules' argument. <apteryx>just use #:modules argument (not field, sorry) <partosqq>apteryx: could you please share example? <apteryx>see the chez-scheme-for-racket package def (guix edit chez-scheme-for-racket) <partosqq>apteryx: i have already include (ice-9 ftw) in use-modules <partosqq>apteryx: am trying to google (guix edit chez-scheme-for-racket) <apteryx>partosqq: check the package definition I've mentioned, the #:modules argument lives in the arguments of the package <apteryx>not in the imports of the guile module containing the package declaration :-) the phases code runs in the build environment (it's staged), it knows nothing about the host environment such as the available modules of (gnu packages java). <lechner>apteryx / Hi, you changed eudev in the mainline? <apteryx>it landed when the elogind branch was merged, yes <partosqq>apteryx: thank you, but how i can find (guix edit chez-scheme-for-racket) module? <apteryx>that's a command-line: guix edit chez-scheme-for-racket <apteryx>it'll open up the definition of the package in your $EDITOR <partosqq>apteryx: cool, thank you, added (ice-9 ftw) to #modules <partosqq>no have got this err - 0 (%resolve-variable (7 . binary-build) #<directory (guil?>) <m4xxed>Hey, I am looking for a way to run a command ("gnu stow") when I run "guix home reconfigure", preferably afterwards. Is there a service type that already offers this, or am I missing any obvious service type? I am using "gnu stow" in addition to guix home manager for configurations that are highly dynamic, e.g. my emacs config, and I therefore do <m4xxed>not want them managed by guix home manager. <partosqq>apteryx: could you point me please to some docs, so i can understand better syntax of package definition? <ruther`>partosqq: by putting only ice-9 ftw to modules you've removed the previous modules. you need to append to the default modules <partosqq>i got (resolve-interface (nonguix build-system binary) # _ # _ ?) <partosqq>thats strange because i have (nonguix build-system binary) <ieure>partosqq, Did you try updating the existing Guix package? Unless this JDK version has changed substantially, it could be as simple as version/url/hash update. <partosqq>ieure: no that is not easy way to upgrade to latest <partosqq>could you please explain me, why do i need to add modules in side package definition? <lechner>apteryx / Hi, i'd like to circulate some patches privately to test Guile-PAM for general availability. Any chance you could add the latest nyacc, which is a prerequisite? Here is a patch: https://bpa.st/YVYA <ekaitz>partosqq: because some of the code is run in the package building, not in the guix codebase <ruther`>partosqq: by using a gexp you are quoting the code, it is sent to the daemon that executes it <ieure>partosqq, What's difficult about it? <partosqq>one more question, how i can get list of bin/* files in package source, so i can include them in patchelf-plan list? <apteryx>lechner: maybe you could inherit from nyacc-1.00.2, and inherit its base origin too, to preserve the snippet? I assume the other substitutions you did not carry would still be useful? <apteryx>and then you do not need to reset propagated-inputs, already '() in nyacc-1.00.2 <ruther`>partosqq: for binary build system you are giving it the binaries directly in source, so you see the files in source... but please just ask about nonguix in nonguix channel,not here <ieure>partosqq, I'd just say that the route you've chosen seems very difficult to me, and is also something that can never be contributed back to Guix. <ieure>I'm not sure why you're determined to package the binaries. <apteryx>do every java need the -1 version to bootstrap? <apteryx>or perhaps we could skip and bootstrap 24 from 21 <apteryx>I guess not, given how every release so far doesn't skip one release <lechner>apteryx / sorry, I don't use package inheritance <apteryx>I gave a quick try at openjdk 24, so far failing to apply the 2 patches that I assume are still relevant <apteryx>I disagree, and you already have (inherit nyacc) <lechner>except in some cases, which you will surely show me <apteryx>if you mean inheritance of origins... it's a bit verbose yes but it help avoiding loosing patches <lechner>on another note, what did you mean by rebasing my multi-hook patch for nginx, please? I saw no conflicts <apteryx>it fails because the remaining patch doesn't apply, and I'm guessing the openjdk-21-fix-rpath.patch may still have value but the source changed considerably and it doesn't apply. maybe try without patches at first and see if the original bugs still reproduce or not. <apteryx>and if they do reproduce, then try to port them over the new code base. <apteryx>bootstrap requirement verified: configure: (Your Boot JDK version must be one of: 23 24) <apteryx>so we need to add 22, 23 and then 24, using that same make-openjdk helper <lechner>apteryx / how do keep the snippets for nyacc while changing the hash, please? <partosqq>when am trying to use (scandir (string-append #$output "/bin/")) inside patchelf plan <apteryx>I cpied the uri otherwise the store file name of the source would be wrong (embedding the inherited version) <apteryx>it's just like any guix record; you can override any field you like, otherwise it's copied over from the inherited base <apteryx>like you can do at the level of a package record object <lechner>apteryx / okay, thanks. checking it will take while since I have to go through a pull. didn't you lose my snippet, though? <apteryx>lechner: I haven't pushed anything yet <zilti>So, is Savannah ever going to do something against the LLM-Scraper DDoS-Attacks which I assume are causing the issues, or do we just accept that it's "dead" and move on to using the Codeberg mirror permanently instead? <apteryx>lechner: the snippet used is inherited from nyacc-1.00.2's source <apteryx>hm, so yours is different? should the old snippet be applied on top of the new one? <lechner>apteryx / i don't know, but nyacc advanced to a 2.x series and what i had was working <redacted>I'm trying to add a special file to /etc/qemu, but it looks like that directory is symlinked by Guix. <apteryx>lechner: I think the same snippet from 1.x is still good, looking at the source. <redacted>I have a package installed, ovmf-x86-64, that adds a "firmware" subdirectory to /etc/qemu, so Guix has symlinked the /etc/qemu directory to /etc/static/qemu <redacted>So I'm getting a "read-only fileysystem error" when reconfiguring <redacted>It can't make the /etc/qemu/host.conf file <apteryx>it looks like your version would not adjust the GUILE_SITE_CCACHE (.go byte compiled files) location <lechner>apteryx / okay, sounds good. how do keep my snippet as well? ./configure may also be essential <lechner>apteryx / about nginx, i will also rebase. probably something I did locally a long time ago <apteryx>lechner: just reverified your snippet, and it's fine, yours is correct <apteryx>don't bother inheriting the source of nyacc-1.00.2 <apteryx>the other prefixes are now set to expected values in configure, so don't need patching <lechner>apteryx / will you apply my patch, please? <redacted>Hm, so removing the ovmf-x86-64 package doesn't remove the /etc/qemu -> /etc/static/qemu symlink as expected. Maybe I'm wrong about how this is working. <lechner>Hi, what is ,bournish mode in the Guix REPL and where may I read up on it, please? <hako>lechner: (guix build bournish) <redacted>Ah, so /etc/qemu is created as a computed file by libvirt <ruther>redacted: packages cannot create files in /etc, only services do that <redacted>So I guess I have to find some way to modify the libvirt service's extension to the etc-service-type to get my extra config file in there. <ruther>redacted: so you want something under /etc/qemu/firmware or <redacted>Just /etc/qemu. Trying to add the /etc/qemu/bridge.conf file for the qemu bridge helper <redacted>the recommended (extra-special-file "/etc/qemu/host.conf" "allow br0\n") invocation gives me a read-only filesystem error <ruther>redacted: oof, then you need to change the libvirt service <ruther>redacted: yeah, that can't work given how the libvirt service just writes /etc/qemu directly <ruther>redacted: the firmware folder has been added quite recently, I suppose the manual was forgotten <ngz>andreas-e: texlive-tex doesn’t build on i686 because of a "faketime" error. Does that ring a bell somehow? <ruther>redacted: upon some research, I think it would be best if libvirt service type just extended etc with "qemu/firmware" instead of "qemu". That should be possible as it uses file-union that supports that use case <ruther>(etc service type uses file-union) <ngz>andreas-e: segmentation fault =/ <redacted>ruther: Oh, wow, thanks. I'll look into testing this when I have the time. <andreas-e>I have no idea! That is really unpleasant. You mean, the compiler segfaults? <ngz>andreas-e: command "faketime" "1970-01-01T00:00:00+00:00" "fmtutil-sys" "--byfmt" "tex" "--fmtdir=web2c" failed with status 1 <ngz>Let me try without the faketime wrapper <ruther>ngz: there is no log(error) from faketime command before this error? <ngz>ruther, andreas-e: Interestingly there is a (if (target-64bit?) "faketime" "datefudge") in nss package. <ngz>I confirm texlive-tex builds fine on i686 without the faketime wrapper <ngz>So datefudge should work <ruther>Is debbugs having issues the same way savannah has? I submitted a patch like 10 minutes ago, got no answer and now I cannot really load debbugs.gnu.org <ruther>One of my patches already got lost like a week ago, I had to resent it <ruther>This sucks. I guess I will appreciate the switch to codeberg. While I like the e-mail based approach more, if GNU is not able to cope with AI scrapers, that's a problem... <ieure>It's an arms race now, I don't expect stuff like Anubis to fix this long-term. <ieure>Only the complete annihilation of the entire so-called "AI" industry. I cannot wait. <Ghgsrt>I’ve packaged an up-to-date spotifyd that actually has dbus-mpris support so it can interface with playerctl, but it’ll require updating ~200 dependencies. I’m not against taking the time to patch everything, but should I send it as a single massive patch series? <ieure>ruther, The thing many open projects are deploying to deter the horde of malware wrecking their infra. <ruther>Ghgsrt: are those dependencies related to a specific team, or at least most of them? Maybe it would be good asking the team members that's so <ruther>Ghgsrt: oh... well in that case, you should check the patch series that reworks how rust build system works <ieure>I don't know how Rust ended up with NPM-level dependencies. <ruther>Ghgsrt: I would definitely not submit 200 deps updates now to master since the build system is being reworked completely <Ghgsrt>Is that a recent rework? I just had a patch accepted a couple weeks ago and wasn’t informed about any changes to the build system <ieure>I thought that was a JS-specific problem since it's a community thing to have "tight dependencies," meaning packages for utility functions that are 1-5 lines of code. <sham1>It's a product of the same culture <ruther>Ghgsrt: The change has been submitted a month ago, not sure when the team started talking about it. See one m <ruther>ieure: oh, I think I saw that Anubis on codeberg even <Ghgsrt>Oh man. Well it’s a good thing I asked then <ieure>ruther, Yes, they have also had to deploy it. <ruther>Ghgsrt: still definitely do ask the rust team. I am not really sure what the plan is - like when they plan to merge the changes <bdju>Would be nice if the people closing a bunch of bugs on the mailing list didn't wipe out the old subject, making it hard to tell what the bug was at a glance. <andreas-e>bdju: This would be me. Usually I do not "wipe out the subject", but just write a new mail to xxxx@debbugs.gnu.org. <andreas-e>The drawback of a mixed web and email based workflow, I suppose - I pick them up on issues.guix.gnu.org on the web, and then use email to close them. <bdju>Ah, I see. I wonder if you could copy/paste the subject from the webview then. <andreas-e>Well, probably so. Where do you see them? Are you subscribed to a mailing list? <lechner>bdju / which bugs are you talking about, please? <andreas-e>If you just go to issues.guix.gnu.org, you see them at the top of the page under "Recent activcity". <bdju>My inbox was just full of "Closed" earlier and I thought it was a shame to not see at a glance *what* was closed. I've already archived them all away now. <andreas-e>Lots of old things. Many "guix pull" failing because of a network failure and the infamous message enciting people to submit a bug, when there is none. And hardly ever anybody reacts to them. <andreas-e>Package updates that have been superseded by more recent package updates. <andreas-e>Yes, this one was an issue for science-team that I actually had in my inbox. <andreas-e>More generally, when there are patches to apply, I download the emails, "git am" to them and in the end reply. <andreas-e>So the "Close" are essentially all trivialities. <andreas-e>As said earlier today, I think we need a massive bug closing effort. We have more than 4000 open bugs right now. <andreas-e>Just going through them and closing those that are not relevant any more or not actionable would be very useful. <lechner>andreas-e / maybe i should send closing notifications here again... <andreas-e>lechner, well, I liked them. It gamifies the thing. <lechner>plus, peanuts pulled the current bug titles, not your subject line <old>Title: [Hosting] Future of OSL in jeopardy <Ironsmith>hello, i'm testing something out and having issues using `(define-public ... (inherit esbuild) ...)` inside of gnu/packages/node-xyz.scm. `esbuild` is from `gnu/packages/web.scm` and it's already being imported via `(define-module (gnu packages node-xyz) ... #:use-module (gnu packages web) ...)`. <Ironsmith>the error i get is: `Computer/Guix/Source/gnu/packages/node-xyz.scm.go, error: esbuild: unbound variable, hint: Did you forget a `use-modules' form?` then it starts listing a bunch of other modules that are 'unbound' <ruther>Ironsmith: it's not modules that are unbound, it's variables. <ruther>Ironsmith: most probably you've introduced a cyclic dependency by inheriting from esbuild <ruther>(cyclic reference in the modules) <ruther>nckx: any reason that privileged-program doesn't support not giving executable permission to others? To allow only users of a certain group to execute a program <Ironsmith>ahh i see, thanks @ruther! i'll look into a possible cyclic dependency <ruther>Ironsmith: good luck, it's the worse kind... if you want to confirm it's a cyclic dependency, try doing the same thing you're doing currently, but outside of the guix tree in your own scm file <Ironsmith>yeah you're right, just tried it in a separate scheme file and it worked. so i guess `esbuild` can be imported and used in the build step but if i try to use it as inherited, it tries to access that earlier and triggers the cyclic issue <ruther>inherit is known to cause problems like that, I am unsure on what the workaround is though <Ironsmith>gotchya, i'll see if i can rectify the dependency somehow, otherwise i think a new file is a good strategy <ruther>Ironsmith: I am not really sure if a new file is going to work though <ruther>Ironsmith: the issue with inherit is that it somehow evaluates module-ref too early <ruther>Ironsmith: so I am not even sure if node-xyz is part of the cyclic dependency in your case ... maybe it just triggers the cyclic dependency deeper... <lechner>Hi, does Guix always take all build slots? How many do I have? <Ironsmith>oh i see, hummm but i can build within guix git with `./pre-inst-env guix build my-module` when it's in its own file, or are you saying, if i do a `make clean && make` it'll run into an issue? <ruther>Ironsmith: try it, but I am afraid that yeah, it will run to n issue on make. I've seen that happen already that evaluation with guix build was fine, but make failed. <Ironsmith>ruther: gotchya, ok i'll make sure to test that, thanks again! <ruther>redacted: I've submitted libvirt patch to fix the etc/qemu symlink: #78165. CCd original author of the libvirt service. There was an issue with the first patch I sent you, mkdir-p should be removed. <ruther>Ironsmith: if you can, please report back what you found out, I am also not so proficient in that area, so would welcome new inputs. <ruther>If I am making a new guix module, how should the commit message look like if there are multiple variables introduced? <csantosb>The idea is not to introduce variables one by one ? <ruther>csantosb: seems unnecessary to me... I don't know... <csantosb>Eases traceability of changes in case of bugs, I guess <ruther>I don't think it does since until the functions are actually used, there is no way to see a bug <ruther>to put more context, it's a new guix/build file <csantosb>Something like f61151e325 in emacs-team branch ? <csantosb>gnu: Add (gnu packages emacs-build) module. <csantosb>lechner, by build slots you refer to guixbuilder0N workers in /etc/group ?