<sigfig>is this an appropriate place to ask questions about building guix from source <sigfig>i have some pretty strange issues with the installation i built locally and i'm not really sure how to diagnose it <lfam_>sigfig: This or the <help-guix@gnu.org> mailing lists are the place <sigfig>i'm attempting to build the standard install image from master, using `guix system gnu/system/install.scm`, with guix built from the same repo and no modifications <sigfig>this sort of works but during every build action there's a stall for about 100-200 seconds, and strace reports the guix daemon is trying to connect to every host in the 99.84.168.0/24 range <sigfig>possibly others, i've only caught the output twice so far <sigfig>i'm running the daemon with --no-substitutions attempting to do everything locally but clearly not succeeding <sigfig>the length of the delay is probably just due to connect() roundtrips taking a while from my vpn, but why on earth is it scanning a host range when trying to build a derivation <sigfig>about half the hosts i've checked from that list are up and running an http so i presume these are actually part of the guix ecosystem and are just unusually contiguous <lfam_>sigfig: My guess is those IPs are used by Cloudfront <lfam_>Overall though, that's not the expected behavior <lfam_>I can try to reproduce it. Basically, you built Guix from source, started the daemon with '--no-substitutes' (double-check your spelling there), and then did `guix system gnu/system/install.scm`? <sigfig>the most information i've gathered so far is, after downloading something (in this case the linux-libre archive) guix prints a message indicating it's building, then issues a series of about 60 connect() calls to these hosts on port 443, closing each one immediately <lfam_>Okay, those IPs are definitely part of Cloudfront, which we sometimes use (based on our budget) <sigfig>and yes that's all i've done so far, though i did have to build guile-ssh myself to work around version conflicts with libssh <lfam_>Can you also share some of the build output from your terminal? <sigfig>let me try to clean up and run it again, right now it's getting stuck trying to change permissions on a .chroot file that doesn't exist, which i assume is a partial build artifact left over <lfam_>In general, it may be looking for the derivations themselves, although if you used --no-substitutes (again, make sure you didn't actually type --no-substitutions), it should not <sigfig>definitely using --no-substitutes <lfam_>It would also be helpful if you did --dry-run and shared that output <sigfig>just cleared the store, will do a dry run first <lfam_>Finally, since you built Guix from source rather than starting with a binary, it would be helpful to know how you configured the build <lfam_>I don't have any potential misconfigurations in mind off the top of my head, though <sigfig>something persisted as configuration in the store and dry run gets caught up looking for a "logo.txt", let me just tear down the whole thing <janneke>str1ngs: channel sub-directory feature is now in guix master <sigfig>hm, ok that persists even after removing /gnu /usr/local/var/guix and /usr/local/var/log/guix, and performing a new `./configure && make && sudo make install` <sigfig>i guess its a reference persisting in a guile cache file somewhere <sigfig>none of the guix commands complete <sigfig>error: canonicalize-path: No such file or directory: "/usr/local/share/guile/site/2.2/gnu/installer/aux-files/logo.txt" <lfam_>You could try removing ~/.cache/guile, taking care which user you are actually using (`sudo` vs `sudo --login`) <sigfig>still persists after removing ~/.cache/guile <sigfig>i attempted using ./pre-inst-env but i was seeing the same weird delay behaviour, let's see if it avoids this weird file dependency tho <lfam_>Unfortunately nothing rings a bell. It would aid debugging to get a concrete list of steps to reproduce the issue <lfam_>Btw, make sure you are basing your work on the release tag rather than the latest commit. <sigfig>this is master as of three hours ago, 6b61dea3365e8cbb6d5a918df5288489e27854e2 <sigfig>i'll try switching to release tag after attempting to produce this again <sigfig>hah, haven't caught the connect sweep again yet but i did catch a "Bad Date header: Tuesday, 27 Mar 1984 05:00:00 GMT" in tls exchange with the its.dal.ca mirror <lfam_>Copy it out of the store, decompress it, make it writable, then run it with QEMU <sigfig>ok there appear to be a few major "stall" points in networking here, every transfer performed via http completes then causes a stall on the order of 40 seconds, failed transfer or redirects also do this, but there's no related output in strace or -v 9 for this <sigfig>this does not appear to be part of the socket handling, since it closes before the stall <sigfig>this occurs with every http connection as part of building the bash packages, so every individual patch spends between 80 and 120 seconds just spinning depending on how many redirects it gets <lfam_>sigfig: Hm... that's not supposed to happen <sigfig>i don't have any open sockets from the guix daemon during that time and curl to the same address returns the file in 60ms <sigfig>so definitely something going on there <sigfig>i'll swap to the release tag and see if it's still present <lfam_>Sadly I'm not gonna be able to debug it. The most expert help is available during the European day. Or else mail to <help-guix@gnu.org> or, for concrete problems, <bug-guix@gnu.org> <sigfig>release v1.0.1 builds fine at least <Dynamicmetaflow>lfam_: Is there any way to manage the images generated by Guix by like using virt-manager? <PotentialUser-55>I have a error in config.scm, it say "invalid field specifier", the code is: <lfam_>Dynamicmetaflow: I'm not familiar with virt-manager so I don't know <sigfig>Dynamicmetaflow: libvirt/virt-manager are just wrappers over qemu/kvm in a lot of cases, you don't have to convert the image at all <sigfig>you just have to put the usual qemu flags in an xml file <rb__>is there a way to use build-system cargo nightly? <Dynamicmetaflow>hmm Thanks sigfig i'll look into it, first time using QEMU and was looking for ways to manage it all after creating them with guix <Dynamicmetaflow>Part of me feels like creating a small emacs interface for this using transient or hydra <sigfig>release v1.0.1 built, running with `./pre-inst-env guix-daemon --no-substitutes` and `./pre-inst-env guix system disk-image gnu/system/install.scm`, some type error after calling out to python <sigfig>starting to get the impression guix is very fragile <sigfig>let's see if the binaries have similar problems <rvgn>Dynamicmetaflow Qubes is based on the principle of "Security through Isolation". The same can be conceptually reproduced with `guix system vm` and `guix system container`. Qubes was a brilliant idea; and so was flatpak, docker, LXC etc. But the thing is, these features should have been innately provided by system/package managers and that's one of the visions of Guix Project; as explained by civodul in the con <Dynamicmetaflow>I've been playing with Qubes for the past few days, and have spent HOURs reading and learning and trying to understand it further <Dynamicmetaflow>weighing the pros and cons, I have another computer running Guix as we speak, so serendipity that you messaged that <Dynamicmetaflow>Thanks, I think I did listen to this some time ago but I think it will be a good reminder since I have a little more experience with Guix <Dynamicmetaflow>So I completely agree with the statement you quoted about guix, the question that I have is how to replicate something like the Qubes Manager that lists VM's so we could manage them with Guix. <Dynamicmetaflow>From a prior conversation, I think an interface could be great like how emacs-guix has one but one for managing and starting VM's etc <rvgn>Dynamicmetaflow I will not be able to answer that question now as I am not well experienced with them either, apart from conceptually understanding them. <Dynamicmetaflow>I think I'm going to dedicate some time and try to create an interface in emacs for managing guix images etc <rvgn>QUBES: Installing program abc inside work domain that can be accessed and available only in that domain. Installing program xyz in the host domain which can be used and made available in all other security domains. <rvgn>GUIX: Installing program abc inside guix-vm-1 which has dedicated gnu/store and that program will be accessible and available only inside that vm. Installing a program inside host's gnu/store which is accessible and available to all other guix-vm-x that shares the host's store. <sigfig>released v1.0.1 binaries do in fact have this issue when running the daemon with --no-substitutes, i still see nonsense connect calls to the same assortment of servers <sigfig>tho the time it wastes on those is only about thirty seconds <rvgn>Dynamicmetaflow That's one example comparison as far as I understand. :-) <Dynamicmetaflow>Thank you rvgn :-), I'm with you, after using Qubes, while I appreciate all of the efforts and contributions and progress made and particular for the security landscape, I'm left with an itch and thinking, I should and I know I can do this with Guix. <Dynamicmetaflow>The one part I'm unsure about that Qubes has what's called HVM, where the ethernet and wireless networks for example run on a separate VM. Then vm abc has access to the network vm, and vm XYZ does not, or has limited access <sigfig>problem happens reliably if you just `guix build linux-libre` (which, as i've just discovered, absolutely destroys your terminal with the stdout of any other currently running build jobs) <rvgn>Dynamicmetaflow I know that virtual networks can be created using libvirt but not sure how to apply the same concept in `guix system vm`. <sigfig>the gcc package also seems to stall reliably <rvgn>Dynamicmetaflow Thanks for sharing :) <Dynamicmetaflow>From the link I shared with you, the example given should be applicable to Guix <rvgn>Dynamicmetaflow As far as I understand, `nix appvm` appears to be a mixture of features that can be found in `guix vm` and `guix env`. <Dynamicmetaflow>I think my general takeaway after spending a few days with qubes getting it up and running is that it provides interfaces and tools to manage the vm's allow the model of security thhrough isolation, the same can be done with guix it's a matter of creating similar tools, interfaces or adapting existing ones <Dynamicmetaflow>so I'm going to dedicate more time with guix tools and see what comes from it all <rvgn>Yeah, Guix is a growing project. :-) <sigfig>using the release binaries i was able to get a guix system working, but shortly after i noticed the gcc 5.5.0 derivations aren't reproducible, in the sense that any build fails with a linking error that is a bit obscured by guile stacktraces <sigfig>a `guix pull` from the binary release also requires building various incarnations of `gcc-5.5.0.drv` multiple times, unsure why ***chipb_ is now known as chipb
<apteryx>sigfig are you building your Guix from a "guix environment guix" environment? it seems your error might be related to an old version of Guile being used (from your host system), maybe. <sigfig>apteryx: what i'm doing currently is just running `guix pull` in a guix system vm, produced from the v1.0.1 release binaries with the bare-bones template <sigfig>with substitutes in the daemon, which definitely has effect as most other packages are pulled as binaries, except for the strange extra derivations of gcc 5.5.0 <sigfig>i do get one derivation of gcc 5.5.0 as a binary, but further down whatever dependency tree is constructed i have to build another with a new hash, from source <sigfig>this is pretty resource demanding because gcc is gcc, and i probably won't be able to get it to succeed in a vm <sigfig>oh, dry run says it is attempting to build guile, but an older version than is installed, this system has a derivation for 2.2.6 and it's building 2.2.4 <sigfig>guilec is also astonishingly slow <sigfig>its got 8 cores @ 2.5ghz right now, occupies enough of it that ssh throughput is reduced, compile times are on the order of two to three minutes per .scm file <sigfig>srfi-1 in particular has been sitting there for 10 minutes now <sigfig>i think the guile compiler might be bad <PotentialUser-43>I am trying load nonfree firmware because doesn't exist for my GPU. Here is possible help for it? <sigfig>i'm still seeing extraordinarily pathological cases in both guile and guix here, so i'm giving up on it for now, guess you weren't ready for me <sigfig>parting note: please update your ssh libraries to support ed25519 <chipb>how, uh, long does it generally take a machine to 'guix pull'? <chipb>I'm running on a fresh install in a VM. <chipb>nothing special derivation-wise, I'd expect. I've not customized past what the TUI installer did. <chipb>top shows the machine mostly idle too. <chipb>maybe I'm seeing terrible network performance? it's macvtap so I thought it'd be relatively good. <pkill9_>cool, build phases are just standard guile functions <pkill9_>what's the purpose of the GUIX_PACKAGE_PATH environment variable as opposed to using GUILE_LOAD_PATH? <efraim>I still use it for working on out-of-guix packages <pkill9_>i use GUILE_LOAD_PATH for working on out-of-guix packages now, i find GUIX_PACKAGE_PATH doesn't always work <pkill9_>well, just now i got an error about an unbound variable <pkill9_>wouldn't a missing import also cause the bug to happen when using GUILE_LOAD_PATH instead? <pkill9_>cool, node-build-system just got added *rekado still fights with texlive <rekado>I built a lot of new packages for the most basic parts of texlive, but that seems to have broken the build of texlive-latex-base, which isn’t fun. <rekado>pkill9_: are you reading build system code? <rekado>private-keywords are keywords that shouldn’t be passed down to the bag <rekado>I guess you can see as much by looking at the code. It doesn’t answer *why* they are removed. <MH026>is the best way to learn how to write config.scm files to just read existing ones? I find the functions and variables quite opaque at times 😬 <rekado>pkill9_: we build a bag from a package, and then use bag->derivation to compile a derivation from it. <pkill9_>MH026: a combination of that and referring to the manual i think <rekado>pkill9_: you’ll see in (guix packages) that bag->derivation applies the build procedure of the bag to the arguments. <rekado>the build procedure might be gnu-build (or something else) <rekado>gnu-build accepts only a certain number of keyword arguments <rekado>so if we want to be able to use it we have to remove any extraneous arguments <pkill9_>MH026: i would read the guid ein the manual on writing a config.scm first, then look at example config.scm files, also there's examples in the manual <rekado>those arguments would presumably have been dealt with in earlier stages. <pkill9_>MH026: plus some examples in the guix repository, and also others have their own ocnfig.scm files they made public <pkill9_>rekado: do those arguments that aren't passed down get used for anything? <rekado>pkill9_: sure, but not at the lower level that gnu-build operates on. <apteryx>Is anyone using Btrfs with a subvolume for root? Because I have a patch ready to test that makes this possible without symlink wizardry <apteryx>Basically it takes the subvole name from rootflags=subvol=your-volume-name (a kernel argument specified in your Guix config), and uses that name to prefix the linux and initrd paths that are written to /boot/grub/grub.cfg <apteryx>so, if you have defined rootflags=subvol=rootfs, then your grub.cfg will have linux and initrd paths starting with /rootfs/gnu/store... instead of /gnu/store... <apteryx>The last bit I need to add is documentation; I'm trying to see where it'd fit. <pkill9_>i'm getting an unbound variable error in the package module, with a correct module suggestion, even though I've put the variable in 'exports' and used "define-public" instead of "define" (just to test if it works), what could be the issue <rekado>did you get other errors before that? <apteryx>pkill9_: maybe a mismatch betwen the file hierdarchy of your Guile source files and the module names? <apteryx>(e.g. (some place your-module) should be under some/place/your-module.scm) <pkill9_>it's probably because i used a mixture of (use-modules) and (define-module #:use-module ...) <pkill9_>i got it building a package now, yay <nckx>So do I get my money back when guix builds something starting with /gnu/store/maga. <rekado>nckx: only if it’s a GNU package. <dongcarl>I'm asking on #talos-workstation if they have spare power9 machines... <dongcarl>We do require physical custody, correct? <efraim>for an official build machine i guess <rekado>dongcarl: build nodes don’t have to be hosted at the same place. <rekado>some build nodes are donated by institutes and are hosted in their data centre <rekado>even without physical access for members of the Guix community <rekado>so that would be okay (though it wouldn’t be ideal) <rekado>we really just need someone to take care of the machine. <rekado>most build nodes, however, are in the datacentre where I work. <jonsger>dongcarl: we have already one or two Guixers with a POWER9 machine: one is Tobias Platen <efraim>before we had official aarch64 machines the 0.16 aarch64 release was built on one of my personal boards <dongcarl>Please let me know how I can help with this <ng0>you have a node-build-system now? Did someone discover the best way to untangle this :O? <ng0>doesn't read like there's specific place for the intended use <ng0>maybe this can be negotiated though ***lx0 is now known as lxo
<vagrantc>anyone savvy with guile-ssh? trying to build it for debian in order to build guix, but it's got a test failure on arm64 ... builds fine on guix on arm64, right? <efraim>Last I built it by hand it was for powerpc <vagrantc>seems like the test failure is also on amd64 ... <quiliro>Mi interesigi min en Hurdo-o sur Guix-o. <pkill9_>how do i add a possible argument to use in a build system, and how do i access that argument inside the build-system builder? <pkill9_>e.g. the build expressions that are the phases <pkill9_>through intricate cargo-culting i have solved this problem <[rg]>can someone point me to the source code for the installer? <civodul>[rg]: the UI itself is in (gnu installer …) <[rg]>civodul: the website now says its deprecated? lol <quiliro>Mi estas interesita en Hurd-o sur Guix-o. Kiu konas ĉi tion? <civodul>what part of the web site are you referring to? <mbakke>civodul: Can you update Cuirass to do the full core-updates build? <mbakke>Will it start immediately, or on the next push? :) <rekado>quiliro: I wanted to install a Hurd build node, but got stuck because the bootstrap binaries we produce segfault on Hurd. <rekado>quiliro: so the next step would be to figure out why our statically linked cross-built “tar” segfaults. <quiliro>rekado: is there information on the web about Hurd on Guix? I do not think i will be able to do it without any preparation (reading). <huuskes>is it allowed to speak non-English in this channel? <quiliro>i have spoken spanish and esperanto...nobody has oposed....i think it is inclusive <huuskes>since other forms of communication generally enforce English only, which sucks sometimes imho *nckx vindt het allemaal prima. <rekado>quiliro: no, there’s no current info about Hurd on Guix on any of our websites. <nckx>Whoever asked here the other day whether linux-libre 5.2 was in master: it is now. *nckx leest met belangstelling het interessante artikel. <huuskes>not fighting in the IKEA is a sign of a great match? lmao <quiliro>ho! cosmopolitan! haha! pardonu min... <nckx>It's missing ‘she installs this weird Guix thing just to humour you and make you shut up’. <chipb>mystery partially solved...apparently macvtap NIC to my VM was causing the slow package operations? <chipb>I dunno htf/wtf that would be, but... <nckx>chipb: Were you the ‘my Guix is portscanning Cloudfront’ person? <chipb>uh. I can't see how I would've been. was just trying to 'guix pull' and 'guix package' some. <chipb>I let 'guix pull' crank overnight. it eventually seemed to finish? <chipb>I was able to DHCP with macvtap attached, so it wasn't outright corrupt or broken. <chipb>maybe I was getting catastrophic frame loss? <chipb>when I run 'guix system reconfigure', is that generally meant to be run as my normal user? does it elevate privileges internally to update the system? <rekado>chipb: it’s supposed to be run as root. <rekado>however, you don’t have to use the root user’s copy of Guix. <chipb>by specifying the path to my guix binary in my user's profile? <chipb>oh, and of course I don't need to run as root to build the derivations themselves; just the actual final steps of the rootfs update, huh? <chipb>rekado: wouldn't sudo be scrubbing the user's $PATH value? <rekado>I’m using “sudo -E” myself, but I hear it may not be necessary any more. <rekado>chipb: correct, you can use “guix system build” to build the system first. <rekado>but really, there’s no difference. <rekado>the daemon doesn’t run anything as root even when the root user talks to it. <rekado>it uses its root powers only to be able to spawn a chroot and switch to an unprivileged build account. <chipb>speaking of, does it also create an isolated network namespace for the chrooted build? hadn't dug around in that part of the code yet. <rekado>chipb: networking is disabled in the build environment. <chipb>cool. I suspected so, but I didn't see it outright said in documentation. <pkill9_>is there a guile interface for guix containers, and doing stuff in them? <rekado>pkill9_: yes. There’s call-with-container to call a thunk in a container environment, for example. <rekado>but that’s different from how the daemon does things <rekado>unifying this is one of the goals of replacing the C++ daemon with a Guile variant. <chipb>oh. you're still using the nix daemon? <rekado>many of its features already exist in Guix. <chipb>it's been a while since I had really played around with things. <rekado>there’s an ongoing student project to replace the daemon. <rekado>it’s not really urgent for us because the current setup works fine and the daemon doesn’t really change much anyway <rekado>so the project is moving along at a leisurely pace <rekado>but it is under active development. Slow enough for deliberate testing. <chipb>I've seen there's been so many improvements since, I had just figured that had been switched already. <rekado>our version of the daemon has also gained some improvements, but still in C++ not in Guile. <chipb>er. not to diminish the effort it'd take to replace, I mean. <rekado>it’s quite a bit of work. All the needed pieces seem to be in place on the Guile side, but to combine them requires changes throughout the code base to ensure that existing code can be reused. <rekado>making sure that nothing breaks unexpectedly is not easy, even with a big test suite. <chipb>undoubtedly. that part is often 95% of the effort and maybe 5% of the fun. :-P <nckx>chipb: Maybe. I have a kexec-tools package on another laptop that I could bang into shape & submit if you need it. <nckx>I haven't tested it with Guix's kernel though. <chipb>I can take a look myself, too. wasn't sure if it was an intentional omission or not. <nckx>We have no known beef with kexec. <rekado>usually omissions are not intentional. <nckx>Fellow Guix, do any of you use RIME without a desktop environment? Say, with i3? I am having 0 lucks ☹ <chipb>I've got a laptop I got an NVMe drive for, but found out that annoyingly the system firmware won't boot from NVMe for this generation. <chipb>was going to construct a usb-drive linux kernel bootloader to actually use it. <chipb>I thought for a moment kexec might be a systemd thing. <nckx>chipb: Not that I don't applaud your commitment to going Guix, but you could use a different distro to kexec for now. <nckx>Although I do wonder how to tell the shepherd not to halt but call a custom command like kexec. <Marlin[m]>most likely it will take some time for the traditional unix-like way of doing stuff to be "bridged" to guix <chipb>well, I'm rather uncertain that other distros will make my bootloader any easier to construct. kexec isn't exactly hard to build. <chipb>I guess dracut might make it marginally straightforward, but why not just play in some scheme instead. ;-) <chipb>oh, bugger. I guess it does take cooperation with init to do cleanly. <chipb>still, that seems like it Can't Be Too Bad... <nckx>chipb: Yes, actually, in your case a graceful shutdown probably wouldn't matter, since everything's going to be mounted ro and you don't care about the ‘pre’ system at all once the real kernel loads. <nckx>Still, it'd be nice to support ‘fast kexec reboots’ like it's 2008 and still cool. <chipb>oh geez. or I could to the sane thing and just put the vmlinuz/initrd on the same EFI partition as grub and be done with it... <nckx>chipb: …er, oh, I thought the whole issue was that your UEFI firmware didn't see the drive? Or do you have a non-NVME EFI partition? *nckx gives up farting around with ibus for now; if anyone's experienced, I beg you for aid. <chipb>well, the EFI partition being on thumbstick. <nckx>That's not supported out-of-the-box either (you'll still get to write that Scheme code) but yeah, probably more sane 😛 <pkill9_>how feasible would it be to use inferior packages as inputs for packages? lol <chipb>it's all to happy to deal with that. and let me install to an NVMe drive (sans an annoying prompt on boot of "unsupported drive"). just not a thing if I don't use the USB. heh. <pkill9_>that could end up as a guix-specific dependency hell <chipb>same laptop just hung on me a second time today. debian 10 seems unhappy on it? <chipb>ahem. with the plain sata m.2 drive, that is. <nckx>Sounds like one hell of a laptop. <chipb>meh. several years old, but I don't exactly want to replace it either. <chipb>none around the vicinity of the hang. not flushed to disk on account of me hard cycling power, presumably. <chipb>next time it happens I'll try logging into it from another machine before cycle. <chipb>might just be a framebuffer freeze. but I did try to switch to another vt. <chipb>oh yuck. I do see something a few hours before the first crash. <chipb>ul 11 07:38:01 omicron kernel: [30596.275555] sd 3:0:0:0: [sda] tag#5 Sense Key : Medium Error [current] <chipb>Jul 11 07:38:01 omicron kernel: [30596.275559] sd 3:0:0:0: [sda] tag#5 Add. Sense: Unrecovered read error - auto reallocate failed <chipb>Jul 11 07:38:01 omicron kernel: [30596.275563] sd 3:0:0:0: [sda] tag#5 CDB: Read(10) 28 00 1c 72 63 80 00 00 08 00 <chipb>then "hard resetting link". rinse, repeat a couple more times. <chipb>but I suppose that's well off-topic for #guix...sorry. <nckx>chipb: Uh, I'm not familiar with NVME, but ‘reallocating’ is never a good thing even when it succeeds. smartctl -a /dev/sda time, I think. <chipb>this is the sata drive still. nvme isn't permanently installed yet. <chipb>but yeah, rather concerning. hence the "yuck". <j-r>Is there an example on how to run a user's shepherd init.scm at system startup? I'm running Guix and would like to have the system shepherd for a user at boot. <j-r>I'm trying to sort out how to write a service definition to add to %base-services. I'm not sure that is the correct way. <rekado>j-r: services that are specified in the operating system configuration will be system-wide, not per user services. <nckx>I don't want to speak for j-r, but I read the question as ‘how can I run a user's shepherd instance & services, as that user, but before they log in?’ Is that correct? <nckx>What with all the ‘modern’ session/logind/seat magic, I don't really know the canonical answer to that anymore. <j-r>yes. The particular use case at the momement is starting znc as a user when the the system starts. <rvgn>efraim Just saw your email regarding virt-manager bug. I get the same output for `ls /sys/fs/cgroup/unified/`. But as shown in the error, the virt-manager is searching the directory "/sys/fs/cgroup/unified/machine" (not "/sys/fs/cgroup/unified/"), which does not exist. o.O <j-r>I want to have the system shepherd have a service that has something like #:start (make-forkexec-constructor '("/home/james/.guix-profile/bin/shepherd") #:user "james" #:group "james") <rekado>j-r: we don’t have a mechanism for user services yet. This would have to be done outside of the operating system configuration (e.g. by launching a shepherd instance upon login). <j-r>I'm trying to solve for when my linode reboot all the services start back. I don't won't to run znc as root. <j-r>I have such working (mostly) on Debian. A systemd unit starts shepherd as root, and root's shepherd starts a shepherd instance for a couple of users. My goal is to migrate from Debian to Guix. <rekado>j-r: maybe section 8.17.4 Shepherd Services in the manual would be of interest to you. <rekado>you’d have to use modify-services to modify “shepherd-root-service-type” by extending it with your (shepherd-service …) <j-r>rekado: my manual doesn't have a 8.17.4. <j-r>rekado: I see, the info pages have that section. Thanks! <nckx>j-r: Then just navigate to the (top-level) ‘Shepherd Services’ node. <nckx>j-r: Oh, I see. What you call ‘info pages’, GNU calls ‘manuals’ (no ‘man pages’). <j-r>Oh. I was calling document on the web the manual ;) I'm gathering the manual installed with the system is more up to date. <nckx>j-r: Oh, yes, that too. We like manuals so much we have different ones side-by-side 😒 (sorry about that). <nckx>It will eventually be fixed.