IRC channel logs
2023-04-06.log
back to list of logs
<panosalevro>any chance of OpenTabletDriver and digimend being packaged on guix? <the_tubular> How do I check which package pulled a specific package in /gnu/store ? <rdrg109>[Q] Is there any way to know from which URL are files being downloaded when using "guix package -i <<package>>"? I have two systems, in system A, I'm using guix publish. I want to download packages from A in system B, but I'm not sure if they are being downloaded from A's store or the URL in the package definition. <lfam>rdrg109: Increase the verbosity of the output of the command, it will show you URLs <lfam>I don't remember which verbosity level, but "--verbosity=$number" <wingo>guix install: warning: Your Guix installation is 245 days old. <jonsger>since rebooting today, dmenu is broken in sway for me. It doesn't work anymore, don't know why <civodul>jonsger: are you suggesting that wingo should wait for a few more days/weeks before upgrading? :-) <bjc>guix makes upgrading safe. which is why i only do it once a year <jonsger>ah nope, I doubt that he is using sway... <jonsger>how "stable" is core-updates ATM? is it already worth a try on a desktop pc? <civodul>i think there aren't that many substitutes yet <jonsger>TristanCottam[m]: could you post your config.scm <jonsger>TristanCottam[m]: guix deploy: sending 0 store items (0 MiB) to 'example.com'... looks a bit strange, I assume you want to send to cottam-server <jonsger>no idea, never used guix deploy. Does ssh work with the configuration you provided? <TristanCottam[m]>How can I troubleshoot this? Is it possible to use Guile's magical debugging abilities? <rekado>civodul: I can’t SSH to ci. Is this my problem or do you see the same? <civodul>rekado: hi! i just ssh'd into berlin just fine <rekado>civodul: good, it’s working for me now too. Thanks for confirming! <cbaines>I don't know if anything important is missing though <cbaines>that number is coming from data.qa.guix.gnu.org, but it should be similar to that reported by guix weather <civodul>i hadn't checked in a while actually, and was sorta assuming it was not that good <cbaines>civodul, I'm seeing the data service have problems with mostly ocaml packages <cbaines>locally: → ./pre-inst-env guix build ocaml-base64 <cbaines>guix/build-system/dune.scm:113:34: In procedure dune-build: <cbaines>error: gnu:%strip-flags: unbound variable <cbaines>starting after: debug: Starting getting derivations for (x86_64-linux . #f) <civodul>due to ae587c2ef041413bc709a555261db752068ea360, oops <Guest41>Hi, I'm trying to package a program for the first time and I find it quite difficult. My approach right now is to start with a basic program definition which has already been packaged and modify that to fit my new package. When the build fails, I try to change the package definition based on the error message I got. Is this the standard approach or should I do something different? Giving the right inputs is especially difficult. I'm barely ma <rekado>Guest41: it depends a lot on the kind of package. <rekado>for R packages, for example, I recommend just using the importer; it’s good enough for that. <rekado>for Python packages the importer gives you a decent starting point <rekado>but there are also applications or libraries that are really quite difficult to package <rekado>we can often glean information from build system files such as configure.ac or CMakeLists.txt, but it is not uncommon to repeatedly build, fail, and change. <Guest41>okay, thank you for the info. I will try that <Guest41>it is Fragments, a rust program using meson and ninja, designed to be distributed as a flatpak. <rekado>you may be able to use the cargo importer to package all as yet unpackaged Rust dependencies first <jpoiret>wow, I wasnt expecting core-updates to have 80% <jpoiret>i still have failing packages in my main manifest though <jpoiret>civodul: do you wanna organize a core-updates hackathon this we? <jpoiret>i can send a mail to that effect today i guess <jonsger>86.8% substitutes available for me from bordeaux, and 68.7% from ci.guix.gnu.org. its mostly leave-packages <jlicht>civodul: I haven't forgotten about your importer review, life just seems to find creative ways to eat into my time ;) <jpoiret>heh, I thought qtbase@6 was actually building on QA because it's not under failing, but actually it's only scheduled for now <TristanCottam[m]>How can I make use of native-search-paths in a Shepherd service's start field? <TristanCottam[m]>I'm making a service for Minetest server, but I can't tell how to make use of minetest-data's games and mods when starting the server. <civodul>so that was it, the dune-build-system issue <civodul>well, it's also *failing* to build stuff <bjc>is there a preferred, non-named-let, way of looping over a list for side-effects? the context here is testing w/ srfi-64, so it's only the side-effects i'm after <TristanCottam[m]><TristanCottam[m]> "I'm making a service for..." <- Does `native-search-paths` have any effect at the system level? If so, does setting `#:environment-variables` in `make-forkexec-constructor` overwrite existing ones? <bjc>one last thing (i hope): is there a way to test service composition? i want to verify that my configs get generated properly when extensions get used. i thought that ‘fold-services’ may do the trick, but i can't wrap my head around it. it always seems to want a basically complete service graph, even when using ‘instantiate-missing-services’ <bjc>and anyway it seems too heavy. i'm only interested in like 2 layers of the graph, and ‘#:target-type’ doesn't seem to work the way i expected it to <civodul>that's what i would use to test specifically extension composition <bjc>if i try: (fold-services (instantiate-missing-services my-service-list) #:target-type pam-mount-service-type), it still complains "no target type 'activate' for service 'etc'" <bjc>(there is an etc-service-type in my-service-list. i'm still banging rocks together to try to make fire here) <bjc>is there an existing example i can crib from? <civodul>bjc: there are examples under tests/, but yeah, on real examples you need the full list of services <bjc>civodul: ah, i was looking under tests/services before hoping that there'd be an existing service-type test that used it which i could steal^Wuse for inspiration <bjc>when you say i'll need the full service list for real examples, do you mean that if i have a service-type that hooks all the way down to the system, i'm going to need to stub those out for testing? <civodul>bjc: or you need to have #:target-type system-service-type <bjc>hmm. i guess i'm using it wrong somehow, then. #:target-type didn't seem to stop fold-services from trying to walk the whole graph <Fd9a>Hi. Did a little work on making a guix image to run on visionfive2 riscv sbc. The system boots to a state where you can see the nscd log and then hangs. Tried removing most of the services didn't help either, so not sure what to do next yet. <Fd9a>Might be helpful to someone <bjc>how do i convince make to produce html from the texi files? <Guest19>Hello, has anyone figured out how to make Keepassxc work with Icecat? In Icecat the extension states "KeePassXC-Browser detected an error:", but the error itself is not displayed. It works with Firefox-ESR immediately. <rekado>bjc: “make html” produces unadorned HTML from the docs <bjc>i have the same problem with keepassxc's browser integration. i suspect it has to due with either it being unable to find the keepassxc-proxy from the profile or icecat not using ~/.mozilla/native-messaging-hosts (or both!) <bjc>i haven't had a chance to dig into it yet, but that's where i'd start looking <rdrg109>[Q] Is it possible to execute "guix pull" on a given channel? I'm asking because I'm using another channel which contain a very few packages, but when I execute "guix pull", the command takes too much time on the "guix" default channel , so I prefer "guix pull" to skip the default channel and only download from the other channel that I added. <civodul>rdrg109: you can run "guix pull -C channels.scm" and pass a channels.scm where the 'guix' channel is pinned to a specific commit, for instance <DZoidberg>is there as special way or do I just add nix to my config.scm packages <lfam>ardon: Does your email describe a problem that you are having? Or ask a question? <tavoris>hi, I'm looking for examples of shepherd services being defined with service extensions. preferably with the home-environment config. <tavoris>I'm trying to start pulseaudio when the user logs in <civodul>tavoris: hi! you can try "guix home edit ssh" (for example) <bjc>pulseaudio should already start automatically, as part of dbus, iirc <civodul>actually "guix home edit home-openssh" <tavoris>it's not starting automatically for me <civodul>if you start an audio player, or pavucontrol etc., it should definitely start <tavoris>thanks, that's emacs example is helpful <bjc>you /may/ need to use (service home-dbus-service-type) <bjc>ohh! i may be having the same problem, actually. i have to start pavucontrol *before* i start firefox in order for firefox to have sound <tavoris>that sounds like what I might be missing. I'm just starting out with the home service today <bjc>that started about a month or two ago, iirc <tavoris>I'm able to get sound by running `pulseaudio &` in my .xsession but it felt like a hack <civodul>hmm i get sound without doing anything special <bjc>i haven't narrowed the problem down yet. it may be because i stopped using ‘%desktop-services’ in favor of ‘%base-services’ and i haven't included some missing service <bjc>it definitely should work as soon as you log in with no special steps taken, and it used to for me <lfam>ardon: If you are still there, I can help you with 'pre-inst-env' <lfam>ardon: I had asked what problem you are having <ardon>lfam: Basically, I can't access the modules from the local checkout even though I'm including the path in guile's load path <ardon>This works with other Guile repositories that I have cloned locally, but not for Guix, and I'm unsure why <rekado>ACTION fixes a few packages on core-updates <lfam>ardon: Let's back up. Is the pre-inst-env file fully generated by the Guix build scripts? Or have you edited it yourself? <lfam>Yes, but was it created automatically, or did you write it? <lfam>Okay, the automatically generated variety is used for testing changes to a Git checkout of Guix. I recommend doing it that way if it applies to what you are trying to test <lfam>If that doesn't apply, I personally don't have the expertise to assist, but others here do <ardon>I have built Guix with those instructions, and I do have an auto-generated pre-inst-env at the root of my Guix checkout. My question is more geared towards how can I make use of the code that I write in the local checkout FROM my pre-inst-env. <ardon>I've had a look at the auto-generated file but it simply sets the load path and does a few more bits that I tried to replicate in my script, to no effect <Guest19>gparted doesn't have any icons although I have the adwaita icon theme installed. Which one is required? <ardon>So I'm left wondering, do all Guix devs test new services/packages builds from the pre-inst-env at the root of the project and not have any local config they use for this <lfam>In general, we first test our changes with pre-inst-env. If the changes affect more than just packages, I recommend also testing with `guix time-machine`, which is a more complete test <lfam>Take note, the pre-inst-env file only works if the Guix checkout is './configure'-d and built properly <lfam>Usually, when it doesn't work, my first step is to do `guix shell --pure -D guix && ./configure --localstatedir=/var && make` <lfam>For example, if you've built Guix but then garbage collected, some of Guix <ardon>Yeah I get that. Hmm ok, so let's say you're writing a new home service, and you want to test it builds by including it somewhere inside your local config. Which means you'd need to somewhat have access to your local changes in your guix checkout, how would you do this? <lfam>Some of Guix's dependencies may have disappeared, and then the pre-inst-env script will silently fail <lfam>Personally I haven't used Guix Home yet, so I don't have a workflow <lfam>But, `guix time-machine` is probably a good start <lfam>I made a typo in that command I wrote. The first '&&' should be replaced by '--' <lfam>So, does anyone have a workflow for testing Guix Home services? <HexMachina>Hi all, I'm running guix on a foreign distro and trying to test out the wireshark package in a secure way; running "sudo wireshark" is dangerous on the internet because now you are running very complicated parsing logic on completely untrusted data and any bug gives an attacker root access. <HexMachina>I wanted to try to run `guix shell -C -N wireshark` so I'd be in a container to limit the danger of compromise, but sudo isn't available in the container. Adding 'sudo' to the guix shell invocation doesn't work, because the guix-provided sudo binary is not marked setuid, and I can't manually `chmod u+s` it to be setuid because /gnu/store is read-only. Any suggestions? <ardon>Thanks for the pointers, I'm use the pre-inst-envto build/test packages which I want to upstream FROM the guix checkout, but sometimes I'd like to include a new home service I'm working on in a dev branch of guix (which sometimes involves a new package too) from my config to see if it builds, so that I don't have to write a minimal configuration in the guix repo. <HexMachina>(same also applies to tshark, the CLI version of wireshark, which is a lot easier to test with in containers) <ardon>The problem, which I've asked to other Guix home users like Andrew Tropin, is that there is an error that prevents the local Guix in the load path from being sourced and the build fails <ardon>Basically, use the local Guix checkout like a Guile library <lfam>And what does the error say, ardon? <lfam>HexMachina: How about simply working as root in the container? Or is that impossible? <HexMachina>lfam: I don't see a way to change your uid in the container. If I start it with `guix shell -C -N -u root` and run id, my uid is 1000, not 0 <lfam>I see. I don't have a solution in mind. How would you normally run wireshark, on a distro besides Guix? <HexMachina>lfam: Debian and Ubuntu (and most other distros AFAIK) install wireshark in such a way that if you are a member of the 'wireshark' group, you are allowed to capture packets without being root <HexMachina>adding yourself to the wireshark group is the recommended way, this lets you packet capture without being root <lfam>Personally I dunno, sorry! Hopefully someone else can recommend something <HexMachina>this involves linux capabilities, which I don't think guix handles well <morganw>You can just use tcpdump and then load the capture into Wireshark later, if it is acceptable to run tcpdump as root. <HexMachina>morganw: hm, that's slightly better, as I don't think tcpdump is doing anywhere near as much parsing, but it's still doing some <HexMachina>will guix get upset if I make /gnu/store writable in order to run setcap on the wireshark/tshark/dumpcap binaries as recommended by that blog.wireshark link? <rekado>HexMachina: you should never make /gnu/store writable <bjc>lfam, HexMachina: i use wireshark as non-root by way of setuid-program-service and creating a wireshark group for it <rekado>one important invariant is that *only* the daemon writes to /gnu/store <rekado>when you invalidate this invariant bad things might happen <bjc>running wireshark as root is problematic because it wants to open an X client, which has xauth/permissions issues <HexMachina>bjc: it's easier to reason about tshark, which suits my needs and is just a CLI program <bjc>ah, i didn't know about that. i do kind of rely on the gui conveniences, though <bjc>we should probably have a ‘wireshark-service-type’ or something to make it easier, though <HexMachina>bjc: once I have the pcap generated, I can use wireshark without root to view it. It(or tshark/dumpcap) only need to be root (or have CAP_SYS_NET and CAP_SYS_ADMIN) to do the initial packet capture <bjc>i don't run it in a container, so haven't needed to specify the capabilities it needs <bjc>i mostly use wireshark for live capture, and never figured out how to get its pipe mode working <HexMachina>I think if guix shell had a mechanism to say "let me be root in the container" this would be sufficient <bjc>ping doesn't work in containers, so i assume some caps are turned off by default <HexMachina>yeah I've noticed that, I think that would be sidestepped if you could just be root in the container (which is e.g. the default in docker) <lfam>We could also say "the UNIX / Posix / Linux security model is swiss cheese" and just cross our fingers <bjc>if its locked by capability, then being root shouldn't make a difference <lfam>On a workstation with long-running user accounts, there's not much difference between compromising privileged or unprivileged users <lfam>Any compromise can eventually be turned into a root compromise <bjc>lfam: if this is just about wireshark, then supplying a service for regular users to use it is pretty standard and not too hard to do <HexMachina>lfam: that's why I'm trying to do all this inside a container, to limit the damage of compromise <bjc>containers can be compromised by users cooperating on both sides of the boundary <lfam>Anyways, we should definitely figure out how to make this work in the expected way <bjc>i'll try to put a patch together with a service for it. i don't think it should be a problem. the only reason i haven't done it yet was laziness and i already have it working for me =) <HexMachina>bjc: yes but my thread model right now isn't considering a malicious user already running outside the container, I'm just trying to contain the damage of an intruder exploiting wireshark by broadcasting malicious packets <bjc>yeah, i get it. i do the same thing for a lot of stuff. security happens through layers anyway, and containers can be a decent one <HexMachina>bjc: I definitely appreciate a service that makes this cleaner for guix system users but unfortunately that doesn't help me as a guix-on-foreign-distro user. <bjc>do system services not work on foreign distros? <bjc>i kind of assumed (operating-system) was still valid there for some reason <HexMachina>not as far as I know - but I'm welcome to be corrected here <bjc>you're probably right. i never really thought about it <HexMachina>there's no shepherd service running on my Ubuntu host <HexMachina>what I was hoping for here was some way of being root inside a guix shell container <bjc>can you create system containers on foreign distros? <bjc>not that i see a way to manipulate the container capabilities in a fine-grained way anyway. there is ‘--network’, but i don't know if that'll have everything you need <bjc>you can create docker containers with guix, if all else fails <podiki[m]>you can't run system services on a foreign distro as far as I know (since that needs sheperd pid 1 I believe) <podiki[m]>you can create containers via guix shell and do things in there; there is no setuid in a container <HexMachina>podiki[m]: yeah that's what I'm trying now, `guix pack -f docker wireshark bash inetuils coreutils` and then seeing if I can import that into docker and run tshark from there <podiki[m]>unfortunately I don't know nixos modules :-) system services in guix are like systemd services I guess, ones that run not as a user <jpoiret>shepherd services are like systemd services <jpoiret>but "system services" are roughly modular parts of a system configuration. They can contain shepherd service definitions, but also other stuff <jpoiret>for example, a service that extends the etc-service-type will just add files to /etc <jpoiret>i think the "system service" denomination is very unfortunate <bjc>i do wish we had a separate name for system services. it can be confusing <jpoiret>i would call them system extension points <jpoiret>maybe there's a good analogy to find with modular synthesizers as well <bjc>but then there's also ‘extensions’ on system services =) <jpoiret>bjc: yeah, cause extension points connect to other extension points by extending them. But not the most descriptive either <HexMachina>podiki[m]: the guix tshark IS able to capture successfully in a container I manually created via `docker load < $(guix pack -f docker wireshark)` <HexMachina>not as ergonomic as a possible `guix shell -C --root` but workable for now <HexMachina>much love to the guix community, you all are great :) <jpoiret>haven't followed the discussion, but `-C --root`? <HexMachina>jpoiret: that doesn't exist, I was suggesting it would be a nice addition to run containers from guix shell being root inside the container <HexMachina>which would help for things like wireshark that need to be root (or have certain capabilities) to run correctly <bjc>if you mean running a container as a non-root user, so that in the container you are root, i think that requires /etc/sub[ug]id <bjc>i know i need that for rootless podman <jpoiret>I don't envision it working from inside the container if the original user doesn't have the right permissions <HexMachina>jpoiret: because you need CAP_SYS_NET and CAP_SYS_ADMIN to do packet captures <jpoiret>unless you're now also capturing the new network namespace's packets <HexMachina>this works with docker. I, a non-root user, can launch a docker container in which I am root, and can run wireshark inside that container. But in this case, the docker daemon is root and sets things up on my behalf <jpoiret>couldn't you just start the process with just CAP_SYS_NET? <jpoiret>also, unless you passed some options to docker, I don't believe you're going to be capturing packets on the root network namespace interfaces <bjc>wouldn't it be a pretty big hole if a random user could start a rootless container and sniff network traffic? <bjc>or do you mean you want the container to start as root? <HexMachina>bjc: your use has to be a member of the 'docker' group for this to work <jpoiret>being able to run docker containers in the default docker configuration is equivalent to being root :) <jpoiret>docker doesn't support rootless containers by default <bjc>HexMachina: yeah, i get how it works in docker. i'm thinking of the guix shell container case <HexMachina>but being a member of the 'docker' group is a known security hole, because it allows you to talk tot he docker daemon which can do all sorts of things <HexMachina>bjc: yeah I haven't cleary thought out how (if?) such a thing would work in guix, given that there is no guix container daemon <jpoiret>you don't need a daemon to start containers, that's just how docker does it <bjc>you'd have to prefix the container script with ‘sudo’ or something <HexMachina>I meant more, a dameon that is root that can do things the normal user can't <bjc>can you: sudo /gnu/store/…/container.sh? <jpoiret>maybe something like `sudo guix shell container --dropcaps-except=network --network ...`? <HexMachina>alternatively, the guix dumpcap binary (installed as part of the wireshark package, which is what actually does the packet capture) could be installed as setuid / owned by wireshark group. But I don't know how setuid works with stuff in /gnu/store <jpoiret>that way you retain CAP_SYS_NET in the parent namespace and you also share the network namespace <lfam>In short, Guix can only make things setuid on Guix System <bjc>HexMachina: nothing in the store is setuid. that happens during activation at boot <HexMachina>ah right, yeah, I ran inot this before tryinig to test Singularity/Apptainer on guix <jpoiret>here's how Guix does it (don't tell anyone about this trick): you just copy out and chmod :) <bjc>guix developers hate this one simple trick!! <HexMachina>`guix pack -f squashfs` exists, but on a foreign distroy you can't just install the singularity package to run it, because of various setuid issues and the fact that singularity needs some files in /var <jpoiret>tbh, you could very well copy dumpcap out of the store, setcap it, and run that <HexMachina>wouldn't the wireshark binary be using the hardcoded full /gnu/store/.../dumpcap path though? <jpoiret>HexMachina: ah, I thought you could run it on its own <jpoiret>otherwise yes, that would be a problem <ngz>I wonder how Guix could properly handle this dumpcap issue. Maybe defining some wireshark service? <TristanCottam[m]>In a Shepherd service, is it possible to reference a file path relative to the current profile? Specifically in `<profile>/share/`. <jpoiret>there's no current profile in a shepherd service <jpoiret>the clean way would be to directly reference the dependency <jpoiret>since shepherd service start actions are in g-exps, you can just reference a package's output by using #$(file-append package "/share/...") <TristanCottam[m]>jpoiret: Or is it possible to somehow enable existing `native-search-paths` from a package? <jpoiret>well, since there are no profiles, it doesn't really make sense <TristanCottam[m]>jpoiret: Problem is the package in question uses `define`, not `define-public`. <TristanCottam[m]>Minetest server, to use the MINETEST_SUBGAME_PATH and MINETEST_MOD_PATH from native-search-paths inside make-forkexec-constructor. <jpoiret>then either 1) it's really not supposed to be used 2) it could be used, and you're 7 characters away from making that happen! (ignoring patch sending/review time, restrictions apply, suggestions are provided AS-IS) <jpoiret>you could add a field to your service configuration record to hold the list of "subgames" and "mods" I guess <civodul>ardon: hi! why don't you use Guix's ./pre-inst-env? <jpoiret>then it's just a matter of using the search-paths functions in Guix to combine those manually <TristanCottam[m]>The package is minetest-data, it's the Minetest game data for the Minetest game engine <TristanCottam[m]>I could try pulling off the good old code as data trick and extract it manually <ardon>civodul: Hi! I use it when building new packages, but in this case I'd like to test the build of new home services that I'm working on in my local Guix checkout <ardon>And I use the pre-inst-env script in my local config for this, but adding Guix to the load path doesn't seem to do the trick <civodul>ardon: if you have a local Guix checkout that contains your modifications, you can run "./pre-inst-env guix home container ~/path/to/home-config.scm" from that checkout <ardon>civodul: Thanks, I considered this, but it's kind of inconvenient seeing as I have a Makefile in my config set up. What I really want to understand is why adding the local Guix checkout to guile's load path isn't enough. What else is needed that the pre-inst-env takes care of? <civodul>ardon: it sets GUIX_UNINSTALLED (you should take a look, it's just a few lines of shell) <ardon>I took a look and included most of what is there, albeit not understanding most of it. However, setting that flag causes RDE and other guile libraries that have a dependency on Guix to fail at build time <ardon>civodul: Do you reckon this flag alone is what may cause the local guix modules not to be found? <jpoiret>ardon: if you run `guix` outside of the ./pre-inst-env, you'll use the `guix` wrapper from your `guix pull` checkout, which will probably mess with everything <jpoiret>also, you'd need to add -L path/to/rde to the command line <jpoiret>overall, i'd recommend replace all uses of `guix` in your Makefile with `./path/to/check-out/pre-inst-env guix` instead <bjc>is there an issue with setting up setuid-programs in ‘guix system vm’? it's telling me file not found for files that exist. is this because of how the store is mounted? <bjc>ie: too late for setuid-programs to work <bjc>and if so, is that a bug or intentional? <lfam>Is that error message from Guix or from the kernel or glibc <bjc>that's from the early-boot guile <lfam>Can you share the exact text <bjc>the activation for everything starts in guile at first boot, before shepherd. i thought it was called the early-boot guile? <lfam>Those error messages can be very misleading. They don't tell you *which* file is not found, and they can be overloaded in other ways <lfam>You'd have to run the program under strace to see what was actually missing <bjc>i'm not sure i follow. this is happening during boot, so it's not really feasible to strace it <jpoiret>i wouldn't call that early boot, early boot is the script that runs until the /run/current-system/boot script is called <bjc>ah, ok. i thought everything pre-shepherd was considered early boot <lfam>Anyways, take my hint about it not telling you what is missing <lfam>It can also give this error in cases where it lacks permissions to carry out the operations <lfam>At this low level, the error reporting is not very good <lfam>Also `guix system vm` creates immutable VMs. Nothing can be changed on them <lfam>So, it's possible that it simply can't create the setuid copy <bjc>oh, that's possible. i can make it volatile <lfam>You might try `guix system image` <jpoiret>but I wonder why only dumpcap would not work, aren't there other setuid programs by default? <lfam>`guix system vm` creates a shell script that invokes QEMU with some parameters. All the referenced files are in /gnu/store, again immutable <bjc>adding volatile didn't help it, fwiw <lfam>Dunno, it was just a guess <bjc>yeah, /run/setuid-programs is tmpfs anyway <jpoiret>but yeah from gnu/system/vm.scm, it seems like /run/setuid-programs/ resides on the main image <bjc>i'm not modifying the store, i'm trying to copy a program into /run/setuid-programs by using the ‘setuid-programs-service-type’. i've also tried it with the ‘setuid-programs’ slot on ‘operating-system’ with the same results <lfam>Understood, but Guix creates setuid-programs by writing files after boot. Impossible if the image file is immutable <bjc>jpoiret: my mistake. it isn't tmpfs. i thought everything in /run was <lfam>"Under the hood, the actual setuid programs are created in the /run/setuid-programs directory at system activation time. The files in this directory refer to the “real” binaries, which are in the store. " <jpoiret>(you will need to copy the image out of the store and make it u+w as well) <lfam>System activation is aka later stages of booting <bjc>since /run/setuid-programs is created fresh at boot every time, would it make sense to change it to tmpfs? <lfam>I confirm that a basic `guix system vm` does have some setuid-programs, so maybe we are discussing a red herring <bjc>jpoiret: is that to avoid having mount.tmpfs on the initrd? <lfam>However, it seems like the default setuid-programs are created *before* the build of the VM is complete <lfam>Whereas, you are seeing a failure long after the VM is built <lfam>Hm, I'm wrong, it does populate setuid-programs at boot time <jpoiret>can you try using (file-append wireshare "/bin/dumpcap") instead of the g-exp bjc? <jpoiret>not that I think it will change anythng 😈 <bjc>jpoiret: i did that accidentally already. it complains about ‘file-append’ not being defined at boot-time <jpoiret>that's because you put it inside a g-exp