IRC channel logs

<alendvai__>not sure how i got this, it's a simple guix shell: guix shell: error: reference to invalid output '#<package gcc-toolchain@11.4.0 gnu/packages/commencement.scm:3606 7efe92680f20>' of derivation '/gnu/store/5fp4k9r4scbh9hghidqiy2yq4k5dhvld-clang-toolchain-20.1.7.drv'

<attila_lendvai>i think it's due to having both gcc and clan-toolchain in the manifest

<attila_lendvai>oh, it was the error message of passing two packages to (package->manifest-entry p1 p2)

<vagrantc>hrmpf.

<vagrantc>i appear to be getting notifications for all codeberg pull requests and issues again

<vagrantc>i turned it off at some point ... but something appears to have turned it on again?

<vagrantc>or maybe it is not all issues/pull requests ... just ... totally arbitrary ones?

<adanska>ci is failing... does anyone have the ability to see whats up?

<podiki>i think it might just be the web front end, still responds to weather and downloading files via guix

<podiki>or comes and goes depending on page? e.g. https://ci.guix.gnu.org/jobset/core-packages-team works for me right now

<adanska>podiki, oh, yeah i can still download with it, i should have been more specific. all the recent evaluations have been failing

<podiki>is it the same thing as some a few weeks ago, fails on some missing store files?

<adanska>podiki, looks that way from the build log...

<podiki>unfortunately i don't know if we had figured out a cause, some things were fixed (i don't remember what) and seemed to be okay for a while

<apteryx>old: not sure if you are still interested in jami, but in case you do, the agent currently fails to build: https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/1139

<apteryx>the C-w muscle memory when editing text in a browser...

<tazjin>apteryx: in EXWM you could remap it to actually work ;)

<ekaitz>gabber: hi!

<qbit>hm, when I emacs TRAMP into a guix box, i get "Couldn't find a proper `ls' command"

<qbit>any suggestions?

<jakef>does your guix user have coreutils?

<identity>qbit: you have to edit ‘tramp-remote-path’

<qbit>mmm, no coreutils

<qbit>i'll look at both, ty

<qbit>i assume tramp-remote-path should include '/run/current-system/profile/bin?

<identity>qbit: and things like ~/.guix-home/profile/bin i think

<tazjin>there's a magic value you can set that makes it use the remote $PATH automatically

<mgd>Silly question maybe but when you choose exwm as your only DE, does it run over another DE or on it's own?

<tazjin>qbit: yeah, 'tramp-own-remote-path - add that symbol to the list and it should just work(tm)

<identity>mgd: EXWM is a WM, not a DE, there is emacs-desktop-environment for that, but i guess that is nitpicking; i would guess most people run that and maybe something like polybar with it

<tazjin>you could technically run EXWM as the WM with another DE, I've definitely (accidentally) done that with XFCE

<tazjin>it's not the smoothest ride

<mgd>My mistake. I did the installation only choosing EXWM and not something else like Gnome or XFCE. I have an old laptop so trying to keep things lean

<tazjin>no that's a perfectly fine setup

<tazjin>I used basically plain EXWM like that for 6 or 7 years, before switching to wayland

<identity>the EXWM option in the installer adds emacs-desktop-environment to the system iirc

<mgd>Also, is there a guix way to setup udiske or something like that for USB usage?

<z572`>It seems that there is a problem with the guix database on ci. Many drvs no longer exist, resulting in many build failures

<jakef>is the open parenthesis first or last in the alphabet?

<bjorn3> as someone working on rustc, i was curious if an unofficial patchset to allow skipping several rustc releases (say 5 or so releases) during bootstrapping would be beneficial to guix. or if you rather only use the official source tarballs during bootstrapping.

<bjorn3>also i noticed that you are still starting the bootstrap process from 1.54. mrustc nowadays supports 1.74 too.

<z572`>bjorn3: see rust-team, some architectures is bootstrap from 1.74, but other is use 1.54.

<z572`>bjorn3: If the patch is not large, I think it's okay.

<avalenn>do we have a function to shell-quote an arbitrary string ?

<muaddibb>.

<muaddibb>my ar9271 usb dongle just arrived 8)

<tusharhero> https://bpa.st/XT6Q Is it recommended to update every 10 days?

<muaddibb>It's recommended that you run `guix pull' not too much before running `guix system reconfigure'

<tusharhero>muaddibb: is it fine to not update so regularly then? (I was running guix system vm when this warning appeared.)

<muaddibb>tusharhero: I think that the message is there just in case something goes wrong, you already know where to start.

<muaddibb>I'm not sure how often you should upgrade. I don't upgrade that often.

<muaddibb>s/upgrade/update

<bjorn3>z572`: the patches would be a couple hundred lines worth of changes to bootstrap the current master branch from 1.84. mostly adding back feature gates, but also inlining some unsafe functions that don't exist yet on older rustc versions and some other changes.

<bjorn3>to be clear, i have no experience with guix build scripts, not do i use guix myself, so i won't be opening a PR to add those patches.

<bjorn3>they can be found at https://github.com/bjorn3/rust/tree/bootstrap_from_older_rustc (the last couple of commits are still wip)

<lockbox____>That sounds like something that would at least be considered, do you have a current ref for the changes?

<lockbox____>Sent as I was typing :p

<lockbox____>Nice

<bjorn3>the last commit i would probably drop rather than finish.

<bjorn3>the rest of the wip commits are capable of building a rustc that can build the standard library, but not itself because the patches aren't made conditional on using the bootstrap compiler yet.

<lockbox____>hako: this could be nice

<bjorn3>i don't know how easy it will remain to do those patches in the future

<bjorn3>already i had to downgrade some dependencies because they started using new features.

<bjorn3>at least nothing significant broke since i started this branch last month.

<drewverlee>For a Guix install ontop of Ubuntu I assume I should use the Shell installer script found here https://guix.gnu.org/manual/en/html_node/Installation.html. Past that What other steps, from that link, are necessary? I take it none are. Do I need to add any env variables to my ~/.zshrc?

<drewverlee>From Emacs, when i run guix-packages-by-name-regexp i get this output: "Starting Guix REPL .. helm-M-x-execute-command: Error in evaluating guile expression: ice-9/boot-9.scm:1685:16: In procedure raise-exception: Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f))'." I assume this means I didn't

<drewverlee>install something correctly or the emacs-guix package can't find something.

<futurile-lunch>drewverlee: is the systemd service there - can you do `guix describe` on the command line

<futurile-lunch>drewverlee: sudo systemctl status guix-daemon.service

<ieure>drewverlee, `sudo apt -y install guix' on Debian-based distros.

<qbit>is there a nix-top like tool for guix? (i imagine the same tool could be pretty easily adapted)

<identity>qbit: i guess “guix processes” is similar

<qbit>nice

<qbit>ty!

<qbit>i really appreciate that I don't have to reach for other tools for things like serving the store.. and now this

<nomike>Hi

<nomike>I'm working on an upgrade of the prusa-slicer package as the one currently in guix is heavily outdated and thus not usable with recent 3D printer models. But I have a few issues where I need help with.

<ekaitz>nomike: what do you need help with?

<nomike>Firstly, and I guess that's pretty simple to answer: There is a dependency called opencascade-occt. It is at version 7.6.2 in guix. The latest official version is 7.9.1 from 2025-05-19. At PrusaSlicer they have hardcoded the version number to 7.6.1, stating that they had to downgrade to that versions as all newer versions have a bug where something is calculated wrongly which hasn't been fixed yet, even though they reported it.

<nomike>opencascade-occt is currently used by horizon-eda@2.7.0 librepcb@1.2.0 freecad@1.0.1 kicad@9.0.2 f3d@3.0.0 openfoam-org@10.20230119 python-pygmsh@7.1.17 openfoam-com@2212.

<ekaitz>nomike: make a separate package with the 7.6.1 for prusaslicer in that case

<ekaitz>something similar is already happening with some other lib in prusaslicer

<nomike>I would like to create a new package "opencascade-occt-7.9.1" and inherit it from "opencascade-occt" as I don't think it's a good idea to downgrade it for all those other packages, just because it has a bug which maybe only affects prusa-slicer.

<nomike>My question: Is this a good approach?

<ekaitz>nomike: yes

<ekaitz>nomike: take a look to prusa-wxwidgets for example

<nomike>Good. The second one is something I might not be able to solve on my own: A native-input for prusa-slicer is catch2, an automated test framework for C++ and Objective-C. There is a package "catch2-3" where this library is at v. 3.5.3. PrusaSlicer requires version 3.8 (it says "find_package(Catch2 3.8 REQUIRED)" in CMake, I'm not sure if this only covers "3.8.0" or also "3.8.1").

<nomike>I could now just update "catch2-3" to version 3.8.0, but `guix refresh` says "Building the following 1733 packages would ensure 3354 dependent packages are rebuilt".

<nomike>And now I don't know whether I should add a "catch2-3.8" package or whether I should upgrade the existing one, as these are a lot of packages which would be affected.

<efraim>I'd add a new one, and assume that 3.8.1 works for 3.8

<nomike>Well, this has the drawback of fragmenting that package even more. So before going down one road and later be told that I should have done it differently, I though I'd ask here first.

<nomike>efraim, that's anyway what I did for the time being.

<nomike>I'm still having some trouble getting prusa-slicer to build (it fails at linking with "ld: cannot find -lhidapi: No such file or directory", but I'm investigating this right now, and it's probably something stupid).

<nomike>ekaitz, efraim: Thanks for the advice! That helps a lot.

<bjorn3>i will have to leave. if anyone has questions regarding my rustc bootstrap patches, feel free to contact me on github or the rust-lang zulip.

<Aurora_v_kosmose>All this codeberg stuff has no impact on email contribution, does it?

<futurile-lunch>Aurora_v_kosmose: not yet. So you can still send emails with patches if you would like. But by the end of the year we'll change over to pull requests as the supported method

<Aurora_v_kosmose>Well that's obnoxious.

<Aurora_v_kosmose>If only Github had died before that caught on.

<Aurora_v_kosmose>I don't disagree that email-based messaging has issues, but making git workflow platform/server-centric is /not/ an improvement.

<ekaitz>Aurora_v_kosmose: many people agree with you, many others are as strongly opinionated as you are in the other direction

<Aurora_v_kosmose>I shouldn't have to register on /yet/ another platform. Especially since there's no standard (de facto or otherwise) way of extracting all the project data.

<ekaitz>Aurora_v_kosmose: I personally agree, but complaining here won't change the decision

<ekaitz>we thought about it, and had a long deliveration period

<ekaitz>deliBeration*

<Aurora_v_kosmose>I suppose it saddens me because I saw Guix as one of remaining bastion of freedom from that rot.

<futurile-lunch>Aurora_v_kosmose: if you'd like to take part in deliberations then they are open to everyone - join guix-devel and discuss!

<futurile-lunch>ACTION is clearly not still on lunch

<Aurora_v_kosmose>futurile-lunch: Aren't the deliberations already over though?

<ekaitz>Aurora_v_kosmose: I feel the same, but also the status of our infrastructure was absolutely impractical

<futurile-sleep>Aurora_v_kosmose: yes - sorry I meant for future ones - as moving towards concensus using GCD's is pretty new

<Aurora_v_kosmose>Ultimately the problem is git. Regardless of the fact some project attempt to fix its issues, so long as those fixes aren't upstreamed people will ignore them and upstream is uninterested in fixing it.

<Aurora_v_kosmose>*some projects

<ekaitz>Aurora_v_kosmose: in my opinion the problem is the industry has made people get used to things and made them lazy

<ekaitz>and some people have more energy to complain than to actually learn something else

<identity>Aurora_v_kosmose: iirc forgejo folks are/were working on ActivityPub federation, so that is something

<ekaitz>something *new*

<Aurora_v_kosmose>Nah, email has some really silly pathological cases that could be avoided by git having a proper messaging protocol & project state management & tracking.

<Aurora_v_kosmose>Email should be entirely unnecessary to operate a git project and contribute to one.

<Aurora_v_kosmose>That's an artifact of LKML assumptions.

<Aurora_v_kosmose>Packing message bundles so one can share them over UUCP or USB drives if need be would be just as compatible with email, there's no need to provide it with "first-class" (it really ain't first class) support

IRC channel logs

2025-07-10.log