IRC channel logs

<loquatdev>Where is the partition initializer documented? I'm trying to write one.

<loquatdev>As in, what arguments are provided?

<ieure>loquatdev, I don't think it is documented, you have to read the code.

<loquatdev>Do you know which file I should be looking at? I found initialize-root-partition and initialize-efi-partition but neither of them seem to include everything.

<loquatdev>At least, from what I can tell.

<ieure>loquatdev, I'd be looking at the default initializer, what do you mean they don't include everything? Also why do you even need this?

<apteryx>jlicht: I'm a bit rusty with the importer code, but it looks like that's global behavior of the importers, to add -x.y.z to the variable names, unless the version imported matches the already present one. I guess that can be useful for e.g. rust or go.

<loquatdev>Sorry, I just meant that it seems like there might be more keys available since both have #:allow-other-keys. I'm making an image for a specific SBC that has some quirks in how it boots the disk. I have to plant some specific blobs alongside other things in the boot partition so I'm writing a custom initializer for it.

<loquatdev>I'm mainly trying to get more familiar with Guix's internals by using it in some of my other projects, so I apologize if I'm being naive.

<ieure>loquatdev, I see, well, I'd be looking in the system image code (which is probably in scripts/image.scm, but not sure) to see what kwargs it might set. Also I'm not sure if your approach is ideal, if you ever need newer versions of the blobs, you'd have no way to get them except by creating a new image.

<loquatdev>It's not ideal, yeah. I'm letting myself ignore it because the chip I'm flashing to is pretty brittle. I only really plan to flash it once it works and be done with it.

<loquatdev>Also, you've answered a large deal of my questions here. I just want to say thank you for all the help you've given me.

<loquatdev>I'll keep hacking at it, hopefully I'll manage to use Guix on this device. I'm determined to get it on everything now, haha

<ieure>You are very welcome!

<loquatdev>Found it, the initializer is called at line 539 in gnu/system/image.scm

<apteryx>hello, Guix!

<bdunahu>hi! :)

<apteryx>hm, in after ',use (guix monad-repl)' why isn't this working? ,build-options '(#:build-mode 'check #:graft? #f)

<apteryx>Unrecognized keyword: #:build-mode

<apteryx>ah, it's an enum; this works: ,build-options '(#:build-mode 2 #:graft? #f)

<apteryx>it's a bit low level to my taste ^^'

<ieure>apteryx, Yeah, could be improved.

<apteryx>err, still not accepted at ,build: Unrecognized keyword: #:build-mode

<ieure>Looks like the enum value is sent over the socket to the Guix daemon, and that's inherited from Nix.

<apteryx>seems a valid build option according to (guix scripts build)

<apteryx>ah, so it's not even a build option? crazy

<apteryx>it's passed as the 'mode' to build-derivations

<apteryx>3rd arg

<apteryx>not currently possible with ,build, as it calls build-derivations with (built-derivations (list obj))

<apteryx>in guix/monad-repl.scm:105:65

<apteryx>I created an feature request for it at https://codeberg.org/guix/guix/issues/9089

<apteryx>some hackish Emacs automation, to build a package at point: https://paste.guixotic.coop/guix-build-package-at-point.html feel free to borrow and improve :-)

<apteryx>it depends on emacs-guix

<apteryx>(and geiser)

<apteryx>anyone else getting hangs when using company-mode + geiser in guix?

<apteryx>I've reported the issue to Geiser here: https://codeberg.org/geiser/guile/issues/65

<retropikzel>Is there a way to show the package build log automatically when build fails?

<trev>retropikzel: if you do `guix build` the entire terminal is the log

<apteryx>but otherwise, no, you'd have to script that yourself

<retropikzel>trev: I have package definition in file in same directory, I run: "guix package -L . -i package-name". It fails and tells me to "View build log at '/var/log/guix/drvs/ad/<long-thing>.gz"

<trev>right. same thing if you're reconfiguring. i just copy the path and zless it

<retropikzel>trev: Yes, I copy the path. How can I show it without me copying it and opening it manually?

<trev>script like apteryx said :]

<apteryx>easier said than done ^^'

<trev>i will add it to my guix helper 😬

<apteryx>if you build locally, something like 'guix build hello && guix build hello --log-file | xargs zless' to get you started

<apteryx>or lets complete this elisp script: https://paste.guixotic.coop/.emacs-25745-26886.html :-)

<apteryx>in my script, (geiser-eval-definition-and-go) doesn't seem to work; it doesn't switch

<apteryx>this breaks the rest, as the geiser-repl--send must be run in the REPL buffer

<switchy>hmm, guix weather says librewolf isn't available, but it seems that the derivation that's trying to build on my machine has indeed passed on ci.guix... more mysteries

<csantosb>I get https://ci.guix.gnu.org ☀

<csantosb>And https://ci.guix.gnu.org/search?query=librewolf-151.0.2-1%20spec:master

<switchy>csantosb: yeah, I get a build for /gnu/store/bp4f150mjsh8jahqc367iwhwrhp8p8xx-librewolf-151.0.2-1.drv, but https://ci.guix.gnu.org/build/22251760/details is exactly that derivation...

<switchy>but I also get a sad guix weather for librewolf (I have done guix pull, that's about as far as my knowledge of troubleshooting this kind of issue goes)

<stephen2>oh, switchy, can I see your snippet for polkit again? the previous one expired and I hadn't saved it to version control while I was experimenting with it

<stephen2>The rule for netdev/network manager

<switchy>stephen2: ah yeah, sorry about that. https://paste.debian.net/hidden/eb3f2ece

<stephen2>tyvm!

<switchy>I guess network-manager-service requires polkit anyway, so mayyyybee that should be in there at the guix level?

<stephen2>I had tried to create a polkit-service-type but couldn't figure out how to make the config work.

<switchy> https://github.com/NetworkManager/NetworkManager/blob/cb71852c205d3ea1853117098c5fe0bcc8d81920/data/org.freedesktop.NetworkManager.rules.in if you configure networkmanager with polkit_noauth_group, it automatically creates this polkit file

<switchy>but maybe it does make more sense at the service level

<ieure>untrusem, Speaking of LibreWolf, did you see 151.0.3-1 is out?

<apteryx>oh, this works better than the last version I posted: https://paste.guixotic.coop/guix-build-package-at-point.html

<apteryx>I don't need to save a buffer while refining a package anymore, neat

<noxi>noice

<orahcio>Hi, I'm with a problem in #9044, there are some opengl tests. Is there some standard on guix to run python tests which need graphic acceleration?

<apteryx>oh wait, that was not necessary, we already have something like this in emacs-guix: guix-devel-build-package-definition

<ieure>apteryx, You could also use `geiser-eval-definition' instead of manually finding the function start/end and evaluating the region as a string.

<apteryx>I used `guix-geiser-eval' for the error handling (I want to abort on syntax error or the likes)

<apteryx>and then after being happy with this, found out emacs-guix had something to do just that already: guix-devel-build-package-definition

<apteryx>C-c . s

<apteryx>I saw that working once, but now getting `Zero values returned to single-valued continuation'

<apteryx>so my version still has some value ;-)

<apteryx>the emacs-guix version also lets you re-evaluate manually

<apteryx>instead of automating that away

<apteryx>now it also opens the build log if something went wrong: https://paste.guixotic.coop/guix-build-package-at-point.html

<PotentialUser-91>hello. I have a problem. I have a primitive `(gexp->derivation "foo" #~(begin (mkdir #$output))` but `guix build` gives `guix/ui.scm:1030:18 Wrong number of arguments to #<procedure... at guix/gexp.scm:1255:2 (state)>`

<samplet>PotentialUser-91: Are you looking for ‘computed-file’ instead of ‘gexp->derivation’?

<samplet> https://guix.gnu.org/manual/1.5.0/en/html_node/G_002dExpressions.html#index-computed_002dfile

<yelninei>janneke: With the latest mesa i got xorg to compile and cross-compile. Getting exwm requries figuring out emacs (also not cross compilable afaik), do you know another minimal wm that would work (dwm does not build)?

<samplet>PotentialUser-91: If not, ‘gexp->derivation’ is a monadic procedure, which means you’ll have to run it in the store monad.

<samplet> https://guix.gnu.org/manual/1.5.0/en/html_node/The-Store-Monad.html

<samplet>But you should avoid that stuff unless you’re sure you need it.

<janneke>yelninei: hmm. twm maybe? although, for me personally, only exwm is really interesting ;)

<bjc>fvwm is also pretty small

<bjc>and debian is using windowmaker

<yelninei>emacs-minimal works (if you skip some tests) but has no gui, the emacs used for exwm depends on logind

<bjc>you've made some progress!

<yelninei>guix does not have the rest of gnustep (windowmaker and tvm build at least)

<bjc>ah, i thought you could run it w/o the whole environment. oh well

<bjc>fvwm is a similar vintage to twm, so approximately as minimal

<yelninei>does objectivec work even? (it seems enabled in the native gccs at least)

<ieure>fvwm is a twm fork.

<ieure>Isn't twm what used to come bundled with the X11 source code? I'd think that's likely the simplest to build.

<bjc>i don't know why it wouldn't work, but there's also precious little to test on

<bjc>twm was the default, at least. i can't remember if it came with or not

<yelninei>ACTION is still not sure why x forwarding does not work and the x connection just drops

<bjc>xauth/xinit?

<yelninei>bjc: "X connection to localhost:10.0 broken (explicit kill or server shutdown)."

<bjc>hmm

<bjc>yeah, that's odd

<bjc>you doing this over ssh or directly?

<yelninei>bjc: Over ssh (with a patched cross-glibc to have a correct shell for popen). xauth sets DISPLAY and XAUTHORITY. running xterm/xeyes thery get the welcome msg from the forwarded server and then something dies

<bjc>are you using smp?

<yelninei>no

<yelninei>in other news x86_64-gnu are slowly building now

<yelninei>substitutes

<PotentialUser-91>thanks for the `computed-file` tip.

<PotentialUser-91>I just find it quite impossible to learn and debug anything about gexps without seeing everything it generates.

<csantosb>Hi ! I'm build a package using `clang21` as a backend, it takes 2550 MB; switching to gcc14, closure size goes down to 869 MB, see !9101.

<csantosb>This is something to be expected, or is it considered as a Guix issue ?

<ieure>csantosb, I'm not really sure it's either of those. Have you diffed the `guix size' output from the clang vs. gcc builds to see what's increasing it?

<csantosb>Main difference comes from clang (870 MB) and llvm (606 MB) as new references

<csantosb>I have just pasted the output of `guix size` in !9101

<ieure>csantosb, llvm seems expected to me, surprised at clang. Have you grepped the package to see where the references to those are?

<yelninei>python keeps a lot of references to native python inputs because it wraps with the whole PYTHONPATH . llvm is just enormous, maybe you could find the clang reference?

<ieure>csantosb, Some builds do things like including the path to the compiler used to build it, which produces a reference in the package closure.

<csantosb>I included `clang-21` as a native-input, which I understand is correct ?

<ieure>csantosb, That is correct, but is not relevant to what I'm saying.

<csantosb>I know; just in case.

<yelninei>ACTION whishes kept references to native-inputs would be an error

<csantosb>Just wanted to be sure that switching between clang and gcc should not have an impact on closure sizes

<csantosb>ieure: I'll try to investigate the internals of the package

<ieure>csantosb, You cannot say with any level of certainty what the behavior "should" be.

<ieure>I will say I find it surprising, but I don't necessarily believe that everything which surprises me is wrong.

<csantosb>It's annoying for me; I'm concerned about Guix overweight.

<psycotica0>If you grep for `lvwvkmkv5lszgi8i5svj5jf5bgbxg2zf` in your clang build dir, it should pop up if the path to your compiler is included somewhere, I'd expect. I wonder if a build log or something is accidentally being included in the package

<psycotica0>(That being the path you pasted from your issue that looks unique)

<dajole>How do people go about installing things like the typescript language server? It seems like the main options are 1) via npm (messy), 2) via Nix, 3) package it yourself 4) manually (clunky)

<ieure>dajole, Oh, there's no package for it? The only thing I need a LSP server for (golang) is packaged.

<dajole>Yeah, no package yet

<dajole>(as far as I can tell)

<dajole>My guess is because of the mess of JavaScript dependencies

<ieure>I'd try packaging it, but... yeah, same

<csantosb>psycotica0: I see lvwvkmkv5lszgi8i5svj5jf5bgbxg2zf in `bin/yosys-config`

<csantosb>But this is just a text file

<ieure>csantosb, Take a look at the LibreWolf package, it has some stuff which mangles references to remove store paths from the output for this exact reason.

<csantosb>The `neutralise-store-refs`, right ?

<psycotica0>If I'm not mistaken (and I very well could be) the way that guix finds dependencies is that it looks for literal strings that have absolute store paths in them, anywhere in the package. It doesn't know or care what type the file is. So if your package has `bin/yosys-config` in it, referencing the compiler, then it _must_ include the compiler in the set of dependencies because otherwise you'd install you p

<psycotica0>ackage, you'd run `yosys-config` and it wouldn't have what it needs.

<ieure>csantosb, Yes.

<csantosb>psycotica0: You mean that, if I patch any text file with the path to an item in the store, it will include it in its closure ?

<ieure>csantosb, Yes, that's what the package closure is.

<csantosb>I assumed something more elaborated; anyway.

<csantosb>The only difference I can see is g++ replaced by clang++, including a different store item

<csantosb>This pulls clang/llvm; which is built on top of gcc, adding a 2 GB layer on top of it.

<csantosb>IIUC: a bin/clang++ line somewhere brings the binary to the party, along with its 780 MB lib friends.

<ieure>csantosb, Right, but you need to look at where that somewhere is, and whether it's actually needed to run the packaged program. If it's not needed, you can remove the reference by patching the source to not include it, or mangling it.

<ieure>And that will reduce the closure size.

<csantosb>Now I understand this, thanks; I'm just a bit surprised.

<csantosb>By the way, this is what #:disallowed-references is for, right ?

<ieure>I'm not sure and am not near a machine I can use to answer you.

<csantosb>Never mind, I'll try

<ieure>csantosb, I think #:disallowed-references causes a build failure if the output includes references to those packages, but doesn't remove them for you,.

<csantosb>That's correct, I just tried. I'll need to patch the sources.

IRC channel logs

2026-06-05.log