IRC channel logs
2025-03-31.log
back to list of logs
<nomike>ieure, thanks for the tip. `guix shell --pure --check` informed me about tainted env variables. I've changed my zsh-config and will re-login to see if that helps. <nomike>ieure, sorry, I meant to say 'clobbered' <PotentialUser-5>Is git.savannah.gnu.org down or something? Anyone else get guix pull failing with name or service unknown on a fresh install? <Tadhgmister>to confirm though you were running `ping git.savannah.gnu.org` without any slashes or prefixes, just adding a trailing slash or https etc causes it to throw unknown host <Tadhgmister>guix system init does explicitly delete store items from previously built systems, was implemented to fix bugs.gnu.org/20722. It would totally be possible to add a flag to just have init skip already present contents in the store but that'd still not track previous generations as it would still just directly override bootloader <lechner>ieure / thanks for the pointer to LibreWolf! <Tadhgmister>I think the workflow I want where it effectively does `system reconfigure` of a external flashdrive would need a new command line flag no matter what, it is so close to being `--skip-checks` to assume store items are valid or `--root` to specify the root of the system to reconfigure but doesn't quite have the right semantics <RavenJoad>Tadhgmister: Are you trying to a USB as a root disk for Guix? Because I contributed an EFI bootloader a few years back that should let you do that. <Tadhgmister>no I'm trying to get guix running on an arm device and struggling to get a kernel that makes it happy <Tadhgmister>hopefully soon I'll be just copying it to the internal drive of the machine and using guix copy or guix deploy to send new stuff over network but for now it is waiting for files to move around <Tadhgmister>ugh, last attempt booted totally fine but had missing drivers and this attempt to add drivers apparently dropped the one to identify the boot partition, this is why I'd really like to be able to try booting from last revision, to verify what was going on previously to see what needs to be added back <Tadhgmister>.... fdisk is showing a different UUID than lsblk is <meaty>Is there a way to get the path of a file added to the store via 'program-file'? <meaty>there is program-file-{gexp,name,guile,module-path} but nothing like program-file-program-path <apteryx>hello Guix! When using least-authority-wrapper, it seems #:pid-file doesn't work correctly? That's hinted at in commit 8bd1c14997fe2393e79c19ff5f3230a88cfb9abc. <apteryx>because inside the container the PID is in a different name space and doesn't match what Shepherd expects <apteryx>and so shepherd never detects that the service started <apteryx>the workaround isn't perfect; it turns the start slot into a blocking procedure that could hang-up shepherd, IIUc <lechner>meaty / maybe a round trip through Gexp? <lechner>meaty / #~#$, but there is probably a smarter way. how about converting to a string? <apteryx>re #:pid-file and least-authority-wrapper, my solution of choice is currently: #:namespaces (fold delq %namespaces '(net pid user)) ;added pid <Tadhgmister>meaty if you have a file that just has the `(program-file` as the last line running `guix build -f ` on the file should print out the path <Tadhgmister>apteryx I'm not totally sure I follow with the commit you pointed to, that is about giving it access to the passwd file to look up users and doesn't use any pidfile <apteryx>Tadhgmister: if you look at the diff, it used to use #:pid-file, and that commits removed that for the workaroNd <apteryx>if anyone is interested in doing so, it should now be possible to self-host your IRC server: bug#77396 <apteryx>most ngIRCd configuration options are exposed (at least those that makes sense) and its containerized via least-authority-wrapper <apteryx>now to tackle pounce-service-type for a bouncer (that's my actual use case but I needed a server for the system test) <Chubbymomo>Hello, I'm having issues with the Shepherd (It's stalling on reboot and on restart of certain services like NGINX or Docker), any advice on what I could collect in order to put in an email to the help mailing list? I just don't want to waste anyone's time on there by not providing enough info. If anyone decides to help me here, I have version 1.0.3 <Chubbymomo>of the Shepherd so I think I'm past that `reboot --kexec` bug that was going around a bit ago. <guixgeek>I am a new user and newly installed guix to qemu . When I run reconfigure from my user I get "guix system: error: symlink: Permission denied: "/var/guix/profiles/system-5-link.new". <guixgeek>Is this because I made a mistake in the install process? I think it could be I used root to initially run the first guix pull and guix reconfigure before doing it with my user. <podiki>guixgeek: reconfigure needs to be run with sudo (for the bootloader step yes) <podiki>really that's the only time you need sudo on a guix system for guix operations, no need to use root directly <apteryx>mirai: I forgot why maybe values in (gnu services configuration) can have defaults? <apteryx>when a default is used, it seems the maybe value will never be unset, so it defeats their maybeness, no? <janneke>apteryx: i guess it's ok for the user to specify a #f value then? <adanska>is someone with sysadmin rights able to restart the gtk build and webkitgtk-with-libsoup2 builds in ci? its the evil package that my laptop simply cannot build :( <civodul>restarted it now (no special privileges needed) <civodul>normally dependents of gtk (including webkitgtk-with-libsoup2) will be built soonish <adanska>indeed, im making more of a general statement. especially when theres a patch pushed to something like core-updates, there is a lack of utilisation i have noticed. I cant provide an example right now, but when i notice it next i will inform irc <civodul>well, ‘core-packages-team’ is another story: to evaluate it, Guix and all its dependencies must first be built, and that happens via the normal build mechanism, so it’s invisible to Cuirass <civodul>(not great either, but that’s how it is) <Rutherther>civodul: what's normal build mechanism in this context? What does start the build if not cuirass? <civodul>Rutherther: the evaluation process starts it, as if it were running ‘guix time-machine …’ <mirai>apteryx: what are you trying to do? <mirai>I've used the maybe-values in the past as following: %unset-value to mean "do not serialize anything to the configuration, #f/#t/… to serialize that value in the configuration <mirai>you can set maybe-values in default as well, iirc by (maybe-value X) <mirai>and if the user really wanted to blank out a field from the serialized config, they'd manually punch in %unset-value <apteryx>mirai: I see, so the only use case using (maybe-value DEFAULT) would be when you want to allow the user to optionally set it to %unset-value <apteryx>I was basically deciding vs: (local-host (maybe-string "localhost") "The host to bind to.") or (local-host maybe-string "The host to bind to. When unspecified, @code{\"localhost\"} is used.") <apteryx>I think I prefer the former, as it's more upfront and won't lie in the future if/when the implicit default changes and we forget to adjust the documentation. <andreas-e>Hello! Savannah is down again? Is there a website where to check? <Guest743>No idea where to check but its down on my end too <andreas-e>Thanks! Well, the problem is I would like to push :) <andreas-e>I have a pacakge that is available on x86, but not on aarch64, due to one of the transitive inputs. Is there an easy way to find the offender? Actually I know that it should be possible to make the package itself available also on aarch64. <efraim>I guess you could iterate through the inputs in the REPL and see if aarch64-linux is supported <efraim>something like (for-each (lambda (pkg) (supported-package? pkg "aarch64-linux"))(append (package-inputs foo) (package-native-inputs foo)(package-propagated-inputs foo)) <andreas-e>civodul: Thanks for the blog post! What remains unclear in the end is whether the rootless daemon is desirable. My impression after reading the blog post is that on a Guix System, running the daemon as root might even be safer? At least it sounds as if there is a stronger guarantee for build isolation. <andreas-e>efraim: Thanks! I will have to read the documentation on guix repl first. <civodul>andreas-e: oh interesting; what makes you think it would be stronger? <andreas-e>Because of what you write about different build users, which see the store as belonging to them. But in the end this is just about raising one error or another? <civodul>yes, we do achieve the same level of isolation without privileges <andreas-e>Or potentially errors in name spaces. But this is speculation, right? Will it be easier to break out of a container or to exploit a potential bug in the guix daemon running as root, who knows. <civodul>it’s just that it relies on different mechanisms <andreas-e>efraim: Got it! With the following code (and suitable use-modules): (for-each (lambda (pkg) (unless (supported-package? (second pkg) "aarch64-linux") (format #t "~a\n" (first pkg))))(append (package-inputs foo) (package-native-inputs foo)(package-propagated-inputs foo))) <andreas-e>Coming from its own inputs python-jupyter-server, python-nbclassic and python-nbconvert. <andreas-e>In the end you are right - it boils down to pandoc! <andreas-e>So it looks as if we do not have certain packages because their documentation cannot be built. <efraim>it's almost always pandoc, valgrind or rust, depending on the architecture <mjw>ACTION looks up, valgrind? <efraim>looks like it's not supported on any hurd, armhf or riscv64 <andreas-e>efraim: So haskell is not supported on aaarch64? <jas>efraim: thanks! what is the challenge to get those up on guix.gnu.org? i would think that at least arm64 should be fairly stable? <efraim>the machine that builds them doesn't have a very strong aarch64 offload machine so that particular build target was disabled, but there should be an official 1.4.0 tarball for aarch64 <jas>efraim: okay thanks. i was looking for snapshot releases though, to try the new priv-less guix-daemon <jas>but getting it running on amd64 should keep me busy for a while first :) <efraim>where does config.gz from the kernel config live? <efraim>hmm, ours is in /proc/config.gz. I don't have one on my rpi5 running ubuntu <PotentialUser-40>Hi! Does `guix pull` still require pulling a git repo nowadays? I switched to NixOS a year ago because pulling was getting too slow on Guix <janneke>PotentialUser-40: we had a session on guix pull slowness <jdrjdr>but luckily it's often down, and so you can't pull at all unless you remember the mirror <PotentialUser-40>Okay I will keep an eye on Guix, hoping it gets faster someday. Have a nice day everyone <mirai>apteryx: I think its fair to use a string value for your case <mirai>explicitly %unset-value is normally used for cases like bittorrent client port values, where using %unset-value would completely leave the 'port' field out of the configuration file which the program interprets as 'bind to random port' <mirai>consult the program manual to see whats the behavior of leaving that directive out of the config file <Rutherther>can I get aarch64-linux-gnu toolchain out of guix somewhere easily? I know of cross-gcc that gives me gcc, but no libc <Rutherther>can I get aarch64-linux-gnu toolchain out of guix somewhere easily? I know of cross-gcc that gives me gcc, but no libc <moksh>Rutherther: I would like that too <moksh>I run into several issues while building stuff that I build in FHS complient distro <moksh>also cc doesn't link to gcc in guix <emacsomancer>have been unable to do `sudo guix system reconfigure...` for the past couple of days because I keep getting an error "guix system: error: reference to invalid output 'pnp' of derivation '/gnu/store/x66w0w9adx9qsk7cmsk1lghlz2f0y1w8-hwdata-0.391.drv'" - not sure why <Rutherther>anyway most tools should respect either GCC env var or make parameter <emacsomancer>Rutherther: which log should I check? '/gnu/store/x66w0w9adx9qsk7cmsk1lghlz2f0y1w8-hwdata-0.391.drv' doesn't actually reference 'pnp', despite the error msg <emacsomancer>2>&1 .... guix system: error: reference to invalid output 'pnp' of derivation '/gnu/store/x66w0w9adx9qsk7cmsk1lghlz2f0y1w8-hwdata-0.391.drv' <reepca>seems we may be running into that <untrusem`>guix shell --emulate-fhs --container sdl2 gcc-toolchain make busybox clang --preserve='^XDG_RUNTIME_DIR$' <untrusem`>but when I run the build.sh, it says `src/uxnemu.c:11:10: fatal error: SDL.h: No such file or directory <jdrjdr>I think Guix and Uxn are incompatible cults <untrusem`>by the way , there is a uxn packages in guix <jdrjdr>(for the record I think both uxn and guix are super cool) <untrusem`>it gives `exec: Failed to execute process '/home/untrusem/.local/share/../bin/uxnemu': The file exists and is executable. Check the interpreter or linker?` <untrusem`>I am retrying to install uxn with a newer commit <Rutherther>untrusem: just putting something to shell packages doesn't mean it will be picked up by the build scripts... you need to check how it actually tries to find the sdl, and if it doesn't, you will need to change the build script or env vars <untrusem`>I installed uxn from the guix repo, and now the error is different `Boot:Failed to boot rom` <untrusem`>I am going to ask this in #uxn channel as well, but this seem to be guix problem as it runs fine on my artix linux <jdrjdr>@untrusem` I tried running `uxnemu adelie.bin slides.txt` with the binary from the substitute server on amd64 and it flashes up some junk in a new window and then prints "Run: Ended.: <Rutherther>untrusem: just putting something to shell packages doesn't mean it will be picked up by the build scripts... you need to check how it actually tries to find the sdl, and if it doesn't, you will need to change the build script or env vars <untrusem`>`guix shell sdl2 gcc-toolchain make clang --preserve='^XDG_RUNTIME_DIR$'` <untrusem`>this was the command I ran and just ran ./build.sh <spiderbit>Hi I have a problem I just updated my system and my user profile, yet the "emacs-daemon" from my homeconfig uses it seems a old version of emacs that has some dependency error <spiderbit>the shepherd service from home-config uses (specification->package "emacs") <spiderbit> "/bin/emacs") shouldn't that point to the newest emacs like /run/current-system/... <Rutherther>spiderbit: so did you reconfigure your home with guix with newer channels? <spiderbit>no... I thought guix package -u does that trick... <Rutherther>guix package and guix home are completely unrelated <spiderbit>why can't specification->package not point to /run/current-system? <untrusem>spiderbit: guix system configure the system and guix home is different for every user <Rutherther>spiderbit: I don't understand the question. specification->package will find emacs package in the available modules and point to it directly in the store, it can't point to anywhere else than the store as then it wouldn't be doing its job. <Rutherther>if you want ot point to "/run/current-system/profile/bin", just provide that string directly, but it's usually not a good idea to do that, it's better not to relay on system environment. <spiderbit>but the user has also in <home>/.guix-profile/bin/ <spiderbit>a own directory... and if there is no special user version you would assume it jumps over to system version <untrusem> that folder is for packages you install with `guix install <package>` without reconfiguring the hone spiderbit <ieure>spiderbit, You're using both Guix Home *and* `guix package -u'? <spiderbit>I currently try like 5 times get nonstop errors <spiderbit>substitution of /gnu/store/8mby9vfwqsk51crfrzif23h8azmqjri0-module-import-compiled failed <spiderbit>guix home: error: some substitutes for the outputs of derivation `/gnu/store/5gkf9al46yc41zfsfqbwbq8vjwiklivl-module-import-compiled.drv' failed <spiderbit>Error: /gnu/store/8mlw3q73vpgynzhhsxp54wkiv1hgkllx-emacs-29.4/bin/emacs: symbol lookup error: /run/current-system/profile/lib/gio/modules/libdconfsettings.so: undefined symbol: g_once_init_enter_pointer <spiderbit>does guix system delete dependencies that homeconfig still points to or how can that happen? <Rutherther>that is error that happens when the gio module versions desync between system and user/home. The problem is the gio module path environment variable (search path) that, if unset, will prevent this error usually <Rutherther>no, guix system doesn't delete any dependencies. The issue is that wrong (unexpected) dependency is used. <Rutherther>hopefully the new GCD for search paths will fix stuff like that <spiderbit>I didn't knew that home is seperate from the user config, thought it's both about a user so shares it's packages... <Rutherther>spiderbit: I don't understand the question. specification->package will find emacs package in the available modules and point to it directly in the store, it can't point to anywhere else than the store as then it wouldn't be doing its job. <Rutherther>no one forces you to point to it... I don't know what you're saying. But of course it's much better to point to a specific version as that is the only guaranteed to be there, the system nor user's profile is guaranteed to be available on the system. That is a strong guarantee of Guix that it will provide you all necessary dependencies. This goes for everything guix does, not just shepherd services. <Rutherther>that is error that happens when the gio module versions desync between system and user/home. The problem is the gio module path environment variable (search path) that, if unset, will prevent this error usually <Rutherther>hopefully the new GCD for search paths will fix stuff like that <ieure>Rutherther, Your client is reposting everything again. <graywolf>Hello :) It looks like shepherd is adding a timestamp into the log file (set via #:log-file). Is there a way to suppress that? <lechner>Hi, has anyone on Guix successfully used adb and fastboot to flash CalyxOS? <ieure>lechner, I tried recently and wasn't able to, because the Android dev tooling is way out of date. <ieure>lechner, I ended up doing it on a Debian box, using downloaded binaries, because the Debian stable packages are also way out of date. <gabber>how can i get a dependency graph of a Guix system definition? <identity>gabber: i think you can give it the system's .drv with the `-t derivation` flag, though the derivation graph may be too detailed for your needs <lechner>ieure / okay, thanks! that's what I did two years ago. just got a new, slightly less antique pixel <lechner>ieure / Hi, do Librewolf and Firefox from nonguix share a Mozilla profile? <gabber>identity: i don't think there's such a thing as "too detailed" for my current needs (: i'm trying to prove a point here <Rutherther>lechner: no, they don't, librewolf lives at ~/.librewolf, whereas firefox at ~/.mozilla <jas>hi! i'm trying to understand the new privless guix-daemon, but i'm missing something: what is the now recommended way to launch guix-daemon? i assume it is no longer intended to be run as root? <jas>running guix-install.sh to install as root in a debian container suggests this: ~root/.config/guix/current/bin/guix-daemon --build-users-group=guixbuild <jas>but that runs guix-daemon as root, doesn't it? or does it drop privs internally now? <Rutherther>jas: exactly, you just start it as other user. Depends on what system you're on, on Guix System just don't care about it, Guix System includes the new service. On other systems, see the new .service file, specifically you should add the capability and start it as other user than root. But if you're already using guix, you're going to have a problem with the store being owned by root, you will need to manually 'reown' everything in there <jas>thanks -- i am running this in a gitlab ci debian container. no systemd around. so i suppose some adduser my-guix-builder + su my-guix-bulder guix-daemon ...? <jas>fwiw, i still got the 'guix pull: error: cloning builder process: Operation not permitted' error without giving buildah/podman privileges <Rutherther>1. are you sure you're using newest guix?, 2. are you sure you're not using the --build-users-group flag? <Rutherther>you of course cannot use that flag without root, you can't change users without root <Rutherther>and thirdly, are you sure you're giving guix-daemon the chown capability? you will need it for stuff like guix pull <jas>i'm using guix-install.sh with sha256 fcb671fd25ccfbb38036b6f61516d556bfca4ca5cbdfab74087df2adadfec941 <jas>and guix tarball with sha256 f6f131a54ffa6334d87fffb781b648095070d918582f5ef937316c74f9ffee26 <jas>savannah was down when i fetched these, but they are somewhat new <jas>install via: yes '' | env GUIX_BINARY_FILE_NAME=the-tarball.tar.xz ./guix-install.sh && \ <jas>i was using --build-users-group though, that's what the install script told me to do <jas>i think i'm missing a bit of the logic how this is supposed to be wired up <jas>i re-fetched the files and got the same sha256, so at least i'm working with latest versions <jas>even running as root still require non-default privileges, i believe. just got this one too: guix pull: error: while setting up the build environment: cannot set loopback interface flags: Operation not permitted <Rutherther>jas: the install script is then either old or someone just forgot to update it, you can't use build user groups without root <jas>right now i am trying to get things to work running guix-daemon as root, but without podman/buildah --cap-add's <jas>this is running inside gitlab's shared runners which IIUC is using google gcp and I don't know their security settings <jas>but i am hitting the 'cloning builder process' build.cc throw, even running as root <jas>(root inside podman/buildah, that is...) <Rutherther>first question is if they support unprivileged user namespaces, if not, you will have to use --no-chroot unfortunately <Rutherther>I don't think you can make nested linux namespace 'containers' inside podman <jas>i got everything working without --no-chroot about a month ago. but i had to give nested container some --set-cap's <jas>--cap-add=CAP_SYS_ADMIN,CAP_NET_RAW,CAP_NET_ADMIN specifically <jas>i think the two improvements i can see compared to my setup would be to 1) somehow get rid of those --cap-add's on initial container creation, and 2) avoid running guix-daemon as root when using it for cicd purposes <jas>although i'm not sure 1) is terribly important. those capabilities are only in effect when creating the initial container <jas>maybe i should focus on 2) only instead <jas>so should i start guix-daemon without any parameters at all, running as some non-root user? and make sure /gnu is owned by that user? <Rutherther>you can of course still pass arguments like substiute urls <ekaitz>anyone interested on packaging blender 4.x with me? it includes very interesting things like updating python :) <jas>should /gnu/store be o+rw,go+r owned by the user that will run guix-daemon? is a chown/chmod -R /gnu/store sufficient, or is anything under /var necessary? will it attempt to write /var/guix/profiles/per-user/root too, if root is installing packages? <Rutherther>jas: everything under store should have read and no write. executable depends on the file <Rutherther>jas: it will attempt to write under /var/guix, but it's not so important that it will write there, what's important is that it will try to chown it as the target user, meaning the CHOWN cap is needed