IRC channel logs


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>Hi Guix!
<adanska>Is anyone else having trouble getting gfeeds to run? Running `guix shell gfeeds -- gfeeds` gives the following stacktrace:
<peanuts>"debian Pastezone"
<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, you have 1 message!
<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?
<efraim>sneek: botsnack
<sneek>podiki: wb :)
<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)
<Franciman>is DRM not supported by guix system, right?
<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)
<peanuts>"[gnome-team] What should we do with the "gnome" package?"
<VivienGuest>Don’t you have it too?
<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>Except for #68259
<peanuts>"[PATCH gnome-team] gnu: dbus-service: only symlink /run/dbus the first time"
<lilyp>Cargo.toml 🤢️
<VivienGuest>tour is rust, yes
<lilyp>Hard skip
<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
<VivienGuest>That’s probably a bug
<ineff>sorry for interrupting but, does anyone use guix on a foreing distribution?
<VivienGuest>ineff, I do at work
<lilyp>I did at workk
<VivienGuest>But I have not touched that system since last year
<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>sleep as of sleep or hibernation?
<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>hdd or ssd?
<Guest22>was Debian libre and do you use libre Guix?  Maybe some issue with drivers
<apteryx>can patch objects be origins?
<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?
<adammk`>Hi guix! I am trying to build a custom linux kernel . But when I build my-linux-libr package, it is using the default config. Am I doing something wrong?
<peanuts>"debian Pastezone"
<lilyp>adammk`: use customize-linux
<adammk`>lilyp: oh, it's working, i think
<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!
<sneek>civodul, avp says: I pushed an improved version of the patch for Guile-Zlib:
<peanuts>"uncompress: The procedure fails when input data compression ratio is big - Free code hosting"
<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
<civodul>a bit tedious!
<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)"
<ieure>so uh
<ieure>Yeah this stinks
<ngz>ieure: wouldn't ./pre-inst-env sudo -E work?
<podiki>try sudo -E ./pre-inst-env guix system
<podiki>can see this discussion (at end) for why:
<peanuts>"pre-inst-env: "no code for module (gcrypt hash)""
<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
<ieure>Okay, I understand.
<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
<podiki>"guix show" exists though
<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>but yeah, historical reasons!
<civodul>also, if we were categorizing commands rationally, we’d have “guix package show”, “guix package build”, etc.
<civodul>but that’s more typing
<civodul>so that’s a tradeoff
<ieure>civodul, Yes, but easily remedied with an alias system, either built-in (like git) or shell aliases.
<rekado>would somebody like to claim ?
<peanuts>"[PATCH 0/9] Add Easyeffects"
<rekado>looks like a good patchset