IRC channel logs
2025-05-04.log
back to list of logs
<Tadhgmister>like you could totally just install guix as a package manager on gentoo and do the `guix system init` from gentoo, if the gnu/store was on its own subvolume it'd even be possible to share it between gentoo and guix system <Tadhgmister>but that assumes you can figure out how to write the config yourself without the TUI installer guiding you <Tadhgmister>but if you just mount the subvolume at /mnt or wherever and then if you wanted to share the gnu/store mount that as well under /mnt and the rest of the install process should work exactly as intended <Tadhgmister>*under /mnt/gnu as well as /gnu while doing `guix system init OS.scm /mnt` <zuki>Neat I think i got most of that, thanks! <zuki>Would running guix system init in my gentoo system with the guix package manager on the subvolume let me install guix(os) from within my gentoo system without having to even reboot? <Tadhgmister>oh I misread your question, yes you could install guix system from gentoo without having to reboot, although booting into guix system would obviously require a reboot <zuki>that sounds much more convent. <Tadhgmister>for the sake of a lazy loading web server I'd really like to have a `computed-file` routine or a package that is done with a bunch of local files as the source but using `local-file` forces them to all be copied to the store which I would really like to avoid <Tadhgmister>I feel like I can maybe get away with something like `((@@ (guix gexp) gexp-with-hidden-inputs #~(begin #$abs-filepath) (list (file-hash* abs-filepath)))` so when it is used in other gexps it uses the filepath where it is on disk and has the hash of the file as a dependency so if the file changes it will change the derivation hash and other than <Tadhgmister>needing to rerun that computation when the folder changes I feel like it is stable.... but I also feel like I am opening a door to unknown horrors <apteryx>'mumi compose --close' is fun to use! <jmes>Is there something blocking ungoogled-chromium version bumps or just not enough time? It's been on 112 for quite a while. <meaty>any guides out there yet for using the new rust importer? should I remake my pending rust-team packages to use the importer <hako>it needs some updates though, but still usable. <meaty>wdym updates? is it outdated relative to the rust-team branch <hako>yes, a new cargo-inputs implementation is used (the interface remains similiar), and cross-compilation when mixing build systems is supported <apteryx>hi! we do not yet have a way to extend /etc/profile or /etc/bashrc using shepherd services, right? <adanska>i think i have i misunderstanding of how guile records work and how variables are bound... <hako>adanska: gexp is evaluated on the build side, you need to keep reference of host side values with ungexp <hako>(string-append "-DVERSION_MAJOR=" #$major-version) etc. <cow_2001>if anyone can merge it, that would be great ☕ <cow_2001>(it's an Office Space reference, but it doesn't fit and is not funny because i am not a boss of anyone anywhere) <cow_2001>oh no! it says "QA failing" and the button there is red <efraim>there's more failing and blocked than before, so the button is red, but there's also more succeeding, which obviously is good. I'd check the unknown packages from the Base <cow_2001>maybe i shouldn't have changed the inputs? is that it? <cow_2001>why wouldn't there be (ice-9 textual-ports)? it's built into guile, no? <iyzsong>to read that page, I clicked x86_64-linux Failing (5), then guile2.0-lib/x86_86-linux/ was not present, now failing, then 1 of 3 Failed build, finally 'View build log'. <iyzsong>cow_2001: it seems not available in guile 2.0.14 <cow_2001>so the newer guile-lib, version 0.8.2.1, is trying to use (ice-9 textual-ports) which is not available in installations that are using guile 2.0.14? that's what the test is showing, right? <ruther>cow_2001: did you not build your package update before submitting it? <cow_2001>you know, this is strange, because i don't see any change between v0.2.8 and v0.2.8.1 adding textual-ports <cow_2001>maybe it does not support that guile version <iyzsong>cow_2001: you're right, i just checked, that guile-lib-0.28 failed with the same build error. <iyzsong>cow_2001: by run 'guix build guile2.0-lib' locally, and first I checked that 'guix show guile2.0-lib' reports 'version: 0.2.8' and 'guix build -S guile2.0-lib' does have the same 'ice-9 textual-ports' in the source. <xelxebar>Huh, after my last pull and profile update, things that use python3 broke until I restarted a shell. <xelxebar>Something something environment, but not sure what. <xelxebar>Neovim couldn't find python3, so maybe GUIX_PYTHONPATH was just out of date? <xelxebar>Oh, did we just update to python 3.11, perhaps? <ruther>xelxebar: not just, few weeks ago <pastor>Hello, is it a known issue that `ddcci-driver-linux' fails to build? <tschilp>Hi guix! Do you have an idea, how I managed to achieve a mismatch between the commit shown by `guix describe` and the commit shown by the generation marked as 'active' when running `guix pull --list-generations`? Also, how would I get things in sync again? <tschilp>I'm experiencing 'random' gnome crashes and think this might correlate somehow <ruther>tschilp: what is output of `type -p guix`? <tschilp>`/run/current-system/profile/bin/guix` <ruther>tschilp: so that's how, your guix is not pointing to the one you pulled. Does ~/.config/guix/current exist and point to a valid store path? <tschilp>ruther: it does, but this goes in the right direction... after gnome crashes started (this was after adding calibre to my home environement), I renamed .config to .config.old as I thought some gnome settings got messed up in there. need to check if I messed something here! <tschilp>mhm, the guix folder from `~/.config` looks very much the same to the one from `~/.config.old` though <ruther>tschilp: and did it exist when you logged in? did you relog if not? <ruther>if you ddi relog after it started existing, then your profile files are wrong as they are removing guix profile from the PATH <tschilp>OK, not sure if I entirely follow. I basically 'removed' the original `.config` by renaming it to `.config.old` and relogged. The 'original' `~/.config.old/guix` contains 'current' from May 24th 2023 pointing at `/var/guix/profiles/per-user/me/current-guix`, while the 'new' `~/.config/guix` has a 'current' from May 4th 2025 pointing at the same directory as well. Confused... <ruther>tschilp: when you renamed .config to .config.old, ~/.config/guix didn't exist. It got created after you pulled, probably. Did you relog after that? <tschilp>I had quite a sequence of unconsidered relogs most certainly... <ruther>tschilp: so if do relog now, or `su $USER --login`, you don't get ~/.config/guix/current/bin in PATH? <tschilp>Mhm, I don't think I ever lost it from PATH... <ruther>tschilp: so you do have it in PATH currently? <ruther>tschilp: how does your full PATH look like then? <ruther>tschilp: in that case, does `hash guix` solve it? <tschilp>I just wonder if this really fixes my gnome, just started liking my tty2-emacs :P <tschilp>nope, unfortunately... but at least I'm fine with system, home and guix commits again. Thanks a bunch. <tschilp>Do you maybe have an idea how I'd best debug gnome crashes (that's where the whole `~/.config` renaming started). I'm on guix a35fa2d2cb currently. The one change I did to my home config was adding `(gnu packages ebook)` to my `use-modules` section and add `calibre` to my `packages` section. As my ebook reader did not successfully connect anyway and gnome started crashing ('unfortunately a problem occured. a problem occured that cannot <tschilp>be fixed by the system. Please log out and retry'), I reverted the changes, but the crashes stayed. <tschilp>I've seen this message before on early gnome 46 commits, but haven't yet seen it on a35fa2d2cb before my calibre experiment. I assumed that something in `~/.config` causes it, so this journey got started. But I pretty much have no clue, how to actually debug... <ruther>tschilp: first of all I would look in the log for the actual crash cause, have you found that? <tschilp>ruther: not yet. I'll do some digging now. <tschilp>are there any troubles with savannah currently? <ruther>tschilp: there are and there have been for past few weeks or even months <tschilp>ruther: thanks, `guix pull` seems to have succeeded, but on reconfigure I get a git-related 502 that seems to point there... <ruther>tschilp: yeah, it's probably better to just switch to codeberg mirror for now <tschilp>are there commit mismatches between savannah and codeberg? <ruther>it can definitely happen that codeberg will have earlier commit than savannah <ruther>but other than that, no, and shouldn't be for long <cow_2001>iyzsong: think maybe i should send a summary of this conversation to 78185@debbugs.gnu.org ? <tschilp>ruther: right, I guess I hit a gap where savannah actually gave me brand-new commits :P <tusharhero>Guix is most likely switching to Codeberg right? <ruther>tusharhero: yeah, there is a GCD in deliberation period and many people accepted/supported it. No one is against till now <ruther>I think there is a few days left in the deliberation period <tusharhero>If I understand it correctly, Savannah is still the canonical repository right? <lynnn>hello. i have installed nyxt via guix install nyxt. i am on a native guix system. it tells me "Error in FFI method: the value is not type of GDK:GDK-EVENT when bending NYXT/RENDERER/GTK::EVENT". flatpak works fine. any ideas? <keinflue>I noticed that the current version of edk2-tools in guix has sources that can only be retrieved from the content-addressed mirrors instead of any upstream source provider (because of https://github.com/tianocore/edk2/issues/6398). The problem with that is that I was building with a modified store path, meaning that my output path hash differs from <keinflue>the "normal" one. Because the mirrors are addressed by the output path name instead of the fixed output hash, I then have no way of building that package. Is there any workaround or would it maybe be possible to add the fixed-output hash as content address? <ruther>'add the fixed-output hash as content address' the path hash is made from the output hash already for fixed output derivations. The thing is that the whole thing, including submodules, is packed as one path, that is why it's not substituted (what you call 'mirrors' I assume) <ruther>keinflue: I think the easiest solution would be to just change the source to use mirror url of the now non-existing repository <nomike>I'm packaging an application and have some issues with getting it to run. It builds fine, but I'm having issues at runtime. When there are compile-time issues, I can use the `--keep-failed` build flag so I can inspect the build-directory later on. As my build runs through now however, the build directory is gone after the build completes. My solution for now is to make the build fail intentionally during the check phase. It works, <nomike>but is there a more elegant way? <keinflue>ruther: I have substitutes disabled, what I mean is the fallback mechanism implemented in guix/build/download-nar.scm which (in the normal environment) produces in the log file: <keinflue>I do not see any connection with this hash to the fixed hash in the package definition and it is different in the build container where I changed /gnu/store to /gnu/store2. <ruther>keinflue: to see the connection, you would have to read how the output path hash is generated. You're right that what it's calculated from includes /gnu/store as well, so the hashes are different based on the location of the store. <keinflue>ruther: Is is also affected by the source derivation itself beyond the fixed-output hash? If so, any changes made to the package source derivation, e.g. patching the submodule url, would also change that hash and make it impossible to fetch from the mirror. That's basically my question: Why the address is not just the fixed-output hash? <ruther>you're still using the word mirror, what does that mean? Do you mean substitute? <keinflue>nomike: I'd also like a function to keep the build directory on success. I don't know of a better solution either. <ruther>keinflue: I don't think .gitmodules is kept in the resulting output, meaning, change in submodule url doesn't affect the output path <keinflue>> Trying content-addressed mirror at bordeaux.guix.gnu.org... <ruther>keinflue: okay I think I was wrong, according to nix docs the path of FOD should depend only on name and outputHash. As far as I know Guix hasn't changed how the hash is calculated at all. So what you're seeing is strange. The paths should match. <keinflue>@ruther: ok, thanks, then I will investigate where the different hash comes from <cobra>yeah i tested it, adding --enable-visualizer to #:configure-flags and fftw to inputs of ncmpcpp works <cobra>making patches is scary though <cobra>well i was moreso asking anyone else <Tadhgmister>I can't imagine they will ever intend to fully remove their own hosted copy of it but they may more heavily rely on mirrors <tusharhero>Read GCD 2, they are moving to Codeberg because the Savannah and Guix infrastructure is getting too expensive to maintain. <Tadhgmister>and where do I read GCD 2 I am not familiar with that <tusharhero>The git repositories and development will move to codeberg. <AwesomeAdam54321>tusharhero: I don't think it's really the infrastructure itself that's too expensive too maintain, but that the current contribution workflow has its flaws <Tadhgmister>ok I see they are moving the contributing and development handling to codeburg, that does make sense <luca>I think debbugs is ran by GNU, not guix. (though issues.guix.gnu.org is guix) <tusharhero>Sure. I think they talk about how maintaining their custom tools with debbugs and stuff was getting tiring. <keinflue>content-addressing, which means that the same fixed output can't be addressed when a different store path is configured. <keinflue>But it is only the store path, name and fixed-output hash, not any other source derivation detail as I feared. <ruther>> For fixed-output derivations, on the other hand, the name of the output path only depends on the outputHash* and name attributes, while all other attributes are ignored for the purpose of computing the output path. <ruther>keinflue: my guess would be that this was an oversight - that it will affect FOD as well. And it's expensive to change something like this <keinflue>It has been there since the first commit. Even if it is an oversight for FOD, what is the rationale to have it mixed in at all? <ruther>because for non-FOD derivations they commonly do refer to other store paths, and you cannot bear the possibility that the paths will be the same across different store locations <keinflue>But in any case, modifying the store path is probably a very uncommon thing to do, so I guess my request to add a store-independent address to the mirrors/substitute servers is probably unreasonable. <keinflue>ruther: If anything in the derivation already refers to something from the store, then the hash of the derivation should already differ, no? And if it doesn't, then it should be impossible to introduce a dependence on the store path other than that the build looks at the store path of its output specifically, right? <ruther>keinflue: I think that currently the substitutes work in a way where you basically just expose the files under /gnu/store, and that the clients are finding them on those paths. So it would probably be quite a complicated change in the first place <ieure>nomike, What's in your build environment that you need to determine your runtime problem? I've always been able to resolve those issues with the output only. <ieure>nomike, An idea (I've never tried this) if you really need the build environment is to copy the whole thing to a second package output. <ruther>keinflue: I am not 100 % sure about that. I agree that normal derivations work like that, but I am not sure if all have to. Typically you have at least the output path in drv, which has the full path in there, and then the argument is fine. But if this is a requirement to make an output path, I am not 100 % sure. <nomike>ieure, I think my whole workflow could need some overhaul. I have a local clone of the guix repo. In there, I made a copy of the package definition for openscad and named it "openscad-nightly". I then run a `guix shell` and in that shell I'm running `guix build` to build the package. I'm on Ubuntu foreign distro. <nomike>Is there a way to add the package from that local clone into my guix-home? Or should I `guix install` it somehow? What's the best aproach here? <ruther>nomike: there is a way, but why are you doing it like that in the first place? Why put it to guix channel? <nomike>I want to submit this as a patch to guix to have it inclused upstream and I was told it is best to operate directly in the guix repo for that. <ruther>nomike: yes it is, but you don't have to install it from there, you can just install it from your own home config / home modules until it's upstreamed, it's the easiest way <ruther>nomike: if you really wanted, you can just guix install with pre-inst-env, if you want to put it to home, the easiest is probably to just pull out of the local repository <nomike>Ahhh...you mean with `guix pull --url=file:///home/nomike/coding/guix --branch=branchname`, right? <ruther>nomike: I am not sure if that branch is needed here, but yeah, I had that url in mind <nomike>Now that you mentioned this, it feels kind of like it should have been obvious to me ;-)... <PotentialUser-16>is it possible to set up a substitute server so that when i try to install a package that doesn't have a substitute already built it requests for the server to build it and waits for it to finish? <ieure>It's not a substitute server (it can *also* be a substitute server if you like), but it does the exact thing you're asking for. <menace>hey, there's an accelerator for java gui packages in nixos. is this also needed for guix? I did not see java gui programs like jedit or mediathekview so i did not know how to test this <ieure>menace, Can you be more specific? What's the package's name? What does it accelerate? <yul>Hi, I'm interested in updating a package and I think I've confused myself reading the guix manual. Is there a particular portion of the manual that shows how to build a package locally? I'm aware of `guix build -f foo.scm` but I don't think I'm invoking it correctly. If the scm file defines multiple packages how would I specify which one is the target of the build? <ruther>yul: -f builds what the file returns, you cannot choose what package to build with it <ruther>yul: usually you make modules and you add where you have your modules to a load path, then you can just use specifications <ruther>yul: ie. guix build -L path/to/modules my-package-name <ruther>if you're working in the guix channel, then you should use pre-inst-env instead though <yul>ruther: I'll read through that, thanks! I think I'm working in the guix channel, I have a clone of the guix repo and I'm trying to build the existing version of the package before I mess with it. my understanding was that `pre-inst-env` was for bootstrapping a system without guix installed previously. I'm doing all of this in a vm with guix system as the OS, if that matters <ruther>yul: no, pre-inst-env is not for bootstrapping a system without guix installed. pre-inst-env is for using guix out of a checkout <ruther>yul: this is because the channels are encoded in the guix executable, so you cannot use the normal executable you use with `guix`, pre-inst-env gives you correct executable with correct environment to use the checkout <yul>ruther: I think I understand. should I be using `guix shell` or `guix environment` beforehand? I did see somewhere in the manual that I should build in a container with `guix -CPW` but I think that was related to building guix itself and not a single package. <ruther>yul: definitely, you should be at least in a pure shell. Doesn't have to be a container <ruther>if you aren't, you're risking system/user guix environment is going to be picked up <yul>ruther: I think a gap in my understanding was that I hadn't run `make` yet either, I thought I could use the previously installed version of guix to build local packages with. I'm having that chug along for now and I'll see it goes after it's finished. thanks for the help <ruther>yul: you don't have to run make, as long as you're in a pure/container shell, the scm files will be picked up. If you run make, evaluations will be faster afterwards <menace>ieure, tbh i forgot it, because i saw this a while ago. let me check <mghackerlady>I was wondering, is there any reason we aren't on the latest GNOME version? <ekaitz>mghackerlady: probably lack of time, contributors, and reviews <mghackerlady>I was looking at the package definition and it doesn't seem like it would be too hard to update the version from 46 to 48, but I'm very new to this whole guix thing so I don't know if it'd really be that easy or how to go about modifying and installing it if it were <yul>ruther: I found the source of my issue there, I had run `guix shell --pure` instead of `guix shell -D guix --pure` so I was getting errors confusing the guix directory in the repo's directory with the binary I wanted to run. I got the "hello" package to build locally now, so I'm going to move onto the package I was originally interested in. <ngz>mghackerlady: There are many packages to update and verify. There’s an ongoing effort to bump Gnome to its latest release by the Gnome team. You may want to get in touch with them if you’re interested in giving a hand. <mghackerlady>Alright! I'm very much a newb and if theres already an effort I think I'll let the experts do their thing, I'd just get in the way haha. I don't care too much about GNOME being on the latest version, it's just that theres a few features added in 47 and 48 that I'd like to have lol <Wurt>Hi, is there a way to test a Guix system service without reconfiguring the system? I have already defined a <service-type> but I do not know how to proceed, with home services it is easier because I do not need to reboot the system (although I think I am using a hammer to crack a nut). <ruther>Wurt: you can use system vm or system container <Wurt>ruther, thanks. I will try it. <identity>Wurt: you also don't need to reboot, depending on the service. you should be able to just (re)start the service with herd after reconfiguring <mghackerlady>Also, why does guix take so long to do a guix pull? I don't really care that it takes a while, I'm just curious as to what it is doing <identity>mghackerlady: pull a Big repo, verify all commits. it should be faster after the first pull, as the repo is cached <mghackerlady>Ah, OK :) Again, I'm very much new to guix I hope I'm not annoying lol <ruther>apart from that it also builds the guix modules in case you're unlucky and the latest commit hasn't been built by substitute servers yet <identity>mghackerlady: if the manual does not answer your question (or you simply could not find the answer), this is the place to ask <mghackerlady>Alright! I've flipped through the manual a few times so I know most of what it covers. I've gone through phases of wanting to use guix, getting annoyed with something and leaving guix, and wanting to use guix again a few times now but this time I'm actually trying to learn how things work instead of getting confused lol <auk>I do think it would be nice for the guix repo to be split in two or three: the guix tooling, the a core packageset, and the full packageset <auk>trying to pull guix on a small vm with limited disk space can somtimes just fail <auk>Also, question about guix's `make-gcc-toolchain` function: what gcc-glibc combos are generally supported? (how far back in time for glibc?) <auk>not sure about licensing on RHEL's gcc-toolset-N patches. Altho since the patches are mostly against GNU code, i imagine GPL would extend itself to the patches? <ruther>auk: I don't think much care is taken to support multiple glibc versions, so it will probably depend on when breaking changes were introduced. There is just one glibc packaged in guix channel. <ruther>auk: as for gcc, see the (gnu packages commencement), support is all major versions down to 4.8 at least, maybe more will work <auk>ruther, i imagine i could pull historical glibc versions from the guix repo history, and try to apply the devtoolset patches against them? (and of course package old versions of glibc myself if they completely predate guix) <ruther>There are sometimes patches to the gcc packages to support newer glibc version, maybe these patches can break support of older glibc, I can't really say. <auk>would that theoretically be on the right track? <ruther>auk: sure, if you're fine with going to earlier guic commits, then any version that was in Guix is supported <auk>ruther, aye thanks! good to know <auk>so afaik guix is generally a rolling distro, and only provides latest versions of packages at a given time, but: would packaging a select sequence of older versions of glibc potentially be something that would be accepted into the repo? <auk>this is assuming that compatibility issues are worked out <auk>i know guix already does some frozen-in-place packaging of deps for the full-source bootstrapping stuff <auk>OTOH, the devtoolset patches are structured around backporting gcc etc to old distro versions