IRC channel logs
2026-10-26.log
back to list of logs
<Air4x>ieure: Updating it to the last version <nckx>sneek: patched botsnack! <PotentialUser-48>what would happen if someone loaded up claude opus 5.5 with 1000$ and set it off on the guix repo? <RavenJoad>Is there a way for a package to merge or union many packages together? I'm looking at wuffs (which I know is already packaged) but also want to run the compiler. Wuffs is kind of like glib in the way it is set up (I think.) I would like multiple outputs, one for the compiler, one for the generated standard library, etc. Those need two very different build setups and require a dependency between them (wuffs library depends on wuffs <DragonMaus>PotentialUser-48: hopefully something that never sees the light of day, much less ever gets into the codebase <ryanprior>If I check out guix master and run `guix --file=guix.scm` in the project root I get a stacktrace. Is that a bug or am I doing it wrong? <ryanprior>RavenJoad: yes, you make a package with a trivial build system and add the packages you desire as propagated dependencies. Then when you build a profile with that package, all the other ones you selected will come with it. Does that match what you want? (Maybe manifests would be a better fit instead of a package though?) <RavenJoad>ryanprior: Manifests don't make sense here because this would go into Guix's packages directly. <ryanprior>I have no say-so but personally doubt Guix would accept a package that's just a union of other packages. Normally that's left to the end-user if they want that. But propagated-inputs would be the way to do it. <nckx>They have their uses even in Guix. That's all the main gnome packages are. <nckx>ryanprior: Guix doesn't ship a ‘guix.scm’ in that sense, although it could probably be hacked to serve as one (of questionable utility). <nckx>It's a ‘(guix)’ module that happens to share the name. <ryanprior>re-read it; so they have a guix.scm in the root of their directory, which is the pattern they themselves designated for projects to provide a default profile, and intentionally made it error out when you use it with that pattern? double-checking <nckx>A top-level module named ‘(guix)’ will be called guix.scm, that doesn't make it ‘a guix.scm file’ as expected by guix shell --file=. <RavenJoad>This would be a single multi-output package, but building each output in the same package would be annoying, essentially requiring me to define multiple build & install phases for each thing. Might as well go for multiple hidden single-output packages and "merge them" into a public multi-output package. <nckx>ryanprior: Yes, that's a totally reasonable interpretation of what I wrote (not). <ryanprior>I'm not saying you wrote that, I got what you meant when I re-read your message; I'm saying it staggers my belief <ryanprior>it's like using "README" as the binary output path in your makefile <nckx>That's usually a sign that you've missed something. <nckx>Curious how it erroring out is intentional. <nckx>(The answer being, of course, that it's not.) <nckx>If you can make it perform double duty without breaking anything, sure. <nckx>I'm not really sure what relies on it being a proper top-level (guix) module. <nckx>ryanprior: You wrote `guix --file=guix.scm` but I assume meant ‘guix shell’? If so, just drop the --file=…. <ryanprior>nckx: I meant `guix shell --file=guix.scm` yeah sorry for the typo <ieure>ryanprior, manifest.scm is the name of the file you want, see the manual section "Running Guix Before It Is Installed" <nckx>(Yeah, but if they use --file=manifest.scm they'll get a different error; intuitive it ain't.) <ryanprior>ieure: thank you, that's what I wanted (-m manifest.scm). I have read that guide a few times and was thinking to myself earlier, "I swear this worked for me until recently," but I was remembering manifest.scm working. <nckx>Now I understand how you got to ‘they intentionally made it error out’. <bytesurfer>RavenJoad: since you mentioned in your ghostty commit that you needed testers. What commands should I run? <RavenJoad>bytesurfer: You just gotta build it and use it. (At least in theory.) It's the optimization flag selection I have made that needs testing. <cnx>hello guix, my cuirass can't find the build logs since it was switched to remote-worker <cnx>i'd appreciate pointers debugging this <bytesurfer>RavenJoad: do I have to bootstrap and configure -> make or is there another way that I am not aware of? <bytesurfer>because my local pre-inst-env guix build ghostty complains about missing package in the ghostty branch <bytesurfer>and rg find the package definiton... I am confused <RavenJoad>You shouldn't need anything. What's the missing package? <bytesurfer>I am sure something is not right on my end, but what... idk <RavenJoad>Oh. That sounds like your guix/guile cache is out of date. You probably need to do a build of Guix. <RavenJoad>It happens every once in a while when doing Guix dev, especially if you jump forward/backward in commit history a lot. <RavenJoad>Commits are recent, but the point where the branch started from is quite old. I originally started packaging this 11-something months ago and did a rebase 2-3 months ago. <RavenJoad>You do the normal Guix development workflow. It's documented in the manual, (guix) Building from Git. <RavenJoad>But the usual "guix shell -CPW -m manifest.scm", ./bootstrap, ./configure, make. <bytesurfer>also now that I think about it... that is not going to be fun in the future <RavenJoad>It might won't take that long, but yeah. It takes about 20min on my laptop. You only rarely need to do the full compile. <bytesurfer>Last time it did take longer than 1 hour as if it was running on half a thread or something <RavenJoad>Make sure to pass a -j flag to make. That lets Guile do multiple modules at once. Guile is where most of the build time goes. <RavenJoad>Also, make sure to pass a number, or else you are giving Make permission to do something goofy. <pinoaffe> i'm trying to package some node stuff, and some packages consistently fail their configure phase with `npm install` error logs such as https://bpa.st/VM52K - does anyone know what might be going on here? <czan>Seems like it's trying to make a HTTP request? "http fetch GET https://registry.npmjs.org/npm attempt 1 failed with EAI_AGAIN" That won't work in the build container (no network access). <pinoaffe>yeah, but i have no clue at all why it is trying to fetch npm, since that is already installed, not listed as a dependency, etc <pinoaffe>if a dependency is listed but not provided as an input to the package, it will try (and fail) to fetch https://registry.npmjs.org/package-name , which can be resolved by either removing the dependency from the package.json or by adding it as an input to the package, but in this case neither is applicable <czan>I just looked up mlly, is related to the packageManager field in package.json? It asks for pnpm@10.33.4, and you're using npm@11.16.0. I don't know how pnpm is related to npm, but I wouldn't be shocked to find out they're related somehow. <pinoaffe>czan: sadly no, patching out the packageManager (and pnpm) fields doesn't change the behavior <pinoaffe>okay so I did figure out at least one (possible) issue: I think the npm --offline flag should be supplied after the "install" action, rather than before (this seems to have changed with recent versions of npm), but this does not seem to fix the issue at hand <haugh>how do you girls manage config files whose apps support hot reload? I want to modify a dotfile temporarily and see changes on write, then optionally make those changes permanent with a reconfigure. the only reason I don't just reconf every time is I don't want to generate tons of garbage generations <czan>Assuming you're using Guix Home and things are symlinked, you could just replace the symlink with the file it points to (from the store), then modify it in-place. Your next reconfigure (or activation?) should then write over it. <jlicht>pinoaffe: can you check on javascript-team branch? it should have quite some changes that may (or may not) impact this <jlicht>or just wait a bit: it should be merged to master somewhere in the coming days <pinoaffe>jlicht: oh hey good to know! looks like a lot of useful changes <pinoaffe>should minor bugfixes for the npm-binary importer go to javascript-team or master? <dthompson>hey pinoaffe, a little off topic for this channel but I have been playing around with the diet data structure the past few days. <pinoaffe>any takeaways? I haven't really looked at the PR/code in a while 🙃 <dthompson>pinoaffe: I think they're really neat. I've only taken a cursory glance at your code because I wanted to implement it for myself so I could understand how they work better. <pinoaffe>can recommend, they are a fun data structure to implement <dthompson>one thing that bothered me about diets is that they are unbalanced. the paper mentions a thing or two that can be done to improve balancing but it's still unabalanced <dthompson>so I've been trying a fusion of red-black trees and diets. I have this working for inserts but not deletes. <dthompson>pinoaffe: as I think you already know, diets also aren't the best when it comes to doing set union, intersection, etc. but I think that's okay for character sets because membership testing is the most important thing <pinoaffe>dthompson: yeah, as long as you're not accidentally re-constructing the character set you're testing against in your inner loop, having slightly worse operations shouldn't really matter <woodenAllen>How do I configure NetworkManager to use iwd backend? I try it and it kind of fails to connect using GUI tools. <woodenAllen>I have to use the commandline with sudo, despite my user being in the netdev group. <ieure>woodenAllen, That's a known issue, at least, I have experienced it and seen others who have. Not sure why. <lechner>Hi, how do native-inputs differ from Debian's Build-Depends, please? <ieure>lechner, I believe native-inputs can be both a build and runtime dependency. <kestrelwx>I thought you have to duplicate the package in both native and plain inputs, if you need it on both build and target machine. <Air4x>Runnig `./pre-inst-env guix lint sbcl-iterate" I get a "updater 'generic-git' failed to find upstream releases". Should I worry or can I ignore it? I checked on codeberg but didn't find any issue about this. <nckx>Correct, and make sure that the references aren't to the native input. <nckx>Air4x: That's ignorable. <kestrelwx>Air4x: it's a check for availability of newer versions. <lechner>I wrote a build system. My automatic wrapper for executables also looks at "native" inputs when calculating the environment variables. Should the wrapper look only at regular inputs? <woodenAllen>could someone please tell me how to install mpv scripts from guix. There are two to three scripts (mpv-mpris, mpv-thumbfast and mpv-uosc) that I'd like t <Air4x>I have another question, while updating sbcl-iterate I found that the asdf-build-system wasn't able to find the right .asd file, whining about not finding "iterate-d7d...". I was able to fix by adding a "(arguments `(#:asd-systems '("iterate")))", is this ok? I found very few packages written like this. <woodenAllen> #:scripts (list (file-append (specification->package "mpv-uosc") "/share/mpv/scripts/uosc") <woodenAllen> (file-append (specification->package "mpv-thumbfast") "/share/mpv/scripts/thumbfast.lua") <woodenAllen> (file-append (specification->package "mpv-mpris") "/share/mpv/scripts/mpris.so")) <efraim>I didn't notice that we grew a home-mpv-service <woodenAllen> #:ytdl-format "bestvideo[height<=?1080]+bestaudio/best" <nckx>woodenAllen: Please use a pastebin like the one in the topic. You'll probably get quieted by a bot for ‘flooding’, or your client will rate-limit it so much that it will be slightly annoying. JSYK. <woodenAllen>But it's kind of wrong... the osc get's messed up when viewing any video <nckx>But we're on this ride now, oh well. <nckx>lechner: Using only non-native inputs is more likely to be the correct approach until you hit a specific problem that can then be discussed/debugged. <woodenAllen>nckx: Oh, yeah. I forgot. My bad. Used to use that when I was on Gentoo. <nckx>Note that Guix's notion of ‘dependency’ isn't equal to that of Debian etc. ‘Inputs’ are just that, inputs to the build environment. After the build, Guix does *not* look at ‘inputs’ or have a notion of native or not, it *only* scans for /gnu/store references and provides them, it is blind to their nature. <nckx>woodenAllen: No problem, at least it was a shorter ride than I expected :) <lechner>nckx: Okay, thanks! I am not even sure how to get only regular inputs. Why is the terminology in the build systems so inconsistent between "build", "host" and "target", which (guix gexp) says should follow the Autotools manual on "Specifying target triplets"? (My favorite is %build-host-inputs.) How about #$(input-tuples->gexp host-inputs)? Will that provide just the non-native inputs? <yelninei>Hi when creating my own installer can i disable the signature check? <old>So GDB has a jit-reader plugin interface. <old>I'm trying to add this to Guile so we can have symbols of jitted functions in backtrace <old>However, GDB being GDB, it wants the plugin exactly in lib/gdb, under where GDB is installed <old>I guess this is incompatible with how Guix works <pdpnw>old: it's common for packages to override directory locations etc, this should be an option. could accomplish with a small package variant(s) probably. <pdpnw>I have to do this for some versions of programs I use <old>pdpnw: just sad that the one who made that plugin stuff in GDB did not added the 3 lines function to just change the directory <pdpnw>old: I struggled with some GDB stuff a while back setting up a manifest for stm32 development, and it made me realize some of those seemingly odd choices could be compat trade-offs of a sort <pdpnw>I only recently learned gdb happily lives in strange places like on a black magic probe etc <zilti>I got an issue since about a week where Bash does not load .profile. I use Guix Home, and extend .bashrc using home-bash-extension, but that aside, everything for Bash is default. I have to manually call 'source .profile' when I open Bash to be able to use binaries managed by Guix Home. <yelninei>ACTION rebuilds the installer against 3.0.9 <zilti>I also wonder if there's a connection between that, and the similar issue I have where using "guix shell PKG" won't add PKG's binaries to PATH. <ieure>zilti, Bash dotfiles are ludicrous and nobody uses them correctly. <ieure>For whatever it's worth, I have not had problems with my bash setup in Guix Home, and I reconfigured last week. <ieure>zilti, Do you have a reproducer for the guix shell issue? That should not be possible unless your bash files are mucking with the path. <Air4x>When writing a commit message in "changelog style" should I put the tagged version ninside the message even if the version field as a commit hash, or should I put the commit hash in the message? I updated sbcl-iterate to version 1.6.0, but had to put the commit hash in the package definition because the repo is behind Anubis and doesn't let guix downlaod the checkout. The commit message shoudl be "gnu: sbcl-itearate: Update to 1.6.0" <Air4x>or "gnu: sbcl-iterate: Update to 0k3cfvz"? <zilti>ieure, the guix shell thing happens always. E.g. 'guix shell chicken' followed by trying to call the interpreter csi, which is in the package's bin dir, fails <ieure>zilti, The presence of files the user created, which Guix Home doesn't manage, can cause problems which it isn't reasonable for Guix Home to even know about, much less address. <zilti>ieure, yes, but I don't have that. <ieure>`guix shell chicken -- csi' works fine for me (guix commit a639dc9f4767b55d5a9240a76c82957533273657, from 10/24). <untrusem>don't worry just send a pr, a reviewer will tell you anyway :) <ieure>zilti, Both issues point to a problem with your bash files manipulating $PATH somehow. <zilti>ieure, which confuses me, because I don't manipulate PATH anywhere myself. I used to, but I disabled he appending to it in my config (since it never actually got appended anyways) <ieure>zilti, Does the problem reproduce with a different user on the same system? <ieure>zilti, You can `guix describe -f channels > /tmp/channels.scm' with the user you're seeing problems with, then `guix pull -C /tmp/channels.scm' as the second user to make sure you're both on the same guix. Or `guix time-machine -C /tmp/channels.scm -- shell chicken -- csi' <ieure>Or `grep -r PATH $HOME/.*' to see if something in there's some dotfile touching $PATH. <zilti>ieure, I don't have a different user set up currently, but I doubt it is an issue with the current revision per se, since it works fine for you. <ieure>zilti, Yes, just gives you the chance to verify that it is/is not some state in your $HOME causing the issue. <zilti>ieure, I get that; I am now scrolling through the results of the grep you recommended me <ieure>Inspecting $PATH in a subshell might also give a pointer, ex `guix shell chicken' then `echo $PATH'. The first entry should be the anonymous profile for your shell. <zilti>If the grep returns nothing I'll begrudgingly try adding a second account <zilti>the PATH in the subshell is /run/privileged/bin:/home/zilti/.config/guix/current/bin:/home/zilti/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin <ieure>One other avenue is adding `set -x' to your .bashrc, which will enable debug output. Might show $PATH getting changed. <zilti>It is exactly the same outside the subshell <ieure>And you're definitely in a subshell, like C-d exits you back out to the parent shell? <zilti>After calling 'source .profile' it is "/home/zilti/.guix-home/profile/bin:/home/zilti/.guix-home/profile/sbin:/run/privileged/bin:/home/zilti/.config/guix/current/bin:/home/zilti/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin" <ieure>zilti, Okay. I would edit .bashrc (well, move the store link out of the way, copy the file it points to to .bashrc) to add `set -x' to the top, then see what `guix shell chicken' prints. If $PATH is getting manipulated, you should see it in the output. <zilti>ieure: I did add "set -x" on the first .bashrc line that I have access to using home-bash-extension, and opened a new shell. No modification of $PATH happens at all in the appended stuff or when doing "guix shell chicken" <jlicht>untrusem: you mean that our AI overlords apparently fixed a seriuos issue like 8 months ago, but in their infinite wisdom didn't bother to file a CVE? <sham1>I'm trying to use the new extension system for guix. Is there a way for me to use an extension installed in my home environment? When I'm installing it with the home-configuration it doesn't get seen by guix but with guix shell guix guix-pin, it works as expected <untrusem>sham1: have you read pastor's post on extension? <sham1>I have. > I'm adding the guix and guile packages to the shell because we want the different Guile and Guix search paths to be adjusted in the shell. To know more about why this is needed, read Search Paths. <sham1>I was wondering if that couyld be avoided <lechner>Hi, should "x86_64-unknown-linux-gnu" be a valid bag-target? <lechner>Or, in other words: Can I get my current non-cross target from %host-type? <lechner>yelninei: Thanks! I'll try that. I currently use the somewhat convoluted (platform-target (lookup-platform-by-system (%current-system))) <hwpplayer1>Maybe I asked before but I want to memorize again , I want to write a tui framework for mission critical and life critical systems for GNU Guix on GNU Guix with GNU Assembler, C and C++ and Lisp/Guile Scheme. Is it accaptable or what you suggest ? <yelninei>lechner: that would do the opposite though? (there is a nix-system->gnu-triplet as well) <lechner>yelninei: Well, I have %host-type but Guix does not accept it as a target. <yelninei>as a target for cross compilation or native builds? The (linux) cross targets omit the vendor because gcc allows that when it is unambiguous <yelninei>i feel like the thing that you want is (nix-system->gnu-triplet (%current-system)). the %current-system is a parameter so that you can evaluate derivations for a different platform (for offloading , etc) and I am not sure what you want to achieve with the %host-type <bytesurfer>let me share a fun thing I stumbled upon, tried to take the lazy route of packaging https://github.com/astral-sh/ty (cannot find it if packaged...) -> `guix import crate ty` = (description "This package provides a tool to say thank you.") <ieure>Yeah, like crustaceans... but without the C.