IRC channel logs
2026-01-23.log
back to list of logs
<ajarara>after a sysrq reboot (reboot hangs too so I gotta force things), the timer looks clean. Should I instead have it fork off? <ajarara>ah, figured it out, backgrounded it (remove -B). I knew shepherd is single threaded but diddn't expect it to hang on a command given, I expected it to hang on arbitrary scheme code though <mange>I don't expect shepherd to hang for a foreground process. The examples in the manual seem possibly long-running (e.g. guix gc), so if that's breaking things I'd say that's a problem. <ajarara>it's actually quite possible that I forgot to update from a broken definition before triggering. I had a definition that wrapped the command in a list, not realizing it was already in a list. When I restarted I saw the backtrace and fixed it, deployed, retriggered. I didn't update the definition. <ajarara>yup, added -B back, made sure to restart, retriggered, it shows it running under a child process now (with shepherd unblocked). Sorry for the false alarm! <mange>No worries. I'm happy with the good outcome. :) <n|phreak_>trying to get g-golf to work on my emacs session by running guix shell emacs guile g-golf guile-g-golf g-golf-gtk-4-examples emacs-geiser-guile -- emacs <n|phreak_>I can load oop goops but not g-golf or guile-g-golf <mange>The description for g-golf and guile-g-golf says: "Note: Currently, when developing with G-Golf in `guix shell', there is a grafts bug in Guix (https://bugs.gnu.org/75157). To avoid it, use Guix' `--no-grafts' option. Guix packages that use `wrap-program' are unaffected." <n|phreak_>When loading specific libraries using guix shell , do you still need to load a path also ? <mange>The shell should set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH, so Guile should be able to find what it needs from those. <mange>What's the problem you're having? This works for me: guix shell guile g-golf guile-g-golf g-golf-gtk-4-examples -- guile -c '(use-modules (g-golf))' <mange>But I don't know how to use g-golf, so I can't do anything more than testing the module loads. :) <oliverD>Ungoogle-chromium is out of date and when i run guix install it is still behind the chrome version is this normal? also I still cannot get into ether gmail or outlook because the default popup Icedove opens is incompatible with them. <mange>I just ran "guix shell emacs emacs-geiser-guile guile g-golf guile-g-golf g-golf-gtk-4-examples -- emacs", then did "M-x geiser" and ran "(use-modules (g-golf))" in the Geiser REPL and it seems to have worked. What's happening for you? <n|phreak_>hmm yeah doesn't work for me when calling emacs , thats on my side .. thanks <mange>Is it possible you have some other Guile/Geiser configuration hanging around that's breaking things? <oliverD>I have updated everything and spent a while searching and still cannot fix. <n|phreak_>hmm , I'm running the repl when emacs shows up <mange>oliverD: When you say the popup is "incompatible" with them, what do you mean? (I don't know anything about the ungoogled-chromium version issue.) <oliverD>The popup redirect me to page telling me to enable cookies. <oliverD>Or in the case of gmail that something is broken and to try again later <n|phreak_>I just tried with -- emacs -Q also and geiser doesn't even come up <vagrantc>and these ... seemed to succeed, even though they were expected to fail: XPASS: tests/toml.scm - parse-toml: Invalid assignment to implicit table ... XPASS: tests/toml.scm - parse-toml: Assignment to statically defined array <daviid>n|phreak_: can you try, in a terminal, not in emacs, the following <daviid>guix shell g-golf -D g-golf gtk --no-grafts <daviid>$(guix build g-golf-gtk-4-examples)/share/doc/g-golf/examples/gtk-4/.hello-world-real <daviid>[ *-real are the upstream version of the example <daviid>n|phreak_: not a guix user here, but the g-golf upstream author <n|phreak_>Ok , just looking at my guile load paths real quick <daviid>you ddon't need to, guix shell should take care of those ... <n|phreak_>I should be able to lauch a new emacs session just by emacs -Q right ? <daviid>n|phreak_: please just try the above first <daviid>ok, great - ofc you can try any upstream examples this way, including the awaita-1-demo, providing you add adw and call <daviid>guix shell g-golf -D g-golf gtk adw --no-grafts <mange>oliverD: How strange! It seems to work fine for me, as I test it. I get the Gmail login form, I can click through it. I also set up an account with Outlook through icedove last week. <daviid>$(guix build g-golf-gtk-4-examples)/share/doc/g-golf/examples/adw-1/.adwaita-1-demo-real (or what ever it is named in guix) <daviid>$(guix build g-golf-adw-1-examples)/share/doc/g-golf/examples/adw-1/.adwaita-1-demo-real <n|phreak_>ahh got it , very cool .. now I just have to figure out why geiser-repl won't load the library <daviid>n|phreak_: again, not a guix user, but i guess if you add emacs to the guix shell command, then you should be able to ... <daviid>guix shell g-golf -D g-golf gtk adw emacs emacs-geiser-guile --no-grafts; emacs then M-x geiser-guile then ,use (g-golf) <daviid>but i'll let guix expert hekp you there ... <daviid>or maybe guix shell g-golf emacs emacs-geiser-guile -D g-golf gtk adw <daviid>guix shell g-golf emacs emacs-geiser-guile -D g-golf gtk adw --no-grafts <daviid>welcome - ping me if you have specific questions related to g-golf <apteryx>the etc/teams.scm sync-codeberg-teams script fails with a 422 error at the end <Guest10>Is there a way to use guix import to help building a rust package that isn't on crates.io, but has a cargo.lock with lots of dependencies that are? <acidbong>Guest10: write a basic Rust package recipe manually and follow the rest of the Rust packaging guide from Guix Cookbook <acidbong>on Guix channels: if two or more channels have matchingly named packages, how does Guix decide which one to instantiate? does it depend on the order of channels, the versions of packages (like in Gentoo overlays), or do the channels conflict? <Rutherther>if it's different versions it's resolved in the same way as in the same channel. If it's the same version, it's not clearly defined iirc and I think in the end it's going to be based on the lexicographical order of the modules, but not copmletely sure. Anyway you will be warned about such conflicts and it will tell you which one it chose <Rutherther>(assuming we're talking about specifications here) <Rutherther>because if we were talking about guile symbols, then it's a no issue <acidbong>Rutherther: say, i define my own DWM recipe under the same `dwm` symbol. In Guile code, i guess, it should be a no-brainer: I'll just import my own module instead of the Guix one and use my variable. But what about Guix CLI? or should I rather have a runnable file for, say, `guix build -f pkgs/dwm.scm`? <Rutherther>guix cli also supports both specifications and guile expressions, same as in guile. I believe I have already answered for both <Guest10>i prefix the names of my package variants with my initials to manually namespace them. habit from emacs <Rutherther>yeah, I would also say if you're making just a package variant, rename it to prevent the specifications collisions that aren't clearly defined <Rutherther>but if you're packaging a new version, no need to rename it <oliverD>When I install gnome-authenticator and click the add account button it shuts down (I don't know if my computer is cursed at this point) <Rutherther>oliverD: do you mean that gnome-authenticator shuts down or your computer? I am confused, because you typically sway software crash and I would expect shuts down to refer to the whole computer <Rutherther>oliverD: in case it's gnome-authenticator, stuff like that can definitely happen, try strating it from a CLI and see what it logs when it crashes <oliverD1>2026-01-23T09:05:36.106235Z INFO authenticator::application: Authenticator (com.belmoussaoui.Authenticator) <oliverD1>2026-01-23T09:05:36.106287Z INFO authenticator::application: Version: 4.4.0 () <oliverD1>2026-01-23T09:05:36.106295Z INFO authenticator::application: Datadir: /gnu/store/cdsz02njwbjmplkfsk99gfja53d2w2kr-gnome-authenticator-4.4.0/share/authenticator <oliverD1>2026-01-23T09:05:36.128961Z INFO authenticator::models::providers: Loading providers <gabber>apteryx: beautiful, colored HTML paste you did there! may i ask how you did it? <gabber>is the manual section `22.8.9.1 Specifying Dependencies' on python dependencies having to be propagated still actual and factual? i notice my python packages working fine with their dependencies as simple `inputs' but the section implies that these pacakges *have to be in propagated inputs* <gabber>see also the discussion with csantosb in #5638 <dariqq>gabber: a library or an executable? I think any executable should be automatically wrapped <Rutherther>oliverD: I think that boils down to the package being wrongly packaged, supposedly missing a gstreamer plugin. I would say it should probably be wrapped so that this does not happen. (but not completely sure how gst plugins should be handled) As a workaround, try "guix install gst-plugins-bad" and relog <gabber>i think python libraries with dependencies to other libraries make sanse to propagate them, so we can `guix shell python-foo` and have its dependencies (e.g. python-bar) readily available as python modules. but for executables (i.e. a program written in python depending on python-bar) it is not necessary. <dariqq>gabber: python/pyproject-build-system has a phase to wrap all bin/sbin outputs with GUIX_PYTHONPATH to have executables just work. BUt this wont work for libraries. So it depends whether the thing you are trying to package is a library or application or both <Rutherther>but the manual does not really distinguish that. So I agree with gabber that it should be adapted <Rutherther>the manual also says that setuptools and pip are installed per default. They're not anymore <gabber>i guess i'll email the python team. they should know best (: or just open an issue for teams doc and python <sturm>any had experience temporarily overrding the default XDG web browser? I'm trying `BROWSER=librewolf xdg-open http://example.com` and `BROWSER=chromium xdg-open http://example.com` but it doesn't seem to have an effect. Instead it only seems to consider ~/.config/mimeapps.list. Use-case is that I'd like to change the default browser that a ClojureScript development environment automatically launches. <gabber>ACTION likes how opening issues on codeberg and tagging the relevant teams quite often leads to answers by the right people within minutes <civodul>gabber: yup i think it works pretty well <civodul>so, the big question for today is: when do we merge next-master? <Kabouik>My only gripe with Codeberg is I can't reply to issues using emails, but I quite like it as a git server/interface otherwise. <civodul>Rutherther: yeah, i have mixed feelings; i feel like the day we merge, we’re going to have surprises (chaos?), but also the more we wait, but more surprises we’ll get :-) <Rutherther>civodul: I think I would rather not merge it within a few days around the release, that's all. That's the only reason I would like to wait <csantosb>Rutherther: Do we release before Fosdem ? Would be nice to have a bit of noise around Guix at that point. <Rutherther>civodul: and I think when someone (I guess me) will be merging it, they should also try 1.5.0 to pull to next-master <Rutherther>gabber: we're in sort of a quasi-state. The release is ready in all ways, just hasn't been announced yet <gabber>ACTION installs their partying face <csantosb>Regarding huge merges with a quota of surprises, last time it helped to have a weekend to get these fixed asap. <andreas-e>civodul, Rutherther: I have kept next-master frequently rebased on master. <andreas-e>And the numbers are good on QA. So I am rather in favour of merging next-master quickly. <andreas-e>But we have also merged a number of branches (crypto, python, r, if I remember well), so next-master is many commits ahead of master. <andreas-e>In any case, we will have to keep the branch open (and then I would suggest to cherry-pick to master if people mistakenly push to next-master), to avoid pull requests being closed automatically. <civodul>noe: you’ll be around to merge the blog post PR? (if not, i can do that) <efraim>do we have a command for sha3? I found one in perl-digest-sha3 and that's listed by wikipedia <wehlutyk>hello all, I'm looking for srfi-160 under guile <wehlutyk>there's no existing issues around that right? <civodul>efraim: ‘guix hash -H sha3-512 …’ FTW! <efraim>ok, they did ask for base64 with a please, I'll redo that <civodul>there’s also sha3-256, perhaps that’s what people more commonly refer to as “sha3”? <efraim>`rhash --sha3-256 --base64` and `guix hash -H sha3-256 -f base64` return the same value <civodul>Coreutils has ‘sha384sum’, but that’s actually SHA-2 (info "(coreutils) sha2 utilities") <Rutherther>newer coreutils has sha3 support, but we don't have that in Guix yet <efraim>ACTION didn't check gnulib for a release email template, but all the GNU ones are so similar... <efraim>from the aarch64 ghc PR with some local changes: /gnu/store/wgbsqw9wjk7npgwc8my7idjhr2a15mpq-pandoc-2.19.2/bin/pandoc: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /gnu/store/50jqiigxwa1s9xljqrl1wh85yncqnybr-glibc-2.41/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped <gabber>should we consider it a bug that `guix search` searches for raw text in synopses, names and descriptions instead of "rendered" text? i'm ok with `guix search @acronym` yielding results, but i think `guix search "modular SIP"` should yield (at least) the package baresip <lilyp>what if you do modular SPC SIP? <gabber>or wait, by SPC you mean with a single horizontal space character? <civodul>Rutherther, noe, efraim: i guess i can press the button for the blog post? <efraim>after the date fix you can push it <Rutherther>civodul: are you going to merge the version bumps (#39) at the same time as well? <civodul>Rutherther: ah yes, i was going to forget <noe>civodul, thanks for taking care of it <andreas-e>Congratulations for the release to everybody involved, I am very impressed with the release team! <civodul>noe, Rutherther: BTW, i added you to the artwork repo, in case you need to fix typos etc. <librecat>thanks guix team for packaging the latest gnu packages <Kabouik>Congrats Guix team. Proud to be onboard. <librecat>good to remember that each stable zig release needs to be bootstrapped from before introducing the wasm bootstrap <acidbong>btw, one mistake in the blog post: Librewolf is 146 at the stable branch <wehlutyk>pukkamustard, I'd like to package guile-srfi-160 (which also depends on srfi-151), and I see you processed a bunch of other srfi's <wehlutyk>would you have any advice? I see no regular configs in guile-xyz.scm <identity>librecat: what would be the problem with Librewolf? <librecat>identity: i remember before they would ban firefox on fsdg distro for a few reason? <librecat>1) trademark 2) lack of librejs 3) extension store lnk <librecat>even though it looks like i want librewolf removed i just want consistiency in FSF <librecat>if they think forcing libreJS on every distro they promote is crazy nonsense then they should remove the whole rule <librecat>ok good question if guix ships with a default configuration that fsf is happy with no issue <identity>1. where in the name Librewolf do you see ‹Firefox›? 2. Librewolf ships with uBlock Origin, which is at least half as good, if not better than LibreJS; 3. not sure about the Mozilla extension store <dariqq>librewolf in guix uses gnuzilla.gnu.org as the (default) addon url <librecat>also maybe FSDG is more about a commitmen <librecat>for example debian by itself is rejected for a simpler reason than ubuntu <librecat>but pureos can take debian in a direction of full freedom and get listed <civodul>noe: you could email lwn@lwn.net a short message with a link to the post <civodul>they have a section for release announcements <civodul>maybe someone could do linuxfr.org too <look>congrats guix for the release o/ special thanks to everyone involved in the release team <fhang>Congrats on the Guix 1.5.0 release, everyone. Now, time to dust-off the ol' CD burner. <cdegroot>Woot! I missed it, nice! This is the planned start of a more regular cadence, not? <civodul>csantosb: yeah, but i’ve never done that, so i thought Someone Else might wanna do it :-) <civodul>i think roptat submitted translations of the release announcement once in the past <Rutherther>cdegroot: yes, there should be annual releases now <ckewi>already a daily plasma user; very stable <janneke>wow, 1.5.0; congrats and big thank you, release team! <noe>ckewi, Wow my bad I’ll update it <ckewi>no prob, you guys did a very good job! <noe>civodul, its already on the site 😵💫️ <yelninei>How can the guile build driver set a utf8 locale when GUIX_LOCPATH is still undefined? Or is C.UTF-8 special? <civodul>yelninei: C.UTF-8 is special: it’s part of the glibc package <civodul>see: find $(guix build glibc |grep [0-9]$) -name C.UTF-8 <Wurt>I'm looking to commit a package (mldonkey) that depends on camlp4 library. camlp4 requires a specific version of OCaml, which varies by release. Should I set the #:ocaml argument to the required version? Since I'm not familiar with OCaml, I'm also wondering if I need to specify any other arguments. <yelninei>civodul: But why does unsetting GUIX_LOCPATH (before 'install-locale) cause eg. bash to complain about failing to install the C.UTF-8 locale when before guile is satiesfied enough to switch all the ports to utf-8 <yelninei>(this is probably not the problem because it ahs been happening before the change to set LC_CTYPE by default) <ckewi>That's a speedy fix-up :noe :) <yelninei>maybe the reason is that setlocale is called too often with different arguments causing libc to allocate a new string which interferes with libgc? <gabber>will i be able to buy a t-shirt with that fancy artwork at Guix Days? <yelninei>that was not it. setting LC_ALL by default causes leak warning even before starting phase `separate-from-pid1'. But this might by from guix substitute <civodul>gabber: i don’t think so; would have been nice! <civodul>yelninei: re bash and locale issues, you have to check which bash we’re talking about: could it be the statically-linked one? <gabber>civodul: if that has not been planned yet it could still be possible. (online) print-shops do exist and shipping to brussels should not be a problem... do we have a shipping address there? <ieure>Big thank you and congrats to the release team! <yelninei>civodul: Youre right. It think it is the bash that writes out the environment variables with system(3) which should be the static-bash. Probably a red herring <yelninei>i just wish this can be reproduced without guix-daemon being involved <Rutherther>yelninei: when you're applying the environment-variables out of /tmp/guix-build..., are you cleaning up your whole environment? <andreas-e>gabber: We could certainly find someone in Brussels to send tshirts to. <Rutherther>yelninei: or even when running the build script from the drv <gabber>andreas-e: i guess i'll poll the mailing list for orders, then (: <gabber>anyone with better french (or dutch) knowledge than me can help me understand how long it takes this store to print (and ship) shirts: https://www.omnishirt.be ? <yelninei>Rutherther: I start from an empty guix shell --pure, and then run with /usr/bin/env out=/tmp/somewhere /gnu/store/.../guile ... builder <andreas-e>gabber: 2 to 4 working days for printing, and the same time for delivery. <gabber>so, ordering on monday should have them delivered by our second Guix Days? <gabber>no wait. people only work 5 days/week <gabber>andreas-e: can you tell if it's possible to fetch the shirts (instead of having them delivered)? is the shop somewhat close to brussels? <andreas-e>In any case, I do not think that picking up the merchandise is possible. <gabber>csantosb: why is librnd not exported? <csantosb>It is a common library dependency of all RiNgDove packages <csantosb>No utility by itself, if i remember correctly <csantosb>Tried to check, but their site is offline <gabber>i'm just wondering if not exporting variables really makes sense. it exists, it is there and not exporting it just hides it from end-users (who invoke `guix search FOO`) <gabber>there's a bunch of others in electronics.scm. if we encourage designers (and EDA software authors) to make good use of guix then i'd argue exporting as many packages as possible would incentivize hackers to use the available packages <andreas-e>gabber, csantosb: I agree with gabber; hiding packages also makes QA work difficult. I think the packages then do not appear on the QA and CI pages. I have just noticed the problem with trilinos-for-dealii-openmpi, it makes it difficult to find build logs on the servers. <csantosb>Provided the package at hand has a real utility, I'd tend to agree; if it only allows building something else, being transparent has an advantage: reduces noise. <csantosb>This is why private packages exist, after all (there is also hidden packages) <gabber>csantosb: noise where? in the search results? <csantosb>See prjbeyond-db, for example: it is a dependency for nextpnr to support the ng-ultra arch. <csantosb>Do users need to know about its existence ? I dont think so. <csantosb>When users will never install the package, because it is useless by itself, I tend to make it private <gabber>i don't agree. free software is there to be used, re-used and depended upon. so even if the main purpose of a package is to enable the build of another package it could still be used to build other software that builds on that. exporting the variables could help inspiring users/hackers <gabber>aha! so for you exporting packages is about *installing* them <gabber>ACTION wonders if there has been a Guix-wide discussion about exporting them at some point <andreas-e>Not being explicitly installed is the fate of many libraries; for instance glibc is not installed into a profile. <csantosb>That being said, the qa, ci, etc. optic is legit, I agree <gabber>IMO software developers should be able to find libraries (without crawling the sources) and other packages, so i'd tend to export as much as possible (with the exception of maybe duplicates) <csantosb>Maybe. I've personally never use the cli tools to search something, I grep the repo, and so my bias. <csantosb>When I'm using emacs-guix frontend to search for apps to use, I'd be bothered by a long list of meaningless items (do I ever need to know librnd exists ?) <Rutherther>I think this is false dilemma. It does not have to be about exporting or not. It might also be about having the possibility to also look at unexported/hidden packages in case you really wanted. With the hiding being respected just being the 'default' <Rutherther>csantosb: I will merge next-master on Tuesday, so just please don't merge some significant changes to master that would make merge of a branch with multiple teams branches merged harder (such as large refactors or something), but stuff like upgrading packages is fine now that the release is over <csantosb>So `guix search` hides it to regular users, grep shows it to developpers ? <gabber>csantosb: as most people i could go on in my life without knowing about the existance of librnd. but if i ever were to write some EDA CAD software i guess i'd want to know about it (without inspecting each and every CAD EDA tool and its dependencies). <Minall>I'm checking this: https://github.com/vulhub/vulhub/tree/master/inetutils/CVE-2026-24061 , and even though I can of course reproduce it with docker, I'm worried about it going through so much time. I mean, in 10 years, if something binary is missing, I wonder if I will be able to reproduce the same. Or should I archive something. So right now I'm thinking whether this will be simpler in NIX or in GUIX <Minall>Sorry, I think I sent a message but I disconnected again <Minall>So is mostly about just getting a package from one version and another to compare and reproduce the vulnerability. But it must be reproducible against years of course. Now I wonder if guix is what I need given the bit-by-bit reproduction, or I should go with nix... Not sure which one <gabber>Minall: i see a long-ish message about CVE-2026-24061 <Minall>Alright I'll wait for any response then <csantosb>Minall: I think you might be interested by the time-machine Guix facility, along with the SWH built in support <csantosb>Simply put, with a couple of text files you'll be able to reproduce your sw/env, this is all what Guix is all about after all <gabber>Minall: and if you have any questions we're happy to help you (here or on the mailing lists) <Minall>Thanks for the info. I'll check the time-machine now. And check that blog <Minall>How does it differ from Nix, in my case, would it be better or the same? <Minall>Oh this blog is gold, may be what I want <andreas-e>It describes step-by-step how to make reproducible experiments with software. <Minall>I see that these blogs talk directly about cybersecurity topics and so on <Minall>I wonder why I didn't saw them before when searching guix cybersecurity environment and whatever <Minall>I'll study these and see if these are cool for me, compare it with nix and then see what would be the base for my lab <llano>Hi all - I'm trying to figure out if I have a local machine issue, or if there is a bug with the docker system images. I'm running the provided example file from gnu/system/examples/docker-image.tmpl, but it fails to boot in docker. Would anyone be willing to test the same? <llano>Fails (hangs) with: shepherd[1]: Exception caught while starting user-homes: (wrong-type-arg "for-each" "Wrong type argument: ~S" (#f) ()) <csantosb>Do you have a pastebin with the steps you followed, for us to reproduce ? <luca>Congratulations on the v1.5.0 release! <untrusem>so I wanted to review https://codeberg.org/guix/guix/pulls/4623 , so curled the file and tried to open it with emacs, but I found out via doc/build.scm that to convert it to info, I would need to download the `texlive` package which is more than 4gb <llano>csantosb: thanks for confirming <llano>csantosb: in your opinion, is this something for the Help mailing list or something to put into the new codeberg issue tracker? I'm not a normal contributor - just an enthusiast <andreas-e>untrusem: The monolithic texlive package has disappeared, but since it was during the release process, only on next-master. <Franciman>thanks for making a OS free of fascisms and incredibly usable <gabber>friendly reminder that whoever wants me to order a Guix 1.5.0 T-SHIRT for FOSDEM/Guix Days shall tell me sizes and quantities via email until sunday <gabber>as described in my guix-devel mailing-list post <theesm1>congrats everyone on the new release \o/ <jnms>okay this is awesome, testing make install by adding -F --writable-root to my shell just works..