IRC channel logs
2026-07-15.log
back to list of logs
<ryanprior>If package "complete" depends on package "autogen," and "autogen" in turn depends on "complete," don't you need to have a separate package to break the loop? If I add it as a transformed dependency like you suggest, doesn't that create a cycle? <pathera>Im trying to manually install and after changing my config.scm im getting an error which fully reads. "ice-9/eval.scm:142:16: In procedure compile-top-call: error: users: unbound variable" and it gives the hint did you forget a use-module form. whats the way to go from here because ive tried to add a module for ice-9 eval and it couldnt find one. Im also looking at trying to add the <pathera>linux-libre-hardened kernel but i couldnt find it as a guix package is there a module or package i can use to change to this kernel. <czan>Can you put your config.scm in a paste so we can try to help you debug this? I don't know anything about the hardened kernel, sorry. <pathera>thats fine i didnt see any support for it officiallyy when i tried the graphical install (also i apologise if the config is a mess i stitched it together out of the given example and some other templates i found) i dont know of a way i can directly paste it with it being in the iso but ill type it up so i can paste it over <czan>You might be able to paste things with curl like: curl -F file=@/mnt/etc/config.scm https://0x0.st (based on a quick search of the internet). <pathera>my fault i typed the top one out wrong <pathera>i also removed the comments to make my typing up quicker sorry if its harder to read it follows the same layout as the original found under 11.2 in the manual <czan>Your keyboard-layout line is missing a ) at the end. As is your bootloader, mapped-devices, filesystems (missing two). And your supplementary-groups has an unterminated string. I'm hoping these are all typos... <czan>It does make it hard to help, though, because I expect your initial issue was a misplaced ), but I don't trust that these )s match your actual file. :) <krisbalintona>Should I use the `guix style` subcommand for my personal Guile scripts/projects? Sometimes I see it make questionable changes (at least, to my elisp-trained eyes) <czan>I don't use guix style on my personal stuff. I don't think there's a moral angle either way. If you like it, use it, and if you don't, don't. :) <pathera>i did abbreviate alot to try and speed up the process.. i do appologise and yes these are all typos but is there any other things that you think could be wrong with this thats causing such an error? <czan>pathera: My guess is that you have too many )s at the end of "filesystems", which is leading the (users ...) bit to be parsed as a procedure call rather than a field on the operating-system. Without the precise file you're working with I can't say for sure, though. <pathera>i think that was the fix i messed around in there a bit and it moved the issue to services which im just fixing now :) thanks for the help <ngz>Hello. I’m still struggling with worktrees. I try to push a team branch upstream, but I get a strange error after "Compiling Scheme modules..." message: "./pre-inst-env: 61: exec: /home/ngz/.guix-profile/bin/guile: not found". The strange thing is guile is actually located in .guix-home, not .guix-profile. I don’t know where the latter is coming from. <ngz>I successfully ran "guix shell -CPW ; ./bootstrap ; ./configure ; make -j4" beforehand from the worktree. <ngz>Ah, guile is in .guix-profile when in the guix shell container. But I’m pushing from outside the container… <joe>it's updating Maak (the Guile Scheme command runner a la Make) with a lot of new features and fixes <ngz>Interistingly, I can push from master, but not from the worktree. <jlicht>maak seems cool! anyone using it to manage their guix configuration rollout? <Deltafire>i've found a bug in mutter 48.7 (current version in guix); however it may have been fixed in later versions (49 & 50) <jlicht>joe: thanks! I'd really like to explore using the guile API for using guix from something like maak at some point <Deltafire>it's not easy to test however; and i don't want to file a bug report for something that may no longer be an issue <krisbalintona>jlicht: I'm now using Maak after discovering it a few days. I replaced my kind of complex Makefile (which I used to manage my Guix configs) with it <krisbalintona>joe: fyi I'm the one who's been making those issues on the Maak repo recently :) <jlicht>krisbalintona: are you using shell invocations ($), or using the guile api directly? <krisbalintona>jlicht: I'm not done yet, but Guile modules and objects directly. For instance, I could call guix home reconfigure on the file that evaluates to my home-environment, or I could just import that module and reference the home-environment object directly (or even something like "(@(path to home file) home-environment)") <jlicht>sounds lovely (only issue is that it probably doesn't compose well with guix time machines, or at least I don't see how that could/would work <untrusem>I have seen people using blue as a runner too <jlicht>krisbalintona: how to eval things "in" the time-machine inferior. Packages have a solution, but AFAIK we have none for e.g. an entire home-environment. Or would you somehow invoke maak from within the time machine? <krisbalintona>jlicht: Couldn't you just do "guix time-machine -C ... -- shell -- maak ..."? Or have I misunderstood <krisbalintona>jlicht: You could also run the maak process itself in a guix time-machine shell invocation <podiki>anyone else suddenly getting every pr notification? <gabber>not currently and not every, but PR notification preferences seem to be reset from time to time <gabber>i think my last reset was ~2w ago <krisbalintona>How do people keep track of the issues and PRs made in the Guix repo? Just through Codeberg notifications? <gabber>krisbalintona: you can pin the ones you want to prevail <podiki>or i guess be me right now and get every one.... <gabber>podiki: shouldn't be too hard to untick (or re-tick or whatever it was) the right box in your config <podiki>i'm trying "unwatch" on the guix repo <podiki>i think that did it, hopefully back to just getting what i'm pinged on <evohunz>Hi! Can someone please help me understand why 'chicken' package is bound to gcc-toolchain @ 14.3 when there's a newer gcc-toolchain available (16.1)? I'm looking through the gnu/packages/chicken.scm file and I don't see any version pinned to gcc-toolchain. I want both packages in my home config, but they are conflicting. <gabber>ACTION crosses their fingers for podiki <ieure>evohunz, Because chicken inherits from chicken-bootstrap, which gcc-toolchain from (gnu packages commencement), which is 14.3. <ieure>And chicken-bootstrap propagates the older gcc-toolchain. <evohunz>My (gnu packages commencement) has gcc-toolchain 16.1 <evohunz>but then, why when I do `guix shell gcc-toolchain -- gcc --version` it's 16.1? <ieure>evohunz, Because "gcc-toolchain" is a package specifier which doesn't reference a specific version, so the latest available is used, which is 16.1. The chicken-bootstrap package references a Scheme symbol which is bound to specific version, which is 14.3. <gabber>evohunz: what ieure said. i used to be confused about the divergence of the (often equal) package name (string, which is parsed from the cli) and the symbol/variable name <ngz>I’m still struggling with a git worktree. I can push commits on master, but I cannot on the worktree, where it fails with the error "./pre-inst-env: 61: exec: /home/ngz/.guix-profile/bin/guile: not found". I already ./configure’d and compiled from the worktree. Do you have any idea about what could be wrong? Note: guile is actually in .guix-home <ngz>(when outside of guix shell) <evohunz>I assume there's a reason for the symbol to stay at 14 to avoid breaking other packages. Chicken can be built using 16 though, changing it to 'gcc-toolchain-16 works for me locally, but if it propagates it, that doesn't seem correct. Any way I can override that dependency in my home config? <evohunz>ngz: I think the pre-inst-env script is generated, at the very top it has the guix checkout path. You probably need to tinker with it to reflect the worktree path <ngz>In the past, i.e., a couple of months ago, I could use worktrees just fine. Something broke up since then. <ieure>ngz, I set up a new worktree yesterday and it works fine. Are you running in a `guix shell -m manifest.scm --pure'? Did you `./bootstrap && ./configure'? in the worktree? <ngz>ieure: from the worktree, I use "guix shell -CPW", then "./bootstrap && ./configure $$ make -j4". The whole process completes without error. <ngz>err &&, not $$, obviously <ngz>From Magit, I call "git push -v --set-upstream origin tex-team\:refs/heads/tex-team" and it fails miserably. <ngz>evohunz: About your last question, you can use package transformations to replace an input even from a home config. <ieure>evohunz, I'm not sure why gcc-toolchain is propagated at all, I guess Chicken is using it to compile Scheme? <ieure>ngz, I don't know. It works for me. The only times I've seen the pre-inst-env script fail like that is when I'd generated it a while back and subsequently gc'd the store items it references. <ngz>ieure: but ./bootstrap should fix that issue, isn’t it ? <ieure>ngz, I note that you are not providing any dependencies within your shell, even if you want to use a container for some reason, I'd think you need to `guix shell -CPW -m manifest.scm' or `guix shell -CPW -D guix'. <ieure>ngz, But you *are* linking your profile, so likely what's happening is you're putting your user profile inside the container, but not exposing the store, so things like scheme point to nonexistent files. <ngz>Hmmm, but when I call git push, I do not use any special environment, so the pre-inst-env script must be called from some git hook. <ngz>Could the pre-push hook be misconfigured somehow? <ieure>ngz, What does the git hook have to do with anything? <ieure>ngz, The Git pre-push hooks do not use the pre-inst-env at all. <ngz>So where this pre-inst-env call is coming from? <ngz>I mean, "git push…" command is sent from a regular environment, not using ./pre-inst-env. I must be missing something obvious. <ieure>ngz, I see. I believe your problem is the use of a container which exposes your profile. If you `guix shell -m manifest.scm --pure' and re-./bootstrap, do things work how you expect? <evohunz>ieure: chicken compiles scheme to C, then uses a C compiler to produce the binary. so you need a C compiler to compile (not sure if the interpreted mode needs one though). maybe we should not propagate gcc-toolchain from chicken? some other packages doesn't propagate stuff that *may* be required for their complete runtime usage (e.g. gnupg doesn't propagate pinentry) <ieure>ngz, So I'm not sure why `git push' is invoking ./pre-inst-env, I've never observed this before, but with my workflow, it wouldn't matter either way. So either it was a recent change to the hooks, or perhaps you have some direnv or similar type stuff which is causing it to get run. <ieure>ngz, But the immediate failure mode is happening because you're running ./bootstrap inside a container, and your profile is exposed as ~/.guix-profile within there, so paths written to the bootstrap script have those paths in them. But they don't exist outside the container, so using the pre-inst-env breaks. <ngz>OK I’m using guix shell --pure and recompiling the worktree. We’ll see how it goes. Thanks. <evohunz>Tested locally changing propagated-inputs to native-inputs and `guix shell --container chicken', no gcc available. Interpreted mode works fine, trying to compile fails `gcc: command not found'. Is there a guideline whether that should be propagated or not? <ieure>evohunz, It's going to depend on several things. Ideally, chicken would reference the GCC stuff it needs, but not propagate it. For that to work, Chicken would need explicit store references for the gcc-toolchain it's built against. I do not know how reasonable it is to do that, or whether gcc-toolchain would work with that setup. <ieure>evohunz, The other alternative is a wrapper script around chicken's binaries, which set up its environment to point to the version of gcc-toolchain it's built against. Again, explicit paths here point to specific store items. <ieure>Generally, my feeling is: store paths in the package output > wrapper scripts > propagated-inputs. <evohunz>chicken compiler calls gcc via a shell script, I think it's fine if it uses the host gcc and not the same version it was compiled against <ieure>evohunz, Note that I said "reference the GCC stuff it needs," not "reference the GCC it was compiled against." I agree these are not necessarily the same thing. <ieure>evohunz, But the issue is that there may not be a "host gcc" at all. That's why it propagates gcc-toolchian, to ensure that a gcc exists for it to exec after installation. <evohunz>ieure: Parts of it works after installation (interpreted mode). To me it feels like that falls in the same region as gnupg not propagating pinentry (required to a subset of features, e.g. generating keys)? <ieure>evohunz, It is a judgment call, yes. And pinentry is not required to generate GPG keys. <evohunz>it complained when I tried without it, but I'm a complete noob regarding GPG, heh <evohunz>oddly, `guix shell -C chicken' gives gcc 14, `guix shell -C chicken gcc-toolchain' gives gcc 16 without complains. Same if I try a manifest only with chicken (14) and a manifest with chicken and gcc (16). But having both chicken and gcc-toolchain on my home config gives me an error. Is this only checked on profile? <qzdl>my first time seeing datefudge inside a derivation name <qzdl>'Starting download of /gnu/store/g0ha1fd0x299w48hfgs2sa1sl1b6vlnq-datefudge_1.23.tar.xz' <qzdl>oh nah ffs this is a normal source drv I'm just textually challenged <stephen0>Is there a guide somewhere covering adding a channel to the home configuration and then having that same home configuration use a package from that channel? The guix info page shows how to do it to the operating-system but I can't figure out how to adapt that. <ieure>stephen0, I would not recommend doing it this way. You have to add the channel to the configuration, then `guix home reconfigure', `guix pull', add the stuff from that channel to your configuration, and `guix home reconfigure' again. <ieure>There isn't really a usual way. <ieure>I moved all my channel configuration into operating-system. IMO this is the most sensible approach. <ieure>If you want substitutes, those can only be configured at the operating-system level. I think it's cleanest to configure channels globally in the operating-system. <jackhill>Anyone else seeing a hash mismatch on a boost patch? `sha256 hash mismatch for /gnu/store/chzch29xi2gzdxbzk77sb432klkddra1-boost-0001-unordered-fix-copy-assign.patch` <ieure>jackhill, I recall someone mentioning this in #guix a couple weeks back. <ryanprior>What's the delay between codeberg and git.guix.gnu.org? Is there a CI gate inbetween? <ieure>ryanprior, There is no delay, git.guix.gnu.org is a redirect to Codeberg. <kyoji>I am trying to make a package and have a few questions. This might take a few messages <ryanprior>Huh, I just did a git pull and got a commit from Jul 12. Wonder how that happened. <kyoji>1) using the guile repl, can i `,load "..."' the file containing the package code then `,build ...' it? <ryanprior>kyoji: are you asking "is it possible," or "is it the suggested packaging workflow" <ieure>kyoji, Yes, but if you're an Emacs user, Geiser is a little more convenient (C-c C-k to load the file into the REPL). <kyoji>2) I am using the trivial build system, but documentation seems a bit lacking. I just want to download a .tar file and extract it to a place in $HOME. Does anyone have any good examples? <ieure>kyoji, This is impossible, packages cannot extract to $HOME or anywhere else. They go into the store. <ryanprior>kyoji: wrt/ 2) in Guix packages you don't extract into HOME, you're always going to install into a location in the Guix store. The end-user of your package can then copy it or symlink it from there into their HOME <ryanprior>kyoji: ieure is correct that it's impossible, by normal standards anyway. You could patch Guix to make it possible but people would consider that a severe departure from normal platform expectations. <kyoji>ryanprior: ieure: ok that is good to know, i suspected that would be the case <kyoji>i will worry about moving it from the store for later <ieure>Yes, if you want to hard fork and write weirdware, there's nothing stopping you, but that's rarely the best approach. <kyoji>I am an emacs user but I also would like to just know how to use the REPL in general <ieure>kyoji, Have you used SLIME for Common Lisp, or CIDER for Clojure before? <ieure>kyoji, Geiser is very similar, but for Scheme. <ieure>kyoji, Set up Geiser, load a scheme file, C-c C-k will spawn a REPL (if needed) and load/compile the code into the inferior Scheme process. <kyoji>yes, it feels familiar, although I am by know means an expert with SLIME either <noxi>alright, I might need the help of someone smarter than me <kyoji>ieure: what about loading modules? <kyoji>hold on let me just do this, one second <noxi>why is it that `loginctl terminate-session` doesn't work? <ieure>kyoji, You're best off reading the Geiser manual. I know C-u C-c C-z will switch the REPL to the current file's module; not sure if there are thing to use an arbitrary module or load one by spec without opening the buffer. <ieure>kyoji, ,use (gnu packages whatever) is the REPL metacommand to use a module. <kyoji>ok, that brings me to my next question: I am attempting to use `(guix download ...)' in the build g-exp, but guile complains about no code loaded for module (gcrypt hash). If I grab that package from guix, the error persists, so I'm not sure if I need to somehow add the module to guile's path or something <ryanprior>kyoji: I'm not an expert on this so I have to look it up often, but I think gexps are run in their own closures which aren't directly connected to your repl context, so you have to explicitly state your imports inside the gexp. If it's the thing I'm thinking about, there'll be examples in the guix codebase of this. <kyoji>ryanprior: ohhhhh yes, that feel correct! something line `(with-loaded-modules ...)' or something like that <ieure>kyoji, Please tell me more about why you want (guix download) in the build gexp -- this sounds like something that likely will not work. <kyoji>ieure: that doesn't surprise me! I just want to download and extract a .tar file <kyoji>then run the contents in a guix container <ieure>kyoji, You cannot do that in a build step. Guix builds are isolated from the network. <kyoji>the container part is (technically) done, its the package part that is throwing me for a loop <kyoji>ieure: ah, well that would be a problem <ryanprior>kyoji: if you're trying to download something during a package build, that's another "impossible" process by normal Guix standards. Build processes are hermetic and have no network access. Whatever thing you want to fetch should be an input to the build, in which case Guix will download the object and put it into the store for you before the build starts, and then you'll get a path to that in your build process. <kyoji>ieure: so I will need to download to the store and pass the objects into the build process? <ieure>kyoji, Effectively, yes, but the way to accomplish that is with the origin and inputs to your package. The downloading happens automatically. <kyoji>ieure: I see, that makes sense. Does the `trivial-build-system' use the `(source ...)' object? i recall reading in the docs it is ingored <ieure>kyoji, No, it doesn't. copy-build-system is probably closer to what you want. <kyoji>this has given me enough to chew on <ieure>kyoji, I'm very curious why you're using a container inside the build process. <kyoji>I am running a binary and need --emulate-fhs <kyoji>it is non-free so don't want to discuss anymore than absolutely necessary <kyoji>(nor sure what the channel stance on that is) <ieure>kyoji, non-free stuff is off topic. <ieure>kyoji, There's #guix-offtopic or #nonguix. <ieure>jackhill, Did you see the comment civodul left? That should get you going. <jackhill>but anyway, I see also that a commit with a new hash has been added some hours ago. Maybe I haven't pulled recently enough. I'll try that and otherwise comment in Codeberg <vagrantc>ACTION suspects there will be at least three folks from the guix community at fossy ... maybe more? :) <samplet>I’m very glad they moved it to Canada – makes it much easier for me. <ieure>Oh, I thought it was in Portland, but that was last year. Ah well.