IRC channel logs
2026-01-30.log
back to list of logs
<cnx>Could some committer please go through the user-reviewed label, especially the simple version bumps? I don't like leaving contributors hanging (some even start to get conflicts at the copyright headers). <loquatdev>I'm writing a procedure that returns a procedure that accepts a home environment and returns a home environment with slight modifications. If I am just re-using the original services, why am I getting this error? <loquatdev>`guix home: error: more than one target service of type 'home'` <mange>How are you constructing the new home-environment? <loquatdev>Apologies for the disconnection. I'll send my paste <ieure>loquatdev, You need to use home-environment-user-services to get the services to modify, not home-environment-services. <ieure>loquatdev, add-services has most of the logic, but add-services* is the thing I use most, it returns a transformation which adds services to some object. Works on home-environment and operating-system. See (atomized home profiles) / (atomized system profiles) for many examples of its use. <ieure>ex. (add-services* (service 'foo-service-type) (service 'bar-service-type)), that'll return a procedure that adds those services to whatever object type it understands, given as the only argument. Many other helpers/utilities in there as well. <elb>I'm seeing a problem where guix profiles other than current-guix are not being created in /var/guix/profiles/per-user for my user (it's just me on the machine, so maybe for all users?) <ieure>Have been thinking about PR'ing this, there's already a module it would fit into, but I'm not sure I want it there because of reasons. <elb>/var/guix/profiles/per-user/elb is 755 elb:guix-daemon, but if I change it to 775 it just changes back to 755 when I build a new profile <elb>no, I lie, it stays 775, but the links are still not created <Guest21>i am using grub efi in my config, but the system tries to build grub-pc which fails, since I am on aarch64. is it broken? <elb>(the net result of this is that guix gc breaks my profiles!) <mange>elb: Are you using the unprivileged guix daemon? Is it definitely running with the guix-daemon group? <elb>mange: I am running the unprivileged guix daemon; let me dig in proc for a second <loquatdev>ieure, why is that the case? If I'm inheriting an operating-system, I can set services to (operating-system-services os). I tried home-environment-user-services and it worked; I'm just trying to understand the difference. <elb>mange: yes, it appears to be running as guix-daemon:guix-daemon <elb>journalctl -xe -u guix-daemon just says "accepted connection from pid xxxxxx, user elb" and a few "SIGPOLL" <Guest21>got it, the vm cmd overwrites my boot loader config. wasn't aware of that <mange>elb: Looking at package.scm, I think the profile changes are made by the user running the "guix" command, rather than the daemon. Are you having trouble with the default profile (i.e. the one "guix install" affects)? Or only when using "guix package --profile=..."? <mange>I'm also curious whether you're seeing your profiles in /var/guix/gcroots/auto. <elb>mange: guix pull worked and created a profile <elb>there is no link to the profile in /var/guix/gcroots/auto <mange>Does "guix install hello" do anything to /var/guix/profiles/per-user/elb? <elb>as my user I can create and remove files and links in /var/guix/profiles/per-user/elb <elb>it created a guix-profile and guix-profile-1-link <mange>Okay, so are you having trouble with "guix package --profile=..."? <elb>I'm running guix package -p base -m base-manifest.scm <mange>Right. I don't think those are meant to end up in /var/guix/profiles/per-user/elb. They just end up in /var/guix/gcroots/auto, I believe. <elb>let me check on another machine, I thought they did <mange>But with a crazy name. You need to look at the symlink target to find them. <elb>ok you are correct, they show up in /var/guix/gcroots/auto on my other machine, not in per-user <elb>on this machine they show up in neither place <mange>Can your daemon write to /var/guix/gcroots/auto? <elb>base-1-link has a symlink in /var/guix/gcroots/auto <elb>so why is guix gc collecting it <elb>uh let me see if it happens again or if it was transient <mange>If the target of a symlink from /auto disappears (or is renamed so the link is broken) then Guix will happily collect the profile. <elb>and the link in /var/guix/gcroots/auto is now broken <mange>But I guess that's not happening in this case? <elb>no it was a valid link before I ran guix gc <mange>Hmm. Can the guix daemon see the link target? <elb>ahhhh maybe not, when I run guix gc _again_ it says "cannot read potential root ...": Permission denied <mange>If your profile is somewhere that the daemon can't see then the link is effectively broken from its perspective, so it doesn't know about the profile's contents. <elb>this actually makes sense <elb>so what I had was, I was running using the debian guix package <elb>it was removed, so I removed that, and I installed 1.5.0 and updated from there <elb>the debian package is _not_ unprivileged <elb>so I reinstalled everything, everything seemed to be working, I ran guix gc, and blammo ... but I bet I just need to massage the permissions on my home directory stuff <elb>ok let me rebuild a profile and see wht happens <mange>Mmm. This seems like a bit of a trap, though. It's not obvious that you need to do this (and it's not ideal to have to open your home to everyone on a multi-user machine). <elb>I agree, but in this case it's not a problem for me, I just did chmod 751 ~ and checked .guix-local and it had reasonable permissions for this <elb>I'm the only user on ethe machine and the only one who knows the passphrase to decrypt the disk, so ;-) <mange>Well, I'm glad we solved your problem. :) <elb>I could have chased that for a _while_ <elb>I'm sure g uix gc was actually emitting a diagnostic, but it always prints out so much goop that I just didn't even think to look through it for an _error_ <elb>running it twice in a row would have told me the problem <elb>I don't know how practical it is, but having it emit the diagnostic that there were roots it could not find for permissions reasons _after the million pages of status_ would have probably tipped me off <mange>I haven't read the whole thread yet, though, so I don't know the conclusion it comes to. <elb>one suggestion is moving some of the roots to per-user, but that won't help me in this particular case <mange>If there isn't an issue for the specific issue you ran into it might be worth raising one. Guix could presumably store extra profiles in /var/guix so they can be found. <elb>I ... suppose I could just _create_ my roots there, though, right? <elb>it looks like that directory is just plain owned by me after `guix pull` <mange>Yeah, and then you can have a symlink from your home into /var/guix/... <mange>But, like, Guix could just do that for you, right? It already does for ~/.guix-profile and ~/.config/guix/current. <elb>yeah I think that issue is actually subtly different, their guix gc was actually failingm <elb>mine ran just fine, it just gc'd the profile I was actually using <elb>so when I tried to run guile, it was like "what guile?" <elb>the concern I see with that is managing -p -d consistently <elb>not that it can't be done, but it would certainly get a lot more complicated <elb>goblins has also been giving me trouble on check, it doesn't terminate <mange>I'm not sure "break things unexpectedly if you use -p" is an acceptable status quo, though. <elb>if I C-c and just run the install again, it installs fine <elb>(although I wouldn't expect the builder to necessarily quit immediately just beacuse I hit C-c, and I don't know why it installs fine the second time?) <elb>if I leave it long enough without interrupting it, the build eventually just fails, and again, trying a second time just works <elb>anyway I should probably just file a ticket for that <elb>I'm looking at some gc tickets here to see if my problem is already in there <elb>mange: it just occurred to me that another possible workaround for this problem would be to have guix-daemon check to see if it can reach the profile symlink _when it is created_ <elb>that won't help someone who chmod's post facto, but it's another thing that would have tipped me off in this particular case <apteryx>wow, clang 20 weighs a whooping 890.3 MiB <elb>cc on my pdp-11 runs in 64 kB of core and likes it <elb>actually that's not true it doesn't like it, it takes like 45 seconds to compile hello world because it has to run so many binaries to make it happen, but still <nikolar>it definitely didn't take me that long (on an emulated pdp-11 but still) <nikolar>it took a while to compile the kernel, but hello world was fine! <elb>this is an 11/34 with an RL02 <elb>in emulation you usually don't have to wait for disk seeks ;-) <nikolar>can't remember about the disk though <ieure>elb, You have a real PDP-11/34? <elb>(also lostbits.net/the-basement) <rkazak>I executed a "guix pull" followed by a reconfigure and expected to see guix's "-V" command to display 1.5 however I get a long (commit?) number... <elb>rkazak: if you check that commit against the history of the guix repository, you should find that the commit released as guix-1.5.0 is one of its ancestors :-) <tux0r>i'm officially an elb fan now <elb>heh I didn't _make_ it, I just _have_ it <elb>I loved them for historical reasons before I really got to know them, the processor handbook taught me to love them for their architecture, and using them taught me to love them for the experience <tux0r>i wish i _had_ one. :D (granted, they were less capable than whatever GE did, but the software available for them even today is amazing) <elb>they were less capable than a lot of things ... but not for the price <elb>mange: I filed #6023, thank you for your help! <mange>Great! The more I've thought about it the more I dislike 4, because now the profile can't be collected unless the user knows to go in to clear out the root in the profiles dir. <mange>Is anyone around interested in Lua packages in Guix? I've just updated https://codeberg.org/guix/guix/pulls/2796 to make Lua play nice with Guix search paths (so you can use "guix shell lua@5.3 lua-lpeg" and have require('lpeg') actually work), but it's been open for 4 months without a review. :( <apteryx>seen trying guix-install.sh on ubuntu 22.04: Could not open 'abi/4.0': Aucun fichier ou dossier de ce nom, at the time it attempts to install some AppArmor profile <apteryx>had to skip the apparmor profile for guix-install.sh to complete <oliverD>Would the AR9271 wireless network card be compatible with Guix (without any reconfiguring or does it depend on the supplier). Sorry lack of wireless is the main thing I have issue with. <loquatdev>I'm writing a package that uses url-fetch in the origin. The .tar.gz file that it downloads extracts into a subfolder. Is there a flag to avoid creating a subfolder? <loquatdev>I have a patch that's failing because all of the source code is being extracted into a subdirectory of the build directory. I verified that this is the issue with --keep-failed. <mange>loquatdev: Can you just add a phase after unpack to (chdir "subdir-name")? <loquatdev>mange: That's my go-to. I was just wondering if there was some other way. <mange>The unpack phase of gnu-build-system should try to enter the first subdirectory of the extracted result. Is that not what you're seeing? <loquatdev>Perhaps the archive has a second subdirectory in it for some reason. <parra>cbaines: channels-with-substitutes-available is not working neither.. all architectures get pulled into HEAD and it takes the same amount of time, also riscv64 not compiling because it fails a test in cmake-bootstrap... <oliverD>I eventually tried to add the nonguix channel but my computer has been frozen spinning for the past hour <Rutherther>parra: channels with substitutes available just checks the guix self itself has substitutes, so you wont have to wait too long for guix pull. It does not check if packages have substitutes <light`>Is anyone currently here, I'm having problem with setting up hibernate <parra>Rutherther: I did not get you <parra>I'm just thinking to ditch riscv64 <light`>Hello parra, can you help me with hibernation. <parra>I am a noob with guix and I never used it as system, I use it for compiling and distributing software <parra>cbaines: I did a test and using codeberg directly builds faster than channel-with-substitutes-available <parra>but the idea is really good, if it worked properly and it were implemented for multiple CIs it would be awesome <parra>but right now it seems not working at all, it's just pulling to HEAD <Rutherther>parra: It is pulling to the latest commit with guix jobset substitutes on your %current-system. That happens to be the HEAD of master at the moment <Rutherther>parra: most of the time it happens to be the HEAD of master on x 86 64 which I expect is the machine you are using to evaluate this code <parra>Rutherther: it's giving me HEAD with riscv64 too and it's compiling the substitutes due to --fallback, and it's taking +6h.. so I assume it's not working, when there's no substitutes it just uses HEAD <parra>at the end of the build you can see the whole channels.scm <parra>all of them are pinned into HEAD, even riscv64 but it did not finish <parra>basically the problem is that I cannot build riscv64 in any way, it's better if I ditch it, I supported 386 and x86_64 before only so I think I did a big improvement already <parra>if you don't have any other alternative I would just skip riscv64 for now <rrobin>does guix copy (or guile-ssh) do something special with known hosts - i'm getting 'error: failed to authenticate server at 'localhost': known-changed' even though regular ssh is working <rrobin>ah i think i found it - probably due to HostKeyAlias in ssh config <abbe>is there a pre-existing way to have subdirectory of the 'origin' as the 'origin' ? i.e. something like a wrapper/transformer <futurile>abbe: the top-level of the <origin> is a git repo, but the source is in a different subdirectory? <parra>I have another question, if I get a commit from today, and I pull it in a month or two, there will be substitutes? are all substitutes maintained forever or they get deleted from time to time? it means that I can still maintain incremental builds if I delay them in time letting the CIs build the substitutes, no? <futurile>parra: I think we keep them for a while but not forever as it makes mirroring difficult and takes up a lot of space since we build every change. <parra>so for example riscv is also constantly being kept up to date? <futurile>parra: well I think you chatted with Chris about this yesterday. Yes we're building RISCV but I'm not sure how usable it is as we don't have that much resource on it from what I can tell. Your best option is to ask on the mailing list because AFAIK Chris and Andreas are the people who know about this. <parra>futurile: you are right we talked yesterday, I think the best option for now is to remove it from my CI builds meanwhile it fails because it's just fragile, I cannot think of a better way of making it work... with the other architectures it's enough <parra>sorry about it, I think I'm just overthinking <futurile>parra: for the latest release we agreed what our 'primary architectures' were and what is 'everything else'. Realistically we can have good substitute availability for x86 and arm64 and that's it. Even ARM is a bit of a push. <Rutherther>futurile: yeah the ungrafting has left some packages without substitutes on arm64 for quite some time. If we were on the schedule there would be substitutes missing for the desktop manifest for sure <futurile>Rutherther: see the thread on guix-devel about speeding up our commit cycle. <futurile>Rutherther: I know you have some thoughts there ;-) ... also it's generally starting to discuss CI/QA/Substitutes etc - I wonder whether we need more arm64 hardware/resource <Rutherther>futurile: I have seen it. Didnt have time to reply yet <nemin>Hey guys, if I want to suggest changes to documentation, would making an Issue on Codeberg be the right way to ask for a team opinion? I think it'd be beneficial to have a section about how to make cargo-build-system work with git rev based Cargo.toml entries, because it's non-trivial and requires digging into other packages to figure out. <parra>thanks to everyone, you have been really helpful <untrusem->btw did you not stumble upon cargo-audit error while packaging wezterm? <nemin>And thanks for the link... I really should've searched first. <abbe>futurile: sorry, yes, a subdirectory of a git repository <Minall>I'm not sure how it works, but it would make me a docker image with guixSD for example, which I could call and later archive?, in order to ensure behavior regardless of my environment? <Kabouik>What could explain a package working fine in `guix shell` but not in the main profile, like here https://0x0.st/Pqcu.txt? The env I guess? I do not understand what Python the error says. <Kabouik>Oh well, `guix shell pantalaimon --check -- pantalaimon --help` produces the same error, so that confirms an env issue I think. <futurile>Kabouik: it sounds like that app has a ui and maybe a cli option? It's failing to find glib, so maybe there's a missing package <Kabouik>(The above command obviously doesn't work, can't use `-- command` after `--check`; I actually did that in two distinct steps and thought they could be reduced to one command when posting here) <Kabouik>Which means I actually ran `pantalaimon --help` from the main profile instead of the guix shell above, so that's not a valid test at all. <Kabouik>futurile: I don't know if it has a GUI mode, but at least the error does not show up in `guix shell`. Are there cases whereby a shell would better resolve deps than a plain `guix install xxx`? <futurile>Kabouik: not in the resolving. Sometimes you see clashing dependencies when installing something into a profile. and it defintely works in guix shell? <futurile>Kabouik: is it just plain 'guix shell whatever -- pantalaimon --help' or in a container? <Kabouik>I don't know, I have no config yet, I was just trying to install it to work on my config as a second step. When I saw the error, I tried in the shell, and saw it doesn't crash there. <Kabouik>Just `guix shell pantalaimon -- pantalaimon --help` <avalenn>hello, is there any east way to expose some TCP port from a "guix shell --container" to the host ? <fhang>csantosb: Ah, I see. Thanks! <nemin>Hmm, how would one go about using fonts as inputs in a package? Wezterm requires JetBrains Mono, which does indeed have a package, but even if I add it to the propagated-inputs, it cannot see it. The package does offer an option to vendor it, but I'm not sure if that's considered idiomatic for Guix. <futurile>avalenn: no, at that point you're moving into need a full container like docker etc <nemin>(Uh, that last sentence ended up being real vague. What I meant is that Wezterm has a Cargo feature to bundle JB Mono.) <futurile>avalenn: there's a the --network option, I don't know if you could do something weird with netcat to have the process listen on the port maybe - just spit balling an idea really, never done it <futurile>nemin: you can't use wezterm by installing it and jetbrains mono font at the same time? <nemin>futurile: Nope, it seemingly cannot load it that way. Weirdly enough neither can fc-match. <futurile>nemin: seems like there's a `wezterm ls-fonts` which can show the fonts it can see. The example seems to show it's aware of a home dir fonts directory <nemin>futurile: I tried that, but it tries to use Noto Color Emoji for everything. If I manually do --config "font=wezterm.font 'Fira Code'" then it works. <avalenn>futurile, thank you, I suspected it was so, will avoid to do weird things for now, work around was not using container (not really necessary in my use case) <futurile>nemin: If you want to alter the package then you probably want to add the font you want to inputs, and maybe there'll be a switch in the build instructions. Seems odd it can't find a font you're providing as part of config <futurile>nemin: so in 'inputs' not 'propagated inputs' <nemin>futurile: Worth a shot, thank you. <futurile>nemin: also maybe check codeberg issues to see if anyone else has had issues with Wezterm configuration <nemin>I'm pretty sure this is a Guix-only issue :) Other distros probably just use the default bundling and that's that. <futurile>yeah I meant Guix's codeberg - just in case someone else has worked on a solution already <futurile>sometimes I've landed up working on a package only to discover there was an existing patch heh <nemin>Oh, I'd be surprised, afaik nobody packaged Wezterm for Guix before me. <nemin>Ah, sweet victory. I was able to patch the source with font-* packages and that works. futurile, thank you again for the help! I hope the maintainers will not shred my PR to pieces. <ieure>shred my PR in to pieces / this is my last reort <quassel-guy>untrusem- bro can you give me a snippet your system.scm? I just can't get it to work. <jeko>I want to build a package from a custom channel I just updated. So I guess I need to pull. But guix pull breaks with guix channel so i don't see the new package I added. is there a way to pull only a custom channel ? <jeko>or maybe I can put the definition in a file and build from it… <jeko>Oops, I did not read the log enough… The package I want to build is the package breaking… sorry ! <jeko>ah no erk this is not the right log… <untrusem->I am on Guix, I just use a their script, btw `hibernate to disk & power off (ACPI S4)` doesn't work `hibernate to disk and suspend` works <ieure>untrusem-, Are you using disk encryption? <ieure>Hiernation has never worked for me on Guix. I don't know if it's a FDE/no-FDE situation, since I always use FDE. But I suspect that may be the case. <jeko>ieure Ok, confirmed. My package does break. Damn <ieure>jeko, I pulled, no problems. <jeko>sorry to bothered you with taht <untrusem->so can copy zzz to your local channel if you want want to pull in a whole channel its basically copying just the script <ieure>I don't think the script from void will work if the underlying kernel mechanism is broken, which seems to be the case for me. <ieure>yelninei, The waking up part. <untrusem->quassel-guy, don't thank me, I didn't do anything <quassel-guy>untrusem-, I didn't know about the script, and I'm a noob so I can't package stuff yet. So this helped me a lot. <nckx>quassel-guy: What exactly are you doing and how doesn't it work? <ieure>Actually, looks like GNOME doesn't even have the hibernate option in its power menu for me now. <ieure>Suspend, restart, power off, log out. <quassel-guy>nckx, I added resume=uuid= kernel argument, didn't resume properly <ieure>Suspend is the normal close-the-lid sleep. <untrusem->I mean you could have just copied the script in some dir and execute it by hand but yeah a package helps <untrusem->I don't use any kernel arguments other an "psi=1" for waydroid <quassel-guy>untrusem-, The package is supposed to make it "reproducible" right <nckx>That zzz script just asks Linux to hibernate, it won't fix a broken setup. It's to save keystrokes & run hooks. <nckx>(I know you know, but they might not.) <ieure>Okay, I just tried `sudo loginctl hibernate'. Nothing at all happened. <ieure>`loginctl hibernate' returned an exit status of 1. <nckx>So, you echo disk to /sys/power/state, the machine hibernates, but fails to resume? <quassel-guy>printf disk >/sys/power/state, when I had the resume kernel argument this command sent my computer to hibernate but it didn't resume <ieure>"echo disk > /sys/power/state" blanks the screen for a second, then it comes back on and says "bash: echo: write error: no such device" <nckx>ACTION doesn't remember adding UUID support for resume= but maybe someone did. <ieure>Ah, this machine has no swap at all. <ieure>That's definitely not going to work. <nckx>ieure: Heh, errno being totally accurate for once. <nckx>IIRC it wasn't a struggle so... yes? <yelninei>ieure: And in my kernel argumens i have resume=/dev/mapper/cryptroot + a resume_offset for the offset of my swapfile <nckx>I added most of the (little, simplj) code needed but it doesn't handle edge cases I'm sure. <quassel-guy>nckx: can you give me your system configuration, through paste.debian maybe? <nckx>quassel-guy: I can't right now, and I'm not sure what it would accomplish. There's nothing to configure befond resume= <nckx>Have you tried replacing uuid=foo with /dev/foo? That's what I've always used & tested. <nckx>quassel-guy: Who told you to use 'uuid=' anyway? <quassel-guy>arch wiki has that, and LLM as well. second one was bad I know <nckx>I'm like 99% sure we don't support that. We do support resume=<an actual UUID without the prefix>. <nckx>So if you want to keep using a UUID, resume=1234-abcd-... should work. <untrusem->I use zram-service-type, and nothing else related to hibernation listed in manual, so have I been mistaking suspend for hiberation all this time, as it turns out hibernation works for me but just the resume won't work after poweroff and reboot because I have not set it up <nckx>If 'uuid=' is some standard we can support it too, but Linux only understands devices. <nckx>Anything else is faked by the distro user space. <ieure>nckx, Bunch of stuff, then "Cannot find swap device" and "cannot get swap writer", followed by it resuming. <quassel-guy>nckx, ahhh, while booting it was telling me it couldn't find a device called UUID=<uuid>, so that was the mistake lol. Thanks <nckx>Right, but we share no code with Arch, they might support very different things & syntaxes for the same thing. <untrusem->so zram-service makes a swapfile on /dev/zram <nckx>ieure: Well you spoiled the mystery, but thanks :) <untrusem->so I should add is as resume=/dev/zram is my kernel arguments I suppose? <ieure>Okay, found the /swap file I made a while back on this host. It's the same size as main RAM. Same error, "cannot find swap device." I guess hibernate requires a swap partition instead of a file. <nckx>Hibernate to RAM = one weird trick. <nckx>Yeah, or raw block offsets, and that's something that 'should work' but which I've never tested because omg tedium. <nckx>There are scripts to automate it, I know. <untrusem->ieure, you can use a zram service and be done with it <quassel-guy>nckx, do I need to have extra options for the swap, currently it's like this: (swap-devices <ieure>The graphical installer doesn't make it easy to set up a swap partition. <ieure>At least, last time I checked. <ieure>untrusem-, Nice, PR updated / ready for review? I can get to that today if so. <quassel-guy>untrusem- If Substitutes don't have the thing I'm stopping everything <nckx>quassel-guy: No, there is really nothing else to configure, Linux does all the actual work. It chooses the swap device, writes & (hopefully) resumes, we just tell it the resume device at boot. <untrusem->ieure, let me double test everything just to be sure <untrusem->`/dev/zram0: 0 extents found` result of doing filefrag -e /dev/zram0 <ieure>quassel-guy, I don't see anything wrong, necessarily, but you're doing a bunch of nested mapping, which is likely not going to be fast. <nckx>ACTION at dinner, will return. <quassel-guy>I mean it doesn't take a big list as input so maybe it's fine........ Not a great lisp guy <ieure>quassel-guy, I would also suggest that you either lean into just using home-files-service-type and use static files in your repo (or have different files and change the value given to it); or lean into using define-configuration and serializers to express your configuration. <ieure>quassel-guy, There are a variety of things that could be more idiomatic or expressed more cleanly, but I don't think they're going to impact performance. <untrusem->though it is 2 years old so Idk if its still relevant or not <quassel-guy>ieure, So writing every config file in lisp is not the meta?????? <ieure>untrusem-, I'd have to completely reinstall my system. <ieure>quassel-guy, I don't understand your question at all. <ieure>quassel-guy, No. home-files-service-type is literally for taking verbatim configuration files and copying them somewhere in $HOME. <quassel-guy>Ok bros, I'll be rebooting the system a bunch of times to check if hibernation starts to work.... <ieure>quassel-guy, The way you're building this is not very idiomatic. Seems like you have a configuration file on disk, which you then load and parse to generate another configuration to feed to home-files-service-type. <quassel-guy>ieure, noted, won't do this thing for other configs anymore <ieure>quassel-guy, h-f-s-t is for verbatim configurations. Config fully in Scheme requires creating records to represent the configuration, then serializing those to the program's expected format. Many such examples in the Guix codebase. <quassel-guy>I wanted to flex with my friends, "everything is in lisp bro". Seems it's not what everyone does <ieure>That's the goal, certainly, but sometimes there isn't proper support and you need a thing to work. So you use the copy-raw-file escape hatch. <quassel-guy>ieure, thank you for the info. I will now proceed to test hibernate <ieure>quassel-guy, Look at home-msmtp-configuration for an example of how configuration in Scheme is typically implemented. <yarl>The numbers are wrong. why? 