IRC channel logs

<mra>ekaitz: yeah, i suspect so. ah, well

<ekaitz>you could make some other simpler changes that I can push :)

<mra>ekaitz: i'll do that when i think of some simpler changes to make!

<mra>unfortunately i've been pretty hyperfixated on ZFS support. haven't really done anything related to much else

<PotentialUser-83>Hello. How can I set a variable EDITOR, for example: neovim for using it with sudoedit?

<ekaitz>PotentialUser-83: if you `man sudoedit` you'll find:

<ekaitz>-e, --edit: ... the following steps are taken: The editor specified by the policy is run to edit the temporary files. The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that order). If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.

<ekaitz>so it's the same as any editor

<ekaitz>there are several ways to set that: in your .bashrc, adding `export EDITOR=neovim`

<ekaitz>well, no, it's "nvim" instead of "neovim"

<NaN23>Hello everyone! I started using guix about 6 months ago and I love it. Sorry for any clumsiness, it's the first time on IRC since about 20y... I think I first have to set up a bouncer or something similar. I want to contribute to the community and maybe also have questions once in a while. One problem which finally drove me here is the following: Since a recent update audio output stopped working.

<NaN23>I'm using pipewire on a self-knitted system (encrypted root, %desktop-services, xmonad, ...) on my laptop. pavucontrol does not detect any audio cards (but they are there). I assume a dbus problem, because when I stop the user's dbus service and start it again audio starts working (but not by simple restart!). Did anybody have had similar problems recently?

<ekaitz>NaN23: welcome! take a look to the issues we have open: https://codeberg.org/guix/guix/issues

<PotentialUser-83>Thank you it worked. I just thought that I need to write full path for example like /usr/bin/nvim. But what if someday I would need to set full path to binary. Gnu store profile to binary changes after each update is not it?

<NaN23>You may generate the path to the used binary using a gexp in your system or home definition.

<NaN23>In your example it would be #$(file-append neovim "/bin/nvim")

<PotentialUser-83>Thanks

<ekaitz>PotentialUser-83: most of the times you don't need to do that. Guix makes almost everything work magically using search paths. In fact, we patch most of the guix software to support that. In cases we cannot do, you can still do things like what NaN23 said.

<morte>quick question, is there no Xephyr for guix? Or where can I find it?

<ekaitz>morte: is that the libx tool that lets you have nested sessions?

<morte>correct, that one

<ekaitz>morte: we do have it, but i don't remember the package name :)

<ekaitz>morte: xorg-server?!

<ekaitz>oh there you go: xorg-server provides it

<morte>yeah, you are right, I thought that by running a x11 session that was included

<morte>but thank you

<ekaitz>i thought that too!

<morte>but it's working now, thank you ekaitz

<ekaitz>morte: no problem!

<NaN23>ekaitz: Thank's I have look and will look for issues where I can help. I also didn't found anything related to my problem and will open an issue after my account registration succeded.

<ekaitz>NaN23: yeah please open it

<NaN23>Will someone here be at 39C3 this year?

<ekaitz>NaN23: better ask in around... 6/7 hours most of Guix is located in EU and they are sleeping now

<ekaitz>ACTION should be sleeping too

<NaN23>haha thanks, yeah me, too! And 39C3 will happen in Hamburg, Germany. Will ask again later, thanks! :)

<NaN23>oh, just realized which time it is...

<apteryx>ACTION is drowning in codeberg notifications

<apteryx>seems something is not functioning correctly, I get notifications for changes in scopes (teams) I'm not part of.

<bavier>apteryx: are you "watching" the guix repo on codeberg?

<apteryx>yes! but I didn't do that, I think

<apteryx>I've unwatched it now

<apteryx>the teams.scm script must have a bug that causes this, perhaps?

<apteryx>when syncing team members

<bavier>that could be, I don't recall setting a watch either.

<apteryx>I commented here in case https://codeberg.org/guix/guix/pulls/3575#issuecomment-7768253

<kestrelwx>Morning!

<efraim>o/

<ekaitz>apteryx: in icedove I don't have a calendar now since the update for testing the issue

<apteryx>yes, there's another issue for that one :-(

<ekaitz>fuck

<ekaitz>this is important for me

<ekaitz>and installing it for testing changed my profile, so I cannot install an older version

<apteryx>ah, it no longer works?

<ekaitz>nope it doesnt

<ekaitz>ACTION is very mad right now

<ekaitz>maybe it's time to move to another software that I can fix

<apteryx>is there a vanilla thunderbird package in nonguix to test against?

<apteryx>I don't think so right

<apteryx>when I tried to troubleshoot the menu I rebuilt in a clean git tree without using the icecat source and still hit it

<ekaitz>nope

<apteryx>I'll give debugging it another try soon

<ekaitz>but do we touch anything special?

<ekaitz>is this broken for everyone?

<apteryx>seems to be just us from my queries in the matrix channel

<apteryx>we do some hacks like rebranding, which renames stuff in the source, could break something

<ekaitz>i'll try to take a look at it (I NEED IT)

<apteryx>I've asked mozilla if we could simply distribute thunderbird without rebranding, with some patching for Guix/FSDG. Their distribution policy is stiff: https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/

<apteryx>(haven't had a reply in 6 weeks, just refreshed them on it today)

<ekaitz>also, btw, does anyone recommend a calendar application that I can use in the meantime?

<apteryx>I use GNOME's one. It's now awesome (doesn't send notifications).

<apteryx>not* awesome

<apteryx>but otherwise it's OK

<ekaitz>okay...

<ekaitz>ACTION is sad

<tpbsd>ekaitz, I use 'calcurse' it's a cli app, but does import ical files, it's simple and reliable

<ekaitz>tpbsd: that sounds cool

<tpbsd>and it's a nixos package so easy to install

<ekaitz>that i don't like that much

<ekaitz>apteryx: i have to go now but I think i can fix firefox calendar

<tpbsd>well it's also a package on all other distros inc FreeBSD

<ekaitz>** not firefox -> icedove

<tpbsd>oops apologies to this channel, I thought I was replying to a nixos channel <doh>

<tpbsd>Im just lurking here as I currently use nixos and I'm considering installing guix to see if I like it

<tpbsd>I've downloaded the guix image and notes etc

<tpbsd>and I love Racket, but I'm still a LISP noob

<apteryx>ekaitz: that'd be nice!

<apteryx>I have a family member who is also not very happy about the situation ^^'

<tpbsd>I've only been using nixos for about 2 months and came from FreeBSD and Linux before that back to 1994

<apteryx>tpbsd: welcome!

<tpbsd>apteryx, thanks :)

<tpbsd>Im also a Forth addict, but for embedded design

<efraim>I forgot that running the system tests re-adjusted the wrapping of the screen session. I know that at least 3 encrypted-root tests failed, but I don't know about the rest :/

<efraim>looks like they timed out

<Rutherther>I think they were also timing out for me

<Rutherther>I don't know about you, but I've used the make system-check that has --keep-failed so the tests that do not finish are in /tmp and the tests that do finish have their log output in the store

<Rutherther>something like this "find /gnu/store -iname "*.log" -maxdepth 2" should find all the tests in the store, with possibility of some false positives. Maybe it would be good if there were some scripts that gave you info about the tests. Currently I am quite unable to obtain anything as I cannot really let the system-check finish due to lack of space

<efraim>that's a good idea with --keep-failed

<efraim>I bumped the sizes of the images in gnu/tests/install so right now I'm just running those ones. It takes so long to calculate how to run the tests I don't want to run them all at once anyway

<efraim>but I figured I'd start with the failing ones here https://ci.guix.gnu.org/jobset/tests

<jlicht>o/ guix

<gabber`>\o

<andreas-e>Hello!

<ekaitz>apteryx: did find the modules/calendar/Ical.sys.mjs file? where is that?

<ekaitz>okay got it

<listentolist>The documentation says that the `unattended upgrade service` upgrades every Sunday at midnight by default. So if the system is not running on Sunday at midnight but on the next day there will be no upgrade?

<listentolist>In general are those mcron timers more suitable on systems that are always running?

<Rutherther>there is no mcron timer, unattended upgrade service uses a shepherd timer

<Rutherther>but I don't know if it will execute or not. I am pretty sure it would if you computer has been sleeping only, but not sure if it will when it's turned off completely

<Deltafire>i think it's a feature planned for the next major release of shepherd

<listentolist>Rutherther: Thank you. In the documentation it's written: "It sets up an mcron job (see Scheduled Job Execution) that runs guix system reconfigure from [...]"

<Rutherther>yeah, seems that no one has updated the docs since the change earlier this year

<ekaitz>apteryx: updating libical just in case

<kjartano`>Rutherther: would that update be anything more than replacing that mention of mcron with shepherd timers?

<apteryx>ekaitz: I think Debian may have had that issue

<apteryx>worth searching

<Rutherther>kjartano: I would thin so, but I didn't study the details

<kjartano`>Glancing through the page I can't see anything else, so I will submit a patch that does just that.

<ekaitz>apteryx: yeah... while i rebuild the world for no reason...

<kjartano`>PR opened: https://codeberg.org/guix/guix/pulls/3597

<ekaitz>uf i don't find anything

<ekaitz>apteryx: updating libical doesn't help, but it was worth a try

<ekaitz>i could try to debug this thing further but if every iteration is going to take 80 minutes... :( :(

<ekaitz>apteryx: OH maybe it's tzdata!

<apteryx>could it be jut that?

<ekaitz>yes!! looking at the errors it says 2025a

<apteryx>I hope so!

<apteryx>too old? or

<ekaitz>and ;; TODO: tzdata 2024a expected – find a way to regenerate

<ekaitz>that's in our code

<ekaitz>i don't think it expects tzdata 2024a anymore

<ekaitz>hehehe

<apteryx>ACTION tries to wrap up the unshare crash saga

<ekaitz>apteryx: the funny thing is I have no idea how this thing relates to tzdata and how should I add it

<ekaitz>icu4c looks related

<ekaitz>apteryx: since 2024b CET is considered obsolete and it's called MET

<ekaitz>that might be some part of the problem?

<ekaitz>updating tzdata triggers a world rebuild...

<apteryx>ekaitz: maybe we can have a tzdata-next ?

<efraim>check it against tzdata-for-tests

<ekaitz>hmmm...

<ekaitz>i'm not sure if I get what you guys mean :)

<efraim>copy the definition of tzdata to tzdata-for-tests so that package stays and then try upgrading tzdata

<ekaitz>ook

<apteryx>I think I'd go with the classic tzdata-next, where you inherit from tzdata and bump its version there

<apteryx>and then you use that newer variant for icedove

<ekaitz>apteryx: icedove doesn't depend on tzdata directly

<apteryx>ah!

<Deltafire>ekaitz: i successfully downgraded Icedove, I think it may have complained the first time but otherwise it's working fine (on the older version)

<ekaitz>Deltafire: but doesn't it break your profile?

<Deltafire>no.. but i only used the new version very briefly

<Deltafire>a few minutes perhaps, before realising it's totally borked

<Deltafire>and my calender is stored on a remote caldav, not local.. maybe that's why i could revert

<ekaitz>Deltafire: did you use an inferior for the rollback or what did you do?

<Deltafire>used an inferior

<Deltafire>my config files are slowly getting various "temporary fixes"

<ekaitz>ooh id don't really want to do that

<Deltafire>my neither, but i need Icedove to work

<ekaitz>:(

<Deltafire>i've pinned it to commit 91188fc691175ce44a2f4ef7aeb911b4c135e984 for now

<Deltafire>(the one before the update)

<ekaitz>apteryx: I'm giving up for today, i'd say the problem is related with all the TODOs and FIXMEs the icedove package has

<Deltafire>i was wondering if there's a version mis-match between the various components

<apteryx>ekaitz: I think most of the unbundling things are on icecat

<apteryx>(FIXMEs)

<apteryx>I don't see TODOs or FIXMEs on icedove in (gnu packages gnuzilla)?

<ekaitz>oh! debugging session was too long

<ekaitz>they are in mozjs

<ekaitz>you are right

<ekaitz>Deltafire: A newer version of Icedove may have made changes to your profile which are no longer compatible with this older version. Use this profile only with that newer version, or create a new profile for this installation of Daily. Creating a new profile requires setting up your accounts, calendars and add-ons again.

<ekaitz>:(

<apteryx>I think I had tried a build of pristine thunderbird sources with guix shell -D icedove and I had similar problems (without rebranding it).

<apteryx>so if that's still true that'd point to our inputs

<apteryx>rather than our rebranding/recipe specifics

<apteryx>that report would have been for the upstream bug about the menu

<apteryx>I should test this build and see if the calendar is also borked

<ekaitz>apteryx: oh yes! that's a good idea

<apteryx>jlicht: I think we're reaching a good solution for the shell crash: https://codeberg.org/guix/guix/pulls/3603

<apteryx>ekaitz: yeah, here were my repro steps: https://bugzilla.mozilla.org/show_bug.cgi?id=1989158#c0

<apteryx>and then in https://matrix.to/#/#maildev:mozilla.org it looks like thunderbird devs don't reproduce it on their ends

<ekaitz>hmm

<apteryx>ekaitz: I need to plug some caldav server to test the calendar?

<apteryx>I still have that ./obj-x86_64-pc-linux-gnu/dist/bin/thunderbird build

<ekaitz>apteryx: id say so, yeah

<ekaitz>i managed to run the old one and make it work

<ekaitz>hehe

<ekaitz>it destroyed the ui a little bit but it's functional

<apteryx>so what should I test for the calendars, it seems to open at least

<ekaitz>apteryx: CTRL-3 shouldn't work, and settings -> calendar shouldn't open

<ekaitz>what do you have in the logs?

<apteryx>Ctrl-3 brings me to the calendar, yes

<ekaitz>does it complain about the timezone or anything?

<apteryx>lots of garbage

<ekaitz>heh

<ekaitz>apteryx: something like: resource:///modules/calendar/Ical.sys.mjs, line 1942: ParserError: invalid line (no token ";" or ":") "Europe/London[2025a]"

<apteryx>let me restart it in M-x shell

<apteryx>ekaitz: on a 2nd run, I can't access the calendar anymore ^^'

<ekaitz>hehe

<ekaitz>and what log do you see?

<apteryx>it means we're not far and it's probably just a menu glitch thing, like for that app menu one

<apteryx>I do have JavaScript error: resource:///modules/calendar/Ical.sys.mjs, line 1942: ParserError: invalid line (no token ";" or ":") "Asia/Tokyo[2025a]"

<apteryx> https://paste.guixotic.coop/_shell_-173-18025.html

<ekaitz>apteryx: that's the main issue for the calendar I'd say

<ekaitz>but it's very hard to find the specific file that triggers that

<apteryx>we could graft it

<ekaitz>and: "TypeError: can't access property "find", window.gSpacesToolbar.spaces is null" is also wierd

<apteryx>or maybe I can ping the devs again, the soft should be more robust than this

<ekaitz>the question i have is I don't know which file is triggering that issue and why

<apteryx>so it's very strange, it appears to be an upstream bug triggered uniquely with the Guix inputs, I suppose.

<ekaitz>looks like "Asia/Tokyo[2025a]" is not valid because "[2025a]" is not a valid part of the identifier

<ekaitz>that's what I found before, but who is generating that?

<ekaitz>tzdata?

<ekaitz>the ical files?

<apteryx>ical? I don't know.

<ekaitz>if we could know where those are coming from we would be able to reproduce better

<apteryx>let's start grepping thunderbird/firefox

<untrusem>what do you use to theme gtk and qt apps in niri?

<untrusem>in guix*

<ekaitz>can we edit Ical.sys.mjs and make it dump the whole file?

<untrusem>I use niri wm, not a DE

<ekaitz>untrusem: i have some environment variable for dark theme

<ekaitz>i use i3

<ekaitz>untrusem: (simple-service 'adwaita-dark-theme session-environment-service-type '(("GTK_THEME" . "Adwaita:dark")))

<untrusem>ohh cool I have your config cloned :P

<ekaitz>untrusem: bad idea :)

<ekaitz>i hate configuring things

<apteryx>welcome to GNOME, where you can't

<untrusem>ohh you are in wrong place then :P

<untrusem>you might hate configuring, but I know you like reconfiguring :P

<untrusem>ohh I have cloned bunch of configs and steal things from them

<untrusem>mwa haha

<untrusem>what is the future of gnome if it gets too dependent on systemd in near future

<Deltafire>guix remains on Gnome 46 for ever...

<ekaitz>apteryx: i'm reading the Ical.sys.mjs file and it fails in the line 2054

<ekaitz>there's a parse function in 1875

<ekaitz>there we could dump `input` and see what happens

<apteryx>where's the source for that file at?

<ekaitz>apteryx: comm/calendar/base/modules/Ical.sys.mjs

<apteryx>thanks, couldn't find it with git because of that weird git + hg split

<apteryx>I need a js language server

<ekaitz>i never use any language server :)

<apteryx>looks like the fun happens in handleContentLine

<ekaitz>yes, but if you go to `parse` you could dump the whole input and see what it actually is

<ekaitz>i'm trying to go even higher in the call chain so i find the filename that fails or something

<apteryx>I think I could debug this directly in the web console perhaps

<ekaitz>maybe

<apteryx>(of thunderbird)

<ekaitz>ACTION has to go :(

<apteryx>yeah, I'll have to sleep too

<apteryx>but Ctrl-Shift-I in Icedove brings you the console

<apteryx>and then you can search for handleContentLine in the debugger and put a breakpoint on it

<ekaitz>yes, i tried a little bit before

<apteryx>the [2025a] suffixes come from newer tzdata (2025)

<apteryx>2024 didn't have it, I think.

<apteryx>Either we downgrade tzdata or fix the parser

<apteryx>I can look into that later

<apteryx>fixing the parser looks easier

<apteryx>ACTION -> zzz

<yelninei>ACTION rebuilds glibc for the 3rd time today

<mra>was just trawling through the daemon code, and there are some conditional compilation directive which seem strange. consider https://codeberg.org/guix/guix/src/branch/master/nix/nix-daemon/guix-daemon.cc#L492-L494 for instance. i grepped the entire guix repo, and i can only find two other references to HAVE_CHROOT, neither of which define it

<mra>i can't actually tell where this gets defined. is it an automake thing that i'm misunderstanding?

<mra>because it seems like compilation should fail if it's not defined

<kjartanoli>Based on the name I would expect it to be set based on some test performed by the configure script.

<ekaitz>mra: that looks like autotools magic

<mra>ekaitz: man, that feels sketchy as hell

<ekaitz>mra: D["HAVE_CHROOT"]=" 1" <-- my config.status has this

<ekaitz>mra: that's configure scripts were designed for :) sketchy things

<ekaitz>with the weird space included " 1"

<mra>ekaitz: oh, yep, mine has it too. i wonder why it didn't show up when i grepped the repo

<ekaitz>mra: if you greped with ripgrep or git grep... the config.status is gitignored

<mra>ah, ripgrep has outsmarted me then

<ekaitz>mra: it happens :)

<mra>the daemon contains some... pretty impressive mazes of conditional compilation directives

<mra>i also just found out the other day that the building of derivations is basically implemented by a single 500-line-long function lol

<ekaitz>mra: classic C/C++... you should try to work in the bootstrapping for a couple of years, it's a lot of fun

<mra>ekaitz: i reckon i have enough struggles in my life without interacting with C/C++ regularly

<ekaitz>:)

<mra>although my ongoing quest to understand the innards of the daemon may turn out to be comparably torturous

<untrusem>do guix sops have age integration like nix?

<luca>Hi, does anyone else have issues running `guix build prosody`? I get a weird error I haven't seen before https://lucamatei.com/paste/24512aa9-b974-44bc-bdb0-72af337f4f11.txt

<jlicht>apteryx: not amazing, but the npm-binary importer should handle importing the typescript-language-server package (not built from preferred sources, obviously)

<jlicht>if you just drop a jsconfig.json in the directory where you are working, and perhaps a package.json file with a (dev)dependency of typescript in there, it should just work (with eglot)

<csantosb>Ey Guix, anyone knows if there is an equivalent of `#$(this-package-input ...)` for propagated inputs ?

<csantosb>Or is there any one means to refer to them ?

<ekaitz>csantosb: you can use that

<ekaitz>csantosb: guix/packages.scm:853

<csantosb>Funny. This is accepted: `(format #t "~a\n" (assoc-ref %build-inputs "PACKAGE"))`

<csantosb>But not this: `(format #t "~a\n" $(this-package-input "PACKAGE"))`

<csantosb>But you're right, ekaitz, it should

<ekaitz>csantosb: #~(format ...?

<ekaitz>and also #$

<csantosb>I include this kind of "printf" in a phase for debugging

<ekaitz>csantosb: you arent missing the #?

<csantosb>This is it, thank-you once more !

<csantosb>The "unbound-variable #f" message made me think the package was not found

<ekaitz>csantosb: look, the sexp thingies are called reader macros, and they are introduced by #

<ekaitz>you shouldn't forget it now

<ekaitz>in scheme vectors are also that #(...) and block comments too #;...

<ekaitz>or #|

<ekaitz>csantosb: # is the way

<csantosb>Too many hieroglyphs for me late at night 😫

<csantosb>I was trying to avoid cleaning up the dirty "yosys -m '$GUIX_PROFILE/lib/yosys/ghdl.so'" alias I need

<csantosb>But writing to propagated inputs is not accepted, and I cannot build the plugin in guix using ghdl in guix-science, so no luck

<ekaitz>hehe just remember everything that is not parenthesis in scheme needs some #

<ekaitz>csantosb: but you can wrap-program

<ekaitz>that might help

<ekaitz>or... do you need a propagated input for that? a normal input could do

<csantosb>My favourite is #$@

<ekaitz>csantosb: haah but that's the same thing! # is for the reader macro introduction! and the rest is for you to remember the splicing!

<csantosb>Well, when building `ghdl-yosys-plugin`, a plugin for `yosys`, I propagate the later; it doesn't make sense otherwise

<ekaitz>csantosb: shouldn't a #~(invoke "yosys" "-m" #$ghdl-yosys-plugin) do?

<ekaitz>or whatever the (string-append #$ghdl-yosys-plugin "/lib/yosys/ghdl.so")

<csantosb>It could: but the plugin lives in `guix-science`, due to its dependency on `ghdl-llvm`

<ekaitz>for plugins we normally have env vars and then we set them

<csantosb>Looking forward to gnat bootstraping !

<ekaitz>that way you could do it anyway

<ekaitz>look at how kicad does that

<MamboTango>I'm having an issue with the additional channel I set up. It seems stuck somehow: I can `guix pull` it to update it, confirm with `guix describe` that it's on the most recent commit but when I `guix search` (or guix install) any package on that channel, its version is the old one. Does anyone know what is happening?

<MamboTango>Hello by the way! (sorry)

<csantosb>ekaitz, I'll have a look at kicad

<kjartano`>MamboTango: what is the result of `which guix`?

<MamboTango>Hello kjartano`! The result is /home/baptiste/.config/guix/current/bin/guix

<kjartano`>Ok, that is what it should be, so its weird if updates on that channel are not visible.

<kjartano`>Which channel is this?

<MamboTango>nonguix

<MamboTango>I noticed also that installing packages through the system does install them at their latest version

<kjartano`>Strange

<ekaitz>MamboTango: when you guix pull what happens?

<kjartano`>I have never seen this happen, but I don't have nonguix in my user profile. I do have additional channels there though.

<MamboTango>ekaitz: Nothing out of the ordinary: https://paste.debian.net/1401381/

<ekaitz>are those the latest commits?

<ekaitz>guix search shows the latest version?

<MamboTango>ekaitz: Those are the latest commits indeed. And guix search still shows old versions: https://paste.debian.net/1401382/

<ekaitz>MamboTango: you have a channel with a bug?

<ekaitz>i mean -> error: linux-libre-6.15: unbound variable

<MamboTango>The latest version of Firefox is 143 (https://gitlab.com/nonguix/nonguix/-/blame/master/nongnu/packages/mozilla.scm?ref_type=heads#L538)

<MamboTango>I've seen that linux-libre error from time to time. I think it occurs because nonguix is referencing a package from guix that has been removed from there

<ekaitz>MamboTango: i don't have that error

IRC channel logs

2025-10-17.log