<patched[m]>Aah, I did that but picked the default `out` output, but needed to use `lib` to get libstdc++ from gcc :)
<muradm>sneek: later tell bjc: there are other things that depends on cgroups, especially docker, in order to not break others, i decided to maintain the compatibility. and as I point in my comments, i suppose that cgroups should be a dedicated service-type, instead of coming with either elogind or seatd
<bjc>muradm: v1 and v2 *do* conflict. that's why i'd like the things that need the specific cgroup mount to depend on them directly. that way i can have lxd require cgroups v2, docker require v1, and as long as i don't try to run both, things will be fine
<bjc>right now, though, seatd/elogind both put in the v1 mount, so lxd and podman don't work without manual intervention
<muradm>i see.. i would suggest if elogind requires cgroups, and if it works with v1 only, it could be not feasible to do at all
<muradm>s/i would sugget/i would suggest to check/
<bjc>another option would be to separate out the v1 mount service and just stick it in either %desktop-services or %base-services. then i could at least filter it out in my os config with ‘modify-services’ and insert a v2 mount
<bjc>that'd be basically the same thing we have today, but at least make it easier to swap it out when necessary
<bjc>actually, thinking about this more: separating the mount out and then having elogind depend on it is actually the same thing we have today, just more explicitly
<bjc>nm. that's already what elogind is doing. i don't know what just happened to my brain that made me write that. 🙃
<bjc>i think i had this idea where service-types were more like a shepherd service, where you could require something and have it pulled into the dag, but that's not possible; so only one thing can define the /sys/fs/cgroups mount point. which means, i think, that it'd have to go into %desktop-services (since that's where elogind-service-type is)
<PotentialUser-95>Hello. Could you help me to configure my guix systems input methods? I started studying French recently, but at work and at home I usually use an us keyboard. From time to time I have to enter some french words in the web browser. What is the best way to achieve this?
<dominicm>does 'guix gc' seemingly wipe out packages in current profiles for anyone else? my home/system profiles are listed in 'guix gc --list-roots' but when I reconfigure without changes it has to redownload everything for some reason.
<muradm>bjc: i assume from some issues on elogind that it works with cgroup2
<jpoiret>dominicm: also, grub is not in the closure of your system, because it's only needed to install it
<jpoiret>so guix gc will wipe it, and next time you reconfigure it will redownload it to be able to grub-install
<fps>hmm, is it possible to run guix on a system and leave kernel and bootloader configuration to manual setup by the user?
<jpoiret>rekado: i'm looking at mumi's graphql api, and i think the main query types aren't great, combined with kolam's lack of error-reporting
<fps>i.e. have everything from running init under guix' control (managed by guix system reconfigure) but never touch the kernel or bootloader?
<jpoiret>issue should not be non-nullable, otherwise looking up a non-existent issue returns nothing because kolam errors out while handling the response
<dominicm>jpoiret: yeah grub make sense, but as far as I can tell on reconfigure it's rebuilding a ton of stuff besides my kernel, so the graft theory seems to make sense. I guess guix only checks the store for the original package, not the package after grafting?
<dominicm>oh ok, was not aware of that, although that makes sense since grafting basically does find and replace on the package contents right
<dominicm>so it doesn't know the result of grafting a package until it's been built
<apteryx>yes, my understanding of grafts is primitive but your understanding of the process makes sense to me
<apteryx>jpoiret: if that's what happens, I wonder how we could improve it so that it doesn't happen; it seems registering gc roots for both the ungrafted + grafted derivations should ensure things don't needlessly gets downloaded again, right?
<bjc>muradm: yes, there is an existing cgroups2 mount in /sys/fs/cgroup/unified, but it doesn't work with podman or lxd. i was going to see if i could make them work with the different mount point, but tbh, if i can just use seatd, i'd rather do that instead
<bjc>i haven't looked into using the …/unified mount point at all, so it might be straight-forward, but i have a sinking feeling it isn't
<bjc>v1 is pretty old at this point. i think all major distros have moved to v2
<bjc>that said, there's a value in supporting v1 so as to not break older software. so making them co-exist would be nice. although i'd prefer to have /sys/fs/cgroups be the v2 mount with a separate place for v1, since i think v2 is the expectation now
<muradm>i see that systemd is shipped by default with cgroup2 layout since 2021, needs to check state of elogind, then check elogind configuration, and configure control-gropup-file-system to do cgroup2 by default, imho.. i didn't see anything that would require v1 explicitly.. any example?
<bjc>i don't know of anything that needs v1, no. i used to have scripts for resource management with virtual machines that used it, but that was a while ago, and i don't know how popular they ever were
<bjc>however, 246.10 will work with v2 if you pass the build --cgroup-controller=unified
<unmatched-paren>muradm: sorry for bothering you again; i realized that your /etc/config.scm uses a variable "greetd-sway-gtkgreet-xdg-session", which isn't defined anywhere in "guix", so I was wondering how it was defined (I guess it's in (local-common)?)
<bjc>i noticed that, too. i suspect it relies on a gtkgreet package that is in a private channel, as well, since guix doesn't have it
<unmatched-paren>bjc: oh! yes, you're right. i just removed gtkgreet from guixrus assuming it had been added /o\
<rekado>apteryx: yes, node 129 is connected to the public switch and AIUI we don’t need to record the MAC address anywhere.
<rekado>so all that’s needed is to remove the .41 IP from node 130 and assign it to node 129.
<rekado>jpoiret: I’m not using the graphql stuff myself, but you’re welcome to propose changes / patches.
<apteryx>rekado: OK! I'll try taking care of that IP reassignement
<trevdev>Have I set myself up for disaster by having a signing subkey that expires? Just getting a personal channel set up has turned into a confusing mess because my key fingerprint and my signing "authorized key" subkey fingerprint are two different things. The subkey will expire next year.
<maximed>trevdex: Guix doesn't use the expiration dates of keys.
<maximed>(where ‘those reasons = expiration things’, not subkey things)
<maximed>(I don't know how key fingerprints & subkey fingerprints interact in Guix)
<trevdev>I couldn't get it to pull because I was apparently signing with my subkey, so I had to switch my authorized key to my subkey, and it still won't pull because now the latest commit "isn't signed with an authorized key" regardless of which authorized key actually exists in the current version of the .guix-authorizations file.
<trevdev>I just imagine that if I had to rotate that key it might break everything. Maybe there's no reason to rotate it, maybe I just need to re-up the expirey, either way I'm not sure why I'm still stuck.
<maximed>trevdev: I guess you modified .guix-authorizations in a commit that wasn't signed by a key authorisaed by the _previous_ .guix-authorizations?
<maximed>IIUC, you can rotate from a key FOO to BAR as follows:
<trevdev>No commit was every signed by a different key, ever
<maximed>trevdev: Also, what key did you use to sign the commit modifying the .guix-authorizations?
<maximed>(it needs to be the old key, because the new key hasn't been authorised yet, unless subkeys are special somehow (I don't know if they are))
<jgibbons[m]>Does the build daemon that serves all users need to be started as root, or could it be started by a `guix-daemon` user?
<trevdev>maximed: I think that I just learned the hard way that the documented authorized fingerprint, the introduction commit and they actual signature on the commit need to all need to look the same at the same point in time. I'm thinking guix pull doesn't care about what's most current in the repo
<trevdev>This is probably a good thing because if a key needs updating later, it can be added and committed (and signed by the new key) at the same time and it won't break backward references
<jgibbons[m]>My best guess is that, since the build daemon uses chrooted environments for buildind and needs to re-mount the read-only store so it can add things to it, it must have permissions to do all that.
<jgibbons[m]>So either the build dameon must run as root, or the sudoers file must give the build user those permissions.
<maximed>jgibbons[m]: The files in /gnu/store/... are (after building) root. So the build daemon needs to be run as root to be able to do the necessary changes
<maximed>the guix-daemon does not make use of sudo.
<jgibbons[m]>So it needs to be run as root to ensure consistent file permissions?
<maximed>jgibbons[m]: It has to be run as root to normalise the file ownership (among other reasons)
<maximed>I'd assume that "guix-daemon" refuses to start when non-root.
<maximed>Though I don't actually know if that's the case.
<jgibbons[m]>I know a guix-daemon starts when testing. I don't remember if tests must be run as root though.
<maximed>jgibbons[m]: right, for testing it's done a bit differently
<jgibbons[m]>Yeah, a different store prefix is used, not /gnu/store
<maximed>Tests don't need root. /gnu/store needs root.
<trevdev>If a channel depends on some channel that's already declared (but not explicitly set as a dependency) will it impact the success of `guix pull` or `buix build`?
<trevdev>For example, I am depending on packages declared in guix upstream. When I load the package files in repl there are no errors, but guix pull fails due to not being able to build dependencies
***mark__ is now known as mjw
<jgibbons[m]>trevdev: Doesn't `guix pull` only update the ~/.config/guix/current profile with the contents of all the declared channels? I wonder what build dependency is missing in your case.
<trevdev>jgibbons[m]: I tried a few changes with my .guix-channel and still ended up getting: cannot build derivation `/gnu/store/<hasn>-profile.drv': 1 dependencies couldn't be built. Yet if I go `guix build -L /path/to/guix-channel" package-name`, the package (which depends on everything in the channel) builds fine.
<maximed>trevdev: Does it say ‘see build log at /....gz’ at some point?
<maximed>trevdev: Also, what's failing: "guix pull" or "guix build ..."?
<jgibbons[m]>trevdev: Usually above the "1 dependencies couldn't be built" message it shows a red error saying that a package failed to build. A build log would be helpful in resolving this.
<trevdev>jgibbons[m]: It would be, if it said more than:
<KarlJoad>Ahh... I am not trying to make it a module/service-type. Just a package. I would add it to my list of packages in the home-environment.
<maximed>If you want to add it to the list of packages in home-environment, you need a list of packages to append to that list.
<maximed>You can't (easily) convert a manifest into a list.
<maximed>The same reasons apply to home-profile-service-type as to the package list in home-environment.
<trevdev>Would updating my channels inspire `guix home reconfigure` to go and re-download/re-build non substituted packages that are already present (and in some cases running) on my system?
<trevdev>And by updating I mean adding that unrelated channel you guys helped me write earlier
<KarlJoad>So it seems like the method unmatched-paren recommended to me would be better in this case, because manifests are not handled "nicely" by guix home.
<unmatched-paren>maximed: how do i translate a ,run-in-store (lower-object ...) to actual guile code outside the repl?
<maximed>trevdev: The logic behind downloading substitutes is identical for "guix home reconfigure", "guix system reconfigure" and "guix build" and "guix install"
<maximed>unmatched-paren: I don't remember the exact procedure but search for 'open-connection' and 'call-with-store' (not sure about the name)
<maximed>KarlJoad: I guess my point is, is that you don't need to define a meta package.
<maximed>(with its own description, license, etc.)
<maximed>It suffices to define a list of packages.
<trevdev>maximed: Thanks. still trying to come to grips with how guix decides when things have changed. It's building packages that haven't had an update in months. The significant change is the new channel.
<unmatched-paren>specifically, i'm making a session type for greetd (wlgreet), and i need to be able to put a wlgreet.toml into the store and specify it as --config for wlgreet(1)
<maximed>trevdev: Need context -- do you have a build log (logs.guix.gnu.org).
<trevdev>Yeah it looks like Guix is reinstalling way more than one or two deps for some reason here. Somewhere along the way I must have confused it and it's seeing the need to re-establish the package versions/provenance
<nckx>Guix is many things but very hard to confuse.
<unmatched-paren>maximed: i suppose i wouldn't be able to add sway automatically to the user's system packages if they put (default-session-command (greetd-wlgreet-xdg-session-command (greetd-wlgreet-session))) in their greetd configuration?
<unmatched-paren>hmm, unless there's some way to temporarily install packages like (with-packages (sway) (execl #$wlgreet #$wlgreet ...))...
<maximed>'mixed-text-file' is a simple way to make files, but at the same time it's a bit limited in what it can express (e.g., difficult to do JSON configuration formats), so we also have the more expressive computed-file.
<bjc>anyway, if you're using mixed-text-file, you're creating a file-like, so you're in something that takes a gexp
<bjc>so! what you can do is just introduce a new gexp context so that you can ungexp inside it
<unmatched-paren>so i changed (string-join (cons command command-args) " ") to command " " (string-join command-args " "), would that work...?
<attila_lendvai>Raspberry Pi 4: i searched the mailing list, but it's not clear to me whether Guix System can be installed on them. maybe only the installer image doesn't work, but from a booted raspbian it can be installed? can anyone clarify please?
<trevdev>Thanks. The deeper I get into packaging stuff, the more I nuanced I realize it is. My contribution to the ruby packages upstream more or less work because of a typo. I thought `inputs` was better. I am not in charge of these Ruby gems, so if they check the path for dependencies, propagate I must :/
<nckx>Sure. Certain languages/‘ecosystems’ within Guix use propagation heavily, for various reasons, but usually boiling down to ‘it was too hard to avoid so far’. Propagation negates some of the advantages of Guix but it's sometimes a necessary evil.