IRC channel logs

2026-01-12.log

back to list of logs

<Deltafire>is a newer version of Python in the pipeline?
<Deltafire>current version means that Blender is 2 major versions behind current release :(
<ieure>Deltafire, 3.12 is available in the python-team branch.
<ieure>Deltafire, I don't think 3.13 or later have been packaged. You could probably email the python-team if you want to help.
<Deltafire>i think 3.12 is enough for Blender
<Deltafire>just spotted a Python-next, maybe i could make a Blender-next that depends on that
<bdju>Is there an example/skeleton file for ~/.config/fontconfig/fonts.conf somewhere I can take? I don't have one on my system and wanted to start editing it.
<bdju>I found the various ##.config files in the store but I think they're all for more specific use-cases or enabling certain features.
<mange>You've checked the ones in the fontconfig output? "ls $(guix build fontconfig | tail -n 1)/share/fontconfig/conf.avail". 05-reset-dirs-sample.conf sounds like it's pretty minimal?
<efraim>sneek: seen dannym
<sneek>dynamoe was last seen in #guix 5 months ago, saying: bye.
<efraim>sneek: botsnack
<sneek>:)
<pamiro>Hi. I'm quite new to guix and was looking for documentation for use-*-modules which are used in the manual but not documented there. In the end I found the gnu.scm source guix source file which defines the macros and I think I now understand them. My question is that, is there some documentation I don't know about because I feel like use-*-modules should be documented somewhere?
<efraim>I need more coffee. Just realized sneek didn't actually give me useful information
<efraim>pamiro: I'm not sure, I mostly just glossed over it when I first came across those. There's probably a spot in the manual somewhere it could be mentioned
<civodul>Hello Guix!
<civodul>the “freeze” on ‘master’ is not all that cold :-)
<janneke>civodul: yeah /me and andreas-e also wondered a bit about that
<janneke>also, many patches wrt hurd and installer :)
<civodul>janneke: yes! the Hurd gets all the attention these days :-)
<civodul>glad you added x86_64 support, BTW
<janneke>civodul: interesting how amongst the four of us we all came up with an (experimental) suffix :)
<janneke>and how Rutherther and i found two or three bugs on that page
<pamiro>efraim: Yep, I think they should be mentioned as they are used in the manual. I'll take note of this and when I get conformable with guix, I think I can try to contribute a patch for it.
<civodul>janneke: heh :-)
<civodul>i guess i should close the PR i opened because it’s all covered in your pull requests
<janneke>:) i thought about splitting the three aspects in three commits...but yeah, they're related and pretty small fixes so...
<efraim>All I can say about the ntp test failures on ppc64le is that debian dropped ntpd for systemd-timedated, before that they ignored test failures on ppc64le, the bugzilla requires registration to search, and the source is kept with bitkeeper
<apteryx>civodul: hello! is it me or the 'repository' argument in that syntax is not used/useful? https://codeberg.org/guix/guix/src/branch/master/guix/git.scm#L358
<apteryx>its being bound anew in call-with-repository
<apteryx>civodul: ah, nevermind; it is to provide the variable name to be bound. It was a bit confusing in the context of submodules, where repository is already an object.
<mthl>Hello, I'm still looking for some committer to look at my PR which improves Clojure packages <https://codeberg.org/guix/guix/pulls/5162> is merging it into master compatible with current freeze ?
<gabber>mthl: i think everything but bug-fixes go to next-master currently
<civodul>apteryx: salut ! the ‘repository’ argument to the macro should be an identifier, and it’s that identifier that is used for the lambda’s format parameter
<civodul>*formal parameter
<apteryx>merci!
<Guest10>Hi, i wonder if anyone has a setup for flashing qmk keyboards using guix they would like to share? I found make-qmk-firmware which is quite nice, but i wonder what the best way to flash the created firmware would be
<Guest10>just make a shell with qmk in it?
<gabber>Guest10: +1
<gabber>Guest10: if you don't get a satisfying answer here, please ask on the help-guix mailing list. it has a greater reach and has some more persistence (it is archived and searchable)
<yelninei>gabber: Btw were you the one with the issue of not being able to log in to a childhurd
<gabber>yelninei: last time i tried, yes (:
<gabber>why?
<gabber>but that's been quite a while
<yelninei>I found the issue and opened a pr for it yesterday. With that it should work again as long as you have an inital password set
<gabber>yelninei: cool! thanks for the heads up!
<gabber>yelninei: #5538 i presume?
<yelninei>yes, and the pr is at 5543
<yelninei>processing the irc logs with htmlprag and match is exremely convenient, i would have not found the message in my local logs
<janneke>yelninei: i believe it was Rutherther who reported it?
<yelninei>janneke: yes but gabber said something about not being able to log in several months ago
<yelninei>specifially on 2025-09-30
<janneke>yelninei: ah, ok
<yelninei>but it was problaby broken since the update to glibc 2.39 with the removel of libcrypt
<janneke>yelninei: that makes sense
<janneke>ah, and Rutherther acked the fix; great!
<janneke>wow, another 20min build on master, istm that everyone's still just pushing there?
<kestrelwx>Hello!
<sneek>kestrelwx, you have 1 message!
<sneek>kestrelwx, apteryx says: perhaps you would like to review a new update to Jami? https://codeberg.org/guix/guix/pulls/5330
<kestrelwx>apteryx: Hi, sorry I missed this. I'll have some free time starting this February after my midterms.
<kestrelwx>Also, thanks for updating Jami. I haven't used the desktop version recently, but the daemon seems much better recently. It managed to resolve conversations that previously were desynced for weeks.
<FuncProgLinux>o/
<gabber>\o
<RavenJoad>Where would code generators go in Guix? I want to package up GNU lightning. Looking around, commencement seems the best spot, but that does not feel the most appropriate.
<gabber>RavenJoad: i think commencement is for bootstrapping utilities (see the `Commentary:` line at l78)
<cbaines>RavenJoad, commencement relates to the Guix bootstrap, I think the assembly module would be better
<RavenJoad>Right. I don't see a jit.scm. It could go in c.scm, but I wanted more insights first.
<yelninei>is this the same lightning that is already in assembly?
<identity>probably
<RavenJoad>Oh yes! Turns out my spelling has been bad today. "guix shell lightening" did not turn anything up. :P
<identity>lightening is the lightning fork that Guile uses
<RavenJoad>When I search lightening, I get a bunch of RGB Common Lisp packages.
<gabber>RavenJoad: you seem to have a spelling error there
<gabber>(an extra `e' after the `t')
<RavenJoad>Yep, that was what I just discovered. Turns out I just cannot type today. (I would have thought it weird that a GNU project like that was not in Guix already.)
<gabber>don't be too hard to yourself: this happens to the best!
<gabber>maybe you can use the suddenly gained time (that you don't have to package lightning) to treat yourself somehow?
<RavenJoad>I get to recompile stuff and run more simulations instead!
<gabber>this does sound nice, too (:
<GNUtoo>hi, how is the Guix website published exactly?
<GNUtoo>I've been looking in the guix and artwork repositories and I can't find what I'm looking for
<GNUtoo>I'm lookng for why this URL isn't valid anymore: https://web.archive.org/web/20240620144503/https://guix.gnu.org/en/manual/devel/en/ , like is there a commit somewhere?
<GNUtoo>According to archive.org /en/manual/devel/en/ was valid the 20 June 2024, and v1.4.0 has been published the 18 December 2022, but everything pre-1.4.0 I look seems to publish the manual in guix.gnu.org/manual
<cbaines>GNUtoo, could be https://codeberg.org/guix/maintenance/commit/3de9f2119371038650045946ba6e7de6e90f68e5
<GNUtoo>Thanks a lot
<cbaines>you used to be able to access the devel manual by any URL containing /manual/devel and there were a few URLs going around
<cbaines>I forget if any redirects were introduced, but they can be
<GNUtoo>it's the double /en/ that went away, it's fine but I need to reference why in a commit
<cbaines>yeah, there was no significance of the /en at the start, it could have been /GNUtoo/manual/devel/en/ and it would have worked :)
<GNUtoo>ok, thanks a lot
<ieure>Still looking for some feedback on this: https://codeberg.org/guix/guix/pulls/5553#issuecomment-9740600
<GNUtoo>cbaines: so if I understand well, people did workaround manually somehow when uploading the website?
<cbaines>I'm not sure what you mean?
<GNUtoo>I'm mostly looking for the code that upload the website, but if it's in the maintenance repository, I can read the code and find it
<GNUtoo>(I didn't know or forgot that this repository existed, so thanks a lot for pointing it to me)
<GNUtoo>The commit you pointed to is useful, but guix.gnu.org/en/manual/devel/en/ now has 404 and it worked before, so there is something I don't understand. I'll look into the nginx syntax maybe I will understand what you meant after digging into it.
<GNUtoo>Ah maybe I understand now, the redirect you talked about was there before as ^ matches for the beginning, so in that case both URL worked at that time but for some reasons people used /en/[...]/en/
<GNUtoo>And now only [...]/en works, which is more logical, so people then adapted the URLs, and we should also do that.
<identity>‹/some/trash/here/manual/devel/etc› would get interpreted as ‹/manual/devel/etc› because of a miss-written regular expression
<GNUtoo>yes, I was just wondering why people used /en/manual then, but the mentionned commit is more than good enough to point to.
<identity>GNUtoo: maybe they got it from <https://guix.gnu.org/en/> + ‹manual/devel/en›
<GNUtoo>Also it's probably also me not knowing well nginx because I don't remember seeing the redirect direcly in the browser or the URL changing
<GNUtoo>But then I later saw /srv/guix-manual$1
<GNUtoo>so it starts making sense now
<GNUtoo>Thanks a lot for all the help, I woudn't have found it alone
<civodul>yelninei: hey! just replied to https://codeberg.org/guix/gash/pulls/12 , which i had forgotten about
<yelninei>civodul: The test passes without the fix aswell so it is not testing anything and hence the WIP. I think is something with the exception handler in srfi-64 and fork but i am not sure
<yelninei>by that i mean the test fails but the runner records it as passing
<civodul>yelninei: oh i see; srfi-64 in Guile < 3.0.11 would “convert” exceptions to #f
<civodul>best is to be explicit when you expect an exception, by adding a (catch …) form
<civodul>yelninei: you’re talking about the one call “external”, right?
<yelninei>yes. at the first group end it has it as an unexpected failure, at the second group end (?) as all passing. why are there 2 "Group end: lang" in the first place
<yelninei>i think it is a weird interaction with fork and the exception handlers. The builtins before downt spawn a child process
<civodul>yelninei: i hadn’t read your entire comment, apologies!
<civodul>i’ve now formulated a proper reply
<civodul>with a fix!
<ekaitz>civodul: sent a mini-fix to bootstrappable, just in case you want to merge it.
<ekaitz>:)
<yelninei>civodul: Thank you
<galois`>Hi. I'm brand new to Guix. What should I do first in order to be able to slowly get into contributing? Learn guile first?
<rodion_goritskov>Hi! For adding/updating/fixing packages deep knowledge of Guile is not required (:
<rodion_goritskov>You could start with the Contributing section in the manual https://guix.gnu.org/manual/devel/en/html_node/Contributing.html
<rodion_goritskov>And by looking at current MRs in https://codeberg.org/guix/guix
<civodul>galois`: some issues are marked as “good first issue”, meaning they’re considered a good thing to address as a first contribution: https://codeberg.org/guix/guix/issues?labels=660358
<civodul>hmm
<civodul>ACTION thinks that label was assigned to issues that may not qualify as “good first issues”
<Deltafire>none of them look particularly easy
<galois`>Cool. I'll have a look! Even if you think it may not qualify as good first issues :D
<galois`>rodion_goritskov: thanks
<civodul>well i don’t know, some don’t intuitively look as good first issues, but most do!
<galois`>Thank you civo! (I heard this is how you are called in the community :))
<civodul>heh
<civodul>yelninei: BTW, lemme know when you think we should tag a release of Gash
<civodul>with the goal of “unlocking” Coreutils etc. on ‘core-packages-team’
<galois`>Wait or was it Ludo? Luco?
<civodul>could well be the former :-)
<galois`>:D
<Rutherther>galois: have you tried reading the nick backwards?
<yelninei>civodul: I am preparing a fix for 3.0.11 tests right now, i think then it should be good
<galois`>Rutherther: I see :D
<yelninei>civodul: I am still not sure about my hacks to get mes to compile coreutils-mesboot 9.8 but it seems to work
<yelninei>And there is a weird race condition with having to remove the libcurl patch for $SSL_CERT_FILE/$SSL_CERT_DIR which might be solved by apteryx on gnome-team
<lilyp>which gnome-team patch in particular?
<janneke>Rutherther: thanks for the review; is #5515 ready to push or are we waiting for something (possibly the merge of #5543?)
<yelninei>lilyp: the p11-kit commits
<Rutherther>janneke: I think those are independent. And both ready to be merged
<yelninei>(but i have not tried yet, if indeed libcurl (and not the cli) have default certs with that)
<janneke>Rutherther: thanks, merged #5515
<Wurt>Hello, I have a question about mailcap package. Why does /gnu/store/*-mailcap-2.1.53/etc/mailcap refer to "/usr/bin/xdg-open" and not "/usr/bin/env xdg-open"? Is it a bug or I do not understand something crucial?
<Wurt>I am writing a package for rdrview and it needs a mailcap file, so I used (@ (gnu package mail) mailcap). Maybe should I use another package?