IRC channel logs
2024-01-07.log
back to list of logs
<benwr>I've been working for... longer than I'd like to admit, on getting `guix system vm`-based shepherd services running, and I'm finally talking to you via a `pounce` irc bouncer, running inside exactly such a vm! Hope to write a blog post about it soon - it took a long time to figure out, but now that I've done it once, I expect to use the same pattern to self-host tons of stuff! <podiki>was just playing with guix in a vm myself, to work on a new server config <adanska>i've not tried it before so i dont know if this is a recent breakage <efraim>podiki: I'm not happy with the level of coverage for aarch64 but I'm not sure what else to do about it <sneek>efraim, podiki says: any thoughts on status of mesa-updates on non-x86? berlin seems to not build any more for some days and coverage seems okay there; should I merge? <fnat>I'm running `guix git authenticate COMMIT KEY' on my local copy of the Guix repository. The authentication fails because of a missing key. Am I supposed to switch to the keyring branch and update that first? If so, am I also supposed to first run `guix git authenticate' against that? <dariqq>fnat: i think you'll either need to update your local keyring branch (as there recently was an update there) or add "--keyring=origin/keyring" such that the remote branch is used (this is done if you use make authenticate) <fnat>excellent, thanks dariqq - do you think the keyring branch also needs to be authenticated separately, or does guix git auth take care of the security "bootstrap" when run on the main branch? <dariqq>afaik changes in the keyring are also checked, but i'll need to check <fnat>np, thanks, i'll also have a look - i'll hold on with the auth step for now <dariqq>fnat: looking into it the keyring branch seems to just be used to lookup public keys to check signatures (which has nothing to do with authorization). (But not 100% sure) <apteryx>DRM cannot be implemented using free software <apteryx>not in the way it's intended to work anyway (control what users can do) <Guest22>Someone has an example config for nginx reverse proxy? <VivienGuest>Hello guix! My email server is kind of down right now, so I can’t send emails just yet. <VivienGuest>lilyp, you replied on #67651 that we are missing a few packages for gnome-team, but I do have Calls (45.0) in (gnu packages gnome) <lilyp>I probably checked the wrong branch at some point <VivienGuest>We don’t have logs, software and tour, that’s for sure <VivienGuest>I have reconfigured one computer with quite a full gnome (x86_64) on gnome-team (along with my guix-home and guix packages) and it works <VivienGuest>The “global dark mode” switch is rather disappointing to be honest, only some windows respond to it, by changing the color of the header bar <ineff>sorry for interrupting but, does anyone use guix on a foreing distribution? <lilyp>sorry for the double-k, compiling atm, and my machine likes to repeat keys when the CPU's warm <VivienGuest>(mine likes to buffer the keys in the incorrect order sometimes) <lilyp>aaand I've decided I won't compile everything on my own once Inkscape started building <ineff>ok then I've a question for you, I've noticed that everytime I try to install packages (either via manifests or directly via guix install) guix reinstall some derivations (bash-minimal, pkg-config, libgc, guile, etc....) <ineff>But I don't understand why it does reinstall them everytime <lilyp>It doesn't reinstall them, installing in Guix is only the act of making these things visible via symlink. <ineff>oh I forgot, but I think this could be relevant, this behaviour happens only if I do a garbage collection bewteen the two install operations <ineff>lilyp I don't know if I've used the correct terminology, but it basically re-download the same substitues <lilyp>As for why it downloads all those things, you just collected the "garbage" native inputs that are only needed at compile time. <lilyp>Guix tracks what's needed through store references, and those native inputs are never referenced, hence removed. <ineff>so, let me see if I understand correctly lilyp, are you saying that it downloads build-time dependencies even when it's installing packages via substitutes? <lilyp>there may be a bug to that effect (if there is, idk), but more likely than not it actually needs some of those for compiling things <lilyp>there are some unsubstitutable guile things, so stuff leading up to guile will practically always be needed <ineff>lilyp: are these "unsubstitutable" things libraries and binaries required for the purpose of building profiles? <ieure>Anyone have a suggestion for a more efficient dev cycle for hacking on Shepherd services than commit->push->guix pull->guix system reconfigure? <lilyp>ieure: ./pre-inst-env guix system vm? <ieure>Hmmm, possibly. I'll have to experiment a little. What I'm trying to do is make a service that runs `powertop --auto-tune' -- I'm not sure if that works from inside a VM. <ieure>I noticed that my battery life absolutely plummeted when I switched from Debian to Guix, and think this is at least part of the solution. <Guest22>ieure: You can do ./pre-inst-env guix system reconfigure system.scm that way you don't need to pull <anthk_>ieure: are you using software rendering for your desktop? <ieure>Guest22, Okay, awesome, that should definitely work. <ieure>anthk_, No idea. Doesn't seem slow in the way I'd expect if that were the case. I'm seeing greatly increased battery consumption when the system is asleep -- it'll lose ~15-20% battery overnight with the lid closed. <ieure>vs. like 5% max with Debian. Which is still far too much, really. <ieure>All the OEMs are moving to S0ix ("Windows Modern Standby"), but the support isn't as good as the old ACPI S3 yet, in my experience. <Guest22>well, on W11 it would be easy (it is broken) but no clue on Linux <ieure>I generally don't like to use hibernation, takes forever to boot back up from that. <Guest22>was Debian libre and do you use libre Guix? Maybe some issue with drivers <lilyp>I think we have some patches from the web, but it may be better to use a computed origin. <lilyp>for --with-patch, http ought to work IIRC <ieure>Guest22, NVMe SSD, regular (non-libre) Linux kernel on both setups. Though Guix's kernel is newer. <Guest22>hibernation takes ages even on a nvme ssd? interesting. <ieure>Yes, hibernation writes an image of RAM to the swap partition and powers the laptop off. So it takes as long as a cold boot, except your programs and such are still running when you get it back. <ieure>Cold boot is slow, and Guix cold boot is *way* slow. <ieure>Much slower than any other Linux I've used. I think because of the way it does disk encryption. <ieure>Debian uses an unencrypted /boot; Guix encrypts /boot, only the ESP is unencrypted. And that first step, where you unlock /boot, is extraordinarily slow. <efraim>anyone have problems with sddm after the upgrade to 0.20.0? <lilyp>adammk`: use customize-linux <podiki>sneek: later tell efraim thanks. yeah seems we are a bit stuck and the longer we wait just piles up more builds to catch up on :( maybe i'll merge in master one more time, send a note to guix-devel, and merge mesa-updates <ieure>How can I use something like sudo in a guix shell? The naive `guix shell sudo' gives me one without the suid bit. <civodul>ieure: you could pass --expose=/run/setuid-programs <sneek>Welcome back civodul, you have 1 message! <podiki>ieure: on a guix system? or in a container you mean? (not in a container shouldn't make a difference) <podiki>anyone know if anyone worked on a service for unbound? unfortunately the name makes searching for it rather difficult in guix land :-| <ieure>podiki, Yes, GuixSD. Preferably not in a container or VM. <podiki>what do you want to do? assuming sudo works already, guix shell <bunch of stuff> should still let you use sudo, unless you are running guix shell -C (container) <podiki>(that's what i was asking, sorry, if you were doing guix shell to make a container) <ieure>I'm writing an one-shot service for PowerTOP, which calls `powertop --auto-tune', and I need to test/debug it. I guess I'll just try it, but I'm not sure if it'll work without access to stuff like sysfs. <podiki>oh for making services I don't know the usual procedure sorry; I think spawning a vm from test suite? <podiki>but if you are not in a container then sudo is available, guix shell doesn't alter that i don't think? <civodul>ACTION attempts to merge master into core-updates <ieure>podiki, Yeah, but if I don't add --pure, I'm not sure if it'll use the guix in this pre-inst-env or the one on the system. bleh <podiki>you can even use pre-inst-env outside of a guix shell pure to use that local guix git checkout <podiki>civodul: good luck! note that I'll probably merge in mesa-updates today/tomorrow; not a lot of changes but if going to build core-updates fully it'll be a rebuild <ieure>podiki, `sudo ./pre-inst-env guix system reconfigure /home/ieure/dotfiles/system/wight.scm' gives me "no code for module (gcrypt hash)" <ieure>podiki, `./pre-inst-env sudo guix system reconfigure /home/ieure/dotfiles/system/wight.scm' gives me "no code for module (guix ui)" <ngz>ieure: wouldn't ./pre-inst-env sudo -E work? <podiki>try sudo -E ./pre-inst-env guix system <civodul>podiki: great that the mesa-updates merge is coming! <civodul>it’s probably good to do a first master->core-updates merge before <podiki>civodul: well looks like we stalled out on non-x86 subs but doesn't seem to be going anywhere (despite efraim best efforts); it just a few security updates and mesa version bump but some x lib stuff rebuilds everything <ieure>ngz, podiki, sudo has no suid bit even inside the container, so sudo doesn't work at all. <podiki>(this is will be the second mesa-updates merge in last few months) <ieure>Try: `guix shell -C -D guix sudo --pure' then `sudo ls'. <podiki>but why are you using -C? you don't need that if you are just wanting to reconfigure using your local guix <podiki>you can be outside of a guix shell and container for that <podiki>and see civodul earlier comment about exposing setuid, though I don't think you really need all that here, just need your pre-inst-env and sudo -E <ieure>I also need my other channels, which are invisible from the pre-inst-env. <podiki>i frequently use my pre-inst-env while working on other channels <ieure>Not sure how to do that. Maybe a VM is the right call here. <podiki>so just work outside of the shell <podiki>e.g. in root of a local channel /path/to/pre-inst-env guix build -L. <some local channel package> <podiki>reconfigure is a bit trickier, I think specifying a channels file explicitly is needed? <podiki>or just use -L to load each channel if you have them locally <ieure>Okay, that works. Thanks for the suggestions. <ieure>Does anyone else feel like the guix CLI organization is kind of unclear, or is that just me? <ieure>I'm used to stuff like `command verb verb --option', but guix has some verbs as commands and some as options. ex. `guix build thing' is a verb saying to build package `thing', but `guix package --show=thing' is a verb saying to show package thing. <ieure>Also seems weird that things like generations are under `guix package' instead of getting their own `guix generation' type thing. <ieure>It feels more natural IMO to have `guix package show thing' instead of `--show=thing'. <podiki>there is some mixture and overlap <ieure>podiki, Yes, but it's just an alias for `guix package --show'. <podiki>some "guix package" stuff is just "guix" too, like show <podiki>probably some historical reason and changing interface so maybe kept around for some reason? before my time :) <ieure>Actually, the manual says `guix show' behaves somewhat differently than `guix package --show='. Ugh. <ieure>Sweet. "Jan 7 12:38:32 localhost shepherd[1]: Service powertop-auto-tune running with value #t. " <civodul>‘guix show’ should behave the same as ‘guix package --show’ <civodul>also, if we were categorizing commands rationally, we’d have “guix package show”, “guix package build”, etc. <ieure>civodul, Yes, but easily remedied with an alias system, either built-in (like git) or shell aliases.