IRC channel logs

<Guest24>hi. is it possible to configure home-dbus-service like dbus-root-service? as in specifying which packages can use dbus?

<switchy>jlicht: that could indeed be it, thanks! maybe the #101 pull to use RTC would fix it?

<apteryx>hey Guix! In case you didn't see https://lists.gnu.org/archive/html/guix-devel/2026-06/msg00098.html, you can delete your .git/hooks/commit-msg hook to stop producing Change-Id git trailers. If you use worktrees, you need to update your "real" tree (git pull), build it, and run 'rm .git/hooks/commit-msg' there.

<switchy>apteryx: is it because the change-id is no longer necessary with codeberg?

<apteryx>kind of, yes. It had been mentioned as incidental complexity in GCD 002 and discussed in https://codeberg.org/guix/guix/pulls/1740 as well as on guix-devel https://yhetil.org/guix-devel/877bom3htf.fsf_-_@guixotic.coop/; the original purpose was devising an auto-close system when using Mumi/Debbugs, which was not implemented.

<apteryx>With the move to Codeberg there are other ways to tackle this (such as adding support for 'Merges: !XXX') trailers to forgejo to do just that.

<YARs2>Can guix run on a rasbery pi 5?

<YARs2>like the OS

<identity>YARs2: sure

<YARs2>Nice! I don't have to deal with that debian stuff

<jlicht>switchy: I don't understand a thing about these issues, I was just perusing them some time ago and what you said reminded me of this issue :-)

<csantosb>Morning Guix ! Cargo people, I'm reading https://guix.gnu.org/cookbook/en/html_node/Common-Workflow-for-Updating-Existing-Rust-Packages.html

<csantosb>`guix shell rust rust:cargo -- cargo audit` is incorrect, right ?

<jlicht>Any guix CI gurus around? Am I correct in assuming these builds were cancelled somehow?

<csantosb>`guix shell rust rust:cargo -- cargo --list` shows no `audit`, same for `license`

<jlicht> https://pulls.ci.guix.gnu.org/build/195834/details, https://pulls.ci.guix.gnu.org/build/195834/details

<jlicht> *https://pulls.ci.guix.gnu.org/build/195966/details for the second one

<csantosb>You have a: "59:29.74 E error: could not compile `gkrust` (lib)"

<csantosb>Followed by a "59:29.75 E process didn't exit successfully: ..."

<efraim>csantosb: you need cargo-audit and cargo-license in your guix shell also

<csantosb>efraim: so I'm good for fixing the doc

<csantosb>jlicht: Interesting enough, I think you can relaunch the job if it fails before it times out after one hour

<jlicht>csantosb: I get a 403 if I try to relaunch the job sadly; afaik the gkrust thing is caused by a SIGTERM coming from "above", so that's why I thought the build may have been cancelled

<jlicht>a change to build/node-build-system.scm seems to have been pushed to master, leading to a lot of big rebuilds :/

<csantosb>This 0fe8f8bcce3 ?

<efraim>9d3861b8904bc73e7290ad8412d6e667b9d0b35a is more likely

<jlicht>9d3861b890 I think, yes

<jlicht>what's done is done, I guess :-)

<m4xxed>Heya, did a bunch of emacs packages get updates and their hashes are wrong? I just noticed that e.g. emacs-evil-numbers' update was reverted and now also emacs-vui is having a hash mismatch when I try to run `guix shell emacs-vui`

<csantosb>m4xxed: Any other emacs package ?

<m4xxed>csantosb So far I found only those two, but I will quickly go through my packages and try them quickly

<moksh>hello

<sneek>moksh, you have 1 message!

<sneek>moksh, thanosapollo says: that if you have more than one matching remote, forgejo-vc will dynamically add `forgejo-vc-select-remote` as an option, by default bound on `r` on the popup buffer. Use that to switch between guix proper and a different remote

<moksh>sneek: botsnack

<sneek>:)

<csantosb>m4xxed: the two package have been fixed and build now, thanks for noticing !

<csantosb>Ok, now `./pre-inst-env guix build -P1 --no-grafts -m etc/teams/emacs/emacs-manifest.scm` builds all packages

<csantosb>Except one, see #9499

<futurile>they say emacs is an OS ...

<csantosb>Don't agree 🤨 ?

<untrusem>futurile uses vim

<untrusem>ACTION pulls guns out of his pocket

<trev>crusty OS

<sham1>Some of the emacs builds have been broken for me when I've tried to do `package-input-rewriting/spec` to substitute an emacs-next for the emacs-minimal that the packages are normally built with. I wonder if that's related to anything the emacs team has been doing

<futurile>ACTION runs away from untrusem and hides

<csantosb>sham1: let us know it there is any emacs package which fails to build; I have just fixed a few of them.

<sneek>moksh: Greetings!

<dariqq>Is there a recommended way to deal with pkgconfigs Requires.Private (the package already has --disable-shared)

<dariqq>I can just propagate the package but it does not feel right

<futurile>oh filtering 'guix pull' was merged: https://codeberg.org/guix/guix/pulls/2241

<untrusem>rejoice :D

<moksh>ACTION finds futurile and bind them so they can't run

<untrusem>btw i am moksh...

<eikcaz>I see lots of examples of gexps using (getpw "user") throughout the codebase, but I can't seem to (mixed-text-file "foo" #~(getwp "root")). I always get "In procedure getpw: entry not found".

<eikcaz>If I unquote getpw like #~(passwd:uid #$(getpw "user")), then my mixed-text-file builds, but it has the uid of that user on the current system, and I need to guix deploy it to another machine with a different uid.

<eikcaz>Heck, now that I think about it, probably it'd build the file locally before sending it anyway. I need a new approach...

<lavandula>Running into an issue installing packages (boost-1.83 patch hash mismatch). This is fixed in misc-world-rebuild -- does anyone know what the plan for that is, and if it would be possible to cherry-pick the specific commits to master? pr#8382, cc: cnx

<lavandula>(the specific issue is rust depends on gdb which depends on source-highlight which depends on boost-1.83)

IRC channel logs

2026-06-24.log