IRC channel logs

<zeropoint>hmm actually, I'm not sure that works

<vagrantc>just another average update ... Authenticating channel 'guix', commits 9edb3f6 to 32edabd (21,920 new commits)...

<pomel0>ieure: I recommend you ask in #libreboot about problems with tlp on newer thinkpads

<ieure>pomel0, I don't have problems, just asking to see if there are problems.

<pomel0>ieure: well then you should ask if there are problems in #libreboot . I personally only have it on an X60 just like you, although I do remember thinkpad battery tresholds not working in that machine was documented in the libreboot docs, so other thinkpad boards with the same issue should also be documented, ideally

<vagrantc>wow, that upgrade went smoothly ... surprising for aarch64! :)

<untrusem>can someone check if `josm` package is opening for them or not

<rrobin>untrusem: guix shell josm -- josm # opens ok here

<untrusem>rrobin: it just gives me white screen

<rrobin>/gnu/store/igxpn00xyszzazqfr1y2qgin2f86a8wg-josm-19412 for me. Is your version different?

<rrobin>i do see some warnings for missing svg or fonts, and some scaling issues in hidpi screen but it seems to be working

<untrusem>mine is 19412 to

<untrusem>mine is same as yours /gnu/store/igxpn00xyszzazqfr1y2qgin2f86a8wg-josm-19412/bin/josm

<rrobin>ok no idea then - fwiw i am using x11 here

<rrobin>do you see anything useful in the console output?

<untrusem>i do seen some severe: warning but they are related to svg, I am pasting them in pastebin

<untrusem>I am using niri, it is a wayland compositor

<untrusem> https://paste.debian.net/hidden/9bee1ce3/

<untrusem>rrobin,

<rrobin>the errors looki similar to mine - even the font family one looks the same

<untrusem>I am checking in the compositor channel now

<untrusem>maybe its related to wayland or wm specific

<untrusem>I am also trying if the nix package has the same problem or nor

<kjartano`>Another Niri user here. Can confirm white screen here with /gnu/store/igxpn00xyszzazqfr1y2qgin2f86a8wg-josm-19412.

<untrusem>ok so its wayland specific

<untrusem>because nix josm package works for me

<untrusem>can some using a different wayland compositor test this

<rrobin>is this using javafx? closest i found was this https://bugs.openjdk.org/browse/JDK-8198738 maybe worth looking for similar stuff

<untrusem>I mean if nix package version is working, why won't guix one is working

<untrusem>if it was a javafx bug it should affect both, right?

<rrobin>no idea which versions are used with what - i tried reproducing here by running weston over x11, but no luck yet

<untrusem>nix has updated version

<untrusem>19439

<untrusem>I will try updating to it

<kjartano`>Same thing happens on Sway for me.

<untrusem>so its related to guix package then

<untrusem>so I think this is related to java gui not supporting wayland

<untrusem>found setting `_JAVA_AWT_WM_NONREPARENTING=1` works

<untrusem>I also updated it to the `19449`

<untrusem>how would I add this variable in the package itself, I don't think it would work in that way

<untrusem>also I think new java don't support gtk feel

<untrusem> https://github.com/NixOS/nixpkgs/issues/12472 nix has this issue

<nckx><how would I add this variable in the package itself> You'd probably wrap /bin/josm to set that environment variable, probably using wrap-script.

<untrusem>INFO: Look and Feel not supported: com.sun.java.swing.plaf.gtk.GTKLookAndFeel

<untrusem>will need to wrap this too

<Rutherther>does cuirass somehow handle grafts? ie. does it build with grafts disabled / enabled etc? can I say to a jobset if to enable/disable them?

<Rutherther>Aaaah, I think I am starting to get this. The implementations of the jobs are actually in guix source. And in the guix source I see grafts are turned off!

<untrusem>So I am trying to package this emacs package https://github.com/edrx/eev and I am facing some issues, I have explained it more througoly in the paste with the error and package defination included

<untrusem> https://paste.debian.net/hidden/d35e5ebd/

<ieure>untrusem, The file is most definitely test code, why do the non-test parts of this project try to load it?

<ieure>untrusem, I'd be inclined to use substitute* to remove (require 'eev-htests) from eev-load.el.

<untrusem>hmm let my try that

<ieure>You might need to be careful with the order there, if you remove the line before tests run, they will probably break.

<tusharhero>untrusem: is eev-load.el the autoload file?

<ieure>I'd file an upstream issue, non-test code shouldn't be loading tests.

<ieure>tusharhero, It's in the source repo: https://github.com/edrx/eev/blob/UTF-8/eev-load.el

<ieure>So no.

<tusharhero>huh

<ieure>I believe the autoload files have an -autoloads.el suffix.

<tusharhero>ieure: yup

<tusharhero><edrx> because I wanted to make eev have only a single autoload, and there are

<tusharhero> some docs-with-examples that use the functions defined in that file...

<tusharhero>it was intentional it seems

<ieure>Stil wrong IMO.

<ieure>*still

<tusharhero>the author is here!

<edrx>hi!

<edrx>let's see if I can help... =/

<FuncProgLinux>The power of emacs can summon everyone in seconds xD

<untrusem>edrx, you can follow the discussion from here

<untrusem> https://logs.guix.gnu.org/guix/2025-12-07.log#185249

<edrx>ok, read, but I still don't understand what is the error...

<edrx>how are you specifying the files that are included in the guix package?

<ieure>edrx, The emacs-build-system in Guix doesn't copy test code from the repo into the package output, so the require of eev-htests fails.

<ieure>Because eev-loads.el requires eev-htests

<edrx>ieure: how did it decide that eev-htests.el is a test?

<edrx>by the name?

<edrx>the thing is that eev needs to be usable by people who want very minimal setups

<edrx>and these people won't run eev-loads.el

<edrx>eev doesn't have any automated tests, btw...

<ieure>edrx, I haven't looked at the code, but I assume because of the name, yes.

<edrx>can we specify manually a list of .el files to include?

<ieure>This was tried, it doesn't appear to work. Why does the actual eev code depend on the tests at all, though?

<edrx>it doesn't

<ieure>Are you expecting end-users to run them after installing eev?

<edrx>in a sense yes

<edrx>eev blurs the distinction between user and programmer

<edrx>I expect people to follow links to the source code sometimes, and run the tests in comments

<ieure>Is eev-load part of the dev/test setup? Should it be omitted from the package?

<edrx>hmm

<edrx>I have a very extreme answer to that... let me tell it and then we can think on other options

<edrx>a person who wants a really minimal install of eev only needs the code that defined M-e to be equivalent to C-x C-e

<edrx>I have that somewhere - about 10 or 15 lines

<edrx>that's the essence of eev =(

<edrx>sorry, C-e C-x C-e

<edrx>but most people want the kitchen sink because it is easier to use

<edrx>some people asked me for a way to load only eepitch.el, for example... they didn't want the elisp hyperlinks

<edrx>do you have eev installed?

<ieure>No, never heard of it before today.

<edrx>hmm

<untrusem>now you have 🙂

<edrx>untrusem: can you try something in eev and give your opinion?

<untrusem>I can

<ieure>edrx, I'm confused why these are user needs at all. Don't autoloads solve this? I note that you're not autoloading anything other then eev-beginner.

<edrx>ieure: the other option would be to have several hundreds of autoloads, and I decided against that =(

<edrx>untrusem: try this,

<edrx>(find-eev "eev-htests.el" "tests")

<edrx>and run some of the tests with M-e

<edrx>that's how I test the functions that generate "hyperlinks to here"

<untrusem>give me 5 mins, I am also watching the emacsconf talk

<untrusem>🙂

<edrx>ok

<edrx>sure

<edrx>I found a solution

<edrx>ieure said this before I joined: "You might need to be careful with the order there, if you remove the line before tests run, they will probably break."

<edrx>eev doesn't run any tests automatically

<edrx>actually it doesn't run anything automatically

<ieure>edrx, The Guix emacs-build-system runs tests.

<ieure>During the package build; if the tests fail, the package build fails.

<edrx>so just comment out the line with (require 'eev-hlinks) in eev-load.el

<edrx>what if there are no tests?

<ieure>Then we put #:tests? #f in the package, and the build-system doesn't try to run them.

<edrx>then that's what we need to do

<ieure>Disable tests for eev?

<edrx>yes

<ieure>That isn't the problem at all, though.

<ieure>The problem is that the built package doesn't work.

<edrx>because of the (require 'eev-hlinks)?

<edrx>we can comment it out

<ieure>Because of that, and the fact that we generally don't ship test code to end-users.

<edrx>an "end user" of an emacs package is someone who never touches elisp?

<ieure>Not necessarily. I don't think anyone claimed that. The usecase is different. I don't care about running tests when using the package, only when developing it.

<ieure>And you don't develop by hacking on the installed package, you do it in the source repo.

<edrx>the tutorial of eev starts by showing that emacs is a lisp environment and so we can use elisp anywhere - and in eev we are going to use elisp as hyperlinks...

<edrx>can we mark eev as something that is "not for end users"? that would solve everything...

<ieure>I don't understand your proposal.

<ieure>I don't know of any Linux distro which has a "mark as not for end user" facility, or what that would even do.

<edrx>I think that eev does not fit into your distinction between end user and programmer/developer

<untrusem>edrx: I tested `(find-eev "eev-htests.el" "tests")` . What would you like to know?

<edrx>but let's solve the problems one by one

<edrx>untrusem: did you try the tests that use a 3-window setting?

<ieure>edrx, I have authored many Emacs packages which I both use and develop. When I use them, I use the installed package; when I develop them, I use the source repo. I never run tests on the installed package because there is no point. This is how basically everything across every language ecosystem I've used has worked. Why is eev's usecase different?

<edrx>let's 1) mark eev as having no tests, 2) delete eev-htests.el because its name can cause problems, 3) comment out the (require 'eev-hlinks) in eev-load.el

<untrusem>yes edrx, I think every there in there uses a 3 buffer setting

<edrx>untrusem: great!

<edrx>ieure: "test" and "automated test" are different things, and until some years ago people used a lot "tests" that were not "automated tests" - they were things that people would run by hand and inspect the result to see if they looked right

<identity>ieure: most distros have *-dev packages, which are ostensibly «not for end users»

<edrx>eev doesn't have any "automated tests" but lots of its documentation is in "tests that are not automated tests", that people can run by hand and look at the result

<edrx>these "tests that are not automated tests" are usually sexps in comments

<edrx>there is no way to delete them without rewriting everything

<ieure>edrx, Yes, I have worked in several systems which had no automated tests (like when I wrote C in the 90s). We still didn't ship the test code to users.

<edrx>eev expects that "users" will stop being "users" in 30 minutes or less

<ieure>"test code" being, like, a shell script we'd run or whatever

<ieure>Are they modifying the eev code itself?

<ieure>Or using its facilities to write their own code?

<edrx>hmm, imagine that you have an elisp file with this single file:

<edrx>;; (insert "hello")

<edrx>if a person executes that with C-e C-x C-e that will modify the current buffer

<edrx>the person is expected to recognize that she needs to run an undo after that

<edrx>in that sense there are a couple of places in eev in which if a person executes a sexp in comments that sexp will insert something in the current buffer

<edrx>eev also have functions that generate lisp code in temporary buffers, from templates

<ieure>That won't work at all Guix, because installed packages are immutable.

<ieure>So you'll just get an error that the file is read-only.

<untrusem>edrx, can you join the q&a with the gnu hyperbole author

<edrx>untrusem: no, I've had enough of hyperbole for this incarnation, thanks

<edrx>=(

<untrusem>lol, I remember, the first issue in the repo being about hyperbole

<edrx>yep =(

<untrusem>ieure, yeah that's what I was worried about too

<edrx>I've spent bazillions of hours trying to learn hyperbole to integrate eev and hyperbole and rsw never tried eev - and never anwered any of my technical questions about the lisp code in hyperbole...

<untrusem>as guix don't allow modifying package code.

<ieure>edrx, I think you're conflating usecases. There's testing the code you write which uses eev, and testing the eev itself. Right? Like, say, I'm sure jUnit has unit tests to make sure the library works, right? But that is a totally different usecase than tests written *in* jUnit, but *for* something else. Your usecases all seem to be the latter, but the problem is with the former.

<edrx>ieure: that's fine for me - advanced users can try other ways of installing eev if they want

<untrusem>I am beginning to think if installing through use-package is the only way edrx wants users to use the package

<edrx>but there are guix users that don't want to use use-package

<edrx>so let's create a guix package of eev for them

<ieure>Users using eev may need to test the stuff they're doing *with* eev, but that's not the same as tests *of* eev.

<untrusem>edrx yeah I already have a guix package 🙂

<identity>you do not need to use use-package for packages. there are also other package managers apart from package.el, like elpaca, and, who could have guessed, Guix!

<untrusem>yeah I mean that...

<edrx>ieure: many functions in eev are "documented" very briefly with just a line in comments that says something like this...

<edrx>;; Test: (find-einsert '("Greek:\n" (913 969) 10 "Bold:\n" (120276 120327)))

<edrx>that "test" runs `find-einsert', that created a temporary buffer and inserts some things there

<edrx>creates

<edrx>so instead of an explanation in text we have an example with an implicit "try this"

<edrx>and because of that people who want to learn eev will have to run the tests *of* eev

<edrx>identity: actually I don't use use-package... I use package.el

<identity>so you do not use the use-package package and prefer to use the package.el package for your package uses?

<edrx>identity: yes... but learning use-package is in my to-do list

<edrx>untrusem: btw, the tests for find-einsert are here:

<edrx>(find-eev "eev-blinks.el" "find-einsert")

<untrusem>👀

<edrx>and this test inserts something in the current buffer:

<edrx>;; Test: (ee-insert "\n;; " '(?a ?z) 32 "Foo")

<edrx>but there's no problem if it fails because the file is read-only

<untrusem>it all works fine

<edrx>wow <3 <3 <3

<untrusem>I am currently testing all this from elpa's eev package, not the guix one

<untrusem>edrx is there a communication channel for edrx

<untrusem>maybe an irc channel

<untrusem>sorry this is offtopic for this channel

<untrusem>I wanted to ask about things about hyperbole and maybe if we can use somethin in eev

<edrx>#eev

<basicnpc>Does guix implement state controls by executing idempotent check functions?

<basicnpc>For example, in the case where guix is managing firefox, some of the states are stored in ~/.mozilla/

<basicnpc>How does guix control it declaratively?

<ieure>basicnpc, It doesn't.

<ieure>Services can declaratively define configurations, but they drop links to the store where the program expects things, so they're immutable.

<ieure>I don't think there's a firefox-home-service-type in Guix, though I believe there's at least one uncontributed one floating around.

<basicnpc>Not even by guix home? (or is that irrelevant?)

<ieure>Not relevant.

<ieure>Guix Home uses a nearly identical services mechanism as Guix System.

<basicnpc>So they shouldn't be modifying an unmanaged file and making sure that file satisfies XYZ.

<ieure>That isn't how anything currently works, and while it's technically possible, I would strongly advise against it.

<basicnpc>What would you recommend when it comes to managing software (e.g. firefox, doomemacs.. etc) that likes to manage their own configs or dependencies in their own way?

<ieure>Let them.

<basicnpc>ieure: I'm still on macos, so my best bet is nix. It modifies my firefox profile so my extensions are gone (they are not in the nix-store though). So I'm curious what guix does. I will migrate to guix when I have time. Good to survey first.

<Hamled>Rutherther: turns out I was just misunderstanding the potential use cases for elogind, I associated it more with a desktop configuration in order to support a display manager for logging in, but it seems to work fine for this configuration as well

<civodul>hey! a change with ~150 rebuilds is fine for ‘master’, right?

<civodul>maybe more of a question for noe and Rutherther and efraim and others on the release team

<Rutherther>it definitely is if it doesn't change anything from release manifests and if it does, it would be good if it didn't break it

<Rutherther>hm, anyone seen an inferior-exception from cuirass when evaluating a channel could not find repository at "/gnu/store/<profile>", being path to the built profile with the specified channel(s)? Seems to occur after the guix inferior is built

<Rutherther>it seems like it's trying to update cached checkout from the store path? but the store path doesn't have .git

<ieure>Anyone have an example of an X11 setup with a screen locker of some sort? This is a gap in my current setup vs. my old Debian box.

<ieure>I was using xss-lock & xscreensaver before, which launched from my .xsessionrc.

<Rutherther>re cuirass issue, I think it's because of (current-guix)

<fnat>I'm using QMK's `qmk setup` for the first after a while and it seems to require `arm-none-eabi-gcc`.

<fnat>Anyone knows if this is provided by any Guix package or via any other channel? Or, rather, if there's a way to run `qmk setup` that doesn't require `arm-none-eabi-gcc`?

<ieure>fnat, Do you need to run `qmk setup' with the Guix QMK package?

<ieure>I've never used it like that, but I'd assume the package does all the needed setup and it's ready to use after installation.

<ieure>(I have used QMK, but not in a good while, and `qmk setup' didn't exist last I got up in it)

<fnat>ieure: Yeah, I thought of setting up a Guix Shell environment with QMK and then running it from within there.

<fnat>I'm pretty sure I've used it like this at some point in the past.

<ieure>fnat, A think I've noticed Guix is missing is something like README.Debian, which explains how the package is supposed to be used.

<ieure>Package description is the only thing kind of like this, and IMO is not the right tool.

<fnat>Lol, I've got this note from when I used it before that says "This complains that it can't find arm-none-eabi-gcc. It's fine, don't worry."

<ieure>lol

<fnat>Apparently I can go on and run things like `qmk compile -kb ...` anyway. Ok, cool, fine then.

<fnat>Thanks ieure.

<ieure>I did nothing at all, but you're welcome.

<fnat>You did! I appreciate your time. And I think you've helped me before too.

<ieure>Thank you for the kind words.

<Rutherther>fnat: to get arm none eabi, there is a procedure that produces a package, I think (make-arm-none-eabi-toolchain). But as long as your target mcu is not arm, you should be fine without it