IRC channel logs
2026-08-28.log
back to list of logs
<guix-noob>Is that not similar to nix's override feature? <folaht>When guix rolls back, what exactly is being rolled back? Does it include my system configuration if it's saved in /etc/config.scm? <ieure>folaht, The active generation of the profile. The configuration file is not touched. <ieure>folaht, Each system generation saves the configuration which created it, placing it in the store. <ieure>So it doesn't need to manipulate any configuration file state. <sham1>guix-noob: g-expressions differ from Nix's overrides in that they're not at all a similar feature <ieure>The Guix analogue of an override is a package variant. <folaht>ieure, I see. So if one made a mistake in the configuration file.... I guess since one can test it with 'guix system vm' it's not really an issue. <ieure>folaht, I'm not really sure what you're saying. <ieure>folaht, Saving the config for the generation is very helpful if you want to diff the config, either between generations, or against your working copy, or if you don't use version control and need to revert broken changes in your working config. <folaht>ieure, I altered my '/etc/config.scm' considerably and did a 'sudo guix reconfigure /etc/config.scm' and I was no longer able to start gdm. <guix-noob>I am currently browsing the documentation since I did not understand, if I should be honest. <ieure>sham1, I think this is not a great explanation for people new to Guix. <ieure>folaht, I would diff your /etc/config.scm against the config for the last working generation. <ieure>folaht, Also, strongly recommend putting your configuration into version control, even just a local Git repo. There is nothing special about /etc/config.scm, the file can be anywhere on disk. Mine are in $HOME/projects/dotfiles/system/$(hostname).scm <folaht>ieure, I'm about to, with dotfiles, but I haven't gotten my first dotfiles setup working yet. <sham1>Well I don't know what else you'd really link. I guess there's this blog post: <https://guix.gnu.org/en/blog/2023/dissecting-guix-part-3-g-expressions/> But beyond that I don't know if there's much that a person who's new to Guix could look at for g-expressions. Well I guess it depends on how much they know Scheme, because if one knows a lot about Scheme, you could compare g-expressions to syntax objects <guix-noob>and make a bash function for easier upgrades. 😉 <guix-noob>Cannot see emojies, somehow. Guess my font is lacking. <folaht>This was my first attempt really. It didn't work, so I tried the /etc/config.scm instead, but I had altered that one as well during the making of my dotfiles setup. <guix-noob>How hard is it to package fonts in guix? I can see the font I am using missing from the package list in guix. <ieure>folaht, I'm not suggesting anything more than `mkdir ~/projects/guix && cd !$ && cp /etc/config.scm . && git init . && git commit -am "Initial commit"' -- then reconfiguring from that file instead of /etc/config.scm. <ieure>guix-noob, Fonts, like anything else in Guix, are expected to build from source. So if your font cannot do that, you have to make a binary package for it / cannot contribute it. <guix-noob>And I can see nix being listed there as a possible installtion method. Ouch. <ieure>guix-noob, Take a look at the other font packages in Guix. Tons of prior art in the repo, lots of good stuff to rob from. <sham1>I recall someone else also asking about this last night <guix-noob>I wonder if that person spoke one of the languages that font is known for, cjk. <guix-noob>That's actually the main reason for that specific font. <guix-noob>Wow, I was not familiar with that site! Apparently the package exists, just in another channel. <ieure>Yes, surprising number of channels out there. <guix-noob>But wouldn't more channels mean we have to track more places for security measures? How come there is not one unified place that one could use? Something like nix-community group on github has home-manager listed as a possible alternative. <guix-noob>Wait... there seems to be one. Very interesting. I wonder why people don't favour that place. <sham1>It's not that different from people using multiple flake inputs in Nix <guix-noob>Not sure how it looks like in nix, but I assume it's less scattered considering they are not strict about nonfree packages. <guix-noob>The once mentioned in the channels are nto proper builds of the font though, they just fetch the pre-built files. Interesting... <Guest5>ieure: Thanks. I too am using a custom kernel. <Guest5>Anyway there are talks about the new package that added debian kernel or something into the main guix channel. Are we diverging from FSF or what? <sham1>The Debian kernel _should be_ compatible with the FDSG, as long as the proprietary firmware blobs are not getting distributed, which they aren't <sham1>That was the argument presented in the relevant issues and PRs <PuercoPop>Can one add custom attributes to records or configurations (records created with define-configuration) so that one can iterate over the fields and select some fields based on the custom attributes)? <PuercoPop>Or do scheme records support something like a Meta-Object Protocol? <stephen0>What was that command to format a scheme file? <sham1>I don't know if Guile's records proper support the MOP, but IIRC GOOPS (the OO implementation in Guile that's based on the ideas in CLOS) should support the MOP <sham1>But yeah, you really can't extend record in that way <PuercoPop>Too bad. Guix uses define-record for configurations so GOOPS is not possible to user, but maybe a macrolet to do the bookeeping at macro expansion time could work. I think macrolet is called something else in guile <sham1>I _think_ records might also be GOOPS classes, but I'm not 100% on that. #guile would know more <oliverD>I was just wondering with packaging Comaps I tried to build it in the Guix development environment `guix shell --pure -D guix` but apparently ssl certificates don't work there (running ./configure.sh after exiting the environment works). <oliverD>If I understand correctly the (native-inputs) list should have the packages needed in the ./configure phase and dependencies should be in (inputs) list? <oliverD>Still trying to fix dependcies for the ./configure phase <oliverD>* Still trying to fix dependencies for the ./configure phase <untrusem>oliverD: I use `guix shell -m manifiest --pure` <untrusem>oliverD: yep native-inputs for configure phase <csantosb>Good morning Guix from Emacs 31.1 ! So far, so good. <csantosb>This increasing list of broken packages is in !10863 and !10882 <kratacoa>hello, last xdg-desktop-portal seems to break `system reconfigure`: `guix/ui.scm:1033:18: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f` <attila_lendvai>kratacoa, i have also seen that. but i have booted back to the pre gnome update state... is that package still needed/useful? <kratacoa>attila_lendvai: I am using it with sway and wroots. Not sure if it's still useful as last I've pondered this question had been more than a year ago, but it used to be needed for various things e.g. screensharing <kratacoa>untrusem: thanks. what is the issue then? <kratacoa>attila_lendvai: if you use gnome you're using the gnome compositor, no? <attila_lendvai>kratacoa, i guess. i'm consciously ignorant of these things. i just quietly tolerated all the new gnome stuff for not having to learn the underlying machinery. <kratacoa>attila_lendvai: understandable, nowadays I can't be arsed either :) <untrusem>I have created a manifest with all the guix's emacs packages I use in a separate profile, so what I want is, A emacs that I is in default $GUIX_PROFILE i.e .guix-profile/ but I want want all the guix's emacs packages in a different profile, I did that in .guix-extra-profiles/verito/emacs/ , and I want the default profile's emacs to be able to use this profile emacs packages <untrusem> guix package --search-paths -p ".guix-extra-profiles/verito/emacs" gives me $PATH, $MAN_PATH, $INFO_PATH that I need to add, but the emacs packages would be in /share so I don't think it will help in this case <ieure>untrusem, A few options. EMACSLOADPATH might give you the leverage you need here. I think emacs-guix also has a thing to activate a profile from within Emacs, maybe you can use or repurpose some of that code? Worst case, you can walk the profile directory in elisp and add stuff to `load-path'. <ieure>untrusem, Simplest thing here is to include emacs in the same profile as the packages, why not that? <ieure>That will Just Work, because it's how Guix is designed to work. <untrusem>all this would work if guix home would let only upgrade a set of packages <ieure>That wouldn't be declarative. <untrusem>I have my emacs package in guix home currently I reconfigure every two weeks or so but If I want to add, remove or update something in emacs, I have to reconfigure again and again, I don't want to download the whole updates just for emacs things <untrusem>I would also include emacs in my guix-extra-profile but I want it to access guix-home and default profile packages <ieure>untrusem, I think it should do that, if you launch as `guix shell -p .guix-extra-profile/verito/emacs -- emacs' <ieure>If I `guix shell some-package', I can still access anything in my home profile. I suppose there could be an issue with Emacs packages specifically, but for normal stuff on $PATH, that's how it already works. <ieure>Fair assumption that Emacs packages work the same way. <untrusem>I wanted to avoid shell but I guess I will use it <lechner>Hi, how may I add LKMS modules to my initrd, please? <ieure>lechner, initrd-modules field in your operating-system, or do you need something different than that? <lechner>ieure / Thanks, but it looks like #1917 on Codeberg is still open. <ieure>Mm, yeah, I guess there is no solution until that merges, then. <trannus_aran>I swear I can never keep straight inputs, native inputs, and propagated inputs x.x <ieure>trannus_aran, Would you like an explanation, or is this venting? <lechner>trannus_aran / propagated inputs are different; they are available in consuming packages and may cause conflicts there <ieure>lechner, That's not really how they work. <lechner>native inputs are misnamed; they provide architecture-specific files in for HOST rather than the TARGET, in GNU language <lechner>i am just trying to help but could be wrong <ieure>lechner, propagated-inputs work the same as normal inputs, but propagate into the *profile* of the package doing the propagating, as if the user had requested their inclusion. <ieure>So if you have a python-foo package with python-bar as a propagated-input, `guix shell python-foo' gives you the same result as if the package was not propagated, and you ran `guix shell python-foo python-bar'. <trannus_aran>ieure: re: explanation vs venting, it's a bit of both honestly <trannus_aran>Propagated inputs are for packages needed at runtime for the package in question <trannus_aran>Native inputs are architecture-specific, sure, but those are often things like autoconf and bison, yeah? <ieure>Yes. And native-inputs are inputs you need for the build process, rather than the runtime process. That includes concerns like cross-compilation, but also things like tooling to generate documentation -- you only want the output in the package, and don't care (from a runtime perspective) how you got them. <ieure>The leading "Yes" there made more sense before the intermediate message. <lechner>i never understood what to do if i need a package both as a "native" and as a regular input <lechner>trannus_aran / your message made sense to me <trannus_aran>I think I've just never been clear on what "inputs" are for, if not propagated to the profile, nor needed for just the building process <lechner>trannus_aran / the name comes from the functional model. it's mathematics! <lechner>a package gets rebuilt when any of its inputs has changed <trannus_aran>Right, but what functionally goes there? Say I'm building a guile library that depends on some other guile libraries: are those propagated inputs or just inputs? <trannus_aran>Cause seemingly in that case, guile itself is needed as a native-input for the guile-build-system <trannus_aran>(also no idea if there's any benefit/drawback to using that over the gnu build system with added ceremony the way everything in guile-xyz seems to do) <lechner>yeah, it's interesting that Guix package model does not actually work well for Guile modules <lechner>otherwise, your have to list all so-called "transitive" prerequisites in the top package <lechner>fortunately, that's also how the module system works in Guile; it is not possible to use two versions of the same module <trannus_aran>But that still leaves me with my last question, what are just plain "inputs" for, if not for the build, nor for the runtime? <sham1>Well the inputs are for runtime, but unlike propagated-inputs they're not, well, propagated to the user's profile <sham1>They essentially are your main dependencies, the stuff that you need to have in the store for you to be able to use a package, but that don't need to be in the user's profile <lechner>trannus_aran / i think your confusion is winning again. regular inputs are exactly for the runtime. the "native" inputs are for the build" time <trannus_aran>Got it, so are there any useful heuristics to tease out when they'd need to be propagated for the runtime vs not? <lechner>interpreted languages are usually much easier to use with propagated inputs <trannus_aran>Presumably runtime libraries needed by some compiled binary could stand to be standard inputs, then. I'm picturing some C project that calls out to libcurl <lechner>trannus_aran / exactly! you've conquered your confusion. <podiki>what's going on with cuirass/berlin? why have evaluations been failing for a while? <cqstia>I have some bug with X11 and my libraries so, gdm is just stuck constantly restarting, I'm trying to fix it but is there any way to stop GDM from trying to constanly restart itself? <cqstia>On guix system. At runtime without adjusting the config, I can ssh in <cqstia>I tried herd stop x11-display but that did not work <ieure>cqstia, SSH into the machine, `sudo herd stop xorg-server' <graywolf>Hm, how can I get a hash of linux source for the upstream kernel? I am unsure how to achieve that, since 38a7797012907bc8e0ec5f6d4e76aede9666e38a .