IRC channel logs
2025-06-08.log
back to list of logs
<sturm>what part of a shepherd-service defines which packages it depends on? I'm trying to write a simple service that runs a Python script that depends on libnotify. <sturm>or maybe I need to write a package first? <sturm>if I look at services/lirc.scm, which line is saying it depends on the lirc package? <Tadhgmister>sturm I think it automatically determines dependencies based on gexp and otherwise doesn't have any explicit list of dependencies <Tadhgmister>like if you do `#$(file-append quark "/bin/quark")` in the service it will depend on the `quark` package <getstate>Hi everyone, how do I test a change to gnu/system/shadow.scm? Can I use pre-inst-env guix system? <sturm>Tadhgmister: you don't happen to have seen an example of packing up a simple one-file Python/Perl/Ruby etc. script into a service have you? <Tadhgmister>like the service just runs the one script and doesn't have any external python dependencies other than standard library? <Tadhgmister>or are you struggling to add external libraries to your script? <sturm>both - it is a single file python script, with one dependency - libnotify <Tadhgmister>hmm... for guile dependencies there is a dedicated field to specify which modules should be importable I'm not sure there is anything as easy for python <Tadhgmister>I feel like a package where the inputs specify the dependencies and a source is a `(local-file)` and uses the copy build system should work, it should patch the shebang of `#!/usr/bin/python` to the one of the python dependency, you may need to edit the phases to ensure it has execute permission <Tadhgmister>let me check if I have an applicable example in my configs <Tadhgmister>oh no it is not the same context.... you don't need libnotify referenced in the *build container* you need it in the shepherd container <sturm>true, so I guess a propagated-input? <Tadhgmister>I don't think so, gexp dependencies doesnt do anything with environment variables, you need the PYTHONPATH to point to the place with a module right? <Tadhgmister>oh wait, does libnotify expose python modules? or is like a dbus thingy, that may be more complicated <sturm>sorry, the script also depends on python-pygobject which is how it uses the libnotify library, but that seems to already be available by default so I haven't worried about that as a dependency just yet <Tadhgmister>propogated inputs only matter when it is installed to a profile and referencing the package directly in a gexp doesn't generate any profile. That may be a better avenue to go down though, being able to map a `guix shell --pure` that runs your script correctly to a guile profile with identical properties to run the service in <sturm>doesn't need to manipulate the PYTHONPATH I believe, just run `python3 myscript.py` <Tadhgmister>when I say better avenue I don't necessarily mean you will figure out results, it seems like the kind of thing that should exist but it is possible no one has necessarily implemented or decently documented it <Tadhgmister>I still don't know where to even find the documentation for the `fork+exec-command` that magically exists within gexps for shepherd services, <Tadhgmister>strum what I may recommend is to run `guix shell --pure python python-pygobject libnotify` verify that `python3 myscript.py` works as you expect it and doesn't have additional dependencies and then in that shell run `env > first-test.env` and try passing a string with all the environment variables to the `#:environment-variables` argument of fork+exec-command <Tadhgmister>where the command is literally just `(list "python3" #$(local-file "myscript.py"))`as python3 will exist with the PATH environment set <Tadhgmister>if that works then it is indeed just environment variables, you can cull out variables until you are confident about the set you need and then probably figure out how to generate the profile corresponding to the packages you need and read the environment variables from that but I have no clue how to do that in pure guile <sturm>thanks Tadhgmister, sounds like a good approach <Tadhgmister>oh you'd need coreutils to use the env command, I'm sure you'll figure it out <apteryx>Tadhgmister: for things like fork+exec-command, these are defined in the Shepherd itself, so 'info shepherd' would have it indexed. <Tadhgmister>ahhhhh, I knew I found it at one point and couldn't remember where that is very helpful thank you <apteryx>hm, I'm still trying ot wrap my head around define-c-struct. It has a nice record-like interface (syntax), but it seems I can't simply define it as we do with srfi-9 records, which confuses me a bit. <apteryx>OK, the interface works like this: you create a byte-vector object of the write size, then you call the writer which can write every field, e.g.: (write-user-cap-header! bv offset version pid), where bv is the bytevector destination, offset can be 0, and the rest are the field values to write. <jakef>hi Guix, timestamps in tests don't seem to be breaking reproducibility (with guix build --check). just confirming that's expected? <ruther>jakef: tests don't typically change the output of the package, so that is expected <sturm>has the recommended pattern of using a guix.scm linked to a .guix/modules/mypackagename.scm changed? I'm now getting a warning when I `guix shell -L . mypackagename` <sturm>"warning: module name (mypackagename) does not match 'guix.scm'" <ruther>sturm: with module mypackagename, you would have to put .guix/modules to -L, not . <sturm>thanks ruther. Is there any use in having the guix.scm symlink? <ruther>sturm: it is for `guix shell`, when you execute it (without arguments or with -f ./guix.scm) it will give you a development shell for the package the guix.scm returns <jakef>the manual recommends using guix 'shell -CPW' for doing things with 'pre-inst-env', but whenever i use pre-inst-env i get spammed with "source file (in guix local checkout) newer than compiled (in .guix-profile)" <luca>idk what it really means, but what works for me is running `make` first, before doing anything with pre-inst-env <ruther>jakef: that's normal, the go files you've compiled at one point are outdated. You can ignore it. If you don't like it and want to keep behavior, delete the .go files. If you want to speed up the evaluation, compile with make. <jlicht>I still see fsck output flashing by on one of my guix system machines when rebooting: how can I capture and/or store this output somewhere? <ruther>jlicht: you can't unless you came up with a new initrd / mount mechanism <ruther>jlicht: except for stuff like capturing it externally like with serial port or camera <jlicht>That makes sense. Time to transcribe some video! <sturm>thanks for the detailed email reply ruther! <meaty>Is there any reason I should avoid using the @ procedure in gexps <ekaitz>meaty: i think you should avoid it in general, but idk if gexps have extra reasons <cancername_>hi #guix! I'd like to run a specific system service in a non-default Linux network namespace, in addition to the same service running in the default one. how should I go about doing that? I thought about extending shepherd-root-service-type, but make-forkexec-constructor doesn't have parameters to enter namespace, so I'd have to use it with "ip netns exec namespace program config", but then there's <cancername_>also the issue of getting a path in the store from a configuration object. is there some kind of better way to accomplish this? <ruther>cancername_: you get path from store in basically all shepherd services, so I don't really know what the issue is. Anyway for your use-case, see the least-authority-wrapper. I think it should be suited directly for your use case, however if not, you can at least see its source for inspiration on how to do what you want <ruther>cancername_: note that least-authority-wrapper doesn't have any documentation <cancername_>ruther: thanks! sorry, but I don't see a way to specify the network namespace in least-authority-wrapper? also, I'm confused how I'd use it with a system service <ruther>cancername_: least-authority-wrapper is meant primarily for system services. Grep the guix source code for examples <ruther>cancername_: you specify the namespaces that are supposed to be different using the namespaces argument. The default values contains net symbol. But as I was saying, I am not sure if this is the thing you want and if not, see the implementaion, namely the procedure call-with-container <cancername_>ruther: yeah, I see how to use it with shepherd services now, thanks! I don't think I can specify a network namespace, it seems like run-container always creates a new one? I'd want to call setns with the particular namespace beforehand, instead of creating a new one. is that a thing in guix right now, or will I have to do something like call the ip binary or call fork,setns,unshare myself? <ruther>cancername_: you're right, it doesn't allow you to set to one specific namespace. I don't think the implementation supports it, but it shoudln't be complicated addition to it I believe <cancername_>eh, probably easier to just call ip, I'm not an experienced scheme developer. maybe next time. thanks for your help regardless <ruther>cancername_: if you don't feel comfortable with scheme, it doesn't matter, you can just make a bash script or anything else you prefer and call that from your service instead <PotentialRoadkil>Hey all. I'm trying to do my first `guix pull` after the codeberg redirect change and am receiving: <PotentialRoadkil>guix pull: error: aborting update of channel 'guix' to commit daa1128b9c411f4ca32ea9715e38e71eb6ef4610, which is not a descendant of ad8cb7af8fc572bb3d11cd0344bd2bed3b9d653f <ruther>PotentialRoadkil: there was a mistake recently. You will have to allow downgrades <PotentialRoadkil>Thank ya. Does allowing downgrade keep my store as-is with new packages added to it? <ruther>PotentialRoadkil: yes, basically only guix gc removes stuff from store <ruther>PotentialRoadkil: and guix pull specifically just pulls the guix executable itself, it doesn't touch your profile with packages at all. That's what guix package is for, like guix package -u for upgrading <PotentialRoadkil>Oh interesting. I thought it pulled source and then built whatever deltas from there. Good to know it also pulls the binary. <PotentialRoadkil>Last question, just cause I'm curious and my mailing list/bug tracker/irc archive-fu isn't strong enough. Is the mistake documented somewhere? <dariqq>podiki: does it work with --no-grafts? <podiki>nope (first thing i thought of too) <podiki>unclear if it works (but don't see the tray icon) or just hangs with "guix shell syncthing-gtk glib:bin --pure -- syncthing-gtk" <podiki>probably something is missing when I do --pure to make it work/see the error <dariqq>i get the setup wizard (with and without grafts). With pure I get "cannot open display:" <podiki>i wonder if there is something in my environment pulling in another librsvg in some search path (one of the xdg_?) <ruther>podiki: have you tried unsetting the GI_TYPELIB_PATH in your environment? <podiki>yes (well just using the syncthing-gtk wrapper script GI_TYPELIB_PATH rather than how it adds to the env) <podiki>i last built home profile ~5 days ago, i wonder what changed <ekaitz>podiki: any info about that thing you told me? <podiki>;-) I did mean to respond to your email with a teaser, will do that today <dajole>I'm having trouble getting my vm operating-system configuration to correctly set `XDG_RUNTIME_DIR`. Unfortunately, the documentation isn't helpful in that regard. How do I figure out the correct way to set it? <ekaitz>dajole: you could set environment variables with a service that does that <ekaitz>dajole: (simple-service 'adwaita-dark-theme session-environment-service-type '(("XDG_RUNTIME_DIR" . "..."))) <dajole>ekaitz: that's sort of what I have been trying to do so far. I get references to `elogind`, but that seems to conflict with `seatd` required for sway. I'm having trouble figuring out what exactly I need. <ekaitz>dajole: (simple-service 'set-xdg-runtime-dir session-environment-service-type '(("XDG_RUNTIME_DIR" . "..."))) <dajole>So this would be defining a service on the fly? <ekaitz>dajole: just to clarify: in guix services are not necessarily daemons <ekaitz>are "things" that provide "other things" <ekaitz>that is creating a guix service called set-xdg-runtime-dir, usign teh session-environment-service-type as a "template" <dajole>That's helpful, thanks. I have been using Linux for years, but Guix makes me feel rather stupid 😓 <podiki>"guix shell syncthing-gtk glib:bin dbus gdk-pixbuf --pure -- syncthing-gtk" gets me to same error (rsvg) in a pure shell, without dbus or gdk-pixbuf it hangs before that <podiki>dajole: think instead of the joyful beginner's mind :-) <ekaitz>dajole: that's a good sign, it means you are learning things, but also, don't be so hard on yourself <ekaitz>if you never programmed in scheme before it can be a little bit weird at the beginning <ekaitz>we also have very poor naming in the "services" <ekaitz>it's a universal source of confusion <ekaitz>also dajole if you have more questions don't hesitate to ping me here or send me an email and I'll try to help <dajole>Thank you! For the moment I'm playing around with your suggestion above and reading up on some things. Thanks again. <muaddibb>dajole: Guix makes me feel stupid too :s. but it is also very fun to play with, as podiki said. now that I just installed on my main machine, I'm invested <ekaitz>muaddibb: I've been using Guix as a daily driver for 5 years but I'm still learning hehe <Lumie>3.5 years here, and I'm still a noob <lfam>On Codeberg, how do you mark a pull request as manually merged? <podiki>i think it should just pick up that the commit was made? that's how it usually works in forges i've seen <lfam>Apparently I've been doing it wrong <podiki>it shows manually merged on that one <podiki>oh i see wasn't you that did that <lfam>Someone changed it later on <lfam>So, it's like it detected that I pushed it, but I still need to confirm <lfam>I asked in #codeberg, we'll see if anyone can help there