IRC channel logs

<apteryx>hello Guix! Some Emacs-based automation I came up with, while working through a mountain of node packages: https://paste.guixotic.coop/guix-emacs-automation-build-commit-package-at-point.html

<apteryx>another option would be to use etc/committer.scm, but I have a buffer full of WIP packages so I prefer to commit them one by one when they're ready

<dajole>Does Guix have an opinion on where to modify $PATH? Doing so in `home-environment-variables-service-type` doesn't seem to work correctly.

<dajole>I suppose .bash_profile works, but I was wondering if there is another convention.

<apteryx>would there be a way to have comments be part of the package template returned by an importer?

<untrusem>ieure: ahh sorry i will do this by today, damn it is too busy here

<apteryx>when importing a large amount of packages in a module, is there a way to avoid the diff becoming mangled, e.g. work with package units instead of lines? :-) I doubt so, but that's problematic.

<trev>apteryx: have you tried difftastic?

<trev>not sure i'm fully understanding your problem though

<efraim>I end up using tig to use '1' to stage the boundaries of the packages and then '2' to grab everything in that hunk. I haven't worked out how to do that with vim-fugitive still

<Sneed1911>x

<apteryx>trev: I'll look into it

<apteryx>thanks

<apteryx>trev: an example of a diff I was looking at; https://paste.guixotic.coop/magit_guix-spare-57750-60649.html; my change only splices new packages definitions in the module, doesn't change any pre-existing ones.

<apteryx>another example: https://paste.guixotic.coop/magit_guix-spare-35734-44754.html

<apteryx>with this node packaging madness we'll soon catchup with debian on repology ^^'

<apteryx>efraim: I guess you got used to doing that diff staging surgery with the rust-crates module? :-)

<apteryx>trev: I see we have emacs-difftastic packaged; is there some special setup to make use of it, or does it automagically gives superpowers to magit/ediff/etc?

<apteryx>all explained at https://github.com/pkryger/difftastic.el, I see

<apteryx>basically just calling (difftastic-bindings-mode) in your ~/.emacs

<apteryx>trev: difftastic seems to be showing a more sensible diff, thanks :-)

<apteryx>to use, you hit 'd' in magit then M-d, with the default bindings.

<apteryx>ah, but I can't stage from this buffer, pity

<apteryx>trev: I asked about this use case there, sharing an example: https://github.com/pkryger/difftastic.el/issues/23

<bjc>5 versions of llvm and counting to build xorg

<bjc>holy smokes

<apteryx>these mangled diff really slows me down (can't stage something easily) when using 'guix import -i gnu/packages/node-xyz.scm ...'

<postroutine>I've seen a typo error in the documentation. (devel version) In the section "7.1 Invoking guix shell", second note.

<trev>apteryx: i've been playing with magit-difftastic as well

<postroutine>> Note: guix shell can be also be used as a script interpreter

<postroutine>There is 2 "be".

<postroutine>Should I open a bug report for it ?

<bjc>bug report or patch will be welcome

<trev>apteryx: just looking at your difftastic.el issue and i think you will want magit-difftastic instead

<efraim>postroutine: thanks, I see it

<efraim>do we have the github CLI program packaged?

<efraim>looks like it's github-cli

<trev>do not see it

<trev>i have it packaged in my personal packages

<ieure>trev, I see it "version: 2.83.2".

<trev>i guess i've uncovered a bug in my package search tool

<mlxdy>Should I use sudo -E or sudo to make guix system reconfigure?

<Rutherther>mlxdy: rather without -E. You risk adding root owned files to your home with -E. And it's not giving you much

<Rutherther>PATH is passed through sudo, so the guix channels you are using are the same ones either way

<chris0ax>so ive been seeing how to build suricata, which is like a network security tool. It has a mix of C and Rust in its build system. It also seems to build its Cargo files from a Makefile. I used the importer to generate crates from its lockfile (after a cargo generate-lockfile), but during build it complains about the version in the vendor not matching Cargo.toml. I then go like ok, lets just use the Cargo.lock suricata makes during

<chris0ax>build, I run the importer with that so the versions remain the same. But then the build complains about not being able to verify whether a dependency is the same as when the lockfile was generated (probably a checksum issue?)

<efraim>try deleting all the Cargo.lock files

<chris0ax>efraim: I think during the build phase they are generated with 'make'. Cause they are .am and .in files till the build fails

<efraim>ok, then try removing '--locked' from the cargo command in the makefile

<chris0ax>efraim: i assumed wrong, so it was generating lockfiles before build, i deleted them now and it seems to have compiled. Thanks!

<chris0ax>i have a feeling guix would make running security tools like this much easier from an end user pov, lets see

<mlxdy>Rutherther: I was doing it like this, right now I now why I had problems

<graywolf>So, hm, how can I contribute hidden issue on Codeberg? I guess there is no way and best I can do is post patch on mastodon if anyone is interested?

IRC channel logs

2026-06-07.log