IRC channel logs
2026-03-21.log
back to list of logs
<graywolf>Hello Guix :) Reading through the commit log, I see the change in (guix records). Do I understand it right that e.g. (let ((version "1.2.3")) (package (inherit foo) (version version))) now means something else? <apteryx>hm, in my guix checkout: error: arguments: unbound variable <apteryx>I'm on most recent commit 4ac9f297d35 <apteryx>ACTION reaches for the 'make clean-go' sledgehammer <spacematty>I was already working on switching to guix but seeing "comply in advance" MR's going into systemd without broader community input is making me switch even faster :P <rgarcia>hi! I installed arandr but it wont run, python-pygobject throws some import error. help! <yarl>rgarcia: Please show the error. <spacematty>a single dev recently submitted (rudimentary) age verification related MRs/PRs into systemd, accountservice, flatpak's xdg-open, archinstall, and some component of ubuntu that I forget. The first 2 were merged, the latter ones I listed haven't accepted, ubuntu closed it because they haven't determined how/if they're going to comply. IIRC arch rejected it outright. <trev>a single 3 letter agency dev?? <spacematty>there'd be no way to know, the most questionable thing I saw was a post on their linked blog defending google's new restrictions on sideloading apps. <apteryx>rgarcia: python-pygobject was recently updated; I guess this package needs to use the older variant we kept around <apteryx>or try updating arandr first, that'd be best <rgarcia>apteryx: i see there's 3.50.2 and 3.54.3. I tried guix shell python-pygobject@3.50.2 arandr but it just brought along 3.54.3. How can I ask arandr to use the downgraded version? <apteryx>you need to patch the arandr package definition <apteryx>or you package rewriting, e.g. guix build arandr --with-input=python-pygobject=python-pygobject@3.50 <apteryx>hm, but that does a deep rewrite, so you build lots of stuff <sneek>ieure, yarl says: well, thanks! <rgarcia>--with-graft instead of --with-input, eh? I'll try now <yarl>I made the changes on the PR. The bot complained, I don't know why. <rgarcia>I did: guix shell --with-input=python-pyobject=python-pygobject@3.50 arandr, same error. I can see at the beggining that it is using 3.54.2. <rgarcia>so... edit the package definition, specify 3.50 there, ask guix package to read that file, must check the manual <apteryx>the new showtime GNOME video player looks amazing <lilyp>do we already have it on one of our branches? <lilyp>22.13.2 (Commit Policy) suggest one week for unreviewed patches, and I extend this to "patches that only I have reviewed thus far" <lilyp>don't worry, I'll push your patch either today or tomorrow <czan>Ah, okay. So you have a more stringent personal policy? That makes sense. My understanding of that line is "at least two people should have looked at it", so if you're reviewing a change from someone else then you've already hit the threshold. <czan>That's not actually my change, I was just curious if I'd missed an explicit policy somewhere. :) <cbaines>Note that this only applies for your own changes: "If you’re committing and pushing your own changes, try and wait at least one week (two weeks for more significant changes, up to one month for changes such as removing a package—see Package Removal) after you send them for review." <cbaines>For example with https://codeberg.org/guix/guix/pulls/7283 this is suggesting that I, as someone with commit access should wait at least 7 days after I open the Pull Request, but since someone has reviewed the changes, I'm going to push them now. <Rutherther>cbaines: oh that's a nice catch. Did you check in other build systems if another build system could have the same issue? <cbaines>Rutherther, yes, I didn't check comprehensively, but there's at least one other build system which doesn't pass #:grafts? #f <lilyp>I mean, we can make exceptions for proven hotfixes, but I still like my baseline. <Rutherther>cbaines: I started alphabetically and already counted two :) the first two I checked <Rutherther>cbaines: why not change all build systems to have #:graft #f? <Rutherther>not saying to do it as part of that pr... it's definitely better to first fix the ones that actually cause issues <Rutherther>but it seems to me this could cause issues in the future in the other build systems as well <lilyp>I'm out of the loop; what's the deal with #:grafts? #f <cbaines>Rutherther, I wasn't really confident with pushing the go build system change without getting the data service to check on it's effects, so changing lots of other build systems seems even more risky <Rutherther>lilyp: it can happen that if you refer to a package with this-package-native-inputs, it will choose the grafted variant *for the build* itself, not just during runtime. So you cannot get substitutes for some packages. Currently it affected torbrowser <lilyp>ahh, so it would cause gratuitous rebuilds, right? <Rutherther>lilyp: so the way I understand it the "xxx-build" in build system "xxx" itself should not be doing grafted derivations (for the build itself) <Rutherther>lilyp: yeah, building torbrowser is quite resource heavy. On the other only few packages were affected here, since the go packages affected were used just by torbrowser <cbaines>lilyp, just locally, the build farms disable grafts more generally so I think they were still doing the right thing, so people were experiencing the issue as "why am I not getting substitutes?" <chris0ax>Rutherther: just wondering, does this affect mullvadbrowser too? I remember checking substitutes for this package today and getting a 100% availability but then when i try to get a 'guix shell' with it it seems to start building the package. <sneek>chris0ax, you have 2 messages! <sneek>chris0ax, nckx says: I wasn't able to crash emacs but I only tested a daemon. <sneek>chris0ax, nckx says: …nor without daemon. <Rutherther>cbaines: oh! I am not saying to do it blindly. I meant it as an end goal, that it seems to me we want to set it to #f always. So maybe it could be part of the core packages update? <Rutherther>chris0ax: yes, see "guix refresh -l specification-qifs" for all affected packages. <cbaines>Rutherther, it shouldn't cause any rebuilds, but again, checking this is harder at the moment, I don't really trust the Cuirass bot to give accurate data on the changes in Pull Requests (at least based off it saying things have changed when they shouldn't have in some of my Pull Requests) <Rutherther>cbaines: yeah the bot sometimes confuses the 'base' somehow, not sure how exactly it works <Rutherther>cbaines: additionally one is quite blind to the 'base', unlike with QA, where you can clearly see what it compares... <jakef>hey lilyp, emacs-next has compile-command using -j(num-processors) and it looks like (num-processors) from the build machine has been baked in <jakef>not sure if guix bug or emacs bug <lilyp>hmm, I don't think it's part of the package definition, so it probably gets added through the Makefile or some such <lilyp>feel free to file a patch for emacs-team if you find the root cause <jakef>might be from the dump file in libexec/... <elevenkb>Hi, I'm going to reinstall guix after a long break. I used to have encrypted root but I find it really annoying to retype my passphrase twice. <elevenkb>Would it help to encrypt /home only, or something? <Rutherther>elevenkb: yes, encrypting only /home will mean grub doesn't need to decrypt. GRUB needs to be able to read both /boot and /gnu/store. As long as these are not encrypted, you do not have to type password twice <czan>Using the extra-initrd way of doing things still results in a slow decryption from grub. I personally just use the separate home option that the installer gives, which is enough for my purposes. <Rutherther>I copy linux and initrd to /boot with a custom bootloader <czan>How does that go with multiple generations? You just have to copy each of them into /boot? <Rutherther>yes, all variants in all available generations are copied <elevenkb>Trouble is bootstrapping... you can't install it as your first bootloader. <lilyp>jakef: if it's in the dump, then that's probably within a variable that's set somewhere; we already change how the dump gets done, so that shouldn't be too hard a change <yarl>Could someone take a look and tell me if it's my fault or if it's on cuirass? <Rutherther>yarl: I don't think it's your fault. You can try pulling your branch to make sure, though <yarl>Rutherther: What do you mean, how? <yarl>You mean force-push again? <Rutherther>yarl: "guix time-machine --branch=yarlb/home-git-annex-assistant-service --url=file:///path/to/your/checkout" would be one way <bjc>anyone know why i can use the new inherited syntax for operating-system's ‘services’ field, but not ‘users’ or ‘packages’? <Rutherther>bjc: because only services is thunked. It works only with thunked fields <bjc>i assume that's hard to extend to arbitrary fields? <bjc>oh that's probably because of delayed evaluation, so the answer is "yes, it is hard" <Rutherther>the mechanism would have to be quite different I think. Not sure how it would work <bjc>makes it rather hard to use, then <Rutherther>does it? It's very common pattern to change only the thunked fields when changing inherited packages <bjc>i'm trying to use it with ‘operating-system’ <Rutherther>as for users I would recommend you to instead use the user account service for extensions from other parts of your system <bjc>i know other ways to do it, i was just hoping this'd work since it'd be cleaner <Rutherther>as for the packages field... I believe we should make it thunked <bjc>the issue is that i can't tell when it's available as syntax or not <Rutherther>Ludo also agreed that making packages field thunked makes sense <bjc>so unless all the fields are available it might as well be none, for my purposes <Rutherther>but as a workaround even with the packages field you can just extend the profile service type <Rutherther>imo using services to expand a system is clearer way, but that's more of a personal opinion <bjc>i don't really have an opinion, i just want consistency <bjc>the manual is pretty good, but i spend too much time reading it =) <Rutherther>ie. "(simple-service 'add-git profile-service-type (list git))" <bjc>from my perspective it's not relevant whether or not a field is thunked when i'm using it, and would not be able to tell you without digging into source <bjc>so using that as a discriminator for a bit of syntax makes that syntax difficult to use without a lot of experience in guix internals <vknc>hi, Does anyone have a config that I can refer which has setup greetd-wlgreet-sway-session with %base-services? <vknc>or any minimal login manager setup <aliu>i have a guix system that's pretty much fresh install with a few packages installed through guix install; all of them should just apps except for sddm and usbmuxd. should i be concerned that guix is currently building the ilnux kernel instead of downloading a substitute? <aliu>this is during a system reconfigure to just update it <aliu>ah, i think i see what's happening. thanks! <csantosb>Oh ! I love the new `guix upgrade` arrangement, each package along with its version number <ieure>I saw that patch, seemed nice. I don't use imperative package management for anything, though. <bdunahu>is it known that `guix lint` reports on vulnerabilities for different software of the same name? For example, `guix lint helm` only reports vulnerabilities for a Kubernetes package manager, which is not what is in guix <bdunahu>since it looks like it's doing a name lookup, if there were two software of the same name in guix and one had to be named differently, then it might not work for that package either <bdunahu>I'll put in issues just in case, it seems difficult to fix <csantosb>`guix lint helm` gives me "gnu/packages/music.scm:7052:2: helm@0.9.0 : ... " <bdunahu>the version numbers for each software might line up in such a way it gets confused just by checking package name, version <folaht>I don't have sound for my VM. The VM seems to work fine, so it's likely an issue with my configuration of virt-manager on my host OS (Guix). <folaht>And I used a second guset VM to confirm that the sound does not work there either. <ieure>Hmm, looks like master might be broken, reconfiguring complains that there are multiple dbus services. <simendsjo>I like the new "Records can refer to inherited values"! Nice ergonomic change, although it might cause some breakage -- I think I have some `version` variables which will be shadowed in packages now. <ieure>avigatori, I believe this is because gdm is the default greeter regardless of the DE used after you log in. <avigatori>oh that reminds me, does anyone else experience that one can see the desktop for like 3-4s after suspend before the screen locker ... well locks the screen on plasma? <Rutherther>tschilp: so what image type are you creating? You need to use one that is EFI when you are using efi bootloader (grub-efi-bootloader) <tschilp>Rutherther: I'm just trying to run the sequence of commands proposed in the docs. So it's the one defined in lightweight-desktop.tmpl ~image=$(guix system image --image-type=qcow2 gnu/system/examples/lightweight-desktop.tmpl)~ <Rutherther>tschilp: so you will need to use qcow2-gpt type then if you're using grub-efi-bootloader <Rutherther>if the manual says what you mentioned, the manual is wrong and should be adapted <tschilp>Rutherther: thanks, this seems to build now, looks like the manual is off in this place indeed! <bdunahu>trying to build packages on master right now seems broken, unless it is my environment <ieure>donfelohke, Hurd runs a subset of the same packages in Guix when it runs on Linux. It runs a subset because Hurd is still pre-alpha and many things are broken or missing. <donfelohke>Congrats to The Guix team for x64 Hurd support: Software support should be the next priority for the community. We Need Hurd/Guix like yesterday... Main/Upstream Free Software Priority!