IRC channel logs
2025-08-07.log
back to list of logs
<Deltafire>ekaitz: I think because when I was first setting up guix the manual lead me to believe that this is where I should list packages that I want to be installed for all users <Deltafire>which is true.. but with experience now, i think putting them in packages or guix home might be easier <ekaitz>moving them to guix home shouldn be hard for you <Deltafire>i'm not entirely sure about guix home tbh, sometimes i end up with packages in there and then also installed via guix package <Deltafire>so then have 3 separate things to keep updated (guix system, guix home, guix package) <ekaitz>so, i won't nag you for not using it <valorzard>so wait, then how are there standalone programs written in guile? <valorzard>is there really no way to compile a guile script into a standalone executable? <ekaitz>valorzard: some people do some magic for that <valorzard>so like writing some sort of host c program? that sounds annoying <valorzard>huh, i thought you could use guix shell somehow <ekaitz>you can do some things to distribute guile programs for other distros <ekaitz>the windows part i think it's a little bit more complicated <Deltafire>i think guile was designed to be linked as a library into a host application <valorzard>in that case, even though i dont think this would work, could you use guile and friends in cmake <valorzard>but i feel like using both cmake and guix doesn't sound right <valorzard>since from what i understand guix is kinda like a replacement for cmake <eikcaz>valorzard: since you are in WSL, shouldn't things Just Work(TM)? Or you mean you want to create a binary for someone without WSL? <eikcaz>Well, a quick web search finds your reddit post as an early result XD. I think the answer is that compiling a guile program for Windows can work, but not through Guix. <valorzard>oh yeah ive been interested in scheme/lisp for a hot minute <valorzard>decided to ask dave thomspon on mastodon, hope they don't mind <valorzard>i get the feeling im not totally understanding what im talking about but its worth a shot <ajarara>is there any way to have really common packages (like gcc-toolchain) be globally installed? I have some binaries that download binaries that expect to find libgcc_s.so.1. they work when I run them in 'guix shell -C --emulate-fhs gcc-toolchain'. <ajarara>Also hi #guix, long time no see. : ) <gabber>ajarara: sure, just include them in your system configuration, home configuration or home profile <ajarara>ah, thanks, I was just installing gcc-toolchain interactively. I actually like the paradigm of having containers for binaries that are outside of the guix ecosystem. Another route to the same question, is there a way to have emacs tramp into a guix container as part of a direnv setup or something? <ajarara>although I feel like 'guix install gcc-toolchain' is what is meant by having them in the home-profile <vagrantc>ajarara: if you are relying on --emulate-fhs ... installing them in the system configuration will not work without further fiddling <vagrantc>i think the only things available in traditional FHS paths are /bin/sh and /usr/bin/env ... without manually configuring said other things... <ajarara>yeah, a reconfigure including gcc-toolchain in the packages field for system config doesn't have `ldd adb` show libgcc_s.so.1 as found <vagrantc>(well, a few other things such as /etc/ ... but you get the idea) <vagrantc>when i first starting guix /usr/bin/env wasn't available, but there were instructions for how to make it available ... would probably work for other things too <vagrantc>e.g. manually installing symlinks to the right places (or maybe there is some function to do so) <drewverlee>what is the correct order, on a new install of guix, to do `guix pull` vs `sudo guix pull` vs `sudo systemctl restart guix-daemon.service`? <drewverlee>err the restart should obviously happen after sudo guix pull. <drewverlee>but i'm not sure if the order of the other two matters. <jmes>drewverlee: you are on a foreign distro so it should be sudo -i guix pull then sudo systemctl restart guix-daemon.service <jmes>-i is the same --login for sudo <jmes>Also that information can be found in section 2.7 of the manual: Installation > Upgrading Guix <drewverlee>yeah, i guess the natural order, on a fresh install of a foreign distro: `guix pull`, `sudo -i guix pull` and `... restart...` <drewverlee>i mean, i used the guix-install.sh script, so like, i don't know what channel would be less stale. <jmes>drewverlee: oh, about the order. Sorry I misread your question. Well just as it says in the manual ‘sudo -i guix pull’ will upgrade the build daemon, ‘guix pull’ as your user updates the guix that your user will use. I think it doesn't matter the order, but I don't use foreign guix often so YMMV. <drewverlee>Final question, while i'm blowing up the the chat :). Do you, who ever is listening, think Shepherd is a suitable way to run a long lived java webserver? Currently were using systemD as our init system, and it's not clear to me what we might be getting ourselves into by switching. <jmes>drewverlee: RE: stale channel: recently the code moved to codeberg and the mirror is up to date, that warning is just there preemptively. There's no need to worry, I think you'll only get that warning once. The second time you pull, your channels should be updated to the new repo. <jmes>I believe Shepherd is suitable. There may be a reason for you to pick one thing or the other but I can't think of a reason why Shepherd couldn't manage your webserver. Though the actual experts may have better insight :P <drewverlee>Thanks! i grilled chatgpt for like an hour and a lot of the complexity of SystemD seems tied up in this that dont apply to just running a single webserver. <drewverlee>the advantage is then we can build our container with guix, which unifies the conversation around linux and package management. <dtx_>hey I'm trying to use node version 14, but when it tries to build it it ultimately depends on Go 1.17.11 which fails to install because it runs a test that tries to verify TLS functionality but the included certs expired in January. Is there a way to work around this, like disable the tests? <dtx_>I'm trying this in a guix shell with a manifest btw <dtx_>It worked in the past, because I built go before 2025. <dtx_>also, should mention that go is being installed as result of installing node 14 via lookup-inferior-packages in the manifest <gabber>i try to build a (minimal) image for my pinebook pro and run into: <gabber>gnu/build/linux-modules.scm:278:5: kernel module not found "cirrus-qemu" "/gnu/store/fsirzqqniqm8xmrmnmhlxd2c0513a9b1-linux-libre-arm64-generic-6.15.6/lib/modules" <efraim>ugh that diffutils error that we had on ppc64le? it's on ppc also! <efraim>gabber: do you have a "cirrus" module instead? <gabber>i try to build with `guix system --system=aarch64-linux vm path/to/file.scm` <efraim>there's a comment in gnu/system/vm that in 6.14 cirrus was renamed to cirrus-qemu <gabber>it comes from the `vm' subcommand <gabber>and is not renamed for aarch64 yet? <efraim>no idea, that's why I asked if you had the module <efraim>it was a lucky find from 'git grep cirrus-qemu' <efraim>I have that path too, I don't see anything with cirrus in the name <efraim>I don't know if I've ever tried doing an aarch64 vm like that, could it be x86 only? <gabber>when i try a `guix system image` command i run into a similar, yet different error: <gabber>gnu/build/linux-modules.scm:278:5: kernel module not found "usb-storage" "/gnu/store/fsirzqqniqm8xmrmnmhlxd2c0513a9b1-linux-libre-arm64-generic-6.15.6/lib/modules" <efraim>I apparently removed all the modules from my initrd on my pinebook pro <efraim>mine is also flashed with tow-boot, so I'm doing tow-boot -> grub-efi <gabber>ah, it seems to build (when doing an image and without the kernel modules) <gabber>efraim: thanks for sharing your config! <efraim>for the firmware I think ap6256 is the bluetooth and the ath9k one is the wifi. Otherwise I used a wifi dongle <efraim>I have the nvme adapter but I don't have a low power nvme device <gabber>huh, i was not aware the pinebook needs non-free firmware <efraim>oh, and the pbp-asound.state I grabbed from manjaro <efraim>Under light load I get ~9 hours with the wifi, closer to 7 with a dongle, maybe 2 if I'm compiling <gabber>how bright is your screen in these scenarios? <efraim>Probably "normal" for the compiling and "a bit dark" if I remember how long i could last without using it much <efraim>I'd guess 50-60% for compiling, 30-40% for ZOMG BATTERY! <csantosb>ice-9/eval.scm:293:34: error: tigervnc-server: unbound variable; hint: Did you forget `(use-modules (gnu packages xorg))'? <f1refly>hello, I'm trying to create a backup of my passwords and gpg key with this script: https://paste.rs/DQ5oh.sh . I'm in the cdrom group, but cdrecord seems to expect root rights. I'd prefer my backup script not to rely on running as root, is there a way I can burn my cd without sudo? <andreas-e>csantosb: I confirm; I have removed the .go file, and it does not compile anymore. I will have a look. <andreas-e>csantosb: But I do not understand why there is a problem, the gnu/tests/lightdm./scm file already includes (gnu packages xorg). <andreas-e>It is most probably due to commit a4f3216ce8e by apteryx. <andreas-e>csantosb: Maybe you could file an issue on codeberg. <andreas-e>csantosb: It was a question of "make clean-go && make" and waiting for half an hour... <ae-chat>Noticed sbcl-cl-mixed isn't getting built due to failed dependencies. Build ID: 13057346 <csantosb>andreas-e: No problem, just wanted someone else to confirm <csantosb>I have a `#:use-module (guix gexp)` missing; the message I get is "warning: 'replace' may only be used within 'modify-inputs'" <andreas-e>ae-chat: I have updated the dependency libmixed locally. Not sure yet if the dependents build. <andreas-e>ae-chat: Pushed, with an update to the depending packages as well. <efraim>re2c fails some tests on armhf-linux, blocking meson/ninja/cmake <ae-chat>andreas-e can you share a link to the patch? I'd like to see what the fix looks like <andreas-e>Just an update of all the packages involved :) You can see them at the top of the guix git repository. <ae-chat>andreas-e so guix packages cannot remain internally consistent and healthy against the passage of time. I thought guix would eliminate the need for such maintainance. Is it because the dependent package definitions get updated and the dependees no longer work? <andreas-e>I am trying to parse the "dependent*" words, but I think you are right. <andreas-e>In this case, we have recently updated gcc to version 14. So everything that depends on a C or C++ compiler (so indirectly, almost everything) will be rebuilt. And this new gcc is stricter than the previous ones. <andreas-e>And it refused to build the previous libmixed. <andreas-e>And then everything depending on libmixed also fails. <ae-chat>Yep, I was actually looking to build sbcl-trial and libmixed was an indirect dependency <andreas-e>In this case, the problem had already been fixed upstream, and updating libmixed was enough (but then I also updated the dependent packages, since they all come from the same place). <andreas-e>Or in other cases, we repaired things locally. <andreas-e>But as long as you do not "guix pull", the packages should remain internally consistent. It is just the case that if you modify one of them, this can break consistency. <ae-chat>If only there was a state in time where everything I ever needed was present and 100% bug-free, I'd never `guix pull` :) <gabber>ae-chat: i think we all would stop pulling <gabber>unfortunately we are doomed to never halting evolution of things <efraim>I don't think there is a version of re2c that doesn't use itself to bootstrap that was released in the past 20 years. <efraim>it's an alternative to lex/yacc that's used by some packages, like ninja <andreas-e>efraim: So you mean the re2c "source" code contains text generated by a previous version of re2c? Since we do not seem to bootstrap anything in Guix. <csantosb>What is the criteria to set the hidden property to some packages ? <csantosb>Instead of not making them private to its module, for example <ieure>csantosb, It seems to mostly be used for interim packages for bootstrapping others, which you sometimes need to do across modules. <csantosb>Something like intermediate stages on the way up ? <andreas-e>I agree that it only makes sense if they are used in a different module from the one they are defined in. Otherwise they can just be "define"d without the "-public". <old>anybody else failed to use textlive-minted ? <old>I get: Package minted Error: minted v3+ executable is not installed <old>when compiling from auctex <csantosb>I have a change that implies a lot of rebuild, more than 300 packages, see #1873 (and it is not yet over ...). <csantosb>(this is a prime for me ...) Following the doc, I'm expected to git push to a topic branch, not to master. <csantosb>Are not comiters allowed to do so (create new branches) ? Agit seems to reply no. <ColdSideOfPillow>Am I correct in saying that I'm supposed to use `guix download` to obtain hashes for package tarballs? <ieure>ColdSideOfPillow, I use it regularly and have never had that problem. Perhaps the tarball is generated on the fly and differs from download to download? <ieure>ColdSideOfPillow, If you `curl -O first https://...' and then `^first^second', and then `sha265sum first second', do the hashes match? <ieure>ColdSideOfPillow, Do you have a URL and/or or package definition I can use to try reproducing the problem? <ieure>ColdSideOfPillow, What's the time frame here? You `guix download', put the hash in the package and update the version, `guix build' and it immediately fails with a hash mismatch? <ieure>ColdSideOfPillow, It shouldn't redownload, `guix download' puts the tarball in the store. That points to a mismatch between the URL in the package definition and the one you gave `guix download'. <ieure>So neither URL you're giving `guix download' is the same as the package, which is why they don't match. <ieure>Unless you have forked versions which use those URLs or something. <untrusem>I have pasted the error and the relevant files in here <identity>one day pastebins will start loading consistently for me… <Rutherther>untrusem: the parentheses in the error aren't there just for fun... you have a list that contains inferior-package. You need to pass inferior-package to home-environment-packages list directly, not inside of another list <Rutherther>your niri variable is a list since you're mapping over a list <ieure>ColdSideOfPillow, I was telling you that the URLs you're giving to `guix download' differ from the package definitions, which is why the hashes don't match. <ieure>ColdSideOfPillow, keepassxc uses a different URL, and qbittorrent builds from a git clone, not a tarball. <identity>untrusem: note that your inferior is re-evaluated every time you call ‘rust-team-inferior-package’, which may or may not have a noticeable performance impact if you call the procedure multiple times <identity>but yeah you probably want (rust-team-inferior-package "niri") instead of (map …) <untrusem>thank identity, Rutherther, So map would be useful when I wanted several packages from the rust-team branch <identity>yeah, and then you have to use ‘append’ to merge the lists afterwards <ae-chat>andreas-e I'm able to continue working on my game! Thanks for the quick fix <untrusem>identity, cool, use guix, learn about scheme <untrusem>identity: So I have a list of packages that I want to map over, so then it will build all the packages again if I add another one? <identity>untrusem: you mean my remark about evaluating the inferior multiple times? probably not, but it is probably a good idea to move expressions that do not depend on the arguments out of the lambda, like in a separate ‘define’ or with a let-over-lambda like (define func (let ((my-constant …)) (λ (args) body-that-uses-my-constant …))) <untrusem>ohh, I don't get this, my programming knowledge is new & subpar <[>what happened to ci.guix.gnu.org? <vagrantc>i did wake up to the particular evaluation i was interested in actually being responsive ... for the first 3 out of 4 tries. <vagrantc>ok, i *think* we are all current now with kernel updates... whew. that was an adventure. <vagrantc>ACTION expects to see new upstream versions within the next 24 hours, now that we are finally current <podiki>yeah i haven't been able to connect to ci frontend in many days <podiki>i'm going to rebase and push new mesa on mesa-updates so i wanted to cancel any old builds (maybe they finished from a few weeks ago though) <podiki>i unjinxed it and could visit the web frontend finally :)