<lrabbt>hi, I sent a patch, but made an error and now I need to send a revised patch, the manual states I need to resend with "git send-email -1 -a --base=auto -v REVISION ...", what should REVISION be?
<finial>can i use zfs as the filesystem for guix boxes?
<sarg>finial: grepping for `zfs` in guix sources returns only the package. I'd say that it is not supported, assuming that booting from zfs requires pre-mount actions and is not as simple as adding an entry to fstab.
<mfg[m]>Yeah, it isn't supported. There was a patch set trying to get more of it to work (not sure if root on zfs would have been possible), but it stalled
<nutcase>Hi, I am running zsh via home-zsh-service-type and set '(shell (file-append zsh "/bin/zsh"))' for my user-account in my system config. Everything is fine, but when I run "guix shell <package>", my $PATH isn't extended and binaries of <package> can't be found unless I run 'export PATH=$GUIX_ENVIRONMENT/bin:$PATH'. I don't have that issue with bash. My question: Where does bash take the $PATH-extension from and how can I best fix that
<nutcase>mfg[m]: yes, thank you for your hint. Maybe you can identify the line(s) in /etc/profile or /etc/profile.d which look like the lines I am missing?
<evilsetg[m]>How would I uprgrade the guix checkout in /run/current-system/profile?
<mfg[m]>nutcase: Honestly i just looked on a guix system where i also use zsh at those files and i don't see anything special :|
<jpoiret>evilsetg[m]: you can but it's going to make your reconfigures costly
<jpoiret>basically, the guix in the system profile isn't generated by guix pull but by a regular package definition in (gnu packages package-management), which is updated only sporadically
<jpoiret>basically, it's the default guix that you get before having `guix pull`'d, so we only update that package when there are bug fixes or improvements that are relevant for people installing guix
<jpoiret>you can change the guix-service-configuration (i think that's the name) to have (guix (current-guix))
<jpoiret>this will basically use the `guix pull` machinery instead, on your own channels: the annoying thing is that this will create a new checkout of guix for the root user when you `sudo guix system reconfigure`
<jpoiret>in general though: you shouldn't need to do all of this, just use a single `guix pull`
<evilsetg[m]>jpoiret: Thank you for the info! I thought about trying this because guix package --export-man
<evilsetg[m]>guix package --export-manifest fails with an unbound variable error. And the only place where that variable is undbound is in my system guix.
<nutcase>mfg[m]: how does your $PATH variable in a guix shell look like?
<evilsetg[m]>At some point the python-pre-commit package was renamed to pre-commit. For some reason I think I am stuck between a gnu/packages/python-xyz.scm that expects the new pre-commit package and a gnu/packages/version-control.scm that still exports the old package.
<evilsetg[m]>Hmm, it seems it was not the system guix causing this.
<jpoiret>evilsetg[m]: no, this is a known issue :)
<mfg[m]>nutcase: sry, i was distracted. It looks just as you would expect. guix shell coreutils -> PATH=/gnu/store/cm0n98lz63g6pb17kdyv14dfwf5acijr-profile/bin:...
<nutcase>mfg[m]: thanks for checking. I added '[[ -z $GUIX_ENVIRONMENT ]] || export PATH=$GUIX_ENVIRONMENT/bin:$PATH' to my ~/.zprofile and I think that this is solved now, although I am still not sure, why this has to be added with zsh but not with bash
<mfg[m]>This seems to be right. I do think i also have set this somewhere but i can;t find it :'D
<jpoiret>usually the sub-shell's PATH is set by guix shell itself, since you can make child processes inherit env variables
<mfg[m]>okay, jpoiret certainly knows better than me :D
<jpoiret>so your zsh is bound to have a `export PATH=something` somewhere that doesn't extend PATH
<jpoiret>you should check your zshrc, that's likely the place where the offending instructions are
<nutcase>jpoiret: my zshrc doesn't touch PATH. I prepend my PATH from within my (home-environment) using (simple-service 'some-useful-env-vars-service home-environment-variables-service-type ...("PATH" . "$HOME/.local/bin:$PATH")) but this does extend $PATH indeed and is also used by bash.
<jpoiret>does `guix shell coreutils -- env` print an extended PATH?
<jpoiret>uhm, actually, if zprofile solves your guix shell issue, then that means that the shell started by `guix shell` is a login shell (!!!!)
<jpoiret>maybe you somehow include .zprofile in your .zshrc? i'm pretty stumped at this point
<nutcase> jpoiret: I see, that it looks like zsh looses the correct PATH definition at some point, although it was correct at some point before being thrown to the shell. Is it worth to try a blank zshrc ?
<nutcase>jpoiret: I just noticed that I have a (another than I edited before and which was ~/.zprofile) '.config/zsh/.zprofile' that links to '/gnu/store/wq3d4v9hf186k1yby3pk0fs0vh8048f6-zprofile'. That .zprofile sources /etc/profile and ~/.profile
<nutcase>and my ~/config/zsh/.zshrc sources ~/.config/zsh/.zprofile
<nutcase>so, I am quite lost in tracking which *profile files are sourced and why and which ones shouldn't get sourced.
<nutcase>jpoiret: after removing (service home-zsh-service-type) from my (home-environment), there is no ~/.config/zsh/.zprofile to include anymore and the path inside a guix shell is extended. I also don't have a ~/.zprofile anymore now.
<rekado>I just got a substitute for rust-ciborium-0.2 (I’m working on this right now) from ci.guix.gnu.org but … I don’t see any such package on master or core-updates.
<podiki[m]>well Guix doesn't fit FHS at all, so in that sense we don't "care" but not sure what you mean
<hwpplayer1>podiki[m]: I mean what if I dont run that feature
<podiki[m]>the fhs option for containers? definitely don't need to, personally I rarely use it as I luckily don't need to; if you mean how do you run stuff that might need fhs expectations, you can patchelf if it is a binary
<unfroq> I'm getting the following error after adding elogind to my system declaration: guix system: error: service 'file-system-/sys/fs/cgroup' provided more than once. I could use some advice on how to solve this. It's really annoying, since I don't know how to debug the error.
<efraim>rekado: I've been rebasing ontop of master. I'm still waiting on rust to build on aarch64. Right now I'm on mobile
<kani>hi :) I got a guix system running and I'm currently playing with my systemconfig.scm. So far I successfully added and configured wireguard. Now i'm trying to configure docker daemon
<kani>could somebody please give me a hint where to put /etc/docker/config.json so it gets picked up by the dockerd service after a restart?
<kani>or is there a best-practise where to put config files (/etc/bfoo) for a specific system service?
<kani>I noticed that other services e.g. nginx-service-type have a configuration option to supply a config file.. would it be nice to add sth. like that to docker-service-type?
<unfroq>kani: the docker-service-type seems to not have these arbitrary config injections. I would have a look at the env vars if I were you. And maybe you could have a look on configuring the your docker-cli in your user environment to use these flags. In the worst case, use an alias..
<Guest19>If I package a package that requires livudev, how is that handled since Guix does not have systemd?
<NewUser-Basic-Qu>Just because i saw your messages regarding greetd/wlgreet/seat/elogind . That is the background of my service-disable question. wlgreet allways autostarts on term-tty7 and is then in a initialization loop. some pam issue i have using seat as well as elogind
<jpoiret>NewUser-Basic-Qu: I think you can do #:auto-start? #f
<jpoiret>oops, seems i didn't see that past comment :p
<unfroq>jpoiret: Thanks, that worked. Now I know, why I included seatd in the first place, I get the following error with my greetd config: guix system: error: supplementary group 'seat' of user 'greeter' is undeclared. Does that mean, I need to add a second user and add the user to the seat group?
<unfroq>jpoiret: I had the line which NewUser-Basic-Qu posted in my config. I commented it and now it builds - without the need to add a user to a group. I will apply the config and test it now. Thank you very much!
<Guest19>My package produces a bin in build/bin but the guix package itself I defined do not have that bin dir. Why?