IRC channel logs
2025-08-10.log
back to list of logs
<mra>is there a function which, given a gexp, returns the derivations upon which the gexp depends? i can't seem to find one documented in the section of the manual on gexps <mra>ah, it looks like gexp-inputs exists, but isn't exported? <eikcaz>mra: maybe you are looking for (gexp->derivation ...)? <apteryx>sneek: later tell dariqq ah, so the 'fatal error:' is the string to search for in a config.log <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, dariqq says: The failing config.log is gcc-14.3.0/32/build/config.log with error "glibc-2.41/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory" <mra>eikcaz: i don't think that that's what i'm looking for. expression->initrd takes a gexp as input, and i need to modify the function to check if that gexp takes zfs as an input, so that i can mark the resulting derivation as non-substitutable <mra>was working on this a bit over a month ago, but got sidetracked by a vacation lol <Guest20>how do you decide whether to put your packages in system config or home config <ieure>Guest20, User profile or Guix Home is the right place for most things. <bavier>I'll sometimes put packages that are closely tied to the desktop environment in the system config. <bavier>but otherwise, yeah, everything else in user profile <ieure>I have some naughty drivers in my system packages, and stuff which interacts with system services, like podman. <ieure>Some stuff you need in the system packages for things like udev rules. <mra>i use nix, but generally it's just that stuff that I want to be system-wide belongs in the system config (say, curl) and stuff that i don't care about being system-wide goes in my user, like a web browser or a terminal emulator or what have you <mra>basically all packages are home config until proven guilty, imo. if there's a compelling reason to make them system config, do that, and if not then it's home config <mra>btw howdy ieure! long time no see <ieure>Welcome back, how's it going? I think you mentioned you were finishing a degree? <mra>ah, i just finished the first year of my masters degree. spent the first bit of my summer break doing a 1400km bike trip. now back home, so i have more time to tinker on guix stuff <mra>one semester of my degree left. gotta write my thesis, and god willing i'll graduate in december or so <ieure>That's a heck of a bike trip. <ieure>I ride around town, but have never taken a trip like that. <mra>geneva to vienna! was a good time. hoped to get to budapest, but caught a nasty cold in vienna which cut the trip a bit short <mra>fwiw before this i had only ever ridden around town! just decided to go for it and had a great time <mra>but now i finally get to return to my white whale of zfs on guix lmao <ieure>I wish you luck there as well. <mra>cheers! currently stuck on how to figure out whether or not a gexp takes zfs as input in a robust way <BunniesRCute>Hi I am having trouble installing guix, i cant seem to find an up to date iso with the nonguix linux kernel. the systemcrafters repo releases page seems to only provide a script to build the iso? but you need guix to build it. i tried using an old iso because the old releases provides isos, but the ssl certs are incorrect. i tried asking on the #systemcrafters channel but nobody responded to <mra>i guess it's a bit out of date, but it should work. not sure why the newer releases don't include isos <BunniesRCute>@mra, i keep trying to download that one but it fails in the middle of downloading. but I was able to download the release v202106122242 that they used in the systemcrafters.net/craft-your-system-with-guix/full-system-install guide. however, i run into this error described in reddit.com/r/GUIX/comments/pzvt3n/guix_pull_error_the_ssl_certificate_is/ <BunniesRCute>guix says guix pull error git error the ssl certificate is invalid, so i try the fix described in the reddit post, but i assume the nss-certs package is too out of date? <BunniesRCute>in fact, i have a guix system that i bricked which i think is newer than the 2024 iso, and am trying to rescue with the 2021 iso, and if i try to chroot, i still run into the ssl issue <Guest26>when updating a package definition is there a fancy way to update the hash? maybe a emacs command? right now i just download the source into /tmp, run guix hash, and copy paste it into the definition <eikcaz>Guest26: you can run 'guix download <url>', though I just try to build with wrong hash and replace it with the actual hash in the error that prints when the hash verification fails <dariqq>apteryx: the config.log you shared is not the one that is failing. In that the CPP is correctly determined as gcc -E and it continues afterwards . I found the message in /tmp/guix-build-*/gcc-14.3.0/32/build/config.log <sneek>dariqq, apteryx says: ah, so the 'fatal error:' is the string to search for in a config.log <dariqq>not sure how sneek decides to greet someone upon rejoining but I think it stopped for me? <chrislck>any one can know about chromium-embedded-framework? not updated since 2022 <eikcaz>in guix that is. Obviously chromium upstream is still working as normal <csantosb>Ey Guix ! I'm trying to package hls4ml, and I observe a curious problem. Probably Python people is familiar with this kind of particularities. <fnat>Any idea why 'guix pack --format=docker --manifest=guix.scm' seems to be progressing veeery slowly while all the manifest dependencies are in the store already? <fnat>Aha... I've got texlive in the manifest... even if it's in the store already, I guess it's taking time for converting it to the right format. <fnat>Hm... pretty slow even without TeX, to be honest. <fnat>Ok, it completed, it might be that my system is a bit slow, but all fine otherwise. <Kabouik>Can someone help me understand this error? emacs-avy@y@20241101.1357 is no longer in my profile, and same with emacs-avy@0.5.0, and I ran a gc and deleted generations, yet the paths still exist. <Kabouik>I'm trying to restart fresh and would like to remove those paths, but I don't know how if gc and delete-generations didn't help. <Kabouik>I'm struggling to interpret the output. If I understand it right, emacs-consult-mu from Guix channel is propagating emacs-embark from Guix channel, which is propagating emacs-avy from Guix channel too. But why does emacs-avy@20241101.1357 come in the way? <Kabouik>Hum, I think I was only running `guix gc --delete-generations…`, not plain `guix gc`, which is now garbage collecting many more things. <hugohugo>Kabouik you can also run "guix gc --delete" to have gc try to delete a specific path from the store <Kabouik>hugohugo: thanks, but somehow Guix tells me that the emacs-avy /gnu/store/path is still alive, but everything was uninstalled so I don't quite understand. It's also not in my config.scm <hugohugo>that I don't know. maybe there is still a profile somewhere linking to it. You can experiment with "guix gc --list-roots". But it shouldn't be problematic if there is something in the store <podiki>berlin hasn't been building it looks like :( <dale>Has anyone got the docker service going in guix system? I am using a completely default configuration for it and getting the following verbose log: <dale>level=info msg="Starting up" <dale>level=debug msg="Listener created for HTTP on unix (/var/run/docker.sock)" <dale>level=debug msg="Golang's threads limit set to 14130" <dale>level=info msg="parsed scheme: \"unix\"" module=grpc <dale>level=info msg="scheme \"unix\" not registered, fallback to default scheme" module=grpc <dale>level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock <ni <dale>> 0 <nil>}] <nil> <nil>}" module=grpc <dale>level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc <dale>level=debug msg="metrics API listening on /var/run/docker/metrics.sock" <dale>level=info msg="parsed scheme: \"unix\"" module=grpc <dale>level=info msg="scheme \"unix\" not registered, fallback to default scheme" module=grpc <dale>level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock <ni <dale>> 0 <nil>}] <nil> <nil>}" module=grpc <dale>level=info msg="ClientConn switching balancer to \"pick_first\"" module=grpc <dale>level=debug msg="Using default logging driver json-file" <dale>level=debug msg="[graphdriver] priority list: [btrfs zfs overlay2 fuse-overlayfs aufs overlay devicemap <dale>level=debug msg="kernel dm driver version is 4.49.0" storage-driver=devicemapper <dale>level=debug msg="Deferred removal support enabled." storage-driver=devicemapper <dale>level=debug msg="Deferred deletion support enabled." storage-driver=devicemapper <dale>level=debug msg="Generated prefix: docker-252:2-302029" storage-driver=devicemapper <dale>level=debug msg="Checking for existence of the pool docker-252:2-302029-pool" storage-driver=devicemapp <[>dale: please use a pastebin, do not paste stuff directly into IRC <dale>level=debug msg="Pool doesn't exist. Creating it." storage-driver=devicemapper <dale>level=debug msg="processing event stream" module=libcontainerd namespace=plugins.moby <dale>level=error msg="[graphdriver] prior storage driver devicemapper failed: devicemapper: Error running de <dale>iceCreate (CreatePool) dm_task_run failed" <dale>level=debug msg="Cleaning up old mountid : start." <dale>failed to start daemon: error initializing graphdriver: devicemapper: Error running deviceCreate (Creat <ieure>Any ops around to mute or something? <dale>Pool) dm_task_run failed <ieure>podiki, It does that on flood, dale's client is avoiding flood detection by sending slowly. <ieure>It's generally good client behavior, really, but not helpful in this case. <podiki>docker works fine on guix, make sure you followed the manual mesa-updates/gnu/packages/ <dale>Has anyone got the docker service going in guix system? I am using a completely default configuration for it and getting the following verbose log: https://pastebin.com/t6BVJM38 <ieure>dale, I have run Docker on Guix before, but don't anymore. It didn't work last time I tried, but I didn't look into it. <ieure>Docker on Guix is very out of date. <dale>podiki, I've read the manual. There are no exceptional notes that I can see that I need to make it work. <podiki>presumably with go-team about to be merged we will be close to more up to date docker, but yes we have a very old version <podiki>it does work, i use it on my guix server <dale>Is anyone using the forgejo service then? It depends on docker... <podiki>just env variable DOCKER_BUILDKIT=1 needed for some dockers, but don't think that is related <podiki>make sure you are in the right groups and have reconfigured, probably restarted/relogged-in at least <dale>Okay, I'll look at that, thanks. <podiki>there's also (rootless) podman people like, but i haven't tried <podiki>as well as the oci service to set up containers directly in your system config <dale>Yes, I'm trying to use the oci service, but that depends on docker service <podiki>you should share your config dale <luca>Oh are you fishinthecalculator? <dale>Thanks luca, I can't see anything in there that I'm missing. <dale>Will look into the user/group thing. <Kabouik>Is placing that (https://0x0.st/8F4V.txt) in my ~/.bash_profile the correct approach if I want some manifests to be always active and their packages available system-wide? I'm new to using manifests oustide guix shells, I may have misunderstood it. <Kabouik>Also what would be the workflow if I want to add some packages, let's say to the /path/to/emacs profile made with manifest-emacs.scm? If I `guix install emacs-somepackage`, I don't see how to export an updated manifest-emacs.scm since my active profile will actually be merging packages from /path/to/emacs profile and default profile. <Kabouik>I've read futurile's articles about profiles but it's still not 100% clear to me. <ieure>Kabouik, Nothing in a user's configuration will make anything "available system-wide." <Kabouik>The confusion stems from the fact that there's only one user on my system <ieure>Kabouik, There's one human user, but multiple user accounts. <Kabouik>I meant available from everywhere in my WM/DE for my user <ieure>Kabouik, What's turning manifest-emacs.scm into $HOME/.guix-extra-profiles? <Kabouik>ieure: I did run `guix package -m ~/.config/guix/manifest-emacs.scm -p ~/.guix-extra-profiles/emacs/emacs`. Does that answer your question? Now I need to make sure it's correctly loaded when I log in, because I'm not familiar with how multiple Guix profiles work, and then understand the workflow when I want to add packages. <ieure>Kabouik, Okay, makes sense. If you want to add a package to a profile created by a manifest, you need to edit the manifest and rerun the `guix package' command. <ieure>Kabouik, You can `guix install -p ~/.guix-extra-profiles/emacs/emacs', but you don't want to mix declarative (manifest) and stateful (`guix install'). <ieure>Kabouik, I'm not sure what $GUIX_PROFILE is used for, maybe the default profile `guix install' uses? <Kabouik>If I do the second thing you posted, can't I `guix package -p ~/.guix-extra-profiles/emacs/emacs --export-manifest=/path/to/manifest-emacs.scm`? The thing is if I run `guix install somenewpackage`, while I was in a session where both my default profile and the emacs profile were loaded, I assume --export-manifest would export all packages. <Rutherther>$GUIX_PROFILE is used for environment variable paths not refering to /gnu/store, but to locations like ~/.guix-profile so that when you update the profile, you don't need to adapt your env vars. It should be left unset except for the time that one sources etc/profile out of a guix profile output <Kabouik>The sentence "Note to Guix System users: the above reflects how your default profile ~/.guix-profile is activated from /etc/profile, that latter being loaded by ~/.bashrc by default." in the cookbook is not clear to me. Why is it mentioning .bashrc? Should I not load the ddefault profile from ~/.bash_profile as well (just like extra profiles)? <Rutherther>it should always be set to the profile being sourced, so leaving ~/.guix-profile in it when sourcing etc/profile ~/.guix-extra-profiles is wrong and no env vars will point to ~/.guix-extra-profiles <ieure>Kabouik, I don't really mess with this, but I'm pretty sure the manifest export won't be 100% faithful if you have a complex manifest (ex are conditionally adding packages or stuff like that). <untrusem>sneek: later tell dale: I use rootless podman in guix which is a docker equivalent <Kabouik>I am not following Rutherther, sorry. The cookbook itself recommends using this: https://0x0.st/8F4G.txt in ~/.bash_profile, but then sais the default profile ~/.guix-profile is activated from /etc/profile, that latter being loaded by ~/.bashrc. I don't understand what I need in .bashrc if I'm using ~/.bash_profile in the first place with that for loop. <Rutherther>exactly, that is the correct approach, always set guix profile to the profile being sourced and then unset it at the end, that is precisely what I said <Kabouik>So, placing that for loop in my ~/.bash_profile (or a for loop that would filter out some extra-profiles if need be), and then something in .bashrc apparently? Not sure what. <Kabouik>Thanks, that helps. So just that for loop and I should be good to go, and when I want to install new packages that are relevant to a manifest, I edit the manifest and update their corresponding profile, instead of using `guix install something`. Hope I understood it well. <Kabouik>I don't know if I should continue using `guix install something` at all (which will install things in my default profile AFAI) or place everything in different manifests. <Kabouik>I did have "export GUIX_PROFILE="$HOME/.guix-profile" in my ~/.bashrc until now, but AFAI it would be better to place it in ~/.bash_profile, where the loop for extra profiles will be too. <Rutherther>as I said that variable should be unset except when sourcing profiles <Rutherther>exporting it out of bashrc / profile is bound to cause issues at some point in the future after you forget about it and start sourcing <Kabouik>I probably added it myself after installing something with `guix install` in the default profile (before using manifests) and seeing that message at the end where guix says to add it <Kabouik>That message is a bit confusing, and obviously I misunderstood it <Kabouik>90% of my packages are installed in my default profile sinceI only ever used `guix install` with no manifests; will they still be accessible when I log out and back in if my ~/.bash_profile only operates on $GUIX_EXTRA_PROFILES/*? Sorry to be extra cautious but I want to avoid being locked out when I try. <Kabouik>I think ultimately I'll try to move all those packages into categorized manifests if I like the system. <Rutherther>Kabouik: check if /etc/profile or /etc/profile.d do source ~/.guix-profile. /etc/profile will do that on guix system, if you aren't on it, then it depends on how you installed guix <Rutherther>then unless you reset your env vars somehow in your bash profile, you will get ~/.guix-profile search paths sourced <Kabouik>That looks fine indeed, I see the system profile and the $HOME/.guix-profile being sourced in /etc/profile. <Kabouik>let's try. I have set up three distinct Emacs profiles with three distinct manifests that contained conflicting packages that I couldn't put in the same manifest (some from Guix channel, some from Guix-emacs). Hopefully, by loading all three extra profiles in ~/.bash_profile, Emacs should be able to load all those packages; if I understood correctly. <Rutherther>you don't resolve conflicts by putting them the packages to different profiles, you still have the conflicts, they are just hidden... <Rutherther>it's just that Guix doesn't know about those conflicts <Rutherther>that's not about guix, that's about emacs loading from the load path <Rutherther>if emacs modules were capable of referring to other modules by full paths, it would be fine, but that is not how emacs works. It just has one global register of functions and when you require something, first file is found in the load path. When the second/third are going to have a requirement on different version with different functions/variables, they won't find those functions/variables <ae-chat>Is there a way of adding more packages to a `guix shell` I'm in? I use `guix shell sbcl-{x} sbcl-{y} sbcl -- sbcl` as my `inferior-lisp-program` in emacs and I would like to add more dependencies as I go along without losing progress <Rutherther>Kabouik: why are you using emacs packages from Guix channel in the first place when you're using guix-emacs channel? <Kabouik>guix-emacs only packages what is on MELPA, and there are some packages I need that are not there, but are packaged for Guix <Kabouik>I would like to avoid having to use Straight or any other package source, but I fuess this just can't work reliably <Rutherther>ae-chat: no, guix doesn't support adding to a shell, you need to recreate the whole profile the shell loads yourself <ieure>Kabouik, Yeah, I no longer bother submitting my Emacs stuff to MELPA. <Rutherther>ae-chat: as sort of a hack to create a new shell based on the current shell one could use "T=$(mktemp) && guix package --export-manifest -p $GUIX_ENVIRONMENT > $T && guix shell -m $T <packages to add>" <ieure>If someone else wants to, fine, but after doing it a few times and being forced into unsolicited code review of my own stuff... no thanks. <Kabouik>Unfortunately I can neither find all the packages I want on Guix, or on guix-emacs (MELPA), so whatever I choose, I'm missing some. This would encourage using something like Straight but I really don't want that. <ae-chat>Rutherther what if I did a `guix shell {old deps} {new dep} --search-paths` in a separate terminal and carry those env vars into my dev shell? <ae-chat>Rutherther oh what you said sounds interesting too <Kabouik>There are also some packages that are simply working better from the guix channel, like emacs-prf-tools (the MELPA version requires compiling something from Emacs) <Rutherther>ae-chat: that is fine of course, as long a you specify all dependencies... and I don't see why to make it in a separate terminal, or why to look at the search paths, you can just execute shell directly. It's just that you cannot tell Guix: Add X to current shell <andreas-e>ieure, apteryx: You are needed to urgently work on the nss-updates branch and fix the problem with nss-certs-for-test. I think we will be able to merge go-team tomorrow, and it would be nice to finally build out the nss-certs branch. It has been in the queue for quite a long time! <ae-chat>Rutherther I'd have to tell it to more than Guix so it's a question of how much of it I have to invent :) Because from within my lisp env (sbcl) I'll have to dynamically update the load paths so the new dependencies can be found (by asdf) <ae-chat>Rutherther but you've been helpful. Thank you! <andreas-e>ieure, apteryx: Actually this should be easy to fix. The problematic commit is c5227bbc8c60e4746151ffce5fd42a2a396811d2 , which does not adjust all the module imports. For instance, bioinformatics.scm imports certs, but does not now import nss. <andreas-e>Well, the commit dates from May 22; so probably other modules have started to depend on certs/nss in the meantime. <mra>if anyone with commit access has a sec to look at #1910 i'd appreciate it. just a tiny update to docs <mra>lol, testing some changes and i seem to have managed to write such a screwed up derivation that attempting to build it crashes the guix daemon <ieure>andreas-e, Thank you / sorry, I was out with my kids this AM. <andreas-e>No problem, it is good to have a life outside of Guix :) <[>Is anyone else unable to fork the guix repo on codeberg? <Rutherther>probably a lot of people with more like 200 MB storage <[>I'm at 67 MiB / 750 MiB <[>if the size of the entire guix repo counts towards that quota, I don't think moving to codeberg was a good idea <Rutherther>yes it does, codeberg is not smart like github, it needs to actually copy guix repo to every user that forks it :) <[>the entire guix repo is 947 MiB according to codeberg, so if it does count then literally nobody without an increased quota can fork it <Rutherther>forking is not a necessity for contributing though of course <[>it is if you want to submit a PR <mra>i will say, i don't have an increased quota and have managed to fork it with no issues? <[>how do I submit a PR without forking? <Rutherther>I don't think guix is taking 947 MiB in codeberg's storage, cloning new repo downloads 307 MiB currently