IRC channel logs
2026-02-19.log
back to list of logs
<dgr>gabber: I can't get uname -r to run in the manifest before I build the linux-libre-headers@version string. Do I need to inject or why do I get: No such file or directory <dgr>anemofilia: thanks, looks like I got a bad example while searching the web and the error was misleading me. <apteryx>this-package-native-input doesn't work for implicit inputs, does it? <apteryx>the one that fails is #$(this-package-native-input "binutils") -> #f <apteryx>though there *is* a "binutils" label. <apteryx>the manual documents lookup-package-input and lookup-package-direct-input but doesn't mention the difference <apteryx>ok, I think the 'this-package-input' family of selector works on the direct inputs (not propagated, or implicit from the build system); so you can only select packages explicitly listed in the package description <apteryx>for other cases, you have to resort to (search-input-file (native-inputs inputs) ...) for native-inputs or (search-input-file inputs ...) for other types (taking dirname if you need a directory). <mange>Could you use lookup-input (which is unexported...) to search in (package-transitive-native-inputs (this-package))? <mange>Oh, wait, I think this-package shouldn't be applied like that. But you get the idea. <apteryx>another thing which puzzles me in icedtea-7 is how are these origin native inputs unpacked? it seems to happen implicitly <apteryx>the only one unpacked manually is "openjdk-src" <apteryx>it's hidden in some dynamic label computing <apteryx>under (with-directory-excursion "openjdk.src" ... <mange>Hmm, that's annoying. Maybe you could do it with something like (bag-transitive{,-build,-host}-inputs (package->bag this-package)), taking inspiration from package-development-inputs? <mange>Or heck, maybe you can use package-development-inputs. That seems like the wrong thing to use in a package definition, though. <dajole>I'm trying to test a package definition where the source url points to a private git repo. How can I let `guix build` access the appropriate SSH key? <mange>I don't think you can. The build happens in the daemon, so it can't see ssh keys and the like. You could clone the repo separately and use "guix download --git file://..." to add it to the store (if the hashes/names line up with the package source Guix should use the pre-fetched one). <dajole>Hm...I see. I'll give that a try. Thanks! <theruran>efraim: has Ludovic signed your key since this chart was made? <identity>okay, is downloading 300 MiB of QT5 debug symbols *really* necessary? <TanguyugnaT>Hi Guixers! Before I ask on the Guix Help mailing list… am I the only one facing a weird `guix pull; sudo guix system reconfigure` behaviour?! `guix pull --describe` says that I’m at `fe31090`, but `sudo guix system reconfigure` complains that `aborting reconfiguration because commit 2d4ed08662714ea46cfe0b41ca195d1ef845fd1b of channel 'guix' is not a descendant of 230aa373f315f247852ee07dff34146e9b48 <TanguyugnaT>`guix system describe` says that I only have 1 generation, reconfigured this morning (I haven’t `guix system delete-generations`, so I should have at least one before today!?) and I only have 1 channel listed their, my personal channel is missing? <trev>TanguyugnaT: did you do a guix gc? <TanguyugnaT>I rebooted… in GRUB I selected "old systems"… and I saw 4 generations! Only one was listed by `guix system describe`. I selected one from a month ago. <mange>TanguyugnaT: what does "which guix" say? 2d4ed08662714ea46cfe0b41ca195d1ef845fd1b is v1.5.0rc1, and 230aa373f315f247852ee07dff34146e9b480aec is v1.5.0. <TanguyugnaT>and now, `guix system describe` list only one generation… the one from last month (the current one)?! <TanguyugnaT>mange it says `/home/tlecarrour/.config/guix/current/bin/guix` which is not what you are looking for, I guess. <mange>Also, I don't know what "guix pull --describe" is. I get "unrecognized option" when I do that. <mange>Yeah, ~/.config/guix/current/bin/guix is what we want it to be. That's the right thing to see after a "guix pull", and means you're running what's come from the pull (rather than what's on the system). <mange>What commit does "guix describe" report? <mange>I expect the same, but it's always nice to be sure. :P <TanguyugnaT>mange this generation 81 is exactly what I’m aiming for! So I don’t get why `guix system reconfigure` do not talk about `610227591de`!? <mange>One possibility: at that commit the "guix" package is pointing to 230aa373f315f247852ee07dff34146e9b480aec. Maybe you have the "guix" package installed in a profile that's causing an issue. Does "sudo guix describe" report the same 6102275 commit? <TanguyugnaT>mange: yep, but I usually don’t do `sudo guix pull` (right?)… but I might have done it this morning out of panic to get out of this mess! 😱 <identity>TanguyugnaT: pleeeeease do not paste multiple lines in the chat <mange>FYI, pasting multiple lines into messages is a bit awkward on IRC. You can feel free to cut down the output to the relevant bits, or link to a paste (see the channel topic). <TanguyugnaT>identity: sorry! How am I suppose to send… multipe lines then? <identity>and, i mean, do you *really* need to send the whole thing? just the commit should do <TanguyugnaT>mange: and now everyone figured out that I’m not a big fan of IRC! 😅 Thanks for educating me! 😁 <mange>If you want the easiest solution to your problem you can just run the reconfigure with "--allow-downgrades" and hope that fixes everything. <mange>If you want to understand what's going on we can keep digging into it. <TanguyugnaT>mange: thanks for your help. Now that I’m back at a stable state, I’ll try to investigate more and put everything into an email to Guix Help. Thanks! <mange>Don't stress about not being familiar with IRC conventions. As long as you're not being intentionally noisy and/or annoying, and stop when asked, we're usually pretty chill. :) <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, csantosb says: rebased hpc on master, with all fixes and improvements; I'm almost tempted to upgrade spirvm-llvm-translator to llvm-20, same as ROCm and SYCL, WDYT ? <sneek>civodul, yelninei says: Whtats the status on a new gash release? <civodul>csantosb: hi! i’m not really knowledgeable on spirvm-llvm-translator, but upgrading to match the LLVM version of ROCm sounds like a good idea <civodul>sneek: later tell yelninei hi! regarding Gash, i can tag the new release any time, waiting from a green light from you :-) <csantosb>Hum ... Updating my emacs profile pulls 1GB heavy weight qtdeclarative-6.9.2-debug ... <csantosb>I have no idea which package includes it <csantosb>Ah .. I do search with emacs-guix, which seems broken again <folaht>I'm so confused about guix. I feel like I need babysteps to learn some basic thing I want to do, but I don't even know where to begin. <folaht>Where does one set the XDG_DATA_DIRS env var? <folaht>csantosb, I have no idea what this trev person is talking about. I'm a completely newbie when it comes to scheme and guix. <folaht>Am I supposed to run the flatpak.sh script? <folaht>I have two flatpak versions apparently. How do I destroy older versions? <Wurt>folaht, Guix does not automatically delete older versions, so you can restore to a previous system state if needed. If you wish to remove your previous states (profiles), you need to run `guix system delete-generations`, and/or `guix package --delete-generations`, followed by `guix gc`. <trev>folaht: "this trev person"??? COME ON <mange>Is "trev" even your real name? :P <folaht>I'm sorry trev, I'm quite new here. I'll refer you as trev from now on. <trev>folaht: sorry for not being clear enough. you need to have that environment variable set in your shell (bash) profile <folaht>I get the feeling 'guix package --delete-generations' deletes the generations of all packages, correct? There's no way I can just pick and choose one package to delete the old version of? <folaht>It's probably not desirable, but I think I'll ask just to be sure. <mange>It's a bit confusing, but "guix package" actually operates on profiles. A profile is a set of packages that are installed somewhere. So you're not actually deleting the old version of a package, you're deleting the (otherwise immutable) profile that references it. <mange>If you delete all the profiles referencing something, then "guix gc" can collect it. <mange>That said, why do you want to delete the older versions? Having them in the store shouldn't interfere with anything, so it's usually only a problem if you're running out of space. <folaht>What if I want to delete just one generation? Like for example I installed racket just an hour ago to learn more about scheme and then discovered that racket is not scheme and wanted guile instead. (I'm not sure if guile is scheme either, but at least it says scheme in the repl) <Wurt>folaht, Guix has an excellent manual. It can be overwhelming, but if you want to learn Guix, it’s a good idea to familiarize yourself with it. <identity>Racket is not a Scheme only (mostly) in the name. there are only minor incompatibilities, and you can get right of all of them but one with #lang rNrs, where N is the version of the scheme standard, like 5, 6, or 7 for R⁵RS, R⁶RS and R⁷RS respectively <identity>also, you can look at the info manuals installed on your system by running ‹info›, or open a specific section of a manual with, e.g., ‹info "(guix) Invoking guix system"› <folaht>mange, for the above reason. I installed the wrong program and don't want that to show up. Also, if I have to run a shell script in /gnu/store/XXX-flatpak/etc/profile.d/flatpak.sh, I prefer to be sure that I'm at the right version. In other OSes I would simply delete the older folders before proceeding. <identity>you can also open them from inside Emacs by evaluating, e.g., (info "(guix) Invoking guix system") <identity>folaht: you do not need to delete older version to make sure you are on the latest one <mange>You shouldn't run the /gnu/store/... path, you should run it from your profile (e.g. ~/.guix-profile/etc/profile.d/flatpak.sh if you used "guix install"). That way Guix is responsible for making sure the right one is in the right place, and you can benefit from things like roll backs. <mange>I think trying to keep /gnu/store organised and pruned is a fool's errand, and will make using Guix much more painful. <folaht>mange, oh I see now. For some reason I was not able to find the .guix-profile before. <folaht>I must have been in the wrong directory while searching for it in my terminal. <identity>trying to manage the store manually is like trying to manage memory manually with python <aaavigatori>does anyone else have an issue that installed programs don't show up in plasma's kickoff? <aaavigatori>huh, that's weird. I installed both icedove and icecat, but only icedove shows up in kickoff. But KDE Menu Editor has an entry for both <Wurt>Where should I place a new niche language (an array language written in Go called Goal)? Should it be in a new module, such as (gnu packages goal)? <identity>franly, we should create array-languages.scm <folaht>I'm looking at these flatpak csh/sh shell scripts and they look like those environment variable scripts I would see at /etc/profile.d/XXX on Linux distros. <trev>yeah i told you, you don't NEED the script. you can do it yourself <trev>do it = setting XDG_DATA_DIRS <Wurt>identity, thanks, I will try that in PR 6364. <yelninei>janneke: setting crash to crash-kill causes a guile test failure :( There was a recent patch to make crash-dump-core not hang so this might be a better solution? <sneek>yelninei, you have 1 message! <sneek>yelninei, civodul says: hi! regarding Gash, i can tag the new release any time, waiting from a green light from you :-) <ekaitz>yeah... no green light from me yet :) <yelninei>civodul: I have built up to curl with a gash tarball that includes the char classes fixes with the new coreutils <ekaitz>i don't know how to reproduce the hang outside riscv <janneke>yelninei: "a recent patch" for which package? -- all the hangs were in bash or tests other `core' utilities, right? <janneke>yelninei: ahh..."we" (actually you atm) are traiing a moving target... <janneke>yeah, upgrading hurd would seem to be the better fix <janneke>...but you're doing all this work, so... <aaavigatori>isn't there a built in command to reformat sexps in emacs? I could have sworn there was one <janneke>aaavigatori: M-q while in scheme-mode? <yelninei>janneke: Better fix than what? I'd say my target is not moving (trying to fix the packages) but the way to achieve this is <janneke>yelninei: "There was a recent [hurd] patch to make crash-dump-core not hang so this might be a better solution?" <- yes, upgrading hurd might be better than (temporarily) changing the crash server? <janneke>and by moving target i mean: mig, mach, glibc, hurd keep changing; and while you make fixes/workarounds for bugs in some of them, another version comes along... <janneke>yelninei: ie, no criticism of what you're doing, just stressing how much work it all is! <yelninei>yes, though I am bit confused how a change in the crash server causes guiles "time.test: internal-time-units-per-second" to fail (i retried atleast 4 times to make sure it is not flaky) <yelninei>but hopefully when I am done with this we have there are no more differences between 32bit and 64bit in the manifest <yelninei>janneke: That patch also fixes SIGABRT wit crash-dump-core. gdb does not like the generated core but at least it does not hang <aaavigatori>is it normal that `guix system delete-generations` start to build stuff? If so that came very unexpected to me. I expected to remove boot entries and symlinks and not to build qemu <yelninei>also a bit interesting that all the failures are in packages with a very long testsuite (openssl, python, cmake, automake, libtool) but maybe this is just because these tests are so comprehensive that they catch edge cases <janneke>yelninei: yeah, murphy must have foreseen such things <janneke>but why indeed, not only in short and sweet test suites...too bad! <yelninei>aaavigatori: it probably depends on grub to regenerate the boot entries and grub depends on qemu for tests <aaavigatori>yelninei but shouldn't that already be installed? Ohh, it's a new derivation, isn't it? <aaavigatori>uh oh. I accidentally stopped the compilation. The old generations have been deleted, but it hasn't completed the `delete-generations` command. Am I now in a potentially unsafe state? <aaavigatori>How can I query if a package is installed by default? Maybe I misunderstand but if I use `guix package -I` only those packages in my profile are being searched for. But what about packages I described in my system config like `plasma-desktop-service-type`? <aaavigatori>Specifically I want to know if I have the `kservice` package installed <identity>is that I really a capital i or a small L? <identity>whoever chose -I for ‹list Installed› better have had a good reason to not use -l <aaavigatori>update: I thought the solution was `guix system describe -I (capital i)` but it doesn't seem like a recursive list to me <ieure>aaavigatori, You're correct that `guix package -I' lists packages installed in your imperative user profile. You can look at the system profile to see if it includes a package or not -- see /run/current-system/profile/bin <ieure>aaavigatori, What do you mean by "recursive list?" <ieure>Referenced packages and their inputs? <aaavigatori>ieure I meant it in the sense that it only seems to list "top" level packages. For example it only lists "plasma" and no other (obvious to me) KDE packages, so the list doesn't seem to display all installed programs <ieure>aaavigatori, Seems like it might depend on the DE? On a system with GNOME, I see gnome-calculator, gnome-calendar, gnome-music, etc etc. <ieure>aaavigatori, I believe you. There are multiple ways to include packages in a profile, I guess plasma-desktop-service-type is doing it a different way than gnome-desktop-service-type. <anemofilia>aaavigatori: When a service provides a package, that's always done by extending a profile-service-type (or home-profile-service-type, in case of guix-home). To list all packages installed in a given profile, you can use the `-p` of `guix package` <anemofilia>`guix package -p /run/current-system-profile -I` <anemofilia>Lists the packages in your current system generation <anemofilia>`guix package -p ~/.guix-home/profile -I` does the same for guix home, if you're using it <ieure>anemofilia, That command produces the same package list as `guix system describe -I', for me, so presumably wouldn't include the KDE packages missing for aaavigato. <anemofilia>`-I` doesn't list packages that are propagated inputs of explicitely installed packages <anemofilia>And since the only package in the profile-service-type extension of plasma-desktop-service-type is plasma (which is essentially just propagated inputs) none of them gets listed, just plasma <anemofilia>ieure: Also, didn't know about `guix system describe -I`, that's nice <ieure>anemofilia, I didn't know about it either. <ieure>anemofilia, Yeah, I think that's the difference between Plasma and Gnome, gnome-desktop-service-type extends the profile to include all its packages. <ieure>Wonder why Plasma is leaning on propagated inputss. <anemofilia>aaavigatori: You could maybe see `guix size /run/current-system/profile | grep kservice`, if it doesn't appear there it certainly isn't installed on your system profile <ieure>anemofilia, They left, you can use "sneek later tell aaavigatori ..." to leave them a message. <anemofilia>Though it could appear there because it's a input of some other package directly or indirectly used by the profile <aaavigatori>I made progress! I couldn't find kservice, because it's not a binary, but a KDE Frameworks library : D <aaavigatori>tho I have no characterized the bug much better, my question is, should I open a bug for guix or for upstream KDE? <aaavigatori>The problem is that plasma keeps a cache file listing (among other things) all the installed .desktop files in the profile directory. When one makes changes the profile symlink gets updated, however, plasma seems to continue to watch the old inode <aaavigatori>(there is a kded6 program that does the actual watching and it actually creates a new cache file if one forces it via the command line but plasma itself doesn't actually pick up that new cache file but sticks to its old one) <ieure>aaavigatori, You could ask upstream, I don't think Guix has any leverage to change that behavior. <ieure>aaavigatori, Also, it's expected that if you create a new profile generation (by installing a package, or reconfiguring Guix Home), you have to log out and back in for it to completely take effect. <ieure>It sounds like you're creating a new profile generation and expecting it to work immediately. Not everything works that way. <aaavigatori>ieure normally yes, but it doesn't change the behaviour. (That's the part I haven't figured out yet :D) "Normally" you should be able to regenerate the cache files via `kbuildsycoca6 [--noincremental]` but running the command does not update the list of programs in kickoff. I suspect because plasma doesn't pick up the new cache file. Deleting the <aaavigatori>cachefiles themselves instantly updates the list of applications in kickoff <ieure>aaavigatori, Definitely sounds like something for upstream. <aaavigatori>(There is a related issue of not picking up the icon files correctly but I suspect it has the same origin) <aaavigatori>now to some other problem: is there a way to indicate that a package has an optional dependency? I would like to suggest one for a package. <aaavigatori>I installed `emacs-pgtk` in my all wayland session. However, it had no access to my clipboard. I had to install the additional package `wl-clipboard` to make it work. <andreas-e>Guix does not have the notion of an optional dependency. The dependency graph is completely rigidified. Either a package propagates another one, or it does not. <andreas-e>One can create package variants with differing inputs, but then these are distinct packages. <janneke>the bash package is much more useful if you also install coreutils, find, grep, .. (git)? <aaavigatori>andreas-e so would it be a bug then? I would imagine that the main use of emacs-pgtk is to run it without xwayland, but I am not certain. <andreas-e>I do not think it is a bug, since the package should work well without wayland. <aaavigatori>I mean, I guess (I haven't checked), but it doesn't not work completely with wayland <vagrantc>hrm. https://ci.guix.gnu.org/eval/2135915 suggests several kernels from the kernel-updates branch should be available for x86_64-linux ... but guix weather suggests otherwise ... did it go through all the trouble to build them and then just delete them as part of a gc job? <vagrantc>i also get the impresion ci will not attempt to rebuild them once it lands on master... <vagrantc>is e2fsprogs in any fundamental boot path or anything? <vagrantc>trying to sort out the impacts of https://codeberg.org/guix/guix/pulls/4749 and both "guix build --dependent(s) e2fsprogs" and "guix refresh --list-dependent(s) e2fsprogs" are less than enlightening, spitting out lots of architecture-specific packages on all the architectures, which makes it hard to test <FuncProgLinux>How much scheme-fu experience is needed to implement the same Rust crates workflow into Guix's Go packages? <FuncProgLinux>I've been researching about this today and only found a message from hako where they describe some plans to do the same but nothing else. <untrusem>I think there is already a go-build-system pr <aaavigatori>I hope my spelling was better than that, however >_< <loquatdev>I'm trying to create a simple-service using hosts-service-type that reads the contents of a file and uses those contents to generate a list which is then passed to hosts-service-type. The issue is that this file is not something that I have locally, but rather something that would be generated a put in the store. How do I go about ensuring this file is already built before reading it?