IRC channel logs


back to list of logs

<apteryx>evilsetg[m]: I think an issue with pre-commit was reported already
<apteryx>it causes a module cycle or something
<apteryx>evilsetg[m]: do you need anything special to trigger it in your manifest?
<apteryx>I think I have a fix
<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?
<lrabbt>it's a single commit patch
<apteryx>2 :-)
<apteryx>as in version 2
<lrabbt>ok, thank you :-)
<apteryx>evilsetg[m]: the pre-commit issue should be fixed
<apteryx>(run 'guix pull')
<lrabbt>I'm still finding it weird this git build/show problem wasn't happenning on your machine, apteryx, why is that?
<apteryx>I think it would have happened... I didn't try to reproduce it, just validated I couldn't see the problem after the fix
<podiki[m]>can someone try this manifest:
<helpful-friend>"debian Pastezone"
<lrabbt>oh, ok, good thing it's solved :-)
<podiki[m]>it is not actually doing the git transformation for me, thought it was some weird caching but I cleared out ~/.cache/guix and guile
<apteryx> may offer some clues
<podiki[m]>apteryx: nevermind about the stumpwm and autoconf version, they ended up decreasing the version anyway
<helpful-friend>"can't compose 'with-patch' with 'with-source'"
<podiki[m]>hrm. this worked before I think, but now i'm not sure
<podiki[m]>is it maybe a problem to have mixed transformation and not in the manifest?
<podiki[m]>nope, even just the transformed ones, no effect
<podiki[m]>...hmm might be some mixing of manifest specifications or something, trying to reproduce
<podiki[m]>ugh can't, just doesn't do anything sometimes, very weird
<lilyp>with-patch and with-source don't compose because with-source overrides what with-patch does
<lilyp>I think the combination of the two is inherently dangerous and should be discouraged; use with-source with a patched source if you need it
<lilyp>maybe we should raise some warnings if such a case is encountered
<unmatched-paren>morning guix :)
<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.
<finial>damn :(
<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>with zsh?
<mfg[m]>let me see, how i do it
<mfg[m]>I'm on a foreign distro though. Here guix adds a file under /etc/profile.d and my zprofile sources /etc/profile which sources all files in /etc/profile.d
<mfg[m]>so maybe it's just enough to source /etc/profile in zour zprofile?
<civodul>Hello Guix!
<cbaines>morning civodul o/
<nutcase>mfg[m]: I don't have /etc/profile.d on my guix system. I do have /etc/profile which is already sourced by zsh.
<mfg[m]>nutcase: hmm, it was worth a try. I'll have to see, on a different machine then
<jpoiret>hi hi
<user_oreloznog_>Hello !
<cel7t>(greet 'guix)
<evilsetg[m]>Hello guix!
<abrenon>hi guix
<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?
<nutcase>in a shell which installs some binary
<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 :)
<jpoiret>just type `guix show git` and enjoy
<evilsetg[m]>I enjoy seeing the same error :). Is there a fix for this yet?
<jpoiret>oh actually it's been fixed by apteryx i think
<jpoiret>it should be on master now
<evilsetg[m]>Nice after a new guix pull it works now :)
<jpoiret>apteryx: could you also push that fix to core-updates?
<jpoiret>or any other committer for that matter
<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>nutcase: this is problematic
<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>what is your $SHELL?
<nutcase>jpoiret: yes, it does, while without -- env it's not extended.
<jpoiret>login shells usually reset PATH
<jpoiret>if you do `guix shell coreutils -- zsh -f` do you have an extended PATH?
<jpoiret>-f disables loading your rc files
<nutcase>so my zshrc sources something that resets my PATH?
<jpoiret>no, rather `guix shell` is starting a login shell for some reason
<jpoiret>just to make sure, can you do `guix shell coreutils` followed by `echo $-` and check that `l` is in there?
<nutcase>'l' isn't included.
<jpoiret>ah, well that's even weirder then
<jpoiret>i don't see how adding something to .zprofile would help solve your issue then as you previously reported
<nutcase>jpoiret: I seee
<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 but … I don’t see any such package on master or core-updates.
<helpful-friend>"Search results"
<cbaines>so maybe not so spooky
<rekado>not spooky, I just don’t want to step on other people’s toes, and I didn’t know what branch I need to look at
<rekado>so… should I base my work on the rust-team branch…?
<jpoiret>nutcase: i don't really know guix home well, but in general you can let it manage your shell directly
<jpoiret>ie. you shouldn't use .zshrc or .zprofile directly but configure everything through guix home
<jpoiret>don't know if that helps
<mirai>what's the correct scheme terminology for this case? <>
<helpful-friend>"Untitled - Pastebin Service"
<nutcase>jpoiret: ok, and in turn, if I don't manage my zsh configuration with guix home but in my dotfiles-repository (+stow), I don't need the zsh-home-service at all, right?
<nutcase>jpoiret: talking/chatting about that does help me a lot, indeed.
<apteryx>efraim: could we merge what's in rust-team that would fix ffmpeg on staging?
<jpoiret>apteryx: could you also commit the pre-commit fix to core-updates, please? thanks for taking care of it
<quidnunc>Why are packages I install not showing up in the bin directory of my profile?
<apteryx>jpoiret: done
<f3n1x>i regularly do 'guix pull', as a regular user... Sweet. Is it recommended to also regularly run somehting like 'sudo guix pull' ? thanks, thanks, thanks
<drakonis>f3n1x: its not necessary to use sudo
<MysteriousSilver>anyone else get the "workspace process error" in cambalache? same as #58116 but 'build --repair gtk' does not fix it
<helpful-friend>"Cambalache: GTK 4 projects don't work"
<hwpplayer1>podiki[m]: What if we just dont care about it ? I mean FHS ...
<podiki[m]>hwpplayer1: hmm? guix doesn't fit FHS at all. [was this about eclipse?]
<hwpplayer1>No in general
<hwpplayer1>I prefer GNU Emacs over Eclipse by the way
<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
<hwpplayer1>I mean can I live without that feature
<hwpplayer1>podiki[m]: ^
<podiki[m]>great, then you don't need to use it :) is merely an option in guix shell --container
<hwpplayer1>podiki[m]: Understood Thanks
<rekado>efraim: I see that you’re the sole member of the rust team
<rekado>I have some work that is based on the rust-team branch
<rekado>should master be merged into rust-team regularly, or is the rust-team branch to be rebased on top of master?
<faust45>hi guix!
<faust45>i have some trouble with guile
<faust45>when i use system-async-mark and try to do stdout inside i got err
<faust45>"Wrong type second arg closed: string ...." how i can make this work? i got this error only when work in repl
<unfroq>Hey Guix!
<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?
<unfroq>kani: Usually you want to configure your services via guix config items: Or do you need more settings?
<helpful-friend>"GNU Guix Reference Manual"
<kani>thanks for the link unfroq :) Although as far as I understand this only supports the ENV vars for calls to dockerd (see ) The thing i need to configure are CLI flags (--default-address-pool and --data-dir) which I usually did by supplying a config.json
<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?
<Guest19>Do I just need to substitute libudev.h to eudev.h or does it take more?
<Guest19>or does someone know a package so I can just look how it is done by myself by using guix edit package
<mirai>try using eudev as input
<mirai>without changing any code
<mirai>is there any naming convention for services that have been "enhanced" with Guix? i.e. consider a usbip service that has its listening port wrapped with a stunnel/ipsec service extension
<mirai>it would be the kind of service "best used" alongside other guix systems
<mirai>the usbip example is due to: "usbipd offers no authentication or authorization for USB/IP."
<mirai>so, we could have a (vanilla) usbip-service-type and perhaps: usbip-service-type/enhanced , usbip-service-type/E , usbip-service-type*, guix-usb-service-type ?
<ekaitz>hey! anyone here using evince for .ps files? I can't open them and it's supposed to support them
<Guest19>If I just give eudev as input I get "Target "PCSX2" links to target "PkgConfig::LIBUDEV" but the target was not
<Guest19>  found." Therefore I need to substitute CMakeLists.txt.  Am I correct?
<Guest19> I assume this needs to be replaced
<helpful-friend>"pcsx2/CMakeLists.txt at 7cdcfd4b1ae55d05e5740eb30bf67bc059037f6a · PCSX2/pcsx2 · GitHub"
<jpoiret>Guest19: are you using pkg-config?
<jpoiret>pkg-config is usually good enough to include all the right flags and search directories
<jpoiret>i would probably look at instead
<helpful-friend>"pcsx2/SearchForStuff.cmake at ad12a3f735d5a9c15b0bab4c1666172a0707c386 · PCSX2/pcsx2 · GitHub"
<unfroq>Does anyone have some ideas on my elogind issue?
<jpoiret>unfroq: can you paste your config on
<Guest19>jpoiret thanks it was actually because I did not had pkg-config as input (thought it is either included in cmake build system or I would get an error)
<jpoiret>pkg-config should be in native-inputs Guest19
<Guest19>Since it is only required for compiling?
<jpoiret>I don't think pkg-config is by default included by the cmake build system
<jpoiret>no, because it is run on the builder, not on the host, so it has to be native
<jpoiret>guix doesn't have build-time vs run-time
<Guest19>okay thanks for the help
<Guest19>Okay it finished building but only has a share dir with licenses.
<unfroq>jpoiret: . I don't have a full minimal example at the moment and I don't want to share my whole config. Hope this is already enough..
<helpful-friend>"Debian Pastezone"
<NewUser-Basic-Qu>Hi, If i want a service beeing available but not started at starup where do i define this in system configuration.
<NewUser-Basic-Qu>in my case a "term-tty<num>" that should not be started but available when i issue "herd start/enable term-tty<num">
<Guest19>hmm second time I got a disc on web libera.  Is the network kinda unstable today?
<jpoiret>unfroq: ah, just saw that you're using both seatd and elogind
<jpoiret>that's not possible (and is probably not what you want?)
<unfroq>NewUser-Basic-Qu: there is a configuration setting 'auto-start?' for shepherd services. So I would look into that. You might need to modify preconfigured services to use that setting as you want.
<helpful-friend>"GNU Guix Reference Manual"
<unfroq>jpoiret: I am not sure which one to choose. I like to get a minimal sway based desktop up and running. I like to ditch SDDM. Do you have a recommendation?
<jpoiret>these are unrelated: you can use both seatd or elogind with SDDM or without
<jpoiret>greetd is a nice DE, i use it with agreety, but I still use elogind
<jpoiret>since seatd is not a drop-in replacement for logind, some services won't work super well
<unfroq>jpoiret: I have a greetd config which I could not test yet, so I would try that road. Wanted to use wlgreet, since it seems to support sway.
<unfroq>jpoiret: So I won't need seatd? Instead I could use elogind?
<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
<NewUser-Basic-Qu>unfroq thx for the lnk
<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?
<jpoiret>weird, I didn't need to add this
<NewUser-Basic-Qu>jpoiret Yep, but how exactly?...currently googling some configs i can dissect
<jpoiret>NewUser-Basic-Qu: hmmm, I don't think you add this yourself without creating a new service type and copying a bunch of stuff :)
<jpoiret>:( *
<NewUser-Basic-Qu>jpoiret (greeter-supplementary-groups  '("video" "input" "seat")) should do it. If you use elogind you will have to get rid of gdm
<jpoiret>didn't need any of that personally
<jpoiret>but sure, if you do add groups for the greeter, you need to create them beforehand :p
<NewUser-Basic-Qu>jpoiret did not create them beforehand. Were created by greetd i guess
<unfroq>NewUser-Basic-Qu: Not sure if this helps, but in this code there is a use of auto-start:
<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?
<unmatched-paren>evening guix :)
<jpoiret>i'll probably regret this, but am trying to build my profile packages with core-updates
<civodul>jpoiret: heh :-)
<civodul>should we do a core-updates hackathon tomorrow?
<civodul>i haven't had as much time as i hoped for so far, but tomorrow should be okay
<jpoiret>we could try
<jpoiret>apteryx backported the pre-commit fix today so i can run `make` again :)
<jpoiret>but I think if we do want a hackathon it has to be publicized somewhere
<jpoiret>civodul: do you think we'll try to patch glibc directly instead of the ugly hack I sent?
<jpoiret>don't really want to build everything right now just to have it invalidated soon
<jpoiret>I really need a new laptop, 8G is not enough ram at all
<civodul>jpoiret: you mean the -ffreestanding configure things, right?
<civodul>i think we should try something like i proposed
<civodul>i haven't tried to build it yet, but i can do that tomorrow if that makes sense to yoiu
<jpoiret>No, for libstdc++
<jpoiret>Ah, it's not glibc, my bad :p
<jpoiret>But still stands as it's the base toolchain
<jpoiret>What you proposed seems fine to me as long as it does build
<civodul>jpoiret: so let's see: tomorrow i'll start building the whole shebang, modified as proposed, and report back
<jpoiret>Hum, i'll cancel my local builds then, and keep that for later