IRC channel logs
2023-06-20.log
back to list of logs
<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/ <oleander>This does not always happen but quite often. <oleander>Kolev: Hi! I made a typo in the first link. Isn't the code displayed correctly? <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 <lilyp>mirai_: that's strange, have you tried to debug this yet? <lilyp>did your reconfigure entail a shepherd upgrade? It might be related then <ChocolettePalett>Does guix pull download newest GNU/Shepherd besides GNU/Guix? If yes, then it seems like updating GNU/Shepherd was triggered by each of my system reconfigurings <geri>hey, is it possible to create a new guix system from another distribution that has guix installed? <geri>even though ventoy exists i still like the idea of having just one graphical iso and installing anything i want from it <mirai>lilyp: I tried checking what the other distros do for those packages but didn't find anything obvious <mirai>at first sight it looks like a tests only file that is being generated but gdk-pixbuf insists on generating it even when passed the argument to not build any tests <mirai>but to be frank, I didn't do any in-depth debugging (mostly for lack of knowledge or tricks in this department) <rekado>oops: “guix locate: error: unsupported manifest format” <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 <efraim>sneek: later ask zimoun I'm looking at the slow julia thing, what did you use to get your time comparisons? <janneke>jpoiret: headsup, i've reset the hurd-team branch <ngz>Is there some magic to make pkg-config find out about an input? It cannot find kpathsea even though that package provides a "lib/pkgconfig" directory. <jpoiret>sozuba: I wouldn't trust downstream patches implementing whole features like this <jpoiret>grub in guix only supports LUKS2 partially, ie. the user-space tools don't know how to deal with it, and that's a grub shortcoming. The next release of GRUB should overcome this <jpoiret>how far were you able to go? I remember you saying you had all of guix's build deps covered <janneke>ACTION is still working to get guix to build natively, and rumpkernel and to get guix pull to work <janneke>jpoiret: yes, that's right; and i've fixed some problems since <janneke>i'm sure you've seen civodul's libc-for-target help that i worked into a squash commit for your initial patch <jpoiret>yes, i've seen it but haven't properly read it yet <jpoiret>i'm expecting things to settle down a bit more this week <janneke>great, i've been making good progress anyway <ngz>Hmmm maybe the kpathsea package itself need to have pkg-config as a native input, too. <jpoiret>how does kpathsea appear as a dependency of what you're building? <ngz>Yes, it is a propagated input <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. <jpoiret>what's gross is the hardcoded FHS dirs :) <ngz>Well, I'm not paid to do the job for pkg-config! ;) <ngz>Still, I wish I could undestand why pkg-config is failing me. I can't even find where the "include/pkgconfig" search path is defined in the code base. <ngz>(I meant "lib/pkgconfig") <ngz>OK. I give up. Time for the gross hack. <jpoiret>ngz: it's defined as the guile variable $PKG_CONFIG_PATH <jpoiret>(there's lib64/pkgconfig in there??) <janneke>jpoiret: /gnu/store/0dzi12yjqy6skk6clhxjv3dryiybvdsz-guix-1.4.0-8.656960a <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 <Guest28>currently I have the full path as string <ngz>jpoiret: re pkg-config, do you think it would help to put libkpathsea in both native-inputs and propagated-inputs? PKG_CONFIG_PATH is defined as a native-search-path. <ngz>Maybe propagated inputs are just ignored. <jpoiret>you probably need to put it only as a native-input <janneke>ACTION "cheated" by pruning ~1.1G cruft from the rumpkernel archive <janneke>but i hope my pruning will be accepted upstream <VesselWave>Hello! As I see now, rust crate from git source (not from crates.io) cannot be used as a dependency for other crates. What I can do? <ngz>jpoiret: That's not an option because I need the executables it brings (it's not a pure library). For now the gross hack seems to work as intended. <lispmacs[work]>no freedom issues, pretty simple package, all ready to go, I think <lispmacs[work]>I was thinking to start working on a service for it soon, but didn't want to until the package was merged in <janneke>well, hurd almost built natively, but apparently lacks a "check" target; who would have thought? <old>I have a shell script in my project `dev-env' that setup a guix-shell for the project with optional dependencies <old>one of these dependency is actually only define in my own Guix Channel <old>I would like to list this dependency in guix-shell, but if the user does not have my channel pull, then simply ignore the missing package <old>like a : --warn-missing-packages <bjc>the manifest format is just scheme, so you should be able to check whether or not the channel is available in there and print a warning if it's not <old>okay so I would have to change `dev-env' to be a Guile script instead that do some Guix stuff <old>instead of relying on the guix-shell command-line with bash <old>or did I misunderstood? <old>ah you meant using the -m option? <bjc>the ‘manifest.scm’ file is the standard way to specify a profile for a guix shell, and that just has to return a list of packages when its done <old>right I see. I will do that then :-) <jpoiret>old: you could also add a channels.scm file for your project <jpoiret>users can then do `guix time-machine -C channels.scm -- shell -m manifest.scm` <sozuba>Just curious, is it possible to run guix with of choice of ruunning Hurd or Linux during boot? <janneke>=> /gnu/store/jpjy3hwx65knzjphx29v84kldm2is7q9-hurd-v0.9.git20230216 <lilyp>mirai: the tests ought to work, not detecting a simple png file would be a serious issue <janneke>we need guix pull, and guix system reconfigure <Cairn>search-patches... search where? Where are these packages getting all these patch names? <Cairn>I wasn't grepping very well. <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 <jpoiret>old: time-machine doesn't necessarily pin commits <jpoiret>you don't have to specify a specific commit, you can use branches <jpoiret>`time-machine` is to `pull` what `shell` is to `package` <Guest206>ACTION is trying to figure out if they should write another Dissecting Guix post, and what it should be about <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) <bjc>fair enough. i'd also appreciate a dive into how the build system is put together <unmatched-paren>ACTION sees "The new 'guix locate' command lets you search for packages containing a given file", and faints on keyboard in sheer joy <unmatched-paren>i do wonder if we could put the posts or links to the posts somewhere a bit more timeless than the blog <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 <matto>hi, I have an laptop running guix <matto>when I run 'guix home container <file.scm>'. I have to manually do mkdir -p /run/user/1000 <matto>do I miss some package, that should take care of that? <bjc>elogind is what normally makes that file when you log in <matto>bjc: should I add it to /etc/config.scm ? or just run as a user guix install elogind <bjc>you need to add ‘elogind-service-type’ to the ‘services’ section of your config <mwette>unmatched-paren: the blogs are read: i've been refered to them from peeps in my day job who I had no idea were familiar w/ guix <sughosha>Hi! Can anyone let me know why GNOME files (Nautilus) does not show thumbnails? Or is it showing for anyone? <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 <Cairn>> When one of the URL starts with mirror://, then its host part is interpreted as the name of a mirror scheme, taken from %mirror-file. <unmatched-paren>Cairn: sounds like there's a constant with that name somewhere in the source code <Cairn>Ah, it's in (guix download). <Cairn>I thought it meant an actual file <jlicht>sneek: later tell cbaines: Can I just delete the node-18-updates branch, or will the QA-tooling not like that? <cbaines>jlicht, yeah, deleting branches is no problem <sneek>cbaines, you have 1 message! <sneek>cbaines, jlicht says: Can I just delete the node-18-updates branch, or will the QA-tooling not like that? <jlicht>cbaines: thanks for letting me know <unmatched-paren>seems like to get rid of all six mingetty services i now have to repeat (delete mingetty-service-type) six times... <bjc>yeah, i think we might need to revert that patch, as much as i like having errors raised when erroneously specifying services <bjc>once i can figure out how civodul's code works, i should be able to rejigger it to get both the old “match them all” behavior and be able to raise an error if no matches were found <jackhill>cbaines: thanks for reviewing/commiting the sway update!