IRC channel logs
2026-01-08.log
back to list of logs
<ieure>abralek, Thank you for the help! <abralek>np, current-build-output-port defaults to (current-error-port), but geiser redirects error/output to string ports for capturing output. <FuncProgLinux>If one does (define-member) in teams.scm does that imply a request for commit access? <apteryx>or the presence of NIX_* environment variables <xiews>I Havel sbcl-cl-webkit-3.5.10.drv build timed out after 3600s of silence. Has anyone the same problem? <htgoebel>Hi, I fail to push to master with "not signed by an authorized key" <htgoebel>My last key expired and I created a new one, which is already in keyring <efraim>is your keyring branch up to date? <Rutherther>htgoebel: As far as I know that is not the preferred way to handle this. Rather in Guix the keys are extended <Rutherther>htgoebel: but more importantly is your key in the guix authorizations file, signed with key already in there? <htgoebel>rutherer: I assume this piece is the missing one <Rutherther>Are you aware that Guix does not check expiration of a key? <htgoebel>The key is already in my codeberg profile - if this is of any help for trusting the key <htgoebel>rutherer: but gpg does - and thus does not allow signing the commits <efraim>I'll update the .guix-authorizations file with the key from the keyring branch <htgoebel>rutherer: what do you mean with "extended"? <efraim>Rutherther: on ppc64le, with tests disabled for llvm@18, for release-minimal.scm I have openssh, ntp and btrfs-progs-static failing <Rutherther>efraim: I see, not good, but its not a primary architecture so we dont have to care about it for the release <yelninei>during guix pull is the new guix being built with the dependencies from the new guix or the old one? <csantosb>sneek, please later tell civodul, I'm reading the 2025 activity report, and I'm wondering if the survey is something to mention in here <Nessah>Hello, Guix. Is anyone else having issues with frei0r-plugins failing to build? There's been a hash mismatch with my local build on the current master branch. <Nessah>The releases have been moved to a github page and the only old releases there are from 1.8.0 onwards. <Nessah>efraim: many thanks! that fixed it <danlitt>I wonder if anyone has a working guix home snippet for using __git_ps1 to set the PS1 environment variable? I have the following snippet but it seems to automatically escape the inner double-quotes, which is not correct syntax for bash. <danlitt> '(("PS1" . "\\u@\\h \\w($(__git_ps1 \" (%s)\")) ${GUIX_ENVIRONMENT:+ [env]}λ.")))))) <efraim>danlitt: you have to escape a lot more <efraim>I have ("clear" . "printf '\\E[H\\E[J\\E[0m'") <efraim>try "\\\\u@\\\\h \\\\w\\(\\$\\(__git_ps1 \\\" \\(%s\\)\\\"\\)\\) \\$\\{GUIX_ENVIRONMENT:\\+ \\[env\\]\\}λ\\.") <danlitt>@efraim I think that is too much escaping. I get no errors but my bash prompt is now "\u@\h \w\($\(__git_ps1 " \(%s\)"\)\) $\{GUIX_ENVIRONMENT:\+ env\}λ\." <efraim>ok, so start from what you had before but escape the dollar signs <danlitt>With the snippet I previously posted, \u \h etc were working correctly btw. It's the subshell for __git_ps1 that's broken. <efraim> "\\u@\\h \\w(\\$(__git_ps1 \" (%s)\")) \\${GUIX_ENVIRONMENT:+ [env]}λ.") <danlitt>I replaced $(__git_ps1...) with \\$(__git_ps1...) and the result is that I get the following in my .bash_profile: <danlitt>export PS1="\\u@\\h \\w(\\$(__git_ps1 \" (%s)\")) ${GUIX_ENVIRONMENT:+ [env]}λ." <danlitt>I think this just prevents bash from recognising the subshell entirely. I still get -bash: /home/daniel/.bash_profile: line 10: syntax error near unexpected token `(' <danlitt>I can possibly remove the GUIX_ENVIRONMENT part entirely - I don't think it's problematic <danlitt>Here is a more minimal working example (which gives the same error with $ or \\$) <danlitt> '(("PS1" . "$(__git_ps1 \" (%s)\")")) <danlitt>I *think* what is happening is that guix home tries to escape any double quotes you use when defining environment variables, on the assumption they should be literal " characters, but this is not correct if you're trying to use a subshell. <efraim>what is it supposed to look like in the end? <danlitt>In the computed bash_profile it should look like: export PS1="$(__git_ps1 " (%s) ")" <danlitt>Actually I'm wrong... there is a double problem. actual code in the bash_profile should be in single quotes, not double quotes. So, like this: export PS1='$(__git_ps1 " (%s) ")' <efraim>it looks like guix automatically wraps the environment variables in double quotes. would PS1="$(__git_ps1 ' (%s) ')" work? <danlitt>I can get around it by not using the environment-variables service at all and just providing literal bash code. So not the end of the world. <efraim>that was my next suggestion, to put it in bash-profile <danlitt>I think if the outer quotes are doubles then subshells will get expanded, like in this example: <danlitt>daniel@libre-t440 ~/src$ echo "'$(echo hi)'" <danlitt>that won't work for PS1, since it gets re-evaluated whenever you change directory for example, not just when your bash_profile/bashrc is evaluated <yelninei>janneke: Trying to run "make" manually from a checkout and libgc is not complaining about repeated allocations of large-blocks. These messages might (again) be coming from the build driver and not the guile doing the compiling <janneke>yelninei: right, and i'm possibly vaguely starting to remember something from a prolonged guix-daemon debug session, offloading to the hurd <yelninei>janneke: yes, it also caused an occasional test failure when a test asserts an empty stderr. It would mean that something(s) in guix itself consume(s) and leaks memory like crazy <janneke>yelninei: ...that, or the warning is fu <yelninei>it seems to come and go with differrent libgc versions. But it cant be completely bogus as the gc managed heap becomes so big to cause allocation failures <attila_lendvai>guix deploy is broken for dropbear servers (openssh fails to negotiate compression and errors out) <attila_lendvai>LLM about dropbear: "but real packaged builds (e.g., Ubuntu) often disable compression for server->client and only offer none on the server side to reduce attack surface" <podiki>Rutherther: does the vm-image-efi example configuration you added build for you? i get complaint about needing an efi bootloader (which the configuration does specify) <Rutherther>podiki: it does, how are you building it? I suspect you're using -t qcow2, while you need to use -t qcow2-gpt <podiki>ah correct, interesting that the error message is somewhat backward <podiki>i'd expect it to complain that there is an efi bootloader but non-gpt partitioning <Rutherther>podiki: the message is for both cases I think, it's just an and with efi bootloader and gpt partitioning <Rutherther>probably would be better to split it to both cases, yeah, depending on what is missing <podiki>yeah, this cause would be more like "EFI bootloader requires GPT partitioning" (though that makes both messages too similar) <podiki>something explicit like: An EFI bootloader has been specified but there is non-GPT partitioning <podiki>and maybe "An EFI bootloader is required when using GPT partitioning" <podiki>though both cases is a bit strange for a user maybe, as the partitioning is specified in the actual system configuration anyway <podiki>going to test out this new 1.5.0 installer for some training exercise material :) <podiki>i have a spare raspberry pi laying around too i could dig up <klm`>Hi! When I remove/change home services (using shepherd-timer), the old ones aren't discarded and any changes are ignored. Is this a bug or am I missing something? If so, how do I manually delete/purge a service? <podiki>oh right; guess i could try installing from the existing distro on there <podiki>it would be nice if the installer let you specify a --jobs argument to the reconfigure (in graphical installer), that should be mostly downloading so a few jobs would really speed it up <Rutherther>podiki: definitely, feel free to create issues about stuff like that <podiki>will do, letting it install now (just a vm, but using the installer directly) <identity>klm`: ‹herd disable service && herd stop service› should do the obvious thing, but i am not sure if (and how) that works with timers <Rutherther>(just so we're clear it won't make it to 1.5.0, the installer will be modified only when there are bugs, not new features) <Rutherther>klm: guix doesn't restart the services to not break anything, it has to be done manually. When a change is pending, you will see it through herd status <klm`>identity: oh, I didn't know about `herd disable`. How do I list all things I can do with a service? herd doc myservice list-actions only list "trigger" <podiki>ah, 5gigs too small for my vm install (specifying gnome de), looks like about 6 needed; will try with more later <klm`>identity: anyways, disabling and stopping the service before running `guix home reconfigure ... ` makes new changes come into effect <klm`>so thanks for the tip! :-) <identity>klm`: (info "(shepherd) Invoking herd") «Actions that are available for every service are ‘start’, ‘stop’, ‘restart’, ‘status’, ‘enable’, ‘disable’, and ‘doc’» <klm`>oh I see, a bit of a rtfm situation :-) would it be useful to mention those in part of `herd doc $service list-actions`? I don't know if herd is intended to be self-documenting at runtime, but I find it's command line interface difficult to use (and explore) <psycotica0>Hey folks! I was tracking down an issue I had with `bemoji`, and it turns out they use `fuzzel` which uses `libfcft`, which uses `pixman` to do some rendering, and in guix master `pixman` is configured with `-Dgnuplot=true` which is a bonkers option for a low-level library that outputs some gnuplot commands to stdout of whatever it's compiled into so you can pipe the output of any pixman-using binary to g <psycotica0>nuplot and get a graph of something, and it's screwing with my normal command's use of stdout way up the stack. <psycotica0>This option was turned on in the commit acc64de45b7fdacd542c3428d60c1c0ed699b474 with the message "gnu: pixman: Enable some features" <psycotica0>So... this seems like a bad default for everyone downstream to get, but I assume there's a reason someone wanted it once. Is there a guix primitive I should use to expose this as an option a person could enable if they were looking into something, without it being the default? <psycotica0>So should I produce a patch that's just a copy-paste of `pixman`? And then I'd remove the line from the main one and call the new one, like, `pixman-gnuplot` or something? <psycotica0>If a user _did_ want to build their binary with this version of pixman in their dependency chain, what transformer would they use to get it? Is there a, like, `guix build --with=pixman=pixman-gnuplot` or something? <Rutherther>psycotica0: no, copy pasting is more code to handle. Rather, inherit the package and remove the build option in arguments <psycotica0>I mean, I think it would make more sense to remove it from the main one, and inherit and _add_ it in the new one. <Rutherther>psycotica0: pixman has 16332 dependents, so changing it is not trivial to change it. All of these would have to be rebuilt and who knows how many of those packages could rely on this option, that would all have to be checked and a team would have to take it on their branch to let QA rebuild all those packages <psycotica0>Okay, and then it sounds like the flag I wanted was `guix build --with-input=pixman=pixman-gnuplot fuzzel`, as an example of how I'd go about building a version of fuzzel that uses a version of `pixman` that has this option turned on <Rutherther>so while maybe in the long run disabling it could be the way (I cannot decide that without spending some time on figuring out what it does and why it was enabled), if you want something in upstream Guix more quickly, you will need to NOT modify the pixman package <psycotica0>I hope a lot of them don't rely on an option that spits debugging gnuplot output to stdout of the eventual binary user, but fair enough. <podiki>didn't we disable that gnuplot option in pixman in recent mesa updates? <podiki>my mistake, was meant to be removed