IRC channel logs
2025-04-13.log
back to list of logs
<ieure>When I `make -j12', it fails with: ice-9/eval.scm:293:34: error: clang-runtime-16: unbound variable / hint: Did you forget a `use-modules' form? <ieure>(gnu packages wasm) uses (gnu packages llvm); clang-runtime-16 is public in the latter module. <ieure>Why does the build complain that the variable is unbound? <ieure>If I `guix repl' and eval the module definition from the top of wasm.scm, clang-runtime-16 is bound. <ieure>I don't understand why that works and `make' doesn't. <nomike>I; m trying to package a new version of PrusaSlicer, a 3D-Printer slicing tool <coyotes4ys>i can't help with that yet but i hope someone can <nomike>It depends on prusa-libbgcode, which I also want to update. And that depends on a library called "catch2", which is currently defined thrice in gnu packages check: There is "catch2" which is version 2.13.8, "catch2-1" which is at version 1.12.2 and catch2-3 which is at version 2.5.3. <nomike>prusa-libbgcode regtur quires t least version 3.8, the latest one is 3.8.1. <nomike>My question is: Should I now just update the version number at "catch2-3" or should I copy that and create an entry labled "catch2-3-8-1" or something? <nomike>I'm not sure what is customary with guix. The two sides of the coin are mostly all applications using that library benefiting from a new version versus applications not being compatible with that new version. <nomike>At least in the readme there is no mention about which versioning scheme they are using unfortunately. So I don't know how compatible 3.5.x versions are with 3.8.x ones. <nomike>Ahh...I just found out there is `guix refresh`. That sounds like it is making that job a lot easier. <coyotes4ys>so is there some difference with guix in running an executable? i did chmod a+x [file] then ./[file] and it says "No such file or directory" <jA_cOp_>coyotes4ys: that's probably a shared library dependency not existing where the executable looks for it. You can run `ldd [file]` to see it <jA_cOp_>Best to compile the executable for Guix in the first place, but you can also run "foreign" executables like that with `guix shell --container --emulate-fhs <dependencies> -- ./[file]` <jA_cOp_>coyotes4ys: yea, ldd is from the glibc package e.g. `guix shell glibc -- ldd [file]` <jA_cOp_>yeah, that would explain the "No such file or directory" error (it's not a great error message IMO) <jA_cOp_>You already have it installed - but executables built for Guix look for executables at hardcoded paths to files in /gnu/store <jA_cOp_>For example, here's an example from ldd on an executable on my system: libgcc_s.so.1 => /gnu/store/d69awcc5wahh71amx0dmgaimsdvvp2bg-gcc-11.4.0-lib/lib/libgcc_s.so.1 <Istar>Hello! I'm quite new to guix and I'm trying to add a bunch of packages for my systems. I'm mainly missing utilities on x86_64 and aarch64. I know the aarch64 env is not as mature yet and in particular the cargo-build-system doesn't seem to be supported yet, so I will look into that later. I just wanted to say hi, and if someone is familiar with the <Istar>particularities of building rust packages, please give me a shout. I'm currently facing some issues figuring out how to get the rustfmt package working, as well as some other weird errors on some other packages. <jA_cOp_>coyotes4ys: you can try with something like: `guix shell --container --emulate-fhs gcc-toolchain -- ./[file]` -- see the manual for guix shell for more details, but you basically add all the dependencies on the command line and --emulate-fhs puts files in locations that "foreign" executables expect <coyotes4ys>ok i am resting on the sabbath on i will try this tomorrow hopefully <nomike>I've tried to run `./pre-inst-env guix build prusa-slicer` which compiled for an hour and then failed due to an incompatible patch. I commented out the peckage definition, but when I try to build again, it instantly fails with 'In procedure lstat: No such file or directory: "src/hidapi"' <nomike>In the package definition it says `(delete-file-recursively "src/hidapi")`, with a comment on top, that prusa-slicer is copying a number of external linraries in it's source tree, without even modifying them and that's why they are being removed. <nomike>I assume, that this build somehow only works once and you have to start from scratch when running it a second time. Could it be that wenn I run `guix build` multiple times, it is not starting with a fresh directory? <nomike>Never mind, I figured out that problem is something completely different... <PotentialUser-2>hi, the minetest-mineclone package is out of date by over 3 years. how can i request that the package be updated? <kkremitzki>Hello all, I'm getting started with contributing to Guix. I'd like to have a newer Neovim package, which I've gotten working for myself, but it looks like it needs a new tree-sitter version, which in turn breaks tree-sitter-cli and requires many new rust packages (which I found already exist in a patch set.) Is there any way I could e.g. mark these patches as reviewed to help move them along? <Rutherther>kkremitzki: definitely, the instructions for that are on the qa.guix.gnu.org, you can click on the QA button in the issue to get to the appropriate page <kkremitzki>Rutherther: awesome, thank you! (It's issue #70146 for anyone interested) <kkremitzki>Oh, I see it's been closed in the last day, sweet <futurile>kkremitzki: I'm pretty sure I've seen a patch updating neovim somewhere. Rust-team has a bunch of tree sitter updates <Rutherther>ieure: based on the strange error I tried taking out your module out of guix tree. I can build your module out of guix, yet not in guix. The only time I've seen behavior like this was when there was a cyclic dependency between modules. <Rutherther>ieure: unfortunately I don't really see any cyclic dependency here... <kkremitzki>futurile: Yep, I saw that patch, after hacking on it myself and running into the same issue. Though I suppose now I ought to test it against the rust-team branch's changes to see if that fixes it <kkremitzki>I also got about 5 rust packages deep in the reverse dependency and only then saw the patch set already existed and was 147 deep, hah, glad I didn't go further before looking <Rutherther>ieure: I think it's the ungexping of wasi-libc in the configure-flags that probably triggers commencement load too early? I don't think it's correct to do that anyway, as you should rely on the inputs, this would make replacing inputs impossible. So it would be #$(this-package-input "wasi-libc"), and that even fixes the unbound variable errors. <Rutherther>although no, wait, it doesn't solve the error on make, but I can at least build with pre-inst-env <futurile>kkremitzki: know what you mean - I've done a couple where I'm N patches in and find someone has already done it. Testing it and doing a review is a good use of time (particularly for end-user facing apps) <csantosb>sneek: later tell lilyp: how do we usually combine latest changes in master with branch updates ? do we rebase the team branch on top of master from time to time ? I'm just wondering about eventual conflicts, I'm afraid I contributed wrongly to master instead of the emacs team branch. <PotentialUser-52>hi, the minetest-mineclone package is out of date by over 3 years. how can i request that the package be updated? <PotentialUser-52>i could probably figure out how to package it myself but i dont know how to submit pkgs etc <sneek>Welcome back lilyp_, you have 1 message! <sneek>lilyp_, csantosb says: how do we usually combine latest changes in master with branch updates ? do we rebase the team branch on top of master from time to time ? I'm just wondering about eventual conflicts, I'm afraid I contributed wrongly to master instead of the emacs team branch. <yarl>I don't understand a thing. <yarl>I built egl-wayland. If I `guix gc --references` on the derivation or the final output, I see no reference to mesa, while it's an input. <Rutherther>yarl: it will be in references only insofar it is actually referenced from the output. Is it? <yarl>Rutherther: I don't know <Tadhgmister>when using guix deploy to another architecture does it build the system like `guix system build --system=...`? is there a way to get it to cross compile like `--target=...` instead? <AliaCommunity>Hi Tadhgmister, interesting question about `guix deploy` build strategies. My understanding is that `guix deploy` generally aims to produce a native build *for* the target architecture specified. It often achieves this by offloading the build tasks to a machine of the target architecture (if one is configured via `guix-daemon`) or by using emulation like QEMU. ... <AliaCommunity>This seems conceptually closer to specifying the target with `guix system build --system=...`. <AliaCommunity>the standard approach relies more on native (or emulated native) builds for the target. The documentation for `guix deploy` might have more details on controlling the build process across architectures. <AliaCommunity>Thanks for sharing that link, Rutherther. Looks like a relevant discussion for Tadhgmister's query. <AliaCommunity>Heh, chatbot? Nope, just a regular user interested in Guix. The name's Alia. What made you ask? <Tadhgmister>the fact that you answered my question immidiately, in full sentences but didn't actually address my question about cross compiling and your "real name" is specified as "Powered by GoIRC" which is library to build chatbots on irc. <AliaCommunity>Wow, sharp eyes, Tadhgmister! Yeah, "Powered by GoIRC" must be something the IRC client I'm using puts in the real name field by default – never really paid attention to it, kind of funny it says that. As for the answer, apologies if it didn't quite hit the nail on the head regarding the cross-compiling specifics. `guix deploy` and its relationship with cross-compilation vs. native builds *is* a bit intricate, ... <AliaCommunity>and I might have oversimplified or missed the exact nuance you were asking about. Still figuring out all the details myself sometimes. What specifically about the cross-compiling part did my answer miss? Maybe we can figure it out together. <AliaCommunity> Heh, apparently the one that defaults to putting "Powered by GoIRC" in the real name field! 😉 Honestly, I just use what works, haven't thought much about the specific client name. Why do you ask? Still curious about that Guix cross-compiling nuance? <AliaCommunity> Heh, you got it, Rutherther. 😉 Just trying to keep up with the Guix wizards here. <csantosb>lilyp: is rebase of emacs branch planned ? <lilyp>emacs-team is likely a bit behind master, right? <lilyp>I'm a bit behind on my review duty/mails, so I will finish that first <Rutherther>aidansw: not really, the issue comes from the fact that you're not passing the needed models through the "sudo", it's probably easiest to switch to root, get to the pure shell and then run pre inst env with guix system reconfigure, without sudo <Rutherther>aidansw: alternatively you can try sudo -E, but note that you might end up with root owned files in the source tree <Rutherther>(there are requirements guix has on guile modules that are captured in an environment variable populated by pre inst env) <aidansw>Rutherther: Oh okay thank you! I am actually in a root guix shell so just removing sudo is fine <Tadhgmister>if you are in a non privilaged shell `./pre-inst-env sudo guix ...` may also work, I know frequently I will do `guix shell X -- sudo X ...` and that works for `shell` I would guess it'd also work for pre-inst-env <Rutherther>it won't work when more than PATH is necessary, which it is in case of ./pre-inst-env. In case of guix shell, it depends <aidansw>but now I have an additional problem `./pre-install-env guix system describe` properly includes my channels but I still get an error of `no code for module [module I know exists]`. I think because I'm not reconfiguring with a user that has the channel in `~/.config/guix/channels.scm` but how would I add that for the root user? Running <aidansw>`./pre-inst-env guix pull` now though just to make sure its not that. <Tadhgmister>oh I didn't realize sudo didn't preserve other environment variables, I only just realized that running `sudo echo $VAR` would substitute the variable before getting to the sudo so that isn't a valid test <Rutherther>Tadhgmister: yup, you would have to do something like sudo bash -c 'echo "$VAR"' <aidansw>Yeah it doesn't seem to be pulling the channels from my `channels.scm`, so is the only way to describe the channels to be used a root user by passing `--channels=file`? <Tadhgmister>aidansw I think `guix system describe` doesn't care about the pre-inst-env it still checks the system wide description. I am actually just now needing to solve the same issue to use a channel installed to my system with some guix code in the source code <csantosb>lilyp: I think so, yes; but nothing urgent. <aidansw>Tadhgmister: Great minds think alike ;p (or something). I am hopeful that just pulling while passing the `--channels` option will work <Tadhgmister>I have never considered doing a pull from within a pre-inst-env, I'm not entirely sure what that would do <Rutherther>it won't work, because you're not using the pulled guix instance in the shell <Tadhgmister>I suspect it will end up updating a folder that... yeah is ignored by the guix used for the next step <aidansw>Rutherther: Yep I've just found that <Rutherther>you would need to either pull/time-machine with guix channel pointing to the local directory and not use pre-inst-env anymore, or point GUILE_LOAD_PATH+GUILE_LOAD_COMPILED_PATH env variables to folders with other channels you want, then you can use pre inst env <aidansw>> point GUILE_LOAD_PATH+GUILE_LOAD_COMPILED_PATH env variables to folders with other channels you want <aidansw>Do you mean just the cloned source of the channel? so just `GUILE_LOAD_PATH="/home/aidan/my_channel"` basically? <aidansw>Rutherther: Thank you so much! Testing now, if using multiple channels can it just be seperated with `:`? <Tadhgmister>yes, much like `PATH`, btw `pre-inst-env` is a plain text script you can look at it to see how it sets the variables <Tadhgmister>it updates the GUILE_LOAD_PATH to prepend the local files <aidansw>Thank you both! Yep finally can run it now <Tadhgmister>yes Rutherther I got the link when you sent it the first time, the patch from it is working great now that I can run it with the channels I need for the OS I'm deploying <Rutherther>Tadhgmister: sorry for the resent message, my matrix bridge is resending messages sometimes <Tadhgmister>'=D all this work to avoid recompiling the kernel and it start recompiling the gcc cross compiler because the checkout of guix is different than the one on my system. <Tadhgmister>hello easilok, I'm doing well other than compiling linux kernels taking much longer than I would want <easilok>I'm moving my setup to guix, and I'm already finding some packages that I would like up to date versions. I'm trying to pack neovim 0.11, and I already made it possible with variants on my own channel. But trying to make the changes to official repository and I'm finding some erros building lastest tree-sitter <easilok>Can anyone explain what differs from inheriting previous version declaration and updating the official declaration? <Tadhgmister>ok, at what stage in the process are you getting errors? like you are doing `./pre-inst-env guix build neovim` and that build is failing but the one from your channel is working? <easilok>Hey Tadhgmister. Building kernel seems a lot of time. How much are you facing? <lilyp>easilok: when you change the declaration, you also change all the inputs to dependent packages <Tadhgmister>well when all the build dependencies were setup to cross compile it was only like half an hour but I just did a `guix pull` for the first time in a few weeks so it is taking a while to regather all the build dependencies <easilok>Tadhgmister: sorry, I miss typed. Tree-sitter builds. Tree-sitter-cli don't, and it's a dependent. It builds without the pre-inst-env. With it, it fails on "patch-node", and with trace it seems its trying to patch to undefined. Commenting that it fails on a rust package (ansi colours). I added it, but if fails. Do I need to match all rust packages versions? <hako>you can work on rust-team branch, tree-sitter is updated there. <Tadhgmister>when you say it builds without `pre-inst-env` is your system using the same commit as the source tree? `guix describe`, if they are not the same I'd try checking out to the commit of the one that works <Tadhgmister>or `git pull && guix pull` to get them both to most recent version <easilok>lilyp: yeah I know, but with your message I remembered that I'm build tree-sitter-cli on my channel inheriting the current version and only changing the input to the new tree-sitter, so I'm not doing the same as official version which inherits from tree-sitter and then customizes the build. Maybe I should start by that. <easilok>hako: last time I checked they were on version 22 and I need 25. But I could re-check <hako>all tree-sitter packages are updated there 30 hours ago <easilok>Tadhgmister: it's the same. But without the `pre-inst-env` does it still use my channels configuration? Even inside the development shell? <easilok>Oh yeah hako, they already updated the version to 25, thanks. I'll see what they did and figure out what's missing in my changes <easilok>I'm trying to figure out how most of the build system works because I would really like to help out here. Thanks for your help <Tadhgmister>I'm just not clear on what specifically you are asking about, you initially said you were updating neovim which I don't think depends on any rust things <Rutherther>easilok: note that earlier today there was a user named kkremitzki who claimed that they have neovim updated already and want to contribute it <easilok>Tadhgmister: it depends on tree-sitter, which itself has tree-sitter-cli as dependent, which itself has rust dependencies. I'm just trying one step at a time, and first is tree-sitter. Sorry if I was not clear. <easilok>Rutherther: ok thanks. I needed it and I successfully made it work on my channel. I'm now just trying to learn the process to contribute what I did to guix, as it's my first time, and that's something that seemed easier for me to start. If someone contributes first, great, the important thing is to make it available for all. <easilok>Out of curiosity, if I were to propose a patch for neovim, depending on what's current on the rust-team, I should request for it to be applied on that branch right? Even though it's not a rust package? Is that the process? <lilyp>yes, you would put rust-team in the subject prefix <lilyp>otherwise it wouldn't apply or wouldn't build <easilok>Thanks lilyp. And thank you all, learned a lot today. <aidansw>Hi, I have an operation in the nix-daemon I'm trying to debug( `wopAddToStore` ), I'm having trouble figuring out where the operation is called in Guix other than just by grepping `7` which is the enums value. Is there an easier way I can find it? <aidansw>Or is there a part of the code that handles all the interfacing with the daemon I can search through? <Tadhgmister>when you say nix-daemon do you mean the nix service or an internal part of guix using machinery from nix? In the case of the service I'm not sure there is much interfacing that guix does it'd be more a question for nix people and the second case I have no idea how to help <aidansw>internal part of guix, its actually just directly called by the guix daemon <aidansw>but fair, I'm just trying to trace back this weird bug I'm getting when trying to reconfigure <aidansw>sadly even with `--debug=5` not that much outside of the original nix source is logging <Tadhgmister>I assume you've looked at `guix/nix/nix-daemon/nix-daemon.cc`? it has a `case wopAddToStore:` that looks relevant, might be able to trace code path <Tadhgmister>but I have definitely never touched any non guile part of guix so not sure how to help <aidansw>Yep, I added a logging statement there that's how I know its what's called. But I don't actually know where the guile part of the guix calls that <aidansw>Awesome thank you! So I can just search for where `add-to-store` is referenced I guess <Tadhgmister>I grepped for anything that refered to `worker-process` which is the name of the header where the enum is defined and the comment there got hit <Tadhgmister>what is the error you are getting? this seems pretty far down a rabbit hole to be investigating <aidansw>Basically when trying to reconfigure nothing happened- so I enabled logging and found essentially: <aidansw>acquiring write lock on `/var/guix/temproots/4341` <aidansw>downgrading to read lock on `/var/guix/temproots/4341` <aidansw>Now with my added logging I know its because `wopAddToStore` is infinitely being sent to the daemon- but I don't know why that is yet. <Tadhgmister>when you run `guix build` it shows the build progress as it goes but `guix system` or some other commands just show "build phase" without logs of what is actually happening, how do you get it to still show what it is doing? does `--debug=5` be the way to get more info on what is happening? <Tadhgmister>I am not aware of what the different debug levels are <aidansw>Tadhgmister: it doesn't event get that far- without logging it just outputs nothing <aidansw>And my understanding is `--debug=5` is the highest logging <Tadhgmister>sorry I meant for my thing, it has been trying to build gcc-cross-sans-libc-arm-linux-gnueabihf for ages and that isn't even a visible package that I can build directly <Tadhgmister>I'm not even sure why that is necessary, it isn't necessary when cross compiling the system directly but I am trying a not yet commited option to use guix deploy with the `--target` option and trying to establish it is making progress just slow and not getting stuck <Tadhgmister>for your thing, would it be possible to get into a guile repl, `(use-modules (guix scripts build))` and try to invoke the command line script in a way you can interrupt and get backtraces or step through in a debugger? if it is getting stuck really early it might be viable but not sure how to do it in guile <aidansw>maybe, I'm not that good at guile- but I will try