IRC channel logs
2026-06-12.log
back to list of logs
<Indesu>I have a question about good practices : I am packaging the odin compiler and for the "vendor" libraries (ie external libraries that have official support and bindings) there is an issue with glfw. It tries to load Xlib at runtime. I have managed to make it work : I wrapped the binary with added environment variables but for the required <Indesu>LD_LIBRARY_LOAD I use 'which odin' to find the store location of the profile and put its lib in it. It is hacky but is it in accordance with the pure nature of guix ? This is my first package btw <ieure>Indesu, No, it should compute the store path in the build and put it in the script. <apteryx>aren't the various properties understood by the importers documented somewhere? e.g. the recently added regexp for git tags, IIRC <apteryx>found it: (info "(guix) Invoking guix refresh") <dcunit3d>how do i find the ref to push to using agitjo? <dcunit3d>or do i just push a series of commits that includes the same ChangeId? <dcunit3d>i guess i figured it out, but that's a bit weird <f1refly>I added the package "ddcutil" to my udev-configuration rules because I want to control my monitor. The package description said that the user needs to be member of the group "i2c", so I'm trying to add myself to the i2c group. When reconfiguring, guix complains that the supplementary groups is undeclared. shouldn't it be declared when adding the package? <dcunit3d>f1refly: did you add some `(udev-rules-service ... )` for ddcutil? <f1refly>No, I added the package to the "rules" list of the udev-configuration of the udev-service-type like it said in the description <dcunit3d>so you can add `(udev-rules-service 'fido2 libfido2 #:groups '("plugdev"))` into the list of your system's services <dcunit3d>you'll have to assign that group to your user by name though (then logout/login) <dcunit3d>also f1refly you may be adding those rules twice: once with (inherit config) and then again with (udev-configuration-rules config) <f1refly>Oh, true. I think I added the latter by erro <futurile>**REMINDER**: this Sunday is the Guix Foundation AGM. If you're a member of Guix Foundation please come along to take part in discussions / Q&A about how GF will be supporting Guix. <futurile>Sunday, 14th June at 17:00 UTC / 18:00 London / 19:00 Paris / 10:00 in San Francisco <futurile>I'm sorting out the URL for the video conference this morning - so will publish it later <futurile>**UPDATE**: the conference url/login and agenda have all been sent to the guix-foundation members mailing list. <futurile>If you don't see it, or have an issue ping me <apteryx>yarl: I did, and then it got marked read and I forgot about it, thanks for the reminder <apteryx>instead of marking things skipped "implicitly", we could instead just omit displaying anything for these <apteryx>which would be less noise on the screen <yarl>apteryx: I don't know the test system very well, what I remember (1 month ago) is that I made this commit a avoid a crash <yarl>I was working on something specific and I couldn't run specific tests with --select flag. <yarl>I saw in the source this test-result-kind* hack of yours and I realized that it should be used on another spot. <ngz>Hello. I recently tried to start using the unprivileged daemon. Since I use Guix on a foreign distro (Debian), I followed the transition guide in the manual. Since then, I see spurious "error (ignored): program `newgidmap' failed with exit code 1" lines whenever I call "guix pull" or "guix home reconfigure". I assume a forgot a step in the transition process. What could that be? <mwette>ngz: Did you install the uidmap package (it's that on ubuntu)? <ngz>mwette: I didn’t install it, but "apt search uidmap" tells me it is installed on my system. <mwette>OK. That provides newgidmap. I'm not sure what more to suggest. You could try to run guix pull using strace. On ubuntu, some apparmor config is needed, but that is ubuntu-specific. <vagrantc>so, i've been seeing: guix substitute: error: corrupt input while restoring '/gnu/store/m0hhbfls5ds60azp5qlxvy10lj8dhdmx-linux-libre-6.12.93-guix.tar.xz' from #<input: string 7fa1b500e460> <vagrantc>fetching path `/gnu/store/m0hhbfls5ds60azp5qlxvy10lj8dhdmx-linux-libre-6.12.93-guix.tar.xz' (empty status) <vagrantc>so it's no longer just my aarch64 machines ... :( <vagrantc>so far i've only seen it with linux-libre builds ... <vagrantc>it is, unsurprisingly, making it hard to test updates. <vagrantc>my best luck so far is to manually "guix download" the upstream source tarball, which seeds the correct hashes into /gnu/store and then evrything seems to work. not sure how the URL differs ... gnu/packages/linux.scm uses mirror://kernel.org URLs whereas if you go to kernel.org it's got some sort of CDN <vagrantc>gah. something appears to have me getting all notifications for guix again ... wheee. <vagrantc>i have the sneaking suspicion that there is some semi-automated process that occasionally marks committers or team members or whatever as watching guix ... but i suspect it is not doing what people think it is doing <vagrantc>did anyone run any sort of update to something that might have afffected the codeberg configurations today? <ieure>vagrantc, The team membership sync was doing this earlier on, but I thought it had been fixed. <ieure>vagrantc, It was removing all collaborators, then re-adding the ones from etc/teams.scm, that would reset the user's per-repo preferences. <vagrantc>ieure: yeah, had not seen it for a while ... but today is a new day! :) <vagrantc>i managed to catch it before my inbox was flooded with notifications this time ... here's to waking up a bit too early, i guess. <ApptainerUser>hi, when packaging guix environments with guix pack into an apptainer/singularity image is there a way to specify a runscript? I don't see runscripts mentioned in the docs <ApptainerUser>I need to do some more testing but it seems that --entry-point is respected when building an apptainer image <ApptainerUser>Well that doesn't seem to have helped. The issue I'm having is that guix generated apptainer images aren't working with CWL. Recent versions of CWL use singularity run instead of singularity exec, which doesn't seem to like the images guix creates <futurile>ApptainerUser: sorry, I haven't used it. I guess you checked the manual for insight/ <ApptainerUser>These images all work fine with older versions of CWL that use exec, it's just the newer versions that use run that are causing problems <futurile>ApptainerUser: nothing in Codeberg issues, maybe someone else has already solved it <fingers crossed> <Zelphir>Hi! I am using Guix on foreign distro, to run a Guile program in a guix shell using: `guix time-machine --channels=guix-env/channels.scm -- shell --check --manifest=guix-env/manifest.scm --container -- bash` and then `guile -L . main.scm`. This Guile program makes use of `(web client)`. However, when it runs, I am getting the error: `ERROR: In procedure getaddrinfo: In procedure getaddrinfo: Temporary failure in name resolution`. When I don't run this <Zelphir>program in a Guix shell, but instead install `guile`, `guile-gnutls` and `gnutls` in my main profile, and then run the program after (1) `GUIX_PROFILE="/home/xiaolong/.guix-profile"`, (2) `. "${GUIX_PROFILE}/etc/profile"` and (3) `unset GUIX_PROFILE`, (4) `guile -L . main.scm` then it works. For example in this blog post https://www.ducea.com/2006/09/11/error-servname-not-supported-for-ai_socktype/ it turned out to be `/etc/services` related. So I am <Zelphir>guessing in my guix shell container maybe `/etc/services` is not visible and therefore I am getting that error. (Just a guess.) Is this guess correct? And if so, how do I make that file visible to the Guix shell container? <futurile>Zelphir: uh not sure I'm getting all of this, but does your 'guix shell --container' have --network in it? <Zelphir>Hm. That results in another error, which is probably already much further. Supposedly a certificate signer issue, even though the URL I am accessing definitely has a valid LetsEncrypt certificate. The error is: <Zelphir>web/client.scm:283:6: In procedure tls-wrap: X.509 certificate of 'web.xiaolong-hosting.com' could not be verified: signer-not-found invalid <Zelphir>Do I need to `--share` to the container some known issuers/signers from the host OS? <Zelphir>Ha!! It works! I `--expose=...` the host's certs and now it works! <Zelphir>Finally I can make it work in a Guix container : ) <futurile>Zelphir: yeah, you either need to use expose from your host or you can include the nsscerts package <Zelphir>I added that package as a commented out alternative in my `manifest.scm`. <vagrantc>now that substitutes are available for the source, it fails to download them <vagrantc>guix substitute: error: corrupt input while restoring '/gnu/store/7wanfd7sf8b75xsf8gyhyaslg6s60hr6-linux-libre-6.18.35-guix.tar.xz' from #<input:hash-input 7f12f43aca60> <vagrantc>i've now seen it on 3 of my local systems and at least one of the machines on ci.guix.gnu.org <Ghil>Welp, for a "simple" first package, I learned a lot through it. And it's not been accepted yet so I might learn more before it's finished hahaha. <vagrantc>i was thinking it was a bunk mirror://kernel.org ... but now it's happening with the substitute servers as well <yelninei>vagrantc: I have had this before. usually it is when ci or bordeaux are having a bad day and i can just ignore them with --no-substitutes. But there the port is a normal input-port from the download and not a hash-input port <vagrantc>but it also happened when downloading directly from the kernel.org mirrors <vagrantc>so ... all of my machines are having these bad days all the time <vagrantc>ACTION squints at something amiss in guix-daemon <vagrantc>trying with fallback ... as i at least successfully downloaded all the upstream tarballs manually and can at least locally verify them ... <vagrantc>linux-libre 7.0.12 claims to have been built 9 hours ago, but is still not available as a substitute <yelninei>i am not sure if that works, but maybe you try downloading manually with wget and then add the local tarball to your store <vagrantc>guix download URL worked, and then it was able to actually built the derived guix tarball <vagrantc>but this problem has been pretty rough for about a week now <vagrantc>for some reason it particularly affects the linux-libre tarballs <vagrantc>which are quite time expensive to build ... (the kernel builds take maybe 1/3rd of the time of building the source tarball) <yelninei>i think guix download is the automated way of what I described :) <vagrantc>it's really weird, as it usually gets somewhere between 99-100% and then fails <vagrantc>so then i try again, and it gets to 99-100% done, and then fails ... ad infinitum <vagrantc>first time i saw it actually cause problems on ci itself, though <meato>mm, same workaround, too (adding pygobject-introspection to the profile). I'll make a PR <bdunahu>meato: in that thread, lilyp suggests using a wrapper to set GI_TYPELIB_PATH to the package's inputs rather than propagating <bdunahu>it looks like that is done on the `python-screenkey` package already for reference <simendsjo>A cannot build a docker container as it failes to resolve a domain name. I tried copying the ips from /etc/resolv.conf to /etc/docker/daemon.json and restart dockerd, but still no luck. Any idea what might cause this? Is it related to Guix somehow? I seem to remember having similar issues last year, but I cannot remember if I solved it :/ <simendsjo>Regarding my docker build issues... Adding `--network=host` solves the issues ;)