IRC channel logs

<Heterochromium>Does Guix not use a `/usr/local` directory?

<vagrantc>doesn't even really use /usr

<vagrantc>for the most part not even /bin

<vagrantc>Heterochromium: it's a totally different filesystem layout ... everything (caveats apply) is just in /gnu/store/ and it sets appropriate variables in the environment to find programs and such

<sham1>Yeah. And most of the benefits you would get from /usr/local you can get by creating a custom package in a configuration and adding that to your profile

<dlowe>nothing makes a users heart patter like hearing they get to make a custom package

<redacted>dlowe: I think "make a custom package" is overselling it. Not that difficult to make a package that just symlinks.

<Heterochromium>dlowe: You don't say, haha! I want Anki, but it's too complicated to build from source (or so I hear), broken on Nonguix, and probably won't work as a direct install from its site (it uses `/usr/local`).

<redacted>Can you download a binary?

<redacted>Actually, let me go check. I'll try making a package.

<redacted>Oh, right, I forgot that not everything people put in /usr/local is a statically compiled binary. lol

<redacted>I take back what I said about that not being hard.

<redacted>I keep distrobox around for stuff I don't feel like packaging for Guix.

<redacted>I'd probably use it for this case.

<redacted>Unless there was a flatpak I trusted, then I might use that.

<sham1>Oooh yeah, good point. If /usr/local stuff isn't statically linked, then it'll get more involved

<sham1>Then you may have to patch a binary so it can be slotted into the store

<redacted>iirc the nonguix people have a build system that uses patchelf

<j_importer>ooh patchelf

<sham1>Yeah, they do. But correct me if I'm wrong, patchelf only really lets you fix up things like RPATH and such, and for any hardcoded other things you might need something else. Although I hope that patchelf could also do that stuff

<sham1>Dynamic linker paths

<sham1>And of course, patchelf won't do anything for non-ELF files. I suppose that if one needed to do something like this, looking at the relevant build process from Nix might be useful since they of course also have to deal with this stuff

<redacted>Anki is ELF, fortunately.

<j_importer>there's LIEF maybe? https://github.com/lief-project/LIEF

<redacted>Its got an install.sh script that should tell you where it expects things to be. Looks like its resource paths are relative to the binary directory.

<redacted>Is there some kind of guile tooling that can automatically add needed imports to the module? I've got a long list of packages I'm adding imports for.

<Heterochromium>redacted: Oh my gosh! I cannot believe I forgot about DistroBox! That's a good solution in this case — thanks for pointing it out.

<Heterochromium>Does anyone here happen to know which GRUB commands are needed to load LVM-on-LUKS Guix? Apparently this is already possible with minor manual tweaking.

<Heterochromium>I just realized that most Linux distributions use SystemD, but Guix uses Shepherd. Is that a problem for Distrobox?

<j_importer>Heterochromium: it looks like they support alpine, which uses openrc afaik. so guix would probably work ok?

<dlowe>I thought I remembered a guix mode where it would start a shell with a container that looked like a conventional system

<lechner>dlowe: --fhs, maybe?

<apteryx>hako: I think there may be an issue with circular top level module dependencies between (gnu packages rust-crates) and (gnu packages rust-sources)

<apteryx>jlicht: I was trying to unbundle more libraries from node (<https://codeberg.org/guix/guix/pulls/11436>), but I'm getting https://paste.guixotic.coop/w82slg2whkxhcri83r7kvb1png9ixh-node-24.21.0-1403163-1405845.drv.html (Package libllhttp was not found in the pkg-config search path.); should llhttpish be shipping some .pc file?

<Heterochromium>Is it possible create groups without putting any users into it?

<jlicht>apteryx: (otr) possibly, but I don’t think it should be required

<jlicht>it’s definitely a good idea :)

<hako>apteryx: Probably introduced by https://codeberg.org/guix/guix/src/commit/e41f8b4171554eb012beb296fd44b5dca33edcb9/gnu/packages/games.scm#L230 , rust-crates shouldn't be imported by any module.

<apteryx>hako: it doesn't get triggered all the time, which is odd. Is this important bit documented at the module or somewhere?

<hako>apteryx: I think there's a paragraph but it may not be that clear https://guix.gnu.org/manual/1.5.0/en/html_node/Rust-Crates.html#:~:text=Rust%20libraries%20are%20not%20referenced%20directly%2E

<apteryx>hako: thanks; I suggest turning this into a prominent warning; I can have a stab at it

<apteryx>hako: https://codeberg.org/guix/guix/pulls/11438

<apteryx>hako: at least the (gnu packages rust-crates) imports could be remove without breaking guix pull; so I did so in 72d1ff6061d

<apteryx>is it expected that when cross-compiling, the test suite is built for the target, hence test inputs need to be in 'inputs', not 'native-inputs'?

<jlicht>apteryx: afaik, no tests are run when cross-compiling

<jlicht>maybe they are

<apteryx>tests are not run with cmake-build-system at least, but when enabling test suites with cmake, it'll often build them. if headers are in native-inputs, they're missing to the cross-compiler building the test suite

<apteryx>moving the test libraries from native-inputs to inputs fixes that

<jlicht>but shouldn't the tests be built for the target, and we then just skip running them?

<jlicht>as you state

<apteryx>jlicht: one example you can try https://paste.guixotic.coop/magit-revision_guix-javascript-team-485-1116.html

<apteryx>where there's an option to disable building the test suite, a better option is this: https://paste.guixotic.coop/magit_guix-javascript-team-206-1159.html

<civodul>Hello Guix!

<tusharhero-xmpp>civodul: hello!

<csantosb>Good morning Guix ! Just noticed "emacs-forgejo" is live again ?

IRC channel logs

2026-09-23.log