IRC channel logs
2024-09-19.log
back to list of logs
<aswjrisp>In my config it is (services (list my-service ...)) where my-service is the service in the paste above. <mange>Is that a system service, aswjrisp? Does it work? I would have expected you to need to gexp-unquote the "mpv" bit with something like #$(file-append mpv "/bin/mpv") <aswjrisp>mange: I am trying to execute an arbitrary program as a test service. It does not work currently as I can not reconfigure the system after adding the service I wrote to my config. Would it work if I gave it the full path to mpv instead of just mpv? <mange>That's what I'm suggesting with the file-append thing, yeah. That might not work in all circumstances (e.g. if it needs other environment variables), but I think it works for mpv. <mirai>aswjrisp: see the existing services in guix for an idea <wizard>im trying to update sbcl-trial rn, shaved 500 lines of recursive yaks, and now i'm stuck lol <wizard>would anyone be willing to help out :) <wizard>here let me send my guix.scm that i'm trying to get working as a proof of concept, and the failed build log <wizard>sbcl-pathname-utils needs to be updated for it to work, but trial is sttill missing symbols from it for some reason <wizard>oh the drv is a lil too long for the debian pastebin <wizard>m27bxck3z5pvclnanq9xl5vd01nk9v-sbcl-trial-wlo-1.2.0-3.b76c3e6.drv.gz <wizard>i'm very new to all of this guix stuff and i have hopes that i can upstream this at some point once i get everything shaped up and merged into the actual guix packages tree <wizard>(sorry about the really long sentence there oops) <wizard>i have a feeling my problem is somewhere inside of the way i'm trying to override sbcl-pathname-utils but i'm not entirely sure <mange>It's not your problem, but it looks like your sbcl-pathname-utils* has the inputs and native-inputs swapped from what's in Guix's package. <wizard>i'm sure there's a lot of optimization i can do with the inputs/native inputs on these packages <wizard>that's a problem for after i get the whole thing building though <wizard>same with the metadata on all of the packages, they're good enough to start understanding what's there but not good enough for upstream atm <aswjrisp>I looked at the guix repo for an example service. I took inspiration from a mumi service. But when I reconfigure I am still getting a similar error. This is my service currently https://termbin.com/qe8a <apteryx>oof, our bsnes emulator uses ton of cpu for some reasons <aswjrisp>mirai: I changed mpv "/run/current-system/profile/bin/mpv" to mpv "/bin/mpv" but I get the error when reconfiguring. <aswjrisp>mange: This is the error I am getting when I try to reconfigure. https://termbin.com/xkvf The error goes away if comment out the service, so I know it is a problem with the service I am trying to make. <mange>The last line there is pretty clear what the problem is: "error: shepherd-root-service-type: unbound variable". Do you have a (use-modules (gnu services shepherd)) or equivalent in your file? <aswjrisp>mange: You were right. I was missing the use service shepherd. <aswjrisp>Now it reconfigures, the service shows up in herd status and I can start it with herd start. <aswjrisp>Rutherther: mirai: mange: Thanks for your help in getting my first service working. <apteryx>retroarch contains bundled libraries, right? <f1refly>since some time I can't guix upgrade because building icedove-l10n fails. is anyone else having this issue? <apteryx>yes, the icedove build has been broken since the last update <apteryx>perhaps you can use icedove-minimal for now <aswjrisp>f1refly: If you are up for a challenge and open to a different user interface you could also try a command line email client like mutt, neamutt or mblaze. Or an emacs email client like mu4e. <aswjrisp>The challenge being setting up one of those email clients as it can be tricky. <f1refly>i also use icedove as my calendar and task client, i don't think mutt can do that <aswjrisp>I am working on a wpa_supplicant service that uses a shell scipt to run wpa_supplicant with command line arguments. I have tested the shell script by itself and it work. I am able <aswjrisp>to reconfigure and see the service with herd. <aswjrisp>But I get this error when I try to start the service with herd. "herd: error: failed to start service wpa_supplicant" <aswjrisp>f1refly: You would need other program for calendar and task like cal, taskwarrior or org-mode in emacs. <aswjrisp>Each program has it's own learning curve. So probably only a good idea if you have some time to set aside to learn how to set them up and use them. <aswjrisp>The service I have made that is not starting is also not putting anything into the log file I specified in the service. So no clues there and there error message does not give cluse to why the service failed to start. <aswjrisp>I decided to try to use pkill in the make-kill-destructor because it looked like shepherd uses pid to stop a service and I was not sure if that would work with the shell script running wpa_supplicant. <aswjrisp>f1refly: You should also check if icedove-minimal has calendar and task functionality. <aswjrisp>The script that I am try to get the service to run does some preliminary work like getting the interface name to use for the wpa_supplicant command. So I would like to use the script instead of run wpa_supplicant directely in the service. <apteryx>the only thing icedove-minimal lacks are translations <apteryx>so it won't follow your system language <f1refly>can I just switch and minial picks up my user profile? <aswjrisp>I tried commenting out the requirement part. It did not work same error. Then I tried uncommenting and add udev the requirements. I got the same error. <aswjrisp>I want the service to run `bash /home/h/u/scripts/networking/start-wpa.sh`. That works fine. <aswjrisp>I also ran pkill wpa_supplicant before trying to start the service. I still get the error message. <aswjrisp>I looked at dmesg it does not have anything from the failed start of the service. <apteryx>f1refly: yes you can just switch them <civodul>aswjrisp: maybe check /var/log/messages, that’s where shepherd logs what happens <aswjrisp>civodul: thanks for the suggestion to check /var/log/messages. I looked and the last entry was one saying my service was disabled. But then my system froze and I had to hard power off. <aswjrisp>After reboot my service no longer shows up in the output of herd status even after doing a successful reconfigure. <Rutherther>aswjrisp services usually get disabled when they get restarted too many times. <aswjrisp>When I try to enable my service with `herd enable wpa_supplicant` it says "herd: error: service 'wpa_supplicant' cannot be found". My service also no longer shows up in the output of `herd status`. <Rutherther>@aswas for no longer showing in output, are you sure you are executing herd with sudo to use the system services socket? <aswjrisp>Yes I have run `su - root` and successfully authenticated as root. I am using the root user to run the herd commands. <aswjrisp>In the output of `herd status` I can see the other services. Including my first toy service. <Rutherther>aswjrisp so after reboot you did reconfigure, and it didn't show up, is that correct? <aswjrisp>Yes that is correct. I have done a couple of reconfigures since reboot and it still does not show up. <Rutherther>Okay. I dont really see why the service would not be present if there are not any errors in reconfigure. Just a note though. The services usually work by returning pid from the start, and then killing only that pid, not a random process with matching name. The stop procedure will receive the value as first argument <aswjrisp>Rutherther: I was not sure what it would stop if I used a shell script. So that is why I thought of using the pkill. I can try taking out the pkill part and see if that helps. <Rutherther>You just have to make sure the start will return the pid. You can obtain it from the scripts output for example <Rutherther>Or if the script runs for the whole duration of wpa supplicant, then make forkexec executor is already able to return its pid, and you can kill that in stop <aswjrisp>Rutherther: I will have to look into this pid part a bit more. But first I want to see if I can get the service to start. <aswjrisp>I think I will try another reboot and hopefully this service is in the herd status list. <aswjrisp>I think it is weird that one of my services shows up in herd status output but the other does not. <aswjrisp>Rutherther: It looks like the reconfigure was not successful. I got errors about invalid keyword "wpa_supplicant" as well as some service could not be reconfigured. <aswjrisp>It looks like your intuition was good. It appears to be comming from the make-kill-destructor. I found this out because I changed the pkill to target wpa intsead of wpa_supplicant. Which caused the reconfigure warning to change. <aswjrisp>I am going to remove the entire pkill thing I put in make-kill-destructor. <aswjrisp>Removing the pkill from the make-kill destructor allowed the reconfigure to complete successfully. <aswjrisp>Now the service shows up in the output of herd status. <aswjrisp>`herd start wpa-supplicant` works. It says the service is started. <aswjrisp>But when I `pgrep wpa` it shows me that the wpa_supplicant daemon is not running. <Rutherther>What is in the log file you specified, and what in shepherd log? <civodul>aswjrisp: ‘herd status wpa-supplicant’ prints a PID; it’s that process that gets terminated upon ‘herd stop wpa-supplicant’ <aswjrisp>civodul: So I should normally leave it like (make-kill-destructor). <civodul>i didn’t follow the entire discussion, but the ‘wpa-supplicant’ service in (gnu services networking) looks good to me <civodul>which doesn’t mean it’s bug-free :-), but at least start/stop are consistent <aswjrisp>civodul: In this case the wpa-supplicant is a service I created. To start a shell script I wrote that starts wpa_supplicant. This is because I wanted it to be disabled by default. <civodul>ah ok, i was looking at the one in Guix <aswjrisp>That was why I tried pkill in the make-kill-destructor because I did not know what shepherd was going to kill if I told it to use a shell script to start wpa_supplicant. <aswjrisp>Rutherther: I changed the log of the service to a text file instead of /dev/null and was able to reconfigure successfully. <aswjrisp>The service showed up in the output of herd status. <aswjrisp>But I got the failed to start service when I tried to start it with `herd start wpa-supplicant`. <aswjrisp>The service is not mentioned in the messages from shepherd in /var/log/messages. <aswjrisp>Nothing was output to the text file it set for the services log. <aswjrisp>civodul: thanks, I will take another look at it. <aswjrisp>I tried commenting out the logging part of the service and was able to reconfigure successfully. But I still get the failed to start service error. <aswjrisp>I thought that maybe my script was somehow incompatible with shepherd so I tried removing the -B from my execution of wpa_supplicant. But it still could not start the service. <aswjrisp>I saw that in /var/log/messages that my service was disabled. <aswjrisp>I endabled it and started it. It said the service was started. <aswjrisp>But pgrep tells me that wpa_supplicant is not running. <aswjrisp>Even though herd said the service was started, when I check with herd status it says it is stoped. <aswjrisp>So something is stoping it from continueing to run. <nckx>Do services run with PATH=/run/current-system/profile/{,s}bin? <civodul>nckx: according to /proc/1/environ, it’s whatever the initrd put in it <civodul>i have: PATH=/gnu/store/8phianvpd31nvd5g4kdqs9gyfk36ghwb-e2fsck-static-1.47.0/sbin:/gnu/store/nymfinfqxymbw772vc3bcgva31h44k4x-loadkeys-static-2.5.1/bin <nckx>OK, so that's the answer to aswjrisp's problem then, right? <nckx>And thanks for the confirmation, both of you. <aswjrisp>nckx: Are you suggesting that my service should use /run/current-system/profile/bin/bash instead of /bin/bash? <aswjrisp>I was reading through the shepherd manual. <Rutherther>aswjrisp: your service isn't using /bin/bash. It is using "/gnu/store/...-bash-.../bin/bash", being the full path to an existing bash executable <aswjrisp>The examples section looks like they are shepherd configuration specific and I am not sure how they would be used in a guix configuration. <aswjrisp>see in the defining services section of the shepherd manual that in talks about return values. <aswjrisp>Rutherther: I think these are the return values you were talking about before. <aswjrisp>Currently my shell script does not explicitly return anything. <nckx>I haven't read the backlog in detail, so apologies if I'm missing a point, but I assumed that your script invoked wpa_supplicant. <nckx>If so, it ain't gonna find it. <Rutherther>aswjrisp: it doesn't matter it doesn't return anything. It's the script pid that will become the run value <aswjrisp>nckx: Yes I have written a shell script that starts wpa_supplicant. It works fine `bash start-wpa.sh`. <nckx>Because wpa_supplicant is in PATH then. <aswjrisp>I am trying to get that script to run as the start of a shepherd service. <nckx>Unless your script explicitly invokes /run/current.../...bin/wpa_supplicant. <aswjrisp>nckx: In my script I call it with just wpa_supplicant followed by the arguments. <aswjrisp>I will try it with the full run path in the script. <nckx>If PATH does not contain the directory with the binary, it can't work. <nckx>I'm still half expecting to be told I'm missing a point though. <aswjrisp>I changed the path for wpa_supplicant in my script to the one given by which. I can enable the service. I can start the service. But when I check if wpa_supplicant is running with pgrep it is not. Also herd status says the service is stopped. <aswjrisp>I have looked at the section on service contructors and destructors in the shepherd manual. I think that section is probably important to dealing with getting a service working properly but it is written like a programming reference which is not overly friendly to someone know to guile. <aswjrisp>Could it be the shebang I am using for the shell script? <lispmacs[work]>hi, what do I need to install or configure so that Gnome Shell (Nautilus) can mount NTFS drives? <yelninei>aswjrisp maybe try exec /run/current-system/profile/sbin/wpa_supplicant ? <aswjrisp>yelninei: In the shell script or in the service start? <yelninei>in your script replace "/run/current-system/profile/sbin/wpa_supplicant ..." with "exec /run/current-system/profile/sbin/wpa_supplicant ... " <lynn_sh>is there an easy way to make sure what version of a compiler is being used for a build system? im trying to enforce my package of zig is used for a package. <lynn_sh>im building the package with all the flags no problem on my own, but through the zig-build-system it is giving an error that is very suspiciously something an outdated zig compiler would throw. <yelninei>lynn_sh: there might be a #:zig argument to set the zig to use (at least something similiar works with other build-systems) <lynn_sh>yelninei can you think of a build system that uses this? i thought maybe python but i didn't find such a thing. i can work backwards from an example somewhere. <lynn_sh>i tried it in (arguments (list #:zig)) <yelninei>i know go-build-system has #:go and meson-build-system #:meson, not sure if zig-build-system allows that <lynn_sh>hrm. yeah it allows for it, i set it and it just fails despite passing on my own build. guess i have more digging to do, thanks! <bdju>I have capslock rebound to a compose key in my sway config and it stopped working recently. anyone else have a similar problem? I don't think I've fully exited my sway session since I fixed the locale problem so it might just be tied to that. but I have reloaded my config several times with it not helping <nckx>aswjrisp: No, the shebang is completely ignored (you could write a poem) because you invoke ‘bash FILE’ and the shebang is just a comment to bash. <nckx>It's only magical when invoked as a stand-alone executable so the shebang is handled by the kernel. <nckx>Instead, try adding ‘exec>/tmp/log 2>&1’ to the top of your script if you still haven't got Shepherd logs to work properly. Will log. <nckx>Guessing's no longer fun. <makx>maybe embarassing question: does one submit cargo2guix things to guix or does one just dump them in one's own channel? <futurile>makx: if there's an end-user application, and the patches meet reasonable quality standards, then upstream them. <nckx>makx: I don't think there's a significant difference between Cargo packages and other packages in that regard. <nckx>Is cargo2guix something new or just a synonym for guix import? <makx>(what a clowncar of dependencies it sometimes is) <makx>nckx: cargo2guix takes a Cargo.lock file and outputs a package definition <nckx>Yes, and these tools do make it slightly more likely that something nasty (proprietary) sneaks into the huge dependency graph, perhaps even unintentionally, so that can hinder upstreaming. <futurile>oh that's new to me - got a project link for that makx? <nckx>I did try searching for it first but it was ‘corrected’ to cargo2nix. <makx>only discovered it last night in a bit of desparation trying to get starship to run <makx>but maybe this is also a sign that I shouldn't be using that :D <futurile>makx: did you look in toys to see if someone else has packaged starship? <futurile>makx: I haven't seen this before - I know a few people have thought along similar lines - I'll have to try it out on the weekend <makx>successfully built /gnu/store/3q36g22pxnwm3l9lb0128ch9a790l5cn-rust-starship-1.20.1.drv -- well that worked <futurile>makx: there's a guix community called 'whereiseveryone' - it has a search engine of lots of people's channels - often stuff that wasn't good enough quality to get into guix - https://toys.whereis.xn--q9jyb4c/ <futurile>makx: for stuff that you want, but don't want to spend the time upstream - sometimes you can steam someone else's package definition or use their channel (if you trust them etc) <makx>starship is in there, but not the 1.20.1 ;) <civodul>efraim: just noticed that ‘expat/fixed’ has: (replacement expat/fixed) <nckx>futurile: Mmm, steamed packages. <makx>since nowadays one doesn't find anything via "search" engines anymore <aswjrisp>yelninei is gone. I tried their suggest I get the same behavior. It says the service started but then pgrep says wpa_supplicant is not running and herd status says it is stopped. <nckx>I don't really understand why they suggested that. All it changes is that instead of wpa_supplicant running as a child of your (blocked) script, your script ‘becomes’ wpa_supplicant which never returns. <nckx>Sometimes useful, but I don't see how here. <aswjrisp>nckx: I will try your exec suggestion to get logging. <nckx>I hope you finally get a useful hint. <nckx>(The fact that both suggestions add ‘exec’ is a coincidence.) <look>makx: Oh hi, cargo2guix is my project, the purpose of it was to make packaging stuff outside the crates.io registry really easy, and been working flawless for me, for generating the packages definitions in the past month or so <look>right now its essentially a cargo importer (instead of a crate importer like what we have on guix) <aswjrisp>look: That sounds like a good project idea. Does crates.io still need something like a github (microsoft) account? <aswjrisp>nckx: It did log. Which is very helpful so it looks like the problem is that it can not find other program I used in the script like grep, sed, cut and ip. So it is giving bogus arguments to wpa_supplicant as a result. <aswjrisp>I think I can fix it by replacing just the command names with the paths given for them by which. <look>aswjrisp: for login and publishing yes, you use a gh account <aswjrisp>look: So for those who choose to publish elsewhere, your project helps pull in those. <nckx>aswjrisp: Well, you're moving further and further away from a maintainable end product, but I can't fault anything you just said. It will work. <nckx>As an experiment or stopgap solution it will do. <nckx>Good night, sweet #guix o/ <look>aswjrisp: yes, in fact you can package stuff that hasn't been published anywhere, the key point is not wasting a lot of time because the package definitions it generates just straight up work, been packaging working rust apps lately in 5-10 mins <aswjrisp>nckx: It did work I was able to start wpa_supplicant through the service using the script. pgrep confirms that it is running. <aswjrisp>Oddly though it when I run herd status it says the service has stopped. Even though pgrep tells me that wpa_supplicant is still running. In /tmp/log there are no more error messages. <aswjrisp>look: Sounds nice, thanks for sharing what you made. <aswjrisp>civodul: Rutherther: nckx: yelninei: Thank you for your help. <stochastic>Is there a way to apply a patch to your local guix installation? <aswjrisp>The service starts wpa_supplicant and it continues to run. <aswjrisp>Removing the -B option from wpa_supplicant fixed the odd behavior now the services start and stop are working as expected. <Rutherther>yeah, because with -B the script stopped right away, instead of living for whole lifetime of wpa_supplicant itself <nckx>It's not odd. You're asking wpa_supplicant to fork into the background, so it does, and control returns to your script, and your script exits, and hence the Shepherd marks the service as stopped.