IRC channel logs
2024-11-22.log
back to list of logs
<gabber>how can i access #:python (the private-keyword in (guix build-system pyproject)'s lower function)? removing it from the private-keywords list and adding it to the keyword-arguements in the build-phase lambda did not do the trick <ekaitz>gabber: can you send the #:python in an (arguments ...)? <gabber>WDYM? i try to access the value of it in (arguments `(#:phases ...)) <mange>Are you trying to access the package passed as #:python during a build phase? What are you trying to do with it? <ekaitz>accessing? i thought you wanted to overwrite it! <ekaitz>gabber: you can send the python you want to use with (arguments #:python my-python) if i'm not mistaken <ekaitz>for accessing... isn't it the python in the %build-inputs? <gabber>yes, it's about access - and in the end an issue that emerged when using gunicorn as a shepherd-service <apteryx>hm, seems suspend stopped working for me on 6.11.8, at least the video signal doesn't come back upon resume <rho`n>Hi, I have recently installed a Guix System as a home server. I have a cron/mcron job I want to run. Should that go in my main system config.scm or is it better to just run it from a user's Guix Home ? I have tried setting it up in my system config.scm, but keep running into errors. <mange>I would put it in your system config, because I think the user one will only run when the user is logged in. What sort of errors are you running into? <rho`n>The last part of the log is: <rho`n>guix/build/utils.scm:822:6: In procedure invoke: <rho`n> program: "/gnu/store/c9hmd29cqhl48s1xavlxyv7ay47zhyhz-mcron-1.2.3/bin/mcron" <rho`n> arguments: ("--schedule=20" "prologue" "job") <rho`n>Sorry for code spamming the room earlier -- completely miffed the paste.debian.net in the topic <mange>I think the key line in that error is "wrong type to apply: 0". Can you put your mcron config into a paste? My guess is that there's a quote missing around the mcron schedule. <rho`n>the error is generated when I run the guix system reconfigure command <mange>Ah, your range() call looks wrong. In scheme notation, functions go inside the parens: (range 0 59 10) <rho`n>oh, good catch. let me try fixing that <mange>The error message is saying "we tried to call 0 as a function, but that doesn't make sense" because range(0 59 10) has the 0 in the "function" position of the form. <rho`n>Thanks for that explanation. I was trying to figure out what the 0 was. Thought it was a positional argument counter or something <rho`n>Yes, that was it. The system reconfigured successfully. Thanks mange! <jazzy43>First, Hello. Second: How can I add an entry for stumpwm? I currently have gdm as login manager and I have entries for xfce and exwm because I chose them during installation. <mange>jazzy43: Have you added stumpwm to your system packages? <mange>I don't know if it works, but that's what I would try first. <rho`n>now i just need to figure out where my test job log file is created to verify it is working <taeaad>If one installs Git via Guix, do you also need to install sever certs? Which package would that be? <unwox>taeaad: nss-certs. but if you use guix system you do not need to explicitly install the certificates <unwox>you also need openssl to be installed <mange>If you're not on a Guix system, you can install nss-certs and point git to it. There are instructions in the manual "(guix) X.509 Certificates". <taeaad>unwox: Thanks, I have a foreign distro. <taeaad>I am still learning before I can start using Guix System. <taeaad>But I think using it on a foreign distro is a nice use case for some things, e.g. using it instead of Python environments or using it for setting up R. <mange>Yeah, absolutely. Guix as a package manager on a foreign distro is an excellent way to go. <janneke>info-reader doesn't cross-build any more, what's up? <efraim>janneke: info-reader switched from inheriting from texinfo-4 to texinfo-7 for improved locale support <janneke>ACTION hoped to wake-up with a new built world :) <efraim>I don't know enough to know about EUC-CN so I'll let you work on it :) <efraim>I am not too impressed by the configure.ac offering to use any old awk over gawk because of potential speed improvements, followed immediately by needing gawk for generating texindex.awk <janneke>efraim: i've got a fix for cross-compiling texinfo-7, but i'm wondering whether to put it in texinfo, or in texinfo-7 and have info-reader use texinfo-7's package arguments <janneke>i did the first to get it to work, but am thinking to do the latter now <janneke>oh, but that's a big rewrite because it is using quasiquote instead of gexps <podiki>anyone happen to use guix home and include glib:bin in packages? <podiki>trying to move my various manifests to guix home but including glib:bin conflicts with lots <podiki>but it shouldn't the ones i see, like mpv, propagate glib <podiki>how would one get glib:bin (for gsettings) then? <janneke>bah, wrap-program phase barfs when cross-compiling... <dariqq>podiki: DIfference is (hidden) glib vs glib-with-documentation. I switched to the hidden glib for gsettings (not really ideal but works) <podiki>ah, as in something like (@@ (gnu packages glib) glib) explicitly? <dariqq>podiki: i dont think you need 2 @s, it is still exported from the module but hidden from specification->package (which resolves to glib-with-documentation) <podiki>too late here for my brain, will investigate tomorrow. seems unnecessarily odd though (i guess how specification->package resolves or conflicts when it is really different outputs really) <efraim>I'm putting on my TODO list (for eventually) to audit the crates we have and mark the ones that are yanked as yanked. I tested out some deprecated crates so they're still available, but there's no warning like there is with other normal inputs <efraim>for now I'm thinking of just chaning the file-name to (string-append name "-" version "-yanked.tar.gz") <futurile>efraim: are we going to to try and revise the build-system at all, or just stick with what we've got? <efraim>futurile: for this merge we'll stick with what we have, then we can poke it hard <efraim>I'd like to use the rust-target property from guix/platforms <efraim>we need to migrate to the labelless inputs for cargo-inputs <dariqq>i am currently trying to build something which links to libxrandr. The resulting binary has 2 references to libx11 (one correct and one missing) causing things to break. Any ides what could be going wrong? <efraim>and I really want something for guix graph finally <Rutherther>dariqq: what do you mean missing? like it points to non-existent folder? <dariqq>Rutherther: yes ldd shows 2 libx11.so one pointing to nothing and the other one to /gnu/store/*libx11/lib <Rutherther>dariqq: what "nothing" - is the _base_ path it refers to in store? <dariqq>nothing in the sense of : libX11.so.6 => not found <dariqq>but in a later reference it is found <Rutherther>dariqq: so what is printelf --print-rpath output? <dariqq>Rutherther: it has only libxrandr there (+ some other things not relevant to this) <dariqq>but readelf shows it needs libX11.so.6 as well <dariqq>i guess i can force libx11 onto the rpath with some ldflags? Seems like I should not be needing to do this <dariqq>interestingly when i build from the checkout and a --pure shell the libx11 refers to the one from the shell profile (/gnu/store/*-profile/lib) and not the absolute path <efraim>can I not pull in (guix platform) in (guix build cargo-build-system)? <rekado>it would be nice if with the "new" way of declaring inputs we could annotate individual inputs without having to revert to the old style for all inputs. <rekado>this would be very useful for R packages that have plain origins (of JavaScript source files) in their native inputs <rekado>these individual files cannot be selected with search-input-file, nor can they be selected with (assoc-ref inputs "foo"), because they have an automatically assigned label of "_". <rekado>would be nice if we could do something like (label "js-whatever" (origin (method url-fetch) ...)) <rekado>instead of doing (native-inputs `(("esbuild" ,esbuild) ("foo" ,foo) ("js-whatever" ,(origin ...)))) everywhere <civodul>zimoun followed up but it still needs to be reviewed <civodul>actually no, it’s reviewed but needs another round (almost there!) <lilyp>is there a quick command to drop me into a `guix build`-like environment? <Rutherther>lilyp: maybe the closest could be if you are doing "guix build X", is to "guix shell --container -D X". But it's not really the same thing <lilyp>I'm sadly debugging something on the fetch side, so I'm not sure whether `-K` will suffice <lilyp>yep, gives me an empty folder without even environment variables <Rutherther>lilyp: then this won't help you at all, since this -D will get you dependencies of the package, not of fetcher <lilyp>what's more frustrating is that I already know that the package builds from a local checkout :) <x8dcc>Hello, after adding "(service connman-service-type)" to "(services ...)" and doing "guix system reconfigure FILE", why does it say "service connman could not be found"? <x8dcc>Do I need to install it separately, or something? <jakef>x8dcc: did you import the module containing that service definition in FILE? <x8dcc>jakef: In that config file, I have "(use-service-modules ... networking)", if that's what you mean <x8dcc>Rutherther: Sure, but tell me how much you need because it's not on this computer :) <Rutherther>x8dcc: I can't say how much, it depends on the error that I don't know <x8dcc>I think rebooting the machine fixed the error/warning <JackFaller>Does anyone know how to get the dmesg output for a previous boot? My current system isn't booting and I think there is some error output that goes by too fast for me to see it. <x8dcc>JackFaller: In other distros, I read from "/var/log/dmesg.0" <civodul>JackFaller: /var/log/messages should have everything <nutcase>Hi Guix. It happened again, I failed to submit a patch correctly: How should I merge #74472 and #74473 ? <lilyp>mail to control@debbugs.gnu.org "merge 74472 74473" and don't forget to say thanks ;) <nutcase>lilyp: I did that as well. A cover-letter wasn't necessary, when only one file is modified, right? <lilyp>a cover letter is nice to prevent such issues, but what's done is done <x8dcc>If a program expects a "cc" command (usually symlinked in "/usr/bin/cc" to something like "gcc"), where should I create the symlink? <x8dcc>Or is there a standard way of configuring this? <Rutherther>x8dcc: there should be no symlink in the first place - does the program not respect CC environment variable? <Rutherther>x8dcc: if not, personally I would think best solution is to patch it to use CC or directly reference the gcc rather than creating a dummy symlink <x8dcc>Rutherther: No, it doesn't respect the CC environment variable. I can patch it easily, it's just that I though this could be a problem in the future. However, if you say that there should be no "cc" symlink, I won't make one <sepeth>Hi Guix, one thing I miss from macOS is that input boxes by default support emacs shortcuts such as C-a C-e, C-p and C-h, along with some others. Is there any way to set this for some/all Linux gui libs? <Rutherther>sepeth: for gtk there is something called a key theme, when you set it to emacs, you should have emacs shortcuts in gtk apps. For other ones, I don't know <sepeth>If maybe even like before the UI library, for example, can C-h be mapped to backspace, and C-a to home etc? <Rutherther>sepeth: I mean, yeah, but it would be everywhere at that point, so if a program needs to get C-h, how would you give that to it? I hae heard kmonad is good for remapping, have not used it myself though. Should be possible to be used in both xorg and wayland, unlike some other tools that are x specific <lilyp>yeah, you don't want to mess up those keycodes or else you will confuse emacs of all things :) <sepeth>Yeah, I realized I use C-h for other things, like C-h in vim to move to the left window ^-^ I would still wanna try though. Backspace is too far. C-h is just perfect to delete things. <sepeth>Yay, gtk key theme emacs thingy worked for my major case, Icecat! Thank you Rutherther ^-^ I will buy you a beer / coffee or your beverage of choice if we happen to be in the same place <x8dcc>Does anyone know where the "ft2build.h" header is located? I installed "libxft", but when including "X11/Xft/Xft.h", it says "ft2build.h: No such file or directory" <janneke>what's the right curse to set --with-configure-flag=glibc-cross-x86_64-pc-gnu? <x8dcc>lilyp: I just installed it too, but it still happens. Do I need to refresh something? <lilyp>ehm, what are you trying to do? we typically don't solve compilation issues by installing everything around here :) <x8dcc>lilyp: I guess I didn't understand you right. I am trying to complile a program that uses "Xft.h", however when including that "Xft.h" header it says that there is no "ft2build.h" header. I also installed the "freetype" package, but the header is still not found <x8dcc>I am not even sure if the header is inside that freetype package, but I was wondering if I have to refresh some environment variable for the installation to take effect, or something <Rutherther>x8dcc: so you are not compiling it with guix as a derivation, right? you just have the source and trying to call make / whatever it uses yourself in a shell, is that so? <x8dcc>Yes, I am trying to compile a program using make in a shell <Rutherther>x8dcc: one important thing is that you should also have gcc-toolchain in the same profile. But that's not going to save you here if the file has #include "ft2build.h", since the file is not directly in the include folder of freetype. It's under include/freetype2. So you need to also use pkg-config which will give you the proper include flag <lilyp>sed -i Xft.h -e 's#<ft2build.h>#<freetype/ft2build.h>#' -e 's#"ft2build.h"#"freetype/ft2build.h"#' 👍 <x8dcc>I have gcc-toolchain in this profile. AFAIK the program I am trying to compile does not include "ft2build.h" directly. It includes <X11/Xft/Xft.h>, which then includes <ft2build.h> <x8dcc>The <X11/Xft/Xft.h> header should be from the "libxft" guix package, which I installed <x8dcc>I don't know if the problem is with the package, or what <Rutherther>it's not. It's with you having wrong include paths. Use pkg-config for obtaining the flags <x8dcc>Oh... I think I understand what you mean now. I didn't notice the makefile was using a "-I/usr/include/freetype2" CFLAG <Rutherther>yeah, that's not right, it should rather be using pkg-config --cflags freetype2 to get the flag <fnat>Hm, every now and then I end up in a state where my user herd no longer works. E.g. 'herd status' hangs forever. <fnat>'strace' seems to indicate some issue with '/run/user/1000/shepherd/socket'. <fnat>The socket is there but - IIUC - herd can't read or write to it. <fnat>Is there a way to nuke it and recreate it? <rynn>I'm very unfamiliar with herd, but I feel like that happens everytime I complete a system reconfigure. <fnat>It so much feels like 2nd Feb / Groundhog Day as I think I've been stumbling onto this various times but I always forget how to get out of this! :) <rynn>But I'm not sure if the reconfigure is causing it, or if I only notice it then because it tries to restart those services. <fnat>rynn: Luckily it's much more rare in my case. <rynn>I generally just go ahead and reboot to start fresh <rynn>That doesn't actually fix the issue though, so good luck if you dive into it <fnat>Hm, yeah, that'd do it... but... I really hope there might be a less radical solution. <x8dcc>Rutherther: After using pkg-config in a few places, it managed to compile. Thank you. <x8dcc>Now the problem is the installation. This Makefile also has an "install" target, but uses "/usr/local/bin". This issue happens in many other packages I plan on installing. What path should I use? <x8dcc>The $PATH seems to only contain guix paths (most of them being read-only) <Rutherther>x8dcc: it's up to you, just add the folder to your path with .profile equivalent <x8dcc>What do you mean by "with .profile equivalent"? And is there a reason why I shouldn't just create and add "/usr/local/bin" to the PATH? <Rutherther>x8dcc: but note that you will have problems with sw you install like that. The paths the sw refers to, likely to the store, can stop existing after you update and gc <Rutherther>x8dcc: by that I mean that it depends on your shell which profile file is applicable, be it .bash_profile, .zprofile, ... <x8dcc>What can I do about the program pointing to paths in the store? I am compiling a program that I patched, so I can't just use an existing guix package, or anything like that <x8dcc>I really want to like guix, but this all seems like it makes the system more unstable (unless I _only_ use programs from the guix store) <Rutherther>that's the _meant_ way, that you package your sw properly using guix, only then you ensure the paths existence. I am not sure I get you properly... so to make sure you understand this: you can of course package anything you want yourself using guix, it's not like only stuff from the guix channel can be in your store <x8dcc>Perhaps I didn't understand you correctly, but you said that I might have trouble with software I install manually because it might refer to a "volatile" path in the store (I assume because it's linked against a specific version, for example?). That's obviously a problem, since I plan on installing a few packages "manually", and I don't know the alternative/solution <Rutherther>x8dcc: the alternative is to package them using guix <x8dcc>I see. I don't know how that is done, or how hard it is, though <Rutherther>x8dcc: the issues is if they just refer to a path in store, like /gnu/store/[hash]-[name]-[version]/lib/libsomelib.so, sine that path may stop existing when it stops being gc rooted and gc happens - for example if you remove your older profile generations, and performe garbage collection <x8dcc>Yeah, but what do you mean by "refer to a path"? Are you talking about when the program is linked? <Rutherther>x8dcc: it can be the paths it is linked against, but can be other stuff, that's why I used generically it just refers to them <x8dcc>Well, I will try to get the basic stuff working, and see about packaging these programs <Rutherther>x8dcc: check with patchelf --print-rpaths on the executable you built to see where it looks for libraries. If directly to a store, then you are in for a trouble when something disappears, and it's bound to disappear at one point. If to your ~/.guix-profile it's better since you have it more under control, but still, it's not really what guix aims to do - that is, make sure the program refers to paths that really do exist, irrespective of you... <Rutherther>... accidentally uninstalling them. But it might not be the only tihng to check. <x8dcc>And how is this fixed when packaging it? <lilyp>easy: the package is rebuilt when an input changes <lilyp>and kept in store along with its dependencies as long as you need it <Rutherther>x8dcc: because guix captures what your package refers to, and makes sure the paths will not disappear prior to your package disappearing from the store. You can check this on packages you have in store, by looking into "guix graph" command. It just treats all those paths as "active", undeletable paths, as long as the package that refers to them is in store. And since it's only guix-daemon that can touch the store, it's ensured this really is what... <x8dcc>By the way, using "ldd MY-BIN" does show "/gnu/store/..." paths <gabber>otherwise it would be (cough) /difficult/ to build reproducibly <Rutherther>x8dcc: I wouldn't trust ldd on this, I am not sure, but I would think it expands to actual files, when there is a symlink. So I would rather look at the rpath of the executable <Rutherther>gabber: but x8dcc is not building reproducable packages, as they are not building them via guix, only using guix to get the dependencies <fnat>Re my 'herd: error: /run/user/1000/shepherd/socket: Connection refused' problem, I ended up rebooting my machine sort of by mistake... to my surprise the problem seems to have survived the reboot... <Rutherther>fnat: hm. Then, are you sure your shepherd services/initialization is intact, no errors in there? I think shepherd should give you some kind of a trace, either to its log or at least to stdout if you ran it manually <Rutherther>do you know if any of your user services are running? <lilyp>fnat: are you running shepherd as a regular user? <fnat>Rutherther: Hm, all good points, thanks. I'm checking '/var/log/messages'. I don't think any of my user services are running... 'herd status' doesn't work. <fnat>lilyp: Hm, I think I'm running Shepherd as root - I'm not on a foreign distro if this is what you mean? <Rutherther>fnat: if you aren't using user shepherd, then you should be running herd as root as well, ie. sudo herd status <fnat>Yes, 'sudo herd status' works regularly. <fnat>But my user's services are not. E.g. mcron, etc. <lilyp>try 'ps | grep shepherd' – maybe it's not been (auto)started <Rutherther>does /run/user/1000/shepherd/socket exist, and if so, who owns it? <fnat>Rutherther: Ok, I think I'm a bit confused - sorry! I think I run Shepherd as root and I can regularly use herd commands as root, at the system level, so to speak. In addition to that, I normally use herd commands as a user, but this part is now broken. <Rutherther>fnat: for "using herd commands as a user", you need to be running shepherd as a user. There are typically two instances of shepherd running if you are on guix system and using user services. Root's shepherd, being the pid 1 used for system init, and user's shepherd for user services <fnat>lilyp: 'ps aux | grep -i shepherd' returns a process owned by root. <fnat>Rutherther: Ok, that makes sense. It was kind of my understanding too, but it's more clear now. <lilyp>yep, whatever autostarted your shepherd doesn't <fnat>Is there a service in particular that I, as root, should try and restart to get the user's Shepherd running? <fnat>Ok, so it's only a matter of looking at the logs to see what went wrong at boot time? <x8dcc>Rutherther: I used "ldd" because there was no "--print-rpaths" arg for "patchelf". It complained, anyway <Rutherther>x8dcc: it's --print-rpath, not rpaths, sorry for that <Rutherther>fnat: okay, then the scripts that ought to be run should be in ~/.profile. What shell do you use, are you sure its profile sources ~/.profile? <x8dcc>Rutherther: Right, that worked. And yeah, a bunch of colon-separated store paths <x8dcc>to "/gnu/store/...", not symlinks <fnat>Rutherther: I use Bash. Yeah, pretty sure that gets parsed, the system has been running fine for months in this setup (other than the occasional hiccup now and then). I'll double check though. <Rutherther>fnat: okay, do you manage bash through guix home? either way, you can try checking if ~/.bash_profile exists, and if it does, if it sources ~/.profile <Rutherther>if it's managed by guix home, then guix home should have already taken care of that, so it should be fine <fnat>Yeah, my '~/.bash_profile' sources '~/.profile'. <fnat>Yes, it's the default Guix Home Bash service. <Rutherther>okay, then it all seems intact. So possibly shepherd crashed when it was started, have you tried manually starting it? <fnat>ACTION looking at the user logs then... <fnat>LOL, spot on Rutherther! It was just a matter of running 'shepherd'. <fnat>It doesn't crash now (under Xorg), I did notice some error when I first logged in in a TTY though, before starting X. <fnat>So that might explain it. <fnat>It used to work fine for a long time and until a few days ago, so I might have made some changes in Guix Home that are not ok outside Xorg... <fnat>Thanks so much Rutherther! I still have some trouble-shooting to do, but this is a great starting point. <fnat>Hm... it might be the unclutter service... Which, in turn, relies on the x11-display service... <fnat>When launched from a TTY it crashes and brings down the whole user Shepherd. <fnat>I'm only speculating. I'll double-check this and in case open a bug / send a patch. <fnat>Under Xorg, it hides the mouse pointer after a short period of (mouse) inactivity. <Deltafire>wayland (or something) hides the pointer when i start typing in the window containing it <fnat>Hm, interesting, that seems like a sane default. <fnat>Yeah same here futurile. :( <x8dcc>Is there a way of adding something to an env variable system-wide? e.g. to $PATH <Rutherther>x8dcc: not really, since that's not how environment variables work, they are always bound to processes, so it depends in which process you need to have it <jaadu>Is there a geiser-guix implementation? <x8dcc>Hmm... Okay. I was hoping that I could edit PATH in the .scm file I use for "guix system reconfigure" so it somehow gets updated for future shells, independently of the user <x8dcc>(future bash shells, anyway) <Rutherther>x8dcc: if you want to have it in future shells, and for all users, then you can put it to /etc/profile <jaadu>gabber: Yes, but I have noticed M-x geiser-guile doesn't include guix in its load path <anemofilia>x8dcc: You could also use session-environment-service-type I guess <x8dcc>Rutherther: Just to be clear, you mean manually editing the file, right? There is no way of editing the file from scheme, somehow. <jaadu>If I do guix repl --listen=tcp:37146 and M-x geiser-connect I can get it to work. <lilyp>emacs-guix was supposed to abstract that, but alas, it's not working correctly atm <x8dcc>anemofilia: I am looking into that now. Is that also used for appending data to env variables? Instead of setting it <x8dcc>Also, not sure if it would work with $PATH, since it's "unset" in /etc/profile <anemofilia>(service sessnion-environment-service-type '(("PATH" . "your/dir/here/:$PATH"))) <anemofilia>(service session-environment-service-type '(("PATH" . "your/dir/here/:$PATH"))) * <Rutherther>x8dcc: no, /etc/profile is managed by guix, so when you reconfigure, your changes would get replaced. But using session-environment-service-type that's going to put the env var to /etc/environment is going to be easier, and better <x8dcc>anemofilia: Just have access to some binaries/scripts in a directory (system-wide, not from just one user) <Rutherther>x8dcc: there is unset PATH, but /etc/environment is sourced after the unset PATH in /etc/profile <anemofilia>x8dcc: Why don't you package them? I did it for zzz, for example <x8dcc>anemofilia: Hah. Rutherther told me the same earlier. I will think about packaging some of them, but not all <jaadu>lilyp: I just briefly browsed the manual for emacs-guix and it seems like overkill <x8dcc>anemofilia: Tried what you sent, but it says "error: more than one target service of type 'session-environment'". Perhaps because of "%desktop-services"? <anemofilia>(simple-service 'path-extension session-environment-service-type '(("PATH" . "your/dir/here:$PATH"))) <futurile>Also Arun will be there doing some Mumi hacking - so if you're using Mumi and want to do some hacking come along - 18:00 UTC <Kabouik>No, I see that emacs-guix is actually something else entirely, sorry. The confusion came from the fact that the guix-emacs channel was actually not working correctly recently, until this fork revived it, so I thought you were talking about that. <x8dcc>anemofilia: Hmm... Not really. The new path is inside "/etc/environment", but it doesn't show if I do "echo $PATH" <lilyp>I am speaking of the emacs package that provides Geiser bindings and a user interface to Guix. <x8dcc>So the service did get executed, or however it's called. It seems that the environment isn't getting evaluated? <x8dcc>(after "guix system reconfigure ...") <anemofilia>x8dcc: Are you using guix home? It seems to override the PATH inherited from /etc/environment completely <anemofilia>Hm, IDK how to do what you are looking for, then <x8dcc>Not sure if my message sent because I got disconnected. <x8dcc>I don't think I am using guix home. I am not even sure what it is. <anemofilia>What is the output of `guix package --search-paths` there? <anemofilia>Well, I guess the only solutions is extending the PATH per-user or packaging the software <x8dcc>Sorry, I am back. I guess it's better to extend it per-user in my case. Any suggestions for doing that? <x8dcc>I could set it in ".bash_profile" or something like that, but I don't know if it's very guix-like. <x8dcc>anemofilia: Using guix home, I should use `home-environment-variables-service-type' instead of `session-environment-service-type', right? The rest should be basically the same <mjw>janneke, saw your gcc bug report sent to bug-gcc@gnu.org. I did approve it, but I am not sure the gcc hackers ever really look at that list. You might want to enter a bugzilla entry. <civodul>the childhurds on berlin sometimes go wrong and stop responding <civodul>problem is the nodes keep taking i586-gnu builds, which they submit, but nothing happens <dariqq>civodul: The futures construction is pretty elegant. I had something that worked which just reversed the start-service and hashq-set! (and returning what start-service returned) which then required a second lookup in %one-shot-services started afterwards (it passes your test at least :) <civodul>dariqq: oh, i hope that didn’t lead to duplicated work; thanks for checking anyway! <civodul>it’s not “real” futures, but close enough <x8dcc>anemofilia: I tried using guix home, but it's still not set. I can send my config if you want <dariqq>civodul: don't worry it, trying to understand what the problem is and the recursive nature of start-in-parallel lead me into a very interesting rabbit hole <dariqq>this is now the second time that i am impressed how (relatively) easy it is to hack on shepherd <civodul>dariqq: nice, let’s try and keep it that way :-) <attila_lendvai>civodul, debugging stock shepherd is a PITA... i'm working on a simplified reproducer for the respawn issue, and the lack of logging makes it much harder than it should be. e.g. there should be a log for every RPC recevied from herd. <attila_lendvai>civodul, and knowing that it's there in my contribution, which has bitrotten away with a sole "it's baroque" comment from you, adds and some extra flavor of annoyance to this all... <rynn>Does anyone know what the current status of KDE/Plasma is on Guix SD? <rynn>Seeing some articles about porting it, but they seem to be from a few years ago. <ieure>I think the docs aren't up to date about it, but it's there. <ieure>(service plasma-desktop-service-type) in your operating-system will pull it in. Strangely, it's missing some packages I'd expect it to have, like okular. Otherwise seems to work okay. <ieure>I'm actually test driving it on this laptop right now. Don't think I'm going to stick with it, but wanted to see how things were in KDE and Gnome land these days. <rynn>Same, not a big fan of the direction Gnome has been going the last few years, but all my usual tools are there. <ieure>I've run into two things with KDE that I found somewhat puzzling: it takes *much* longer to log into than any other DE I've used. I'm not sure why that is. And after doing a `guix home reconfigure', it'll sometimes still launch the previous version of some programs. <ieure>Don't know why either of those things happen. <[>It doesn't work with X11 for some reason (or didn't last time I tried) <ieure>Yeah, that seems to be where all the big DEs are heading <[>It's not a general KDE thing, it only happens on Guix. It's supposed to work with X11 <x8dcc>anemofilia: (Finally got it working, thank you for your patience) <[>ieure: Does kbuildsycoca6; kill $(pidof .plasmashell-real); kstart plasmashell <[>... solve the "it'll sometimes still launch the previous version of some programs" issue? <ieure>[, I've never tried, but I doubt it. What I've observed is: I `guix pull', then `guix home reconfigure' from a KDE session, log out, log back in, launch LibreWolf. It'll launch the version from the previous home generation. The .desktop file points to the current one, the current one is on $PATH. <[>KDE taking much longer to log in is also a Guix-specific issue: it's much faster on Debian for some reason <[>ieure: kbuildsycoca6 will make it rebuild the .desktop file cache <[>I'm trying to compile guix (doing an incremental build) and getting this error: error: failed to load 'gnu/system/install.scm': <[>ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <nginx-location-configuration>>: record ABI mismatch; recompilation needed <[>What do I need to delete to make it recompile the correct file and why isn't it automatically rebuilding it? <ngz>[: make clean-go should do the trick. <x8dcc>When defining a package, what is the #:phases argument for gnu-build-system supposed to look like? A list of symbols like "patch-source-shebangs" or "build"? <Rutherther>x8dcc: no, phases is an alist, the keys are names of phases, and values are lambdas that say how the phase looks like. There are default phases that work for many packages out of the box, so you might not have to set it to anything. If they don't work for the package you are working on, still, it's probably better to start with the "%standard-phases" and just modify them with "modify-phases" <x8dcc>Those "default phases" are symbols that I can import? Or you meant modifying %standard-phases? <Rutherther>x8dcc: it's already imported, as "%standard-phases", and the default value, so if you are using just that, don't set #:phases to anything <x8dcc>I think I need to change #:phases, because I don't want to follow exactly what gnu-build-system does <x8dcc>I want to build, install and validate-runpath <x8dcc>However, I think the default values for those phases are fine <x8dcc>Perhaps I didn't understand the documentation correctly. I think gnu-build-system uses 4 phases: configure, build, check and install. I don't need those 4 <Rutherther>x8dcc: yes it does have these, but not only these. configure's not going to do anything if there is no configure file, and check is not going to do anything if you set "#:tests? #f" <x8dcc>Either way, I want to know how to change it <Rutherther>I think I already answered - by using "modify-inputs" <x8dcc>Do you mean modify-phases? And doesn't that force me to declare new lambdas? In that page I sent, the alist is created using those 5 procedures. I don't want to re-define them, just change the order and add others, for example <x8dcc>Sorry for asking so much, but it's just too much information for one day <ieure>x8dcc, You can remove phases, add them, or replace built-in phases. As always, grepping the Guix source will produce a wealth of prior art. <Rutherther>x8dcc: I don't know what you mean force you to create new phases, if you want to make a new phase, you have to write it, it's not up to using modify-inputs or not. If you want to just delete some, you don't need any new lambdas <ieure>I often look through the existing package definitions when I want to see how a thing gets used, I find it very helpful. <civodul>attila_lendvai: what is “the respawn issue” you mention? <x8dcc>ieure: That's what I meant by "forcing to declare new lambdas". On the first link, you are replacing "install" for a lambda. What if I want to replace "install" by "build"? Can I just use a symbol? <attila_lendvai>civodul, when a service is replaced that is in a respawn loop, the previous version remains respawning forever. but i'll soon send the simplified reproducer to the relevant email. <Rutherther>x8dcc: you can of course use a symbol that's already bound to a lambda. But it doesn't make sens to replace install by build, as build is already called in build phase <ieure>Maybe you have a different example of what you want to do? <x8dcc>Rutherther: Right, it was just an example. Let me try messing a bit <x8dcc>It's just so many guile concepts, guix commands, etc. <x8dcc>I have a million tabs open and I am losing my mind <ieure>I have packaged several things, including some pretty complex stuff, and I have never once needed to move a predefined phase like you're saying. This doesn't mean that this is *never* what you want, but I do think it's *extremely unlikely* that it's actually needed. <x8dcc>I don't actually have to move a phase like that. It was just an example, I wanted to know if you could use symbols to refer to existing phases <Rutherther>x8dcc: it's a normal thing that you can either put (lambda ...) directly or first (define-public xyz (lambda ...)) somewhere and then just use xyz instead of putting the lambda everywhere. And that has nothing to do with modify-phases itself. (here it's a bit complicated as the phases are ran inside the guix daemon, so you cannot directly refer to a symbol you made above the package, but it's doable) <Rutherther>x8dcc: the reason all of those examples have a lambda is that if the standard phases don't work with the package, you typically need something tailored for that specific package, so it's never going to be reused. So there is no point in making a symbol for it <ieure>x8dcc, Still not sure what you actually want to do. validate-runpath is a built-in phase which runs after 'install already. <ieure>x8dcc, If you want to put your package definition in a pastebin and explain what you want to accomplish, that might lead to better answers. <x8dcc>Where is that mentioned? That validate-runpath is executed after install <ieure>%standard-phases in gnu-build-system.scm <x8dcc>Does it appear in the manual? Or I have to check the source appart from everything I was already reading to get this working <ieure>x8dcc, It's also in the manual. 8.5 Build Systems <ieure>Look for #:validate-runpath? <Rutherther>x8dcc: the code block is just to get the idea of how it might look like. At the top of the page there is more complete list (still not the full one) <ieure>I would always suggest reading the actual code instead of code in the manual. For everything, not just Guix. <x8dcc>Well, I guess I just want to delete 'configure and 'install, then <ieure>Why do you want to delete 'install? <ieure>If you do that, you'll get an empty package. <x8dcc>See what I mean? I am exhausted <Rutherther>ieure: I think the build would even fail as the package output folder won't be created at all <ieure>x8dcc, You should prefer (arguments (list #:tests? #f)) over removing the 'check phase. <ieure>Either will work, setting #:tests? #f is more idiomatic. <x8dcc>What should I do if the build process should be executed in a sub-directory? <x8dcc>Adding something like "-C dir" to #:make-flags? Or is there a cleaner way? <ieure>Hmm, I swear I've seen an argument for this, but I'm not finding it. <x8dcc>I think the package is done. How should I test this locally? <ieure>x8dcc, `guix build -f file-with-defintion.scm' <x8dcc>Is that fine in a non-guix system too? I mean, another (systemd) distro which has guix installed <Rutherther>x8dcc: I think that with exception of guix system you can use all guix command with all arguments they have, on any distro. And even with guix system some subcommands do work on foreign distros <x8dcc>What's the license name for MIT? I am including (guix licenses), but it says "mit" is unbound <ieure>guix/licenses.scm in the source. There's a comment. <ieure>It is annoying, I wish there was at least an `mit' alias or something. <ieure>;; Some people call it the MIT license. For clarification see: <x8dcc>I need to add the package name at the end of the file, right? I guess this is just when building manually from the file? <ieure>I think so, though I don't actually understand why. <x8dcc>It says it's because the definition doesn't return anything <x8dcc>If this problem only happens when building from the file, then I don't understand either <Rutherther>x8dcc: not the name, you need to _return_ the package record, if you made a symbol, then put that symbol there, yeah, but if you haven't, having (package ... at the end will do as well <x8dcc>There is an interesting warning. "freetype" is imported from (guix licenses) and (gnu packages fontutils) <x8dcc>Not sure how to specify that I meant one of them in the code <ieure>x8dcc, ((guix licenses) #:prefix license:) <ieure>Scheme has the undesirable behavior of defaulting to binding every public symbol when you use a module. <ieure>Well, at least, I don't like it much. <Rutherther>ieure: I don't really understand. That's what you tell it to do when you say just the module. You can use just some symbols, or not use at all and just reference directly. What more is there to ask? <ieure>Rutherther, I dislike that the easiest way to use a module is also the least safe. <ieure>Rutherther, I like how Clojure does this. When you require a ns, it makes it available, but you have to qualify symbols within it. It's easy to use `:as foo' and then foo/sym, which is both safe and explicit about where the symbols come from, which I like. The unsafe thing -- reffing syms in *your* ns -- is also the hardest syntactically. <ieure>Since you have to do (require '[some.other.ns :refer [foo bar]]) <ieure>x8dcc, source is a field in your package. You probably need just an (origin) record. <sepeth>Same thing with Python. That's one of the things I like about python. A disadvantage is that import lines at the beginning of a file gets long in a big project on a big file, but still, the advantage is that it is super helpful to see where a symbol comes from by not leaving the file. <ieure>sepeth, Guile has both huge front matter using modules *and* all their symbols get dumped into your module. <sepeth>A lot of languages are like this unfortunately, like C/C++, Java and so on. OCaml, which otherwise I love, can have the same problem, because using "open" is kinda done often. <Rutherther>ieure: how is using ":as foo" easy and "#:prefix foo:" not? <x8dcc>ieure: You are right, I was missing (origin). I don't understand what I have to put as sha256, though. The hash of what, exactly? <sepeth>Rutherther: I don't remember Clojure very well, but what ieure trying to say is when you don't say :as foo or #:prefix foo. In Python and some others then you have to fully qualify the module name if you want to use a symbol from there. <ieure>Rutherther, Because it doesn't add another layer of nesting; because Clojure always uses / to separate a ns from its symbols. <Rutherther>x8dcc: it's hash of the source. The source is coming from somewhere guix doesn't know, so it has to be ensured it's intact - same every time you build. That's how you ensure reproducibility. <ieure>Rutherther, Scheme lets you do silly things like ((guix license) #:prefix woop) and then you reference everything as woopexpat. <Rutherther>x8dcc: to obtain it, there is a command, but I find it easier to just specify a dummy hash and adjust it when the build fails <ieure>Rutherther, Is this a dealbreaker or a major issue? No. But it's a minor annoyance which crops up often. <sepeth>Good thing is that probably in Guile this would be easy to fix perhaps with introducing another way importing a module other than use-module(s) <ieure>If it's a file. Doesn't work for SCM repo clones. <x8dcc>It's supposed to pull from a git repository <ieure>x8dcc, Yeah, put in a fake hash and let the build tell you the correct one. It's kind of silly IMO. <x8dcc>Well, something else failed, but I will look at it in some minutes <dlowe>Has anyone gotten DisplayLink monitors to work under guix? <dlowe>Okay, well, maybe I'll be the first :D <ieure>Am just realizing that DisplayLink is not DisplayPort, ha <podiki>anyone use a network printer via cups here? i got an hp one, can see it on the network and add it to cups, but can't print <podiki>error seems to be error: Unable to communicate with device (code=4) or unable to open device (with the hp:/net.... uri) <x8dcc>ieure: I saw you used (lambda _ ...); I assume the "_" means that the arguments are ignored. Is it the same as using (lambda () ...) ? <ieure>x8dcc, _ does mean arguments are ignored, but is not the same as (). <x8dcc>Because it accept arguments? <ieure>x8dcc, (lambda () ...) is a 0-arity function, so it cannot accept any arguments. (lambda _ ...) is a n-arity function, which will accept any arguments, and ignore all of them. <rekado>my aarch64 server gives me trouble <ieure>x8dcc, The build phase lambdas often take keyword arguments, so you'll frequently see things like (lambda* (#:key inputs #:allow-other-keys) ...) <podiki>and the various tools in hplip just want to use usb, not network :( <rekado>I'm always worried about system upgrades. Very often it won't boot after an upgrade to the kernel. <x8dcc>ieure: Yes, that's why I asked. <x8dcc>However, it complains in the `modify-phases' expression with "source expression failed to match any pattern" <rekado>currently I have a pretty broken system, because NFS stopped working. I can't easily deploy to the system because the NFS service freezes shepherd. <rekado>does anyone else have these kind of eproblems with the rockpro64? <Rutherther>x8dcc: that means you have something wrong inside of the modify-phases <x8dcc>Ah... I think it's because I didn't name the lambda <x8dcc>I mean, I was "calling" `add-after' with 2 args, not 3 <ieure>Right. That's naming the phase, not the lambda. <ieure>I don't know if Scheme has named lambdas or not. <x8dcc>You can define symbols to lambdas, but lambdas are anonymous <podiki>oh, we build hplip without network maybe? <ieure>x8dcc, Well, Clojure has named lambdas, it's definitely a thing. <x8dcc>Now it says that %standard-phases is not bound, and suggests I include (guix build emacs-build-system); lol. <x8dcc>ieure: Didn't know that. I don't really like Clojure (personal preference, had painfully long talk about it on #emacs) <ieure>In Clojure, you can express recursive lambdas like: (fn foo [] (foo)) <ieure>x8dcc, Can you paste your current package definition? This could be a gexp thing. <ieure>Should be: #:phases #~(modify-phases %standard-phases ...) <podiki>so has anyone used an hp printer via network on guix? i wonder if that's why it won't work <ieure>x8dcc, The #~ denotes a gexp. <x8dcc>I saw it on your config, didn't know what it was <ieure>x8dcc, Heh uh weeeelp. It's essentially a cross-process closure. <x8dcc>s/your config/the repo you sent/ <attila_lendvai>podiki, i have a very old hp laser printer on ethernet, and it works for me from guix. i think it requires nonguix, though, but i'm not sure. <ieure>x8dcc, Yes, I don't know much about the internals. But since guix builds everything in isolation, the definitions often need to <ieure>...the definitions often need to move stuff from the context of the package definition into the process doing the building. <ieure>Someone who knows better will probably tell me this is completely wrong. <podiki>attila_lendvai: thanks. this is also via ethernet. cups sees it, installs, sends jobs, but then seems it can't actually talk to the printer? odd, i can see if it is a freedom problem :( <attila_lendvai>podiki, the only unusual thing i have in my service def is this: (extensions (list cups-filters hplip-minimal)) <ieure>x8dcc, Yes, you need to use (guix gexp) and have it be #~(modify-phases ...) <podiki>attila_lendvai: from what i see, hplip-minimal is included by default in extensions anyway <podiki>well we do build hplip without net-snmp support, which probably explains why the dnssd:// addresses didn't work <ieure>x8dcc, Yeah, this is honestly something about the website that should change. Guix is a rolling distro, so the 1.4.0 release stuff is pretty out of date vs. the current state of things. <ieure>But that's just a thing you have to know, which is non-obvious without someone telling you. <podiki>still, i should be able with direct ip or other means, i will try again... <podiki>ieure: it constantly bugs me. i think there were proposals but no actual patch to just change the site <x8dcc>Okay, the build is working, kind of. It fails on the installation, because it tries to use a wrong prefix. Where should the Makefile install the files? <podiki>i'm less savvy with the website so i haven't looked into the actual needed changes <ieure>x8dcc, gnu-build-system sets $PREFIX for you, sounds like the Makefile for dwm doesn't respect that. <x8dcc>It doesn't, but I can change it <x8dcc>So the solution is to just use the env PREFIX <ieure>x8dcc, Ooooh. There's already a dwm package in Guix. I think you could have done this more easily by inheriting from that package :/ <x8dcc>I am 100% sure that would be harder because of how messed up my build is :) <ieure>Maybe that can be your next step. <ieure>I promise this stuff gets easier once you've done a few. <x8dcc>Right. I swear I would have given up if you (all) hadn't been here :) <ieure>Your patience is noted and appreciated. :) <x8dcc>I will have to add some small programs that I wrote (that are for sure not on guix), so it's good to know all this <x8dcc>Hmm... I updated the commit (but not the sha256), and it's still trying to compile the old way. Is it cached somewhere? <ieure>It cached the checkout locally, change one of the characters in the hash and it'll fail and spit out the right one. This is, again, pretty silly. <x8dcc>I was surprised that it didn't spit a new hash. <x8dcc>Wtf... The Makefile now uses `CC ?= "gcc"`. Outside (and inside) of guix, $CC is not set, but it chooses to use `cc` as the command. If I replace the `?=` by `=`, it uses `gcc` <podiki>printing update: works! just used socket address to hostname and port 9100; so much for fancy other ways to configure <podiki>(socket connection as in cups printer setup) <x8dcc>Doesn't guix set $CC in the env? <ieure>I don't see that in gnu-build-system. gcc is on $PATH, though. <x8dcc>I guess the Makefile sets "CC" to "cc" by default, so when using "?=", it doesn't get overwritten because its set