IRC channel logs
2026-10-02.log
back to list of logs
<junypyr>@ryanprior great, thanks! i did see ganeti on the service list, but looked more complicated than i needed (don't need redundancy, auto vm allocation, etc). tho since it's already there i'll give it a shot. thanks! <ham5urg>how do you handle secrets in your dotfiles not reaching the store? <Darelelve>Hello everyone! I have a question regarding GNU/Hurd. There was some past discussion about using the unionfs translator—specifically its "stow" mode—in conjunction with the Guix package manager. Are there any current ideas on this? A proposal is currently being discussed to add an overlayfs translator to GNU/Hurd. <Darelelve>It might be worth adding a "stow" mode (or an equivalent) to overlayfs if that would be beneficial for Guix. <untrusem>adanska: hey I was trying to import your gpg key to encrypt a mail but it doesn't include disroot mail yet <adanska>untrusem, my email is adanskana@gmail.com, im not quite sure what you mean... <adanska>i dont use or check my disroot mail account unless i am using it as a recovery address <JackTheRipper>Hi. Is there a way for guix to manage my symlinks without importing them to the store first? Currently I'm using the `home-dotfiles-service-type` to replace stow and put my dotfiles into correct places using symlinks. But the thing is whenever I want to edit one of my config files, I need to first edit it in my guix home config directory and then <JackTheRipper>do a `guix home reconfigure` to install them again and have my edits effective. This is because guix home doesn't symlink my dotfiles directly to their destinations, instead it copies them into the store and then symlinks the content of `.config` folder into that path into the store, which should not be written to by normal users. This adds the <JackTheRipper>extra step of home reconfigure, and I don't want to do that cause it's slow and often results in package upgrades and downloads. <JackTheRipper>I want a guix method to symlink my dotfiles directly into their real place so that I can just do: `vim .bashrc` and be done with it. <JackTheRipper>I used to use gnu stow but I prefer to ditch it in favor of guix <JackTheRipper>I also tried the symlink manager service type but it also copies the files into the store first and then links them. So same problem. <untrusem>if you use home you will need to reconfigure to take effect <jlicht>is there any particular reason guix's autotools machinery pins a version of gettext from 2014? ("being boostrappable"?) <JackTheRipper>untrusem, Yeah I get it. I don't have a problem with running an extra command. My problem is guix home adopts my dotfiles into the store and then links them into xdg config home. I want it to link my `~/guix-config/dots` folder directly into `.config` and be done with it. Maybe I need to write my own function/service type? <lechner>Hi, what's a suitable home service to manage random files in ~/.config, please? <lechner>JackTheRipper: Thanks! Do you have an example, please? <JackTheRipper>lechner, create the `dotfiles` directory adjacent to your guix home config file. Anything you put in that, guix home will symlink to your home folder. So if you have a `.config` folder in `dotfiles`, guix home will symlink the contents of `dotfiles/.config` into `~/.config`. So `dotfiles` basically resembles your home folder and anything you put <JackTheRipper>in it, will be symlinked to your home with the exact hierarchy. <JackTheRipper>lechner, But the thing is, guix home will first import your dotfiles into the store and then link them into your home folder. This means in order to edit one of your dotfiles, you need to first edit it in `dotfiles` and then do a guix home reconfigure so that your modified files could be installed into their destination, adding an extra step to <JackTheRipper>your config modification. If you don't like this behavior, just use gnu stow instead. <lechner>JackTheRipper: Thanks! Will you please paste that again with a longer expiration? <lechner>JackTheRipper: Strange, it worked the second time around. <JackTheRipper>lechner, the example I gave is from guix's own documentation. Under `Essential Home Services` you can find it. <lechner>JackTheRipper: I tried to read the documentation for Guix Home but was probably looking in the wrong place. <JackTheRipper>lechner, You're welcome. Always check the info manual first, then search for service types using `guix system search` and `guix home search`, and if you couldn't find what you want, then ask a question. <JackTheRipper>lechner, Searching for service types is very crucial because some of them are not documented, or have less than sufficient documentation. Example: `home-xdg-mime-applications-service-type`. <JackTheRipper>There's no mention of it in the docs, but it's there and usable. <lechner>Hi, may I use the home-dotfiles-service-type twice for two different folders? <jlicht>apteryx: is safe-clone "supposed" to be able to get stuck in a futex_do_wait in the child? <Sneed1911>lechner: iirc calling the home-dotfiles-service-type twice will overwrite the first. But what you can do is source from two folders within the same home-dotfiles-configuration. Ideally both folders are using the same plain or stow layout, but you can get around it by how you call directories within configuration. <jlicht>as in, known shortcoming, or Fun bug :-)? <lechner>Sneed1911 / I have two destinations: One is for .config files in my home folder. Another is for "away" files outside my home folder, which are accessible even when my encrypted home folder is not mounted. <lechner>In particular, my Guile-PAM configuration, which mounts my home folder. <Sneed1911>I'm not sure guix home would be able to handle folders outside of your home directory unless your away folder is first mounted in your home. <Sneed1911>fwiw in the example I posted, the dotfiles folder/repo is arranged in the stow layout, and the emacs folder/repo is arranged in the plain layout (~/.emacs.d/...). For the configuration I assume everything is in the plain layout and explicitly call each dotfiles "package" as if it were its own separate folder in the plain layout - hopefully this makes sense and gives you somewhere to go. <lechner>Sneed1911 / Where does your "rice" emacs config end up after you run Guix Home, please? Also, why do you list all the "dotfiles" folders separate? Is it because you need the "excluded" parameter in each one because they are all separate Git repos? <Sneed1911>Two repos total, ~/Projects/rice/emacs and ~/Projects/rice/dootfiles. Emacs is arranged in the "plain" layout: ~/Projects/rice/emacs/.emacs.d/... dotfiles are arranged in a stow layout: ~/Projects/rice/dootfiles/alacritty/.config/... etc. I could not find a way to mix and match stow and plain layouts, so I use the default plain and then trick the configuration to assume each dotfiles package is its own folder, when in reality it is all <apteryx>jlicht: new use case, or some regression? safe-clone only does two things IIRC, to try ensure Guile does not use multiple threads at the time the child process forks <jlicht>apteryx: I see it as part of the "safe-clone and unshare succeeds" test, when run with -j32 <apteryx>could someone please try 'guix build openjdk@11 -S', then 'guix build openjdk@11 -S --check' ? <sneek>Welcome back apteryx, you have 1 message! <jlicht>apteryx: wrt the jdk stuff: successfully built /gnu/store/wvkr89anx47jxgxnshpyg77wclz0p91v-openjdk-11.0.22.tar.zst.drv successfully built /gnu/store/wvkr89anx47jxgxnshpyg77wclz0p91v-openjdk-11.0.22.tar.zst.drv /gnu/store/9wi4cphwp7l40hn6msj8br6796y37746-openjdk-11.0.22.tar.zst <jlicht>sorry for the paste in channel, thought it was shorter <apteryx>jlicht: thanks! so I must have messed something here, ah <apteryx>was trying to test building jdk11 with itself <apteryx>to see if the frequent crash at build time has anything to do with the bootstrap jdk or not <apteryx>7690 suggests safe-clone no longer works with recent guile, some guile internal changed and broke it, reepca did a good analysis <jlicht>ah I just found a "fun" other way to see the same breakage? Good to know <apteryx>and I agree with the conclusion that at this point it'd be nice to avoid these kind of hacks and have some API on the Guile side to accomodate such use case <gkoebel-ext>I'm trying to build BMDA from https://codeberg.org/blackmagic-debug/blackmagic on GUIX System. Runnning into an issue with depedencies specificall libusb1 which is not magically compatible with the libusb package. I'm not sure if this is a case where I should just symlink the GUIX package to the name the build system is looking for or not? <gkoebel-ext>I think this is actually a build system assumption that doesn't hold in GUIX cause libusb does install as libusb-1.0 which appears to be what meson should be looking for. <gkoebel-ext>oki so it appears what I'm missing is a valid .pc file for libusb <t3kkm0tt>So I have an issue. I was following the docs and when I installed something (as a test for guix-daemon), it succeeded. However, the command `guix-daemon` doesn't exist. <gkoebel-ext>re: pc files, so the libusb-1.0.pc file does exist. pkg-config seems to be confused by the symlinking guix does perhaps? <gkoebel-ext>yeah it seems to be using a non-existent store directory <gkoebel-ext>iirc the store changes on every package install right? So pkgconfig probably gets its store directory on install which then becomes invalid at somepoint <skullcap>Sorry if this info is somewhere obvious but can someone tell me the idiomatic way to serialize an unset (maybe I should be doing '()?) value to a structural placeholder like '{}'? I'm trying to create a service configuration file for something that needs to serialize to yaml but is expecting 1. the field name to exist and 2. it to have some <sneek>Welcome back skullcap, you have 1 message! <sneek>skullcap, ieure says: That is not how it works. <lechner>gkoebel-ext / PKG_CONFIG_PATH is also what I use <t3kkm0tt>do you guys recommend guix-system or should I just use guix on top of my arch installation? <Air4x>Hi everybody, do any of you have an example on how to manage guix containers as services? <Sneed1911>t3kkm0tt: I would start with guix on top of arch to see if it is something you like. I still have an arch computer running guix home, works great. It won't be negative learning, should you go guix system in the future everything will translate over smoothly. <t3kkm0tt>Sneed1911 yeah, I'm just struggling because the documentation is ... not very understandable <t3kkm0tt>Sneed1911 for example, I am unsure if I should install guix for the root account or for my user account. <Sneed1911>While the documentation has a number of foreign distro specific things, I'll agree that the line between guix system and guix on a foreign distro isn't always clear. Since you've got systemd you should opt for guix-daemon as a non-root user, the install script should default to this. <gkoebel-ext>t3kkm0tt: Something to consider about GUIX System is that some (not most but some) software makes file structure assumptions that will not translate. These are not dealbreakers but at least for me were part of the learning curve (i.e. earlier today learning that pkg-config makes assumptions that don't work with GUIX stores) <gkoebel-ext>rustup is another example. It can't be run on a GUIX System without some of the containerization stuff GUIX does due to rustup making assumptions about your file structure. <t3kkm0tt>gkoebel-ext i think i'm not gonna use rustup though <gkoebel-ext>but yes cargo and rustc seem to install fine without rustup <dariqq>gkoebel-ext: what is your issue with pkg-config? <gkoebel-ext>dariqq: I fixed it now. pkg-config was looking for .pc files in a non-existent GUIX store directory. I set PKG_CONFIG_PATH to point to my .guix-profile directory instead. <gkoebel-ext>it defaulted to /gnu/store/LONG_ID_HERE-pkg-config-0.29.2/share/pkgconfig <dariqq>gkoebel-ext: You need to have pkg-config (or pkgconf) and the package you want to use in the same profile (both installed, or the same guix shell, ...) and then PKG_CONFIG_PATH will be set to the appropriate path(s) automatically <gkoebel-ext>dariqq: with my understanding of how GUIX System works and my usage it should be impossible for me not to have pkg-config and the packages installed in the same profile. It certainly did not auto-update tho <gkoebel-ext>there's only one user on this system and its installed every package. <gkoebel-ext>specifically today when I discovered this problem it was `guix install pkg-config` and like 5 minutes later `guix install libusb` <dariqq>if you use guix install you might need to restart your shell to make it pick up the new environment variables (guix should warn about this) <gkoebel-ext>Not only did I do that. I rebooted the machine (well powered it down because reboot is borked for unknown reasons) <user381>Here's a random idea that will never happen: replace pipes by communication files like in DTSS. <dariqq>gkoebel-ext "guix shell pkg-config libusb --pure --no-grafts -- pkg-config --cflags --libs libusb-1.0" works so you are doing something wrong <gkoebel-ext>well it does seem that my fix is only working in the shell that implemented it <gkoebel-ext>yeah it's still trying to point to a non-existent path <user381>Also: does anyone here have any news on how it is going with FSF / GNU Brazil with the Hyperbola / Parabola project? I really hope the best for it. <gkoebel-ext>I thought I had done the GUIX_PROFILE paths but maybe I messed up. One moment. <gkoebel-ext>dariqq: you're referring to the " GUIX_PROFILE="/home/gkoebel/.guix-profile" <gkoebel-ext>had to switch to bash to run that properly. I did not catch it failed in fish the first time <gkoebel-ext>well now the pkg-config is using a existing path but still can't find packages. Tried reinstalling libusb. I take it that envvar message isn't sticky and needs to run every `guix install`? <dariqq>Does .guix-profile/etc/profile contain an entry for PKG_CONFIG_PATH? <dariqq>(i am not a fish user so that could be an issue with fish) <dariqq>this should get sourced and set up everything, I am not sure why this is not done for you <gkoebel-ext>probably because that hint from guix install doesn't translate to fish. <dariqq>gkoebel-ext: yre you on guix system or something else? <vagrantc>is it possible to keep the git history on a checkout? I need to generate patches from a git history, and then apply them to a package. building directly from git maybe not appropriate due to FSDG may contain some inappropriate bits... <gkoebel-ext>so why does guix install/remove always put that hint about environment variables when the listed command will just set then remove that variable? Is it supposed to be in some pre-install hook somewhere? <vagrantc>it sets up your login environment to set them properly, but unless you log out and back in, they won't be applied to the current session <vagrantc>you need to set them if you want them to be relevent in the current session <dariqq>it cannot be a in a hook because it is needed to update the current shell environment which a subprocess cannot change. The message is saying that if you dont want to reopen your shell you need to set it manually. But in a new shell it should all be done by the shell startup files <gkoebel-ext>ah gotcha now. I forget that this is sourcing the profile scripts <gkoebel-ext>Yet, it still seems pointless since I already get new commands in my current shell without running that... <dariqq>why the last part is not happening for you, I dont know <gkoebel-ext>at any rate that appears not to be the pkg-config issue. <vagrantc>gkoebel-ext: if you started with a fresh install, you wouldn't get the new commands because your PATH would not include it at all <gkoebel-ext>vagrantc: A fresh install... of GUIX System? On every guix install? <vagrantc>gkoebel-ext: a newly created user, the first install of guix ... e.g. the first time you run "guix install SOMEPACKAGE" <gkoebel-ext>Well I can prove myself wrong. If I had something to install that I don't already have <vagrantc>you're only half reading what i am saying <vagrantc>if your path already includes the place where the "new" thing will be installed, then it will show up, sure. <vagrantc>but if you create a new user, add something to that user's profile, it will not have set the PATH yet. <gkoebel-ext>every user gets a bin directory in their profile though so they would already get most commands <gkoebel-ext>I'm not aware of many linux utilities that decide to use arbitrary folders <vagrantc>before you have created a user profile, then it is not yet in PATH <gkoebel-ext>before you have created a user profile nothing about that user exists <vagrantc>just create a new user, log in as that user, and echo $PATH <gkoebel-ext>I'm not arguing I'm replying based on my knowledge of linux based systems <gkoebel-ext>iirc adding a guix user is a reconfigure not just `adduser`? <dariqq>i think PATH might be set automatically in /etc/profile <vagrantc>the PATH in guix is set a little more dynamically than in most distributions, partly because each user has their own independent profile <gkoebel-ext>default path for a new user is: /run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin <lechner>like vagrantc said, there is nothing in the user profile <lechner>I just skimmed past messages. what is not working for you? <gkoebel-ext>trying to figure out why pkg-config is using a nonexistent location for its path <lechner>didn't I already confirm to you that you have to use PKG_CONFIG_PATH? <gkoebel-ext>and then we went down a tangent of why the guix install/remove hint about env vars also doesn't stick. Which lead to "well things won't be in your path after install unless you run that" which is not true for most programs since they install to bin <gkoebel-ext>as well apparently the pkg-config path "should" auto-update itself <lechner>for users or to build packages in a recipe? <gkoebel-ext>The result of that is what I'm told should auto-update <vagrantc>i think we were answering your tangential question about PATH <gkoebel-ext>13:53 dariqq gkoebel-ext: You need to have pkg-config (or pkgconf) and the package you want to use in the same profile (both installed, or the same guix shell, ...) and then PKG_CONFIG_PATH will be set to the appropriate path(s) automatically <lechner>yeah, i'm not sure about that. it definitely is not set when I build my packages with build -f (but without -D) <gkoebel-ext>anyway the sticky fix for a fish shell is `set -Ux PKG_CONFIG_PATH YOUR_CORRECT_PATH_HERE` <vagrantc>that's going to change whenever you run "guix pull" ... not sure you will want to hard-code those paths in fish shell <gkoebel-ext>afaik the symlink gets replaced by a new symlink to the updated profile. <gkoebel-ext>which iirf is the reason KDE plasma doesn't update app lists since its looking at the symlinked cache file <vagrantc>well, whenevert you run "guix pull" followed by "guix upgrade" or "guix install" or "guix remove" ... or a handful of other options <vagrantc>yes, the files in your ~/.guix-profile and/or ~/.guix-home and ~/.config/guix/current all change <vagrantc>as long as it is showing the path to the symlinks ... but if it shows the paths to things in /gnu/store you could have troubles <gkoebel-ext>that was the issue before. pkg-config defaults to using the path that will always change <mbakke>something is off with my emacs font after reconfigure. Did something change in the past month? <mbakke>why is /etc/guix not world-readable? <untrusem>mbakke: we got emacs 31 in the last month <mbakke>right, apparently I'm on emacs 32 now (using -next-pgtk) <sham1>mbakke: Sensitive information, probably <mbakke>sham1: I needed to access /etc/guix/signing-key.pub on a machine so I could "guix copy" from it, but /etc/guix was not readable :(