IRC channel logs
2025-06-29.log
back to list of logs
<spiderbit>when I start sbcl it already loads sb-ext and with (sb-ext:exit) I end it, but in sbcl-stumpwm when I try to require sbcl-dbus complains about missing sb-rotate-byte function that sbcl-ironcland want, so it does not automatically load sb-ext, when I try to load that with use-package it complains about conflict of exit function of stumpwm-user and <spiderbit>sb-ext and when I try to load it with "require" it does not know how to require sb-ext... <spiderbit>sbcl-stumpwm-stump-nm has itself sbcl-dbus as input, I wonder if stumpwm somehow on start tries to load sb:ext and then fails but only as warning and therefor it can't be loaded manually because it has conflicting function names with :exit <spiderbit>ok I reproduced it with the stump-nm package: <spiderbit>(stumpwm:add-to-load-path "~/git/stumpwm-contrib/util/stump-nm") <spiderbit>this creates the same problem error that dbus wants over ironclod the sb-rotate-byte function that is in sb-ext <meaty>are there any good resources on transitioning an existing guix system to using disk encryption? <eikcaz>meaty: I would recommend trying to install to a different drive and copy your files over <PotentialUser-98>Has anyone managed to get gdm to work with the latest update when using nvidia? <meaty>are there any plans to implement web push notifications on codeberg/forgejo? might be nicer than keeping the notifications page open <hako>meaty: Email notification should be sufficient I think? <link-choice>anyone have advice for debugging guix gc crashing after setting privileged? to #f in guix-service-type? <Kabouik>I packaged a kernel module for my private channel but I had to seek help with a LLM, and I'm not sure the result is the correct way to do it: https://0x0.st/8UmZ.scm The lunar.ko file ends up in the store in those subfolders: /gnu/store/ng321gavf4a65p7pqgbkpaimlwa63fb7-lunar-kernel-driver-0.1/lib/kernel-modules/6.14.11/extra, which I'm not sure is standard. <identity>Kabouik: the Makefile wants to install the module to "/lib/modules/$(uname -r)", there are a lot of other problems with the package definition, you should avoid using LLMs for packages in the future (and everything else, which is my personal opinion and may or may not represent the opinion of other people in this channel; asking to review code generated by a language model is likely to be considered rude or tasteless), there are <identity>examples under gnu/packages/linux.scm in the guix repo <Kabouik>Thanks for the answer identity. Yes I fully understand (and agree) about the risk of using LLMs to solve things the user doesn't fully understands, which was the case here. At the same time, this is also what makes it tempting, in the unlikely scenario that the LLM would have a sensible representation of what the Guix manual contains and what are the good practices for packaging. For a kernel module, I'm even more out of my comfort zone, so I thought <Kabouik>this could help kickstart, but not if the LLM started on the wrong foot indeed. <Kabouik>I didn't want to ask people to review code generated by a LLM here, apologies if that's how it came out. But since it was building correctly, I just wanted to know if the output path made sense at all. It seems it did not. <pastor>I'm not sure if the bug is in Guix `serialize-configuration' function. <spiderbit>ohh does the webchat here autoconnect didn't connect again manually. <ieure>pastor, It is not a bug in `serialize-configuration'. <spiderbit>Anybody with good common lisp knowledge here... can't load sbcl-dbus inside a stumpwm session. <pastor>ieure: what makes you think that? Shouldn't `serialize-configuration' be able to serialize any field defined with `define-configuration'? <jlicht>I seem to not be able to put xmobar in a guix shell container. One out of every three invocations of `guix shell -C ghc-xmobar` crashes for me /w 'Wrong type (expecting exact integer): #f' <attila_lendvai>spiderbit, i know CL well, but i never tried stumpwm, nor know much about dbus <jlicht>does this ring a bell for anyone? It doesn't seem to be entirely deterministic, I've had runs of 3 failures, and runs of three successess as well by trying again and again <spiderbit>attila_lendvai well for some reason it does not load sd-ext and if I try to load that manually I get some conflict error <ieure>pastor, What makes me think that is that there are dozens of services using `serialize-configuration' without issue, so the most likely situation is that specific config is broken. <attila_lendvai>spiderbit, hrm... it's usually because (sb-c::sbcl-homedir-pathname) is wrong <spiderbit>basically part of dbus uses ironclod which is for encryption that wants sb-rotate-byte that is in sb-ext <spiderbit>yes because stumpwm-user has a exit function and so does sb-ext <attila_lendvai>spiderbit, or maybe the sbcl that loads stumpwm is too old. but i don't see why that should be in guix... <ieure>pastor, "Shouldn't `serialize-configuration' be able to serialize any field defined with `define-configuration'?" -> no, absolutely not. The serializer functions are usually defined by the configuration code for the specific service. So if they're buggy, they won't work. <attila_lendvai>spiderbit, oh, i see. then the conflict needs to be resolved. it's not a good idea from stumpwm-user to :import all of sb-ext... <pastor>ieure: do you have any idea on how I could debug it? <pastor>Do you know how is that this serializer ends up being used? I don't see any other reference in code... Is there some kind of magic happening to choose which serializer corresponds to which configuration? <spiderbit>attila_lendvai that is the only way it even tries to load sb-ext that I found: (use-package :sb-ext) "require" errors with not knowing how to require.... <spiderbit>normal sbcl has sb-ext loaded automatically... I don't have to do it manually... which is also strange you would think this is a normal cl / sbcl environment <lilyp>hey, does anyone know how to start a sound server in a package build (for testing)? <attila_lendvai>spiderbit, can you give me a simple reproducer that i can use in a standalone sbcl? i loaded stumpwm, then ironclad and it works just fine (using the github repos, not the guix packages) <spiderbit>because it uses also dbus, creates the same error <attila_lendvai>spiderbit, so, there's sb-ext:quit and it ends up being imported into stumpwm-user... but i don't see where/how. stumwm-user only :use'es :cl and :stumpwm <ieure>pastor, It's magic from `define-configuration', a field type of `foo' will call `serialize-foo'. See the Guix manual section on this.. <attila_lendvai>spiderbit, i ran out of ideas. both dbus and ironclad seems to be disciplined projects when it comes to messing with packages and symbols. <spiderbit>instead of a normal function therefor you need it globally... or do I have to somehow make sure the namespaces are not top level somehow... <attila_lendvai>spiderbit, unwinds to the (stumpwm) toplevel, and tells it to quit <spiderbit>ahh that's not how it's defined but to do the quitting... <spiderbit>I don't explicitly require "user" so it's in top level... <spiderbit>how can I even catch it... I get a popup which I can't copy paste out of... <ieure>pastor, Cursory read of the code, grafana-configuration doesn't set a default value for `smtp', so the serializer is probably calling `gf-serialize-grafana-smtp-configuration' with the wrong arity or a value that makes it blow up. <ieure>pastor, This is a common class of bug in config serializers, in my experience. <spiderbit>attila_lendvai ok give me a second I have it <pastor>ieure: is this a Guile bug? I don't think `grafana-smtp-configuration-password-file>' is a syntax transformer... <spiderbit>attila_lendvai or here a full output of require dbus <attila_lendvai>spiderbit, your paste triggers the error, that's fine. the question is: who/what issues that (or an equivalent) command? <attila_lendvai>spiderbit, 'Component "sb-rotate-byte" not found' happens most probably because stumpwm is an executable image compiled with sbcl, and when the image is started then the sbcl home variable is not restored to a valid path <attila_lendvai>spiderbit, eval (use-package :sb-ext) tries to use the sb-ext package in the stumpwm-user package. both have an exported 'quit' symbol, therefore your error <attila_lendvai>spiderbit, note that the two errors you pasted are most probably completely unrelated <attila_lendvai>spiderbit, check the value of (sb-int:sbcl-homedir-pathname), it should contain the sbcl extensions <spiderbit>The variable SB-INT:SBCL-HOMEDIR-PATHNAME is unbound.Backtrace <spiderbit>attila_lendvai yes should be right... not set <attila_lendvai>spiderbit, the fix is to capture the path when the image is built, and restore it when it is started (assuming that the path will be valid at runtime, too, but in /gnu/store it should be) <spiderbit>so is the bug stumpwm specific of only in guix <attila_lendvai>spiderbit, it seems to be guix specific. see the build-program expression in wm.lisp <spiderbit>I am just not good in clisp, I come from emacslisp <attila_lendvai>spiderbit, the build-image call in the guix package is basically a wrapper around sb-ext:save-lisp-and-die <attila_lendvai>spiderbit, the logic is: load stuff into the runtime, then save the whole memory/image as an executable file <attila_lendvai>spiderbit, but yeah, funny name indeed... :) SBCL has some of those, it has its own vibe <spiderbit>Well I like intepreters more... hate lowend :) stuff just give me a interpreter <spiderbit>but sure that is part of learning I am just not so good with cl yet want to build a connection between emacs and stumpwm so that I can request the buffers from emacs to show it in stumpwm window and then open either the frame+buffer or create a new frame and switch there to the buffer <spiderbit>basically it would then use rofi to show the emacs buffers and normal other program-windows... <attila_lendvai>spiderbit, hrm... i think i'd look into loading swank into the stumpwm vm, then start a swank server, and connect to it from emacs. then reuse the communication API to do what you want. but it's not a simple task. be prepared to learn CL stuff, including the infra <spiderbit>That was my first thought but that also did not work :) <attila_lendvai>spiderbit, the relevant part in guix is in guix/build/lisp-utils.scm and the issue is that the generate-executable and build-program machinery doesn't restore the SBCL home, nor provides a way to add custom image-restore-hooks <dots_>Hi! ive been trying to follow the instruction for building an installation for an arm board via guix system image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")' <dots_> but u-boot is failing to compile with the C error invalid register for name gd, register volatile gd_t *gd asm ("x18").... any pointers? anything i might be missing? or will i have to create a patch file to try and fix the build? <dots_>to specify, i am trying to build for the orangepi-5-rk3588s (yes im replacing the board name) :) <attila_lendvai>dots_, if no one is around to answer here then you should write this in a mail to guix-devel <attila_lendvai>spiderbit, probably needs to be added as an input. i never used the guix cl packages, but it feels inflexible (due to the reproducible build stuff) <attila_lendvai>spiderbit, if you're planning to work a lot on stumpwm stuff, maybe you're better off if you build your own from the git repo <spiderbit>is that that not neccesary too when it can use the path and normal cl packages? <attila_lendvai>spiderbit, that way you can configure ASDF in a more flexible way <dots_>sounds good attila_lendvai, you are referring to this email address right? <attila_lendvai>dots_, there were several discussions about such builds. maybe you get a hint from one of the matches... <dots_>ooo, didnt know that existed. maybe theres a fix in there :) <attila_lendvai>spiderbit, you can try that, and it may get you ahead. but that won't fix e.g. the sbcl home issue <spiderbit>attila_lendvai sure my question would be if the home issue is fixed do I need to add this things in input? <spiderbit>or can I just install them as normal packages <spiderbit>I mean as inputs I have em as dependencies... but that is more important if I would want to alter the package itself <attila_lendvai>spiderbit, not sure if the installed guix packages are registered into the ASDF registry. if yes, then it's enough to have them in the profile. otherwhise you'll need a new package with extra input (and maybe load the needed CL pacakge at build time) <attila_lendvai>if there was a forum, then you could ask this in the CL category. (or you can write the gazillionth mail to the guix-devel list... :) <attila_lendvai>or maybe there's a way to write to the 'lisp team members in etc/teams.scm <spiderbit>attila_lendvai so what happens next do you write a bug report with your solution or a patch or do I have to do something? <dots_>guix-devel hates my email server :( <Kabouik>What would be the best approach in Guix to allow non-root users to change values in /sys/class/leds/.../brightness? I tried setting up a udev rule but saw no change. <ieure>Kabouik, udev is the right approach, if it's not working, you've got something wrong. <ieure>Kabouik, See the emacs-blight package, it has udev rules that already do what you want. <mghackerlady>Does anyone else think we should rename the guix distro to the GNU system? Ever sense the name change from GuixSD to just Guix I find it hard to communicate whether I'm talking about the system or the package manager, and I also think the GNU system is the best name for it as it's the closest thing we have to a complete installable GNU <ieure>Kabouik, Well, it's /sys/class/backlight/.../brightness, but same idea. Should be reusable with light hackery. <ieure>mghackerlady, "GNU system" is too general, doesn't this describe Trisquel as well? <ieure>Also, wouldn't "GNU system" imply a Hurd kernel only? <mghackerlady>Trisquel is a GNU distrobution, but it doesn't really prefer to use GNU software, instead opting to use other free software for some purposes, like the apt package manager and systemd init system <ieure>mghackerlady, Does that imply that my Guix System machine using the full Linux kernel is not a "GNU system?" <mghackerlady>It's a GNU distrobution, like any other GNU/Linux distrobution. Yours just happens to be more GNU than others <Kabouik>ieure: my LED devices in /sys/class/leds are exposed by a kernel driver that is installed from a Guix package in my private channel and then loaded with (kernel-loadable-modules …). Is it possible that this is done after the udev rule and resets the permissions? <ieure>Kabouik, No, udev doesn't work like that. <mghackerlady>anyway, having a reference GNU system would be a good idea for compatibility reasons. It could serve as a target for other GNU software or software that aims to work well with other GNU software <identity>mghackerlady: arguably using "GNU system" for Guix system is more confusing <ieure>Kabouik, The reason udev exists is to respond to changes in hardware topology, like devices being un/plugged. It'd make no sense if it only worked with whatever topology existed when it started. <ieure>Kabouik, See `udevadm(8)' and the `udevadm monitor' command, which is for debugging stuff like this. Or just use the rules I wrote for backlights and tweak them. <Kabouik>I'll check your rules for backlights ieure, thank you. https://0x0.st/8Uji.txt <- I'm thinking maybe my udev rule is not specific enough and does not change the brightness file permissions