IRC channel logs
2025-12-23.log
back to list of logs
<Rutherther>at least they suggest to pull first, so the cache will be populated, at those points it should not make the permissions wrong <civodul>Rutherther: should i reconfigure berlin again, for the build-outputs change? <Rutherther>Hi civodul, I do not know about any more changes. I just wanted to test if these build-outputs I submitted work for me locally. I have restarted a job that already has its output in the store and it's been scheduled for quite some time, so I am still not sure <Rutherther>I do not really understand the "path" field from the manual, what's that about? It should be empty? <gabber>./configure fails today due to "No package 'sqlite3' found". it worked yesterday. did we change something? is it me? <gabber>it's just me (what a weird error, though) <civodul>Rutherther: the ‘path’ field lets you specify a specific file within the build result; see the ‘cuirass-manual’ example in services.scm <civodul>if it’s the empty string, then it’s the output itself that is turned into an artifact <Rutherther>civodul: oh, like if it's a folder? I did not know that, maybe it would've been better if I instead built it as folders with the artifacts then. (not going to change it now, but maybe for next time could be adapted). It would've been better, because the paths wouldn't have the hashes in them, which might be strange for users downloading them - well at least we can identify them based on that <Rutherther>civodul: I have tested it locally and it's fine, you can reconfigure <Nessah>Hey there, Guixers. What's the best way to test linux-libre-6.18, now that the previous kernel is retired? <Rutherther>sneek: later tell Nessah: you could use changes from this PR https://codeberg.org/guix/guix/pulls/4681 locally, easiest is going to be to just guix time-machine or guix pull to that commit in a local repo. Optionally you could rebase it on top of origin/master so that other packages are up to date <basicnpc>Is it recommended to get to dev guix? I've been wanting some config feature in the dev version. <basicnpc>The develop version of the manual vs the stable version. <Rutherther>you should pretty much always use the devel version of the manual. Stable version is only for installations <basicnpc>I hope I can use the guix that's described by the dev version. <Rutherther>you should be using the dev version, stable guix versions are mostly for installation <Rutherther>I do not really know what you mean by 'dev' version still. There is no 'dev' version. Just latest master, that's where the 'manual/devel' is taken from <Rutherther>the commit you're on is from 20th of December, so from that time there weren't many changes, yeah <basicnpc>Huh! I used screen-locker-service-type for swaylock as in the dev manual, but guix complains screen-locker-service-type is an unbound variable <basicnpc>I thought it's because my guix is too old. <Rutherther>do you have the xorg services module imported? ie. (use-service-modules ... xorg) <basicnpc>That was indeed the problem! Thanks! - I thought guix would always tell me I'm missing one package import.. <sneek>Welcome back partosqq, you have 2 messages! <sneek>partosqq, apteryx says: we now have openjdk22 in the repo <sneek>partosqq, apteryx says: we now have openjdk23 and openjdk24 in the repo; time to 'guix pull'! <partosqq> /gnu/store/llx2lq4l5qfi4g17sbbxjka6fjq8x7gb-run-container <partosqq>I see err ERROR: In procedure close-port: <partosqq>In procedure fport_write: Operation not permitted <partosqq>could you please help me to work around? <Rutherther>please don't paste lot of lines lines here, use a paste site <partosqq>Generation 33 Dec 15 2025 17:34:34 (current) <partosqq> commit: 1a9423530362ff898683fd9e29894d926587f85f <Rutherther>pull newer guix, you are using guix that has a bug <partosqq>moon@antelope ~/code/work$ guix describe <partosqq>Generation 34 Dec 23 2025 18:04:33 (current) <partosqq>Rutherther: i still have this permission error <partosqq>maybe some can help me to run this container <FuncProgLinux>Why does changing the native-search-paths cause rebuilds? :o <Rutherther>FuncProgLinux: because native-search-paths are passed to arguments to the build and then used in set-paths phase of gnu-build-system <FuncProgLinux>Rutherther: Ahhh I see. I'm keeping a PR updated by rebasing and the cuirass bot is rebuilding things but It was supposed to be a dead simple patch. <Rutherther>hmm, how do I run make check as armhf on aarch64 / as i686 on x86_64? <FuncProgLinux>as in the processor is x86_64 and run the checks as if it was a 32-bit & ARM one? <Rutherther>as if I did guix build guix --system=i686-linux for example <Rutherther>minus the guix build because I want to debug a specific test <FuncProgLinux>mmm I haven't done any cross compilation but the fastest thing that comes into my mind is Qemu. Although idk if that's overkill <Rutherther>it is an overkill, I do not want to use qemu, I want to use the processor directly. They can give different results <Rutherther>the processor already does support that instruction set <FuncProgLinux>I remember in Funtoo, they had a thing called "FChroot" that used statically built qemu packages to cross-compile into i386 & arm <FuncProgLinux>Rutherther: I found your cross-shell proposal on the mailing lists. So I guess it's currently not possible to run guix shells with another architecture :/ <FuncProgLinux>I see. I'm reading the generated Makefile to see if anything needs to be tweaked there <Rutherther>or maybe I do, I am not sure. Maybe running a shell with make and all deps for that system is going to just run it as that system. <FuncProgLinux>idk if my processor (old xeon) would allow me to cross-test with aarch64 but I bet I could with i386 <Rutherther>I just want to use the already natively available 32bit instruction set <FuncProgLinux>Ahh I see. I was about to suggest guix shell --system=i686-linux -D guix help2man git strace --pure because I was able to run make check that way :( <Rutherther>that could maybe do what I want, yes, but am not completely sure <FuncProgLinux>Do you want me to try that on my system and check if something specific changes? 🤔 I have a local checkout that I just pulled. <Rutherther>guix build is failing for me on armhf after updating guix package (well I am not sure if it was failing before or not. I thought it didn't, but I am not 100 % sure) <FuncProgLinux>I have an abandoned armhf Orange Pi but that doesn't help much <Rutherther>the failure is for armhf, so it could. But I do have only aarch64, that's why I am interested in aarch64 -> armhf. Because I have no other choices <cbaines>Rutherther, guix pull doesn't work reliably on 32bit systems since Guile runs out of memory when compiling things <FuncProgLinux>Rutherther: I'll try to build and dump and image onto an SD Card and see if I can get guix to compile <Rutherther>cbaines: I don't see any OOM, so I don't think it's failing on out of memory <Rutherther>I am also not saying it won't build on any system, really, I am not sure where the issue is. It could be just the board / os on it I have has something strange <FuncProgLinux>Could it be the same bug that affects Guile 3.0.10/11? for 32 bit machines? <ieure>Rutherther, I have Guix running as a foreign package manager on a raspberry pi and ThinkPad T16 Snapdragon, if either of those are helpful, I'm happy to try some builds on them. <ieure>Both are aarch64, but the Pi can run armhf natively as well. I could probably get it running that natively. <Rutherther>ieure: definitely, if you could "guix time-machine --branch=version-1.5.0 -- build --system=armhf-linux guix" on them it would be helpful. I am also running this on RPi5, with aarch64-linux os. Thanks <Rutherther>for me it runs multiple hours through armhf. aarch64-linux takes like 1h40m <ieure>Rutherther, Sure, I'll do that on the ThinkPad since it's hugely faster than the pi. <ieure>Only Pi I have Guix on is a 3B. <FuncProgLinux>it may take longer for me to make a bootable image for the SD card <Rutherther>FuncProgLinux: also, I thought bugs for 32bit archs were solved in 3.0.11 <Rutherther>FuncProgLinux: don't worry about it much, thanks for offering help. I am afraid 1 GB is going to fail on oom <FuncProgLinux>I see. If I can be of any use for this issue in any other way, let me know :) <ieure>Rutherther, That command is running, not sure how long this will take, but I'll let you know. <Rutherther>I think that "guix shell -D guix --system=armhf-linux" is really doing what I needed, not sure why I haven't realized executing as 32bit means to run 32bit binaries in the first place <ieure>Rutherther, build failed with "guix build: error: while setting up the build environment: cannot set armhf-linux personality: Invalid argument". <ieure>Maybe I need some kernel setting to allow this. <Rutherther>ieure: I see. I am not sure how exactly it works on this. But from what I've read not all aarch64 CPUs will be compatible with armhf, are you sure your one is? <Rutherther>maybe for starters you can try "$(guix build bash-minimal --system=armhf-linux)/bin/sh" <ieure>Complains "Exec format error" so yeah, probably no hw support. <ieure>Some way to check with /proc or lscpu? Tried searching, but the internet is made of spam. <redacted>Should I bother submitting packages for Ruby gems I've packaged if they're earlier versions of existing packages? <redacted>That seems like it could result in a lot of noise in searches. <ieure>redacted, Only if some package needs those specific versions. <ieure>ximon, Guix system does not use systemd. Please use full sentences. <redacted>ieure: Presumably that will mean users can't replace Ruby's bundler with Guix, since Guix will only ever have the latest gem available. Is replacing language dependency managers not a goal of Guix? <redacted>I've seen people online implying (or outright stating) that Guix should obviate the need for bundler, npm, etc, but I don't think I've seen official documentation on it, so that might be wrong. <cbaines>redacted, if you need older versions, then you can use a older revision of Guix if there available there, mix and match revisions with inferiors or use package inheritance to get older versions <ieure>redacted, While replacing language-ecosystem-specific package managers is one goal of Guix, packaging every possible revision of every possible dependency isn't. Unless there's a specific need to package older versions of things, we generally don't. <meatoid>one thing I wish guix had was an "in-repo infrastructure" as elegant as Nix' flake.{lock,nix}. I feel like it helps advertise the distro a lot. We have something kinda close but not quite as ergonomic, which I think is an obstacle to adoption <redacted>Fortunately, bundler *does* still work with non-native gems, so I'm able to build a profile for the project I'm working on without a whole lot of packaging work anyway. <redacted>Unless rails turns out to be trickier than I think and I go back to using distrobox <FuncProgLinux>Deno was tricky but thanks to the guix shell it's less cumbersome to use it <ieure>Oh, did we get a working deno package? <ximon>I would like to eat bread now but I know I cant sleep if I do so <FuncProgLinux>ieure: It's still a WIP. But I managed to do a repository to develop using it. Kinda hacky because it's not possible to change the binary path AFAIK <ximon>ahhhh fuck it Ima get a bread <FuncProgLinux>I've read the nix implementation but the rust crates for rusty_v8 are a ton and the test suite requires a lot of patching due to many tests using working internet connections <meatoid>my other 2c is that we should revise the way we expose/document "services". There is a lot of potential there but the documentation is not very accessible <ieure>meatoid, I've been thinking about this also. Not really sure what the right place for that is. <ieure>Thinking about meaning, something I would like to write. <meatoid>I imagine having some way for a user to express the configuration of a web server machine as a mapping of servers to sub-domains/ports/etc, or even mapping to different machines <ieure>Not following, what do you mean? <ieure>Just like a higher-level configuration instead of having to setup containers / nginx? <meatoid>I guess so, yeah; a way for users to say what they want and where and for guix to figure it out in an efficient way? I am the "target demographic" for this, lol. There's a growing desire I feel for people to have their own online spaces, and guix has the machinery to make that accessible <meatoid>Right now guix has no precedent for packaging and deploying "self-contained" <ieure>Again, not sure what you mean by that. <ieure>meatoid, Something like the transformation functions I've been using feel at least adjacent to what you're asking after. They're just functions that take an operating-system and return one with some changes effected. I've been using these to build self-contained functionality which I can mix and match on different systems. <meatoid>-style web apps, the type that are supposed to run "in a directory" in a web server, so it's been an idea of mine for a while to start packaging those, but as you can guess from my communication I know very little about web apps/infrastructure <ieure>meatoid, So that sets up a machine for Go development, and adds tree-sitter stuff if the profile getting that added to already has Emacs in it. <meatoid>ieure: ah, that almost reminds me of emacs' use-package, where the package addition and configuration are "co-located" <meatoid>that's very cool, makes me want to refactor my system.scm <ieure>meatoid, Kind of, yeah. It's targeting specific functionality, which may span multiple functional domains, ex. you want a service and a package. <ieure>These colocate the functionality, which I find convenient. You mix and match these with ex (define xf (compose profiles/+clojure profiles/+golang)) and then (xf (operating-system ...)) <ieure>FuncProgLinux, Not sure what you mean? <FuncProgLinux>ieure: I also use Guix to develop in Go. But I have to include "gcc-toolchain" in my manifests because running go "as is" complains about a missing C compiler. <newguixbie>hi, I’m trying to guix system reconfigure from v1.4.0 to branch version-1.4.0 (i686) from a source checkout. after the reconfigure, everything I run segfaults, and after reboot the terminal hangs when I try to log in. However, I can boot into the old system fine, and in there, commands from the new <newguixbie>system profile seem to run fine too. Any thoughts? <luca>Hi, anyone know if it's possible to start a shepherd service and all of it's dependents? <Rutherther>not automatically, you would have to search for them and start them with start-service, ie. in the start procedure <Rutherther>newguixbie: so if you do "guix system build" to the branch version-1.4.0, can you run software from the resulting folder ie. <the folder>/profile/bin/sh? <newguixbie>I’ll try that specifically, although it sounds identical to what I tried with the system folder from reconfigure <newguixbie>Rutherther: yes, the build command quickly outputs the same system folder, and I can run sh from it fine. <newguixbie>I might have missed something you said when my connection was blipping. I disabled power management here and hope to stay for a bit <Rutherther>newguixbie: so if I got it correctly, after you boot you're not able to do anything? <newguixbie>@Rutherfer: immediately after reconfigure, commands segfault, new logins won’t open, sudo stops working. I have to curl-alt-del to reboot. When it boots, I can’t log in. But it seems to boot fine until I type a password. <Rutherther>newguixbie: kind of shot in the dark here... could you "guix gc --verify=contents" to see ther are no corruptions <Rutherther>also, how have you installed? I presume you have used the i686 iso from the guix.gnu.org website? <newguixbie>yes, I did manual install from iso after running off the cd for some time. it took me a while to figure out how to install, I copied /boot and a few /gnu/store folders to a usb key and reinstalled grub to the usb key. the i686 system won’t boot from my nvme disk <newguixbie>these were copied from the target disk after guix system init not the install cd <newguixbie>well, i tried reconfiguring with /run/current-system/configuration.scm and no segfaults, so it looks like i can narrow down what makes it break with trial and error ^_^ guix gc still running, good idea will take a long time <newguixbie>ok, looks like my i686 system is breaking immediately when i activate a system containing qemu-binfmt-service with all the qemu platforms enabled. I’m trying to figure out how to download source derivations for other systems, e.g. some complain i need an i586-gnu system to generate a .drv file <Rutherther>newguixbie: hm, are you sure you're not putting your own platform to the config? <newguixbie>well I have i386 listed and I’m i686 … what should I have read to understand not to do that? <Rutherther>that's hard to say, what you should have read... well maybe the manual could have a warning case for such cases. i386 is a subset of i686, so you can already run it. You should not add systems you can run to qemu-binfmt <Rutherther>Or maybe we could even make the service throw an error if you are configuring it like that, but that's going to be a bit harder to do <newguixbie>removing i386 fixed all the segfaults and pam failures :D <newguixbie>do you know if I can generate i586-gnu derivations on i686? <Rutherther>as in from Linux compile Hurd binaries? I thought, but I am not completely sure. If you're still on that version 1.4.0 you should definitely update and try it with an up to date version, lot could've changed <newguixbie>I was generating a lot of them at once, maybe I can spend some time trying to narrow down what exactly threw the platform errors <newguixbie>you’re right, I think newer source checkouts did not have the problem. so maybe I can bisect and cherry pick if I’m not upgraded yet too <Rutherther>1.4.0 is 3 years old, it's definitely containing a lot of CVEs <newguixbie>I’m taking it slow, I still haven’t gotten guix pull to succeed <newguixbie>I found I can run master if I first ./pre-inst-end in guix package rrevision 37, then in 45, then in 46, then in master, doing a pure shell each time <newguixbie>right now the system says it can’t detect provenance, I’m assuming that’s because i reconfigured from a checkout, unsure <lewalkingdad>Hello everyone, I've just installed guix on a spare laptop that I hope to turn into a personal server. I'm actually writing from said laptop. <Rutherther>newguixbie: yes, exatly, when you reconfigure through ./pre-inst-env, the provenance is unknown. Don't worry about it too much, it just means /run/current-system/channels.scm is missing - so it's not clear what channels were used to configure your system. It's not a big deal <newguixbie>@Rutherfer I think the biggest problem with updating is many packages (e.g. qt6) don’t build on i686 yet in newer versions <mov-eax>How does `guix shell` caches profiles? I've stuck with old profile for manifest, eg `guix shell -m manifest.scm` creates profile with old package vesion even after `guix pull`. <newguixbie>did you `. .config/guix/current/etc/profile` like it says to after pull? <mov-eax>I've tried to re-loging right now, but stil it uses old profile. How can I clean it up and re-create? <mov-eax>Tried to pass `--rebuild-cache` to `guix shell` but again - still getting old packages. <newguixbie>there are at least 4 profiles in a shell session, /run/current-system, $HOME/.config/guix/current, $HOME/.guix-profile, and $GUIX_ENVIRONMENT, you can see the paths if you echo $PATH, but somebody else may know this more clearly than me <newguixbie>in order, those are the system profile, the guix pull profile, the guix install profile, and the guix shell profile, and later ones take priority <Rutherther>mov-eax: what guix are you using - "type -p guix". It's very unlikely your problem would have to do with the cache <mov-eax>Rutherther: it is /gnu/store/1n4a7ma47bqssbw0zlclrl0cmx1gzsgj-profile/bin/guix <Rutherther>okay, that then cannot quite be determined where it came from exactly <newguixbie>also useful: “realpath $(type -p guix)” and “guix describe” <Rutherther>does "guix describe" show you the same commit you see in the beginning of pull that you ran? <mov-eax>Rutherther: That's the point. I did pull almost a hour ago, and `guix describe` shows exactly that commit to which I've pulled. It is 001cd00bcd123cd1eab6ebd1b85afd7b0aa994fa right now. <Rutherther>and what's the outdated package that you expect to be updated? <mov-eax>Seems like the problem was with environment I'm using Guix within. It is "foreign distro" ontop of a Debian in WSL. I've kept some GUI app opened, so that when I did re-login (by closing an re-opening terminal) user session was keept due to GUI app still opened. After closing it and doing re-login again, `guix describe` shows current generation properly (was not the case previous time, only "guix 001cd00" was shown, without generation number), `type -p guix` s <mov-eax>say it is `~/.config/guix/current/bin/guix`. <mov-eax>Still getting the old package though. The package is zig, and I'm getting 0.13.0 istead of 0.15.2 which is available in latest guix. <mov-eax>manifest is (import (gnu packages zig) (gnu packages zig-xyz) (guix profiles)) (packages->manifest (list zig zig-zls)) <Rutherther>yeah, that refers to zig 0.13, check out the gnu packages zig module <Rutherther>you would have to use zig-0.15 to refer to zig 0.15 <mov-eax>What a tough nut! I would never have guessed.