IRC channel logs
2026-05-26.log
back to list of logs
<sturm>such a strange feeling. I added the home-pipewire-service, enabled it with herd, restarted my Sway window manager and ... it seems to just work. When does a significant new subsystem ever just work? PulseAudio doesn't seem to be running, so I don't think I'm fooling myself. Anyway, hats of to all involved in that! <aloys>What is the general philosophy of Guix regarding opening PR for new services / packages? Are those PRs welcomed (as long as it's FOSS)? <argp>Wow I did not expect my PR to be merged within an hour. That was such a good contributor experience with Info manuals documenting every detail to quick PR review and merge. <RavenJoad>aloys: From my experience, new services have a higher bar than packages, just because they touch more things and do more work. The FOSS part (with a compatible license) is a necessary step 0. The package actually being build-able is step 1. After that, it's general feasibility and, far more importantly, wider usefulness. <apteryx>adanska: oh, the update must have broke something :-/ <adanska>apteryx, yeah, looks that way :/ perhaps a revert and then a new WIP PR working on a working update? <apteryx>The tool is just a bunch of shell scripts IIRC, so maybe some command needs patching or similar <adanska>thanks apteryx! if you make a new PR, when i have some free time next week I can have a go at patching it so things work again :) <identity>when i log in through GDM using the ‹GNOME› session, not the ‹GNOME on Xorg›, it seems to be running under Xorg anyway <apteryx>networkmanager needed a build switch <trev>identity: you sure it's not just xwayland? <identity>or, hm, maybe it is not supposed to be running like that, i am forgetting <identity>PGTK Emacs complains that i am running it under X and not Wayland <trev>identity: well wayland has been the default now in gdm-configuration for a while (i remember switching over) <apteryx>isn't GNOME on Xorg already something of the past? <apteryx>48 with lots of apps from 49, some from 50 <identity>GNOME 49 disables X11 with the default build configuration, GNOME 50 tears out the X11 code altogether, or something like that <dariqq>apperently there was a gtk upgrade in the python-team branch <dariqq>because gtk4 now does not compile with the unofficial librsvg 2.40.23 <dariqq>hmm gtk should itself no longer depend on librsvg <dariqq>Ah i think it is only needed for tests anymore but it is optional <f1refly>is someone using gpodder? It fails to launch on my machine because it can't find the cairo version it's looking for. Unfortunately I'm not able to find the right arguments for guix shell to start it in a container, it won't find the current dbus session. <untrusem>--preserve="^DBUS_*" might help; i need to open my laptop for this <f1refly>yes, that did the trick. I can now confirm the error also happens with -C <untrusem>guix shell gobject-introspection gpodder -- gpodder <untrusem>guix shell --preserve='^DISPLAY$' --preserve='^DBUS_' --expose=/var/run/dbus --share=/run -CN gobject-introspection gpodder -- gpodder <untrusem>would you like to contribute the fix to upstream <f1refly>yes, it works with that input on my machine as well <f1refly>Should I just open a ticket and state the missing input? <untrusem>f1refly, you should make a pr adding the input in the package defination <dariqq>gpodder already has a wrapper for GI_TYPELIB path so it should should have cairo there if it needs cairo <Alavi_me>Hi everybody, I get this error when I try to run `guix pull` <Alavi_me>ice-9/eval.scm:223:20: In procedure proc: <Alavi_me>hint: Did you forget `(use-modules (guile))' or `#:use-module (guile)'? <identity>Alavi_me: i think somebody asked the same question recently, maybe check the logs? <venoflux>Hello folks, I would like to ask you about emacs static-when error, due to some upgrade I cannot use both magit and geiser since both of them uses something called emacs-compat. I have found the suggestion to upgrade it to version 31 but I have seen its 30 on both guix and emacs-xyz channels. Any suggestions to resolve this issue? <untrusem>venoflux: you can make a pr to update it <untrusem>are There are many dependents of emacs-compat <ieure>venoflux, emacs-compat is a library that backports newer Emacs features to older versions. It shouldn't be a problem for multiple packages to use it, unless they're using different versions. <ieure>venoflux, Are you using imperative style package management? `guix package -i magit' style? <ieure>Upgrading Emacs will not help. <venoflux>no I am using guix home from fedora as my emacs package manager, after the guix upgrade it says that static-when is an invalid function <ieure>venoflux, What is trying to use static-when? <venoflux>The error appears on both M-x geiser and M-x magit-status commands other packages are looking fine so far <venoflux>*Messages* showsbyte-code: Invalid function: static-when <ieure>venoflux, If you `M-x toggle-debug-on-error' and run `magit-status', what is the location of the file Emacs is using for that? <ieure>I'm not sure what problem you're having, it seems like it's one or the other of: you're using Emacs package not from Guix; Guix magit/geiser packages got updated and are completely broken. And I'm hoping it's the former. <venoflux>I see load-with-code-conversion that uses a guix hash in /gnu/store/*hash*-emacs-magit-*date*/share/emacs/site-lisp/*package*/magit.el <venoflux>my /home/venoflux/.guix-profile/etc/profile is missing from the last guix upgrade maybe its something to do with that? <identity>geiser works here (Guix System) just fine, and ‘static-when’ too for that matter, e.g. (static-when t "works") <ieure>venoflux, Are there any entries in `load-path' which don't point to /gnu/store? <identity>venoflux: is your Emacs from Fedora or Guix? <identity>so ‹realpath $(command -v emacs)› points to the store? <identity>and where is you compat.el, and which version it is? <venoflux>yes executed command shows a /gnu/store path <identity>i guess my ‘static-when’ is from core and not compat.el <venoflux>I also tried to add emacs-compat package but it could be still using the core version <identity>Guix's emacs-compat is 30.1, but emacs-magit depends on 30.1 <identity>venoflux: why would you want it to be using the emacs-compat version? <untrusem>i think magit depends on compat 31 now, guix's magit is not updated yes <venoflux>Not for any reason I was searching for the error on magit github and it lead to upgrading to compat v31 <identity>i do not see any mentions of ‹static-›* in guix build --source emacs-magit <venoflux>So I assumed it was due to that, even when it says emacs under version 31 I used emacs-next-pgtk to make it 31.0 but it did not work unfortunately <identity>is your magit from Guix or somewhere else? what version is your magit? <venoflux>No all of them are from my guix home config <venoflux>all emacs related packages are from guix only <untrusem>I don't have any issue using magit in emacs <untrusem>can you check your emacs.d, there might be magit package that emacs is loading <identity>venoflux: can you try ‹guix shell emacs-next-pgtk emacs-magit -- emacs -nw› reproduce the error? <venoflux>I have tried the guix shell emacs-next-pgtk emacs-magit -- emacs -nw command and same error happens funny I remember more magit commands but there are only two. I will control the elpa folder now <venoflux>elpa has only archives and gnupg directories <untrusem>strange, I will try to reproduce the error <venoflux>I guess later on I will try to delete everything and re-install guix and home reconfigure my packages <venoflux>maybe I broke something during the guix upgrade <untrusem>you ran this command - <guix shell -C emacs-next-pgtk emacs-magit -- emacs -nw -Q> right? <venoflux>yes I have run guix shell emacs-next-pgtk emacs-magit -- emacs -nw and same problem occurs <identity>venoflux: those are two different commands <identity>though i guess with -Q you are not going to load site-lisp, so downgrade that to -q <venoflux>both of them opened emacs on terminal -Q one run as a TUI and it does not even correct to magit it does not have it <venoflux>-C one reproduce the problem as invalid function: static-when <identity>‹guix shell -C emacs-next-pgtk emacs-magit -- emacs -nw -q› please <untrusem>guix shell -C --preserve='^TERM$' emacs-next-pgtk emacs-magit -- emacs -nw -Q <untrusem>actually you have to preserve TERM env too <untrusem>venoflux, use `-q` and for `-Q` you will have to do `(require 'magit)` explicilty <venoflux>guix shell -C --preserve='^TERM$' emacs-next-pgtk emacs-magit -- emacs -nw -Q and required it and evaluated. It reproduced the static-when error <identity>that is really weird; what is the output of ‹guix show emacs-next-pgtk emacs-magit|grep ^version›? <venoflux>maybe that is the problem, the channel could be broken <identity>and, anyways, that is not what i asked for. the output of ‹guix show emacs-next-pgtk emacs-magit|grep ^version›, please <identity>(or, maybe, that *is* what i asked for, but it is a weird version) <venoflux>there was a package that helps me to add yasnippet suggestions to corfu "emacs-yasnippet-capf" <venoflux>I couldn't find it on the default guix channel <venoflux>identity: after I run <guix show emacs-next-pgtk emacs-magit|grep ^version> <venoflux>yes version names of the guix-emacs channel is weird and more date focused <venoflux>is there a way to tell guix to use certain channels for certain packages? Maybe If I use default package the problem will be resolved <identity>venoflux: yeah, you have a weird magit (probably from the channel you sent) taking precedence over the magit from Guix. i would recommend bringing it up with the authors of the channel <untrusem>venoflux, interesting my guix show emacs-magit to 4.5.0 and when i run `magit-version` function inside emacs it shows `Magit 0.0.0, Transient 0.13.2, Git 2.54.0, Emacs 31.0.50, gnu/linux` <untrusem>you are using the guix-emacs channel magit i think? <untrusem>and with that magit version, you will need emacs-compat v31 <identity>meanwhile, you can write a patch adding the emacs-yasnippet-capf package for inclusion in the main Guix channel :3 <venoflux>I wish I could write a patch I wanted to learn and practice scheme and guix but alas my geiser does not even work due to weird packaging :D <venoflux>Still thank you folks for showing such patience and support <untrusem>maybe you should stop using that emacs channel, it will break things <venoflux>Yeah, great idea. I will probably learn to write my own package definition so I can add it to the default channel later on <untrusem>venoflux, there are yas and tempel snippet in guix repo that makes writing package easier <untrusem>writing emacs package is to be honest easy <identity>see (info "(emacs) Fetching Package Sources") <venoflux>untrusem: the reason I preferred yasnippet was all the predefined completion from doom-emacs-yasnippets and yasnippet-yasnippets <untrusem>I can whip up your package, give me 2 mins <venoflux>untrusem: I really appreciate it, but you really don't have to <venoflux>I tried to define yasnippet-capf myself before as second package after the hello-guix one but failed miserably even though <untrusem>snippets makes it quite easy to write packages <untrusem>> I really appreciate it, but you really don't have to <untrusem>guix is a small community and what makes it great is people willing to help you with their own time, at least, that's what I experienced when I first starting using guix <venoflux>untrusem: ah great thank you so much again, now I can look at the code to see what I did wrong when I tried to do it myself <untrusem>just use snippets, it will make it quite easy and also reduces errors, I remember trying to balance parenthesis at the starting :P <untrusem>just start contributing small packages, so we can have one more person helping us :) <venoflux>normally I try not to disturb and do it myself as much as possible but as you said since it is a small comminity there aren't a lot of places for me to lurk forums and error messages are quite esoteric for my developer skills. For the paranthesis I can thank parinfer and rainbow delimiters for that it helps me a lot <venoflux>yes thank you once again, after I've removed the channel and commented out other packages that default guix channel does not have, I have a fully functional emacs once again. I can try to start by trying to add my missing packages to begin with <ieure>venoflux, Most Emacs stuff is very easy to package, and Guix has `guix import' which spit out a package definition for you. For Emacs packages, that should be 99% correct. <venoflux>ieure: I guess I should read the documentation and guix cookbook again. I tried defining and using a package myself but it ended up myself trying to create my own channel due to lack of knowledge on local file commands <untrusem>ieure: that's only works for elpa packages :p <ieure>untrusem, Fairly easy to change to point at Git after you import, though. <ieure>It's dependency hells all the way down. <yelninei>i guess i can skip 10h of compiling clang then: Fatal Python error: Bus error <folaht>I have a question. Does guix need UEFI for ARM64 SBC computers for it to work? <folaht>I have a question. Does guix need UEFI on ARM64 SBC computers for it to work? <folaht>Oh sorry, I forgot that IRC doesn't have the edit function <folaht>And it's still wrong, it's for, not on. <folaht>Like is UEFI necessary for me to install guix system on an ARM64 SBC computer? <ieure>folaht, It is not necessary, but Guix doesn't provide images for those systems, because there are too many variations. <folaht>ieure, what do mean Guix doesn't provide images for those systems? <ieure>folaht, what part of that sentence don'y you understand? <ieure>I am genuinely not sure how to rephrase it in a simpler way. <folaht>Well if Guix doesn't provide for any SBC, then what is the aarch64 version for? <ieure>folaht, Different hardware than your SBC, of which there are literal thousands of modles. <ieure>folaht, Guix provides an aarch64 image which will boot on machines that have UEFI. If you don't have a UEFI system, it will not work; you have to create your own image for your own usecase. <ieure>gnu/system/examples has some templates for those siutations. <folaht>Then I'll try getting an SBC with UEFI. <ieure>UEFI is necessary to use the images Guix provides. It is not necessary to use Guix on an aarch64 SBC. <folaht>Right, but I'll assume the latter costs a lot more work. <ieure>More yes, I'd say "a lot more" is both hardware-dependent and subjective. <folaht>Would the same be true for RISC-V SBC's? <folaht>I think I'll just buy a Orange Pi 5+ and install the UEFI firmware on that. <ieure>Okay. Might want to ask around to see if others have had good success with that before you spend the money. <yelninei>hmm i am getting a substitute for all clangs except clang@14 without setuptools <folaht>I see someone saying that people got it working with 'raspberry pi', but not much else. I don't think anyone ever tried. I'm gonna go for it. <yelninei>i sent a revert but this is now impossible :( <mlxdy>I'm trying to install Guix again on my laptop, mission impossible. <mlxdy>I already spent a lot of time to get it running and I still have problems. <ieure>mlxdy, You're asking in #guix, I don't think you're going to get a lot of unbiased opinions. <mlxdy>I think about make config in vm first then put in on laptop then I'll be sure that everything gonna work. <ieure>Yes, that's a good way to do it. Or put it on a spare machine. I wouldn't recommend installing *any* new-to-you OS on your daily driver hardware. I ran Guix on a secondary laptop for around a year before I reinstalled my daily laptop. <mlxdy>I was waiting for kernel compilation from nonguix and I got error that there's dependency problem or something. <mlxdy>I really like idea behind this distro, but I don't know how is it. <ieure>mlxdy, #nonguix for Nonguix questions. <mlxdy>Any of you have solution to disable opening root partition through grub? I want to make installation where I'll be opening root disk just with initramfs, without encrypted boot partition. <Rutherther>it's not finished completely, but it works (what's missing is removal of old files, I have to remove them manually from time to time so /boot does not run out of space <Alavi_me>Hi people. I asked this a while back and one friend here told me to check the IRC logs for my answer but I don't have logs, So I will ask it again <Alavi_me>When trying to `git pull` I get this stupid error: <Alavi_me>ice-9/eval.scm:223:20: In procedure proc: <Alavi_me>hint: Did you forget `(use-modules (guile))' or `#:use-module (guile)'? <Rutherther>anyway this looks like the channels.scm sandboxing going wrong, what commit are you on? - "guix describe" <Rutherther>I am not really aware there would be this particular bug, not seeing use-modules, but maybe it was in the earliest version <Alavi_me>Rutherther: OOh that's cool I didn't know that. <Alavi_me>I searched. there isn't anything related <ieure>Alavi_me, Do not paste into the channel. <Alavi_me>I tried everything and I really don't understand what's the issue here <GalaxyNova>Alavi_me: you can't do `use-modules` inside the channels.scm sandbox <Alavi_me>And this is the exact code from section 6.6 of the Guix manual <GalaxyNova>there was a new feature added where the channels.scm is not evaluated inside of a sandbox for security <Alavi_me>oh ok. what should I do? and why isn't the manual updated? <Alavi_me>GalaxyNova: oh ok. what should I do? and why isn't the manual updated? <Alavi_me>Sorry my internet is horrendous (war and stuff) so I keep getting disconnected <ieure>Alavi_me, Sorry to hear that. :( Ukraine? <Alavi_me>No, Iran. The 80-something day blackout is slowly starting to be lifted. wish the best for my ukrainian friends too. <ieure>Alavi_me, Ah, I'm sorry. I'm in the US and deeply unhappy about this stupid pointless war. (I didn't vote for the guy, ever) <GalaxyNova>Alavi_me: I am not an expert but I think it would work if you remove the `use-modules` line <Alavi_me>:)) yeah the world is really going to shit. I don't see a very bright future with the current direction of the world leaders <Alavi_me>GalaxyNova: no it doesn't work. it complains that channel-with-substitutes-available is unbound and needs a use-modules <Guest89>Who else is having their time wasted today cuz of codeberg outages. Can't update my systems '=D <Guest89>I finally got a guix pull done after hours. Now stuck on trying to reconfigure system <Alavi_me>Guest89: you can set the github mirror from Millak/guix.git <Guest89>Oh cool. Didn't think their was a mirror. I looked at Savannah earlier but nada. Thanks. <ieure>Guest89, Savannah is worse then Codeberg. <Guest89>Am receiving objects now out of pure luck lol <Alavi_me>Do only the two main CI services provide substitutes? or can I for example set the github mirror for getting substitutes? <GalaxyNova>Alavi_me: it would work if you pass --unsafe-channel-evaluation to `guix pull` but that is not ideal <Guest89>how does a repo mirror provide compiled bins? <ieure>Alavi_me, You cannot get substitutes from a Git service. <ieure>Guest89, It builds them and serves its builds. <GalaxyNova>Alavi_me: I meant that passing --unsafe-channel-evaluation will make your broken channels.scm work <GalaxyNova>I suppose an alternative will be added soon but I guess --unsafe-channel-evaluation should work until then <ieure>Alavi_me, "doesn't providing the GPG keys make it safe" -> no. That assures the safety of the channel. The sandbox is to assure the safety of the channels.scm file. Example, if I give you a channels.scm which has (invoke "rm -rf" "~/"), and you `guix pull -C malicious-channels.scm', it will nuke your home directory. That's what the sandbox is preventing. <mwette>I'm wondering how to use, if possible, a local clone of guix.git for package defs. Do I just replace %default-channels with a channel created from the local clone? <mwette>ie.g, replace in my .config/guix/channels.scm file <ieure>mwette, Why do you want the local clone? Asking because the correct answer for your question depends on that. <Alavi_me>Oh thanks guys. Adding --unsafe-channel-evaluation to guix pull fixed it but it's still very wierd... <Alavi_me>I honestly didn't expect from guix to just push out a breaking change with no appearent solution like that. <mwette>Packages are not building, causing other packages not to build. I'm finding fixes, but patches takes time to get folded in. How do I get around that? <mwette>I've been copying to my local channel and making package-local but that requires patching the dependent packages for inputs. <mwette>I'm hoping for a canonical solution to deal with this. <ieure>mwette, You can point at a file:/// URL which is a clone, but I believe you also have to disable authentication for it to work. Unless you're a committer. <ieure>mwette, In most cases where I need something from Guix which is broken, I copy them to my channel and fix there. But that's always been "I need package X, which is broken, so I can substitute my fixed version," I've never had to deal with fixing a dependency of a package I need. I'd probably just wait. <ieure>mwette, Are you running non-amd64 hardware? Your problems sound like running on non-amd64 hardware problems. <mwette>That's what I've been doing. Currently, I a script to copy individual defs from guix/gnu/packages/foo.scm to file:///.../local/packages/foo.scm and I rename them. (And I have a "--diffs" option to create patch to submit to issues/.) <mwette>aarch64, and was pulling in guix-science etc; running into issues <mwette>ieure: If you put in a local channel, do you rename the module, the package, the version? <ieure>mwette, Depends on the change, but if it's a pure fix and no version bump, keep the package and version. "Rename the module" IMO doesn't make sense, you have to copy the package to another module. Even if you technically could put a (gnu packages whatever) in a non-Guix channel, I think it's a bad idea.