<gabber>bjc: FYI when i have started pipewire and wireplumber, i need to invoke jack applications by prefixing them with pw-jack. e.g. to start the SuperCollider IDE i call `pw-jack scide`, to make my mpv example from earlier actually work i have to call `pw-jack mpv -ao jack EXAMPLE.mp3`. looking forward to your pipewire home-service, please let me know if i can test anything :)
<oleander>Hello everyone! My T420 with Guix hangs during shutdown after running loginctl poweroff/reboot or /sbin/poweroff /sbin/reboot. It just sits there and only resolution is hard poweroff. This is my system.scm: https://paste.debian.net/hidden/478bc117/
<bjc>gabber: yeah, panosalevro also informed me earlier. thanks for letting me know. i'm trying to squeeze that into the guix docs so hopefully it'll be easier to figure out for future generations
<ChocolettePalett>> Hello everyone! My T420 with Guix hangs during shutdown after running loginctl poweroff/reboot or /sbin/poweroff /sbin/reboot. It just sits there and only resolution is hard poweroff.
<ChocolettePalett>I have the same issue, though it seems to only hang on rebooting/halting after reconfiguring system
<jpoiret>ChocolettePalett: guix system uses shepherd by default as its PID 1, so yes
<jpoiret>wrt. updating shepherd, you're most likely seeing updates to your shepherd services, shepherd doesn't update that often (although 0.10 was released recently)
<ChocolettePalett>Then I don't think that shutdown problems are related to GNU/Shepherd, must be something else causing them after system reconfiguring
<jpoiret>they probably are, usually shepherd gets stuck while trying to shut down
<ChocolettePalett>Probably, I mean they are rather related to reconfiguring than GNU/Shepherd upgrades. E.g. last time it happened I went to "f12 tty" and saw that it stopped all the services, then elogind's signal arrived and then it got stuck...
<ChocolettePalett>It could be two different bugs though, one related to GNU/Shepherd upgrades, and the other one related to reconfiguring. But idk of course, my knowledge of GNU/Guix is not enough especially on this subject
<jpoiret>in general, pkg-config needs to be native, yes
<jpoiret>what's the build log and the package definition?
<ngz>The error is "configure: error: Sorry, not found under any of: /usr/include /usr/local/include *****"
<ngz>The relevant part of the configure script is list="/usr/include /usr/local/include `echo $KPATHSEA_INCLUDES | sed 's/-I//g'`" where $KPATHSEA_INCLUDES refers to KPATHSEA_INCLUDES=`$PKG_CONFIG kpathsea --cflags`.
<ngz>Obviously $PKG_CONFIG kpathsea --cflags returns nothing (or an empty string).
<ngz>I can replace "/usr/include /usr/local-include" with (string-append #$(this-package-input "texlive-libkpathsea") "/include"), but that's a bit gross.
<janneke>(and probably guix system reconfigure, we're not just there yet)
<sozuba>jpoiret: fair point. Thanks for the response.
<efraim>you could probably try building just guix-daemon and using it as a build offload, if you hadn't already built guix itself
<Guest28>in the home openssh service, how can I set the identity file relative and not hardcoded as of (identity-file (concat $pwd "/srv.key"))? Reason is, I don't want it to break by renaming my directory with the config of guix
<old>jpoiret: yes I have a channel file, but adding a time-machine to the script is not something I want to do
<old>since I do not want to restrict package version of the guix channel for example
<janneke>fwiw, /me always adds a time-machine to the guix shell instructions: you're guaranteed it will work and that substitutes are available; just leave it out on your own risk / if you know what you're doing
<unmatched-paren>the three "obvious" topics, derivations, gexps, and monads, are done. maybe the fourth should be about the build environment, the build process, and writing build systems
<bjc>unmatched-paren: one thing i've been meaning to learn more deeply, but never seem to get around to: what does ‘guix pull’ actually do? how are the derivations defined? what's the path from executing ‘guix pull’ to getting fresh new guix program? why does it have its own special profile?
<bjc>i don't think it's actually all that complex, but it'd be nice to have a guided tour
<unmatched-paren>bjc: it has its own profile for the sole reason that it's operated on by a different command to ~/.guix-profile, i know that much
<unmatched-paren>i suspect it'd be considered "bad form" for two entirely separate commands to operate on the same predefined profile
<bjc>i've been suspecting it's a bootstrapping issue. it'd be difficult to impossible to have a consistent state if ~/.guix-profile also included a guix that updated itself. but that's just a hunch
<bjc>anyway, if you're looking for ideas, those are some for your mulling pile. i think it'd be useful to more than me
<sozuba>janneke: sorry just noticed your response. so,native build for guix means, i can use hurd without recompiling my software? I applogise if my question sounds immature or less informed. I am just installing guix.
<unmatched-paren>bjc: the thing about dissecting guix is that it's supposed to be something to explain the "big ideas" and difficult-to-grasp low-level concepts/abstractions; i do think your idea could fit into some sort of "Guix technical FAQ" though
<unmatched-paren>bjc: (i'm also not entirely sure anyone actually reads the posts :P)
<unmatched-paren>but not an overview of packages; that feels like it belongs more in the manual
<unmatched-paren>it would essentially just be "field X does X, field Y does Y", i think
<unmatched-paren>if you know some Scheme, and have read the other posts, there isn't all that much to demystify imo
<unmatched-paren>doubly the case once the build process one is written, since that will explain what the BUILD-SYSTEM, INPUTS, NATIVE-INPUTS, PROPAGATED-INPUTS, and ARGUMENTS fields do, since that's kind of important for building things :)
<unmatched-paren>if anyone else can think of any other subjects i'd appreciate that, though
<unmatched-paren>note that it shouldn't be a simple question like "what does guix shell do?" that can be explained with a paragraph or two; rather something like "what the hell is a gexp, how does it work internally, and where can I order one?"
<unmatched-paren>(the answer to that last bit is, of course, "from all good retailers")
<unmatched-paren>also, while, say, "what's a profile?" is a question about an abstraction, it's not a particularly difficult one, and again you could easily distill that into a few paragraphs; "what's a gexp" requires in-depth explanation, especially if you want to actually, well, dissect it
<sozuba>I am just installing guix, when installing certian packages like lvm2 i get 'hint: Consider setting the necessary environment variables by running:' followed by settingth profile, 'GUIX_PROFILE="/root/.guix-profile"' and '. "$GUIX_PROFILE/etc/profile" '.Is this normal for all distros, are specific to guix.IF so why is there a need to set the environment once the software is installed.Does this have
<unmatched-paren>sozuba: that message can be a wee bit confusing :) what it's essentially trying to tell you is that it's impossible for a child of the shell (guix) to change the environment variables of the shell itself, so if such a change is necessary to make a program work, guix will instead modify a file inside the profile directory that's sourced on login to make it set the environment variables correctly. but since there's no way for guix to say
<unmatched-paren>to all the programs currently running that they need to update their own environment variables, it instead spits out those instructions for how to do it manually in a bash-like shell
<unmatched-paren>the way to put the changes into effect without doing that is to log out and back in so that the newly updated environment variables script is sourced
<unmatched-paren>but in case you don't want to do that, you can paste that shell code so that the shell and all programs launched from it will have the new variables
<sozuba>unmatched-paren: ah makes sense. Thanks for the detailed explanation :)
<unmatched-paren>sozuba: it is, unfortunately, a limitation of the operating system itself :) though you don't need to do this every time you change your profile. it only happens if an entirely new search path is added, like if you installed Emacs, which defines the $EMACSLOADPATH search path in its NATIVE-SEARCH-PATHS field, meaning any packages containing the right directory will automatically get added to that environment variable
<sozuba>unmatched-paren: operating system meaning guix?
<unmatched-paren>it's not a problem if you install a package that adds to the environment variable (such as any emacs plugin), only if you install a package that actually uses the environment variable (such as emacs itself)
<sozuba>unmatched-paren: ah okay, understood. I have chnaged profiles before, but never came across this for installng major packages like lvm, may be that's because pacakages like lvm are installed by default in major systems? Anyway, what you said makes things much clear.Thank you
<unmatched-paren>sozuba: it might just be that LVM doesn't need to add any environment variable search paths -.o.-
<sozuba>unmatched-paren: but in guix installing lvm results in this advisory