IRC channel logs

<FuncProgLinux>very subjective question but is anyone using the modus themes? I use the modus-vivendi theme but idk the tinted variant is good or if anyone knows other good themes in Guix :)

<Deltafire>i'm using modus-operandi (light more) and modus-vivendi (dark mode)

<Deltafire>(light mode)

<FuncProgLinux>Deltafire: like a redshift schema? light for day and dark for night?

<Deltafire>yeah, emacs will follow the system theme set in Gnome

<FuncProgLinux>I liked the vivendi one because I almost always code in the dark. It's a good theme but I have been using it for like two years, I might need a colour refresh

<Deltafire> https://paste.debian.net/1398792/

<FuncProgLinux>Oh nice! with dbus!

<Deltafire>it switches in real time when you change the Gnome "Dark Style" toggle

<FuncProgLinux>I was about to ask for the "modus-themes-select" function but it comes with the modus-themes package.

<FuncProgLinux>oh it needs portals :( I don't have those on MATE

<apteryx>ieure: I just fixed mesa-opencl

<apteryx>not sure what to do with the -icd variant yet

<Deltafire>what are portals?

<FuncProgLinux>Deltafire: more dbus APIs IIRC some come from flatpak if I'm not mistaken

<FuncProgLinux>I know because a certain backup tool I used needed the background desktop portal which was only present in GNOME/KDE

<Deltafire>found the last commit with a properly working icedove

<Deltafire>system: stuff needed to boot into a desktop, home: all your apps etc, profile: downgraded and temporarily fixed packages that can't be upgraded

<FuncProgLinux>Deltafire: Home is good for dev packages as well. Not libraries but devtools like make

<FuncProgLinux>TIL: Make can be compiled with guile support. Why? idk. My best guess was "why not?"

<Deltafire>i wonder if guix uses that? it's probably the largest guile project and uses make

<FuncProgLinux>It does

<FuncProgLinux>make --eval '$(info $(filter guile,$(.FEATURES)))' 2>/dev/null

<FuncProgLinux>truly an Ubiquitous Intelligent Language

<apteryx>ieure: mesa-opencl-icd is now obsoleted by mesa-opencl

<ieure>apteryx, Hmm, I was only seeing failures with mesa-opencl. Thank you for fixing!

<apteryx>great, I'll look into what nutcase reported

<apteryx>ieure: hm, touching rust-bindgen-cli is a mesa rebuild though. Fixed this via a new rust-bindgen-cli-next.

<bdju>I think my guix pull isn't working, it says nothing to do, but the version of yt-dlp I have is older than what the website's package search shows.

<bdju>I'm trying to do a guix pull and then guix install yt-dlp and it's not giving me a newer version.

<distopico>There is a easy way to update only the packages that have subtstitutes available? Ignore those that does not have substitutes or the building is failing? Right now due nextcloud-client is failing I have some conflict with other packages, also other packages like kdenlive is falling as well so these day to update packages I have to do: `guix package --do-not-upgrade="k3b|kid3|nextcloud-client|meld|gnome-keyring|zathura|libnotify|rofi

<distopico>denlive" --upgrade=.*`

<bdju>distopico: Try this: guix package --upgrade . --keep-going

<bdju>It will keep going when there's a build failure, however it will not actually apply the upgrades at the end, so you'll then have to upgrade again with the list of things to skip at the end. But it will save you having to start it over manually as many times.

<distopico>bdju: thank you, that will help

<gnubootuser>hallo

<apteryx>gnubootuser: o/

<gnubootuser>ye

<lilyp>apteryx: can't say I've seen a hanging emacs build locally ever, no

<adanska>just discovered a fairly significant package faliure for the tex team: `perl-xml-libxslt` fails on master after the mesa merge. I'm having a look at it, but i dont have much time today. Submitted to the issue tracker as guix/guix#3175.

<nutcase>apteryx: for all four packages that I mentioned to fail to build, there are issues @codeberg now

<apteryx>nutcase: thanks. I gave a quick try at obs earlier, wasn't successfull (updating it to latest)

<apteryx>adanska: probably needs to depend on libxml2-2.11

<apteryx>that's how I got 'perl-xml-libxml' to build, IIrc.

<nutcase>apteryx: updating wf-recorder to 0.5.0 fails because of missing "gbm" dependency. Any idea, which input is missing?

<apteryx>I'm not sure; I see we have r-gbm and lightgbm packaged, but I have no idea if that is related.

<apteryx>I'd look at the source for guidance w.r.t. to building the package

<adanska>apteryx, still failing.. it seems be an issue with missing test files

<adanska>perhaps due to libxslt updating?

<apteryx>mesa-updates hasn't touched libxslt, I think

<apteryx>only libxml2

<apteryx>ah, "993e34e3d3 * gnu: libxslt: Update to 1.1.43"; nevermind

<kestrelwx>Morning.

<untrusem>morning

<apteryx>how can I run the Guix script (entrypoint) with a locally built Guile?

<apteryx>if I change the shebang of scripts/guix to use my own guile, it appears to cause a world rebuild

<kestrelwx>At all times? Or just "$my_guile -s $(which guix)"?

<apteryx>the latter

<apteryx>kestrelwx: ^

<Deltafire>adanska: how do you make the package name highlight in the codeberg issue title?

<adanska>Deltafire, using backticks!

<Deltafire>cool, i didn't know you could use them there also :)

<adanska>yeah its a nice touch :)

<apteryx>kestrelwx: the guile -s $(command -v guix) trick does not seem to work for me

<apteryx>not in the pre-inst-env at least

<jlicht>hey guix

<jlicht>congrats on the mesa-merge :)

<adanska>apteryx, you disabled tests when you fixed perl-xml-libxml, the test suite is running fine for perl-xml-libxslt except for these wierd missing files, if -P1 builds fine would you be fine with me just disabling tests here>

<kestrelwx>apteryx: Yeah, looking at the script it'd never work.

<adanska>aaaaand latexml doesnt build either, also curiously due to test files not being found??

<adanska>actually, it seems to be an issue of a double free somewhere in `perl-xml-libxml`'s code... apteryx: when building the -P1 dependents of perl-xml-libxml did you get these build faliures too?

<apteryx>I didn't rebuild all of them, I was trying to get one particular binary to build (gnucash?)

<adanska>apteryx, i see.. i think many of the dependents on `perl-xml-libxml` are still broken

<adanska>im going to try and automatically git bisect to find out where exactly everything failed

<fnat-xmpp>Hm, `nextcloud-client` seems to fail in master. Logs say that some Qt5WebEngine dependencies are missing. We do have QtWebEngine - but it's version 6.9.2, so that might be the reason why Nextcloud isn't happy?

<fnat-xmpp>I've tried time-machine but it's a tad slow for me at the moment, any other quick work-around I could try?

<kestrelwx>fnat-xmpp: Qt5WebEngine is also there, just broken.

<fnat-xmpp>Aha.

<pinoaffe>I want to bisect a broken package without having to rebuild it each time (as that takes hours on my machine), is there a way to find out for which guix commits substitutes are available for a given package?

<Rutherther>there is, but I am afraid no one made such tool. It is just that it's possible to use cuirass API to get that information.

<Rutherther>Here you can see the master revisions evaluated by cuirass https://ci.guix.gnu.org/jobset/master. When clicking on them, even the successful/pending/failing builds.

<pinoaffe>Rutherther: fair, the mere fact that cuirass has an API already helps a lot

<pinoaffe>the error message in question is : CommandLine Error: Option 'debug-counter' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options - i've seen a similar message before, but I forgot where and what the fix was

<amypillow>Hi! I'm having an issue with my grub config in a guix system, it's preventing most other changes to my system

<amypillow>Basically, whenever I try to reconfigure the system, it uses an old piece of configuration that I have removed a while ago. I was attempting to enable hibernation mode on my laptop, which I still haven't figured out, and part of my thought process on it was to calculate the disk offset of the swapfile at configure time in order to use as a kernel parameter. For some reason, this filefrag call is repeating in the log despite not being referenced anywhere

<amypillow>The issue is, I did a guix gc, and the specific hash of filefrag is no longer available, so any attempt at reconfiguring will just fail with no such file or directory.

<amypillow>In execvp of /gnu/store/syd38ykaq4c7dfz4r80d0qvb2h4x8c20-bash-5.2.37/bin/bash -c "/gnu/store/pd59dz5kksa8amhx6j4m26q468wq44i7-e2fsprogs-1.47.2/sbin/filefrag -v /home/.swapfile | /gnu/store/wmhb2wmrzx1jjpkfaw1b5dsxarh9jlqh-gawk-5.3.0/bin/awk '$1==\"0:\" {print substr($4, 1, length($2)-2)}'": No such file or directory

<amypillow>In execvp of /gnu/store/pd59dz5kksa8amhx6j4m26q468wq44i7-e2fsprogs-1.47.2/sbin/filefrag: No such file or directory

<amypillow>Oh, the reason I said it's an issue with grub is because the specific drv that requires this script is grub.cfg.drv

<Guest95>Hello all. Could somebody please help me with increasing my fd limit. I'm using a home configuration

<identity>Guest95: why do you need to increase you fd limit?

<Guest95>I'm using an application that's hitting the limit.

<identity>Guest95: you want the ‘pam-limits-service-type’ system service in (info "(guix) Base Services")

<Deltafire>amypillow: probably because grub has a menu of previous configs so you can rollback. Maybe you could delete these

<tesseract>do i need to do "guix pull" before "guix upgrade" to get latest packages?

<identity>tesseract: yes

<Guest95>identity, that's great thank you

<Deltafire>amypillow: guix system delete-generations

<tesseract>identity: so, "guix pull" is like "apt update" on debian?

<tesseract>and "guix upgrade" is like "apt upgrade"?

<identity>tesseract: no idea about apt, but guix pull gets new package definitions, among other things, so likely yes

<tesseract>identity: alright thanks

<amypillow>That worked, thanks!

<tesseract>but guix pull take too much time

<identity>tesseract: “guix upgrade” upgrades packages installed as the user you are running it as; on Guix System, if you want to upgrade the whole system you have to do a system reconfigure; on foreign distros (i think, consult the manual) to upgrade the daemon you have to pull as root and do whatever else

<kestrelwx>tesseract: It shouldn't take very long to pull a few commits.

<tesseract>wow. gnome desktop is still version 46 in repos

<trev>yeah :\

<trev>waiting for gnome-team branch to merge

<crazazy>hi! I installed guix on my laptop, and it doesn't seem to recognize my archer t4u wifi dongle. afaik it relies on the rtw88 wifi driver, which I believe is open source, so how do I add that driver to my guix install?

<attila_lendvai_>crazazy, it may still require a firmware blob, so it's not going to be in guix proper. there's a channel called nonguix that has the full kernel.

<crazazy>oh ok

<Deltafire>i wonder what the newer gnome version is like.. maybe worse!

<Deltafire>i have linux mint on here also, but that's also on gnome 46

<trev>Deltafire: it's about the same, with some extra stuff

<trev>mostly useless stuff except the built in battery health

<civodul>is it just me or Codeberg is slow today?

<kestrelwx>502 atm

<dlmsr>it is slow but no 502s for me...

<gabber> https://status.codeberg.org/status/codeberg

<gabber>> Partially Degraded Service

<untrusem>does any have shared a folder in virt-manager using filesystem-passthrough?

<untrusem>guix does not have virtiofsd package

<zimoun>hi

<dlmsr>o/

<ieure>sneek, Tell fnat-xpp the nextcloud-client qt5webengine issue is happening because qtwebengine@5 is broken: https://codeberg.org/guix/guix/issues/3036

<sneek>fnat-xpp, ieure says: the nextcloud-client qt5webengine issue is happening because qtwebengine@5 is broken: https://codeberg.org/guix/guix/issues/3036

<ieure>Oh, huh, okay.

<ieure>Well ^ fnat-xmpp fnat

<untrusem>I am getting this error after adding filesystem passthrough

<untrusem>Error starting domain: operation failed: Unable to find a satisfying virtiofsd

<ieure>untrusem, Seems expected if there's no virtiofsd in Guix.

<untrusem>sigh, will need to look into packaging it then

<untrusem>but I needed it urgently, will need to look into other ways then

<gabber>can i route a `guix system container`'s ports to my host machine? i have a simple os with a mysql-service and would like to access it from my host

<fnat-xmpp>ieure: Got it, thanks! And tx for sharing the link.

<csantosb>Seems like ci bot checks pr with agit flow 🥳 ! See https://codeberg.org/guix-science/guix-science/pulls/237

<untrusem>how does ci bot select pr to build build packages of?

<csantosb>Note this is guix-science; haven't noticed the same on guix itself yet

<untrusem>> Note this is guix-science; haven't noticed the same on guix itself yet

<untrusem>I have seen in guix proper too

<csantosb>Ah, great

<look>Hi, it seems one of the ci workers is out of disk space, there are no substitutes for rust-1.85.1+ atm because of the failed build: https://ci.guix.gnu.org/build/14361847/details

<look>should i open an issue for it?

<gabber>look: yeah, why not

<look>gabber: thanks, issue here: https://codeberg.org/guix/guix/issues/3193

<gabber>look: thank you!

<gabber>what is our line length limit and why don't i find it in our reference manual?

<untrusem>gabber: you could use `guix lint <package>`

<gabber>it's not for me (i exclusively rely on emacs to do that job for me) but for reference in a review. i want to point a user onto our standard (and can't find it currently). but yeah, running `guix lint` should do the trick, too (:

<gabber>thanks

<QUL>HI, I am trying to install GNU Guix on a foreign distro using the install script but the download speed is too slow. I checked my internet speed and it is order of magnitude larger. So I assume the problem is with the FTP server. Does anybody know how to install GNU Guix on a foreign distro without waiting for 3 hours to download one 100MiB file?

<gabber>QUL: i think codeberg is currently having issues. or in which phase of the installation are you seeing the slow speeds?

<QUL>gabber: When the script is downloading an archive file from the GNU FTP Server.

<csantosb>QUL: You may use the GUIX_BINARY_FILE_NAME env variable to point to a /tmp/guix-binary-1.4.0rc2.armhf-linux.tar.xz file

<csantosb>See https://codeberg.org/guix/guix/src/master/etc/guix-install.sh#L45

<gabber>FTP? i sure didn't go down that route a long time. unfortunately the GNU project undergoes heavy attacks from (i think) web scrapers and LLMs so their bandwidth is extra reduced

<QUL>csantosb: Thanks you, but how do I optain the archive file in the first place

<csantosb>Do you have the link ?

<QUL>csantosb: Yeah it prints out in the terminal but I tried just downloading it with wget but the bandwith on the server is apperently just to low to download it from. Is there a mirror? The project recently switched to codeberg from savannah which improved the speed while fetching in my GNU Guix system VM. So is there maybe a mirror for this file?

<Rutherther>QUL: I would suggest downloading the guix-install.sh script somewhere to your fs and editing the GNU_URL to "https://ftpmirror.gnu.org/gnu/guix/"

<csantosb>Ah ! https://ftp.gnu.org/gnu/guix

<Rutherther>there are many mirrors. ftpmirror.gnu.org should choose one close to you.

<csantosb>Yeah, the default url seems down

<QUL>gabber: Yeah I read the blog post recently what a shame. I know anubis is javascript dependent but I saw that Hyprlands dev made a custom version which gives the option to avoid JavaSctipt and still providing proof of work. Maybe its worth looking into it.

<csantosb>Maybe it is worth replacing GNU_URL="https://ftp.gnu.org/gnu/guix/" in etc/guix-install.sh

<csantosb>by https://ftpmirror.gnu.org/gnu/guix/

<QUL>Rutherther: You are a live saver!! Thank you so much!! it works a like fast swiss clock now. Why is it not the default i can not think of any downsides from the top of my head?

<QUL>csantosb: Yeah I just did it and it works perfectly

<gabber>QUL: (as many things) this is just one PR away from getting done (:

<QUL>gabber: Ah yeah the etternal truth lol.

<civodul>csantosb: probably a good idea!

<csantosb>Worth documenting it too

<csantosb>civodul: #3196, (not sure about the message/changelog)

<peanuts>"bad install" https://issues.guix.gnu.org/3196

<csantosb>?

<csantosb>Ah, debbugs

<gabber>csantosb: i'll push it with the other PRs shortly

<gabber>is ftpmirror.gnu.org the official ftp mirror? or is it deprecating the now obsolete(?) ftp.gnu.org?

<FuncProgLinux>wohoo my atril pr was merged \o/

<tesseract>guys, am i seeing right or something? about:support in icecat says "H264 Unsupported"! no wonder it doesn't play videos in invidious!

<tesseract>vp9, vp8 etc supported

<tesseract>anyone know something about this?

<gabber>tesseract: there may be the right input missing, but maybe more work is needed

<tesseract>so, i can play videos on youtube but not on invidious lol

<QUL>csantosb: Oh I just noticed your pull request after making mine lol. They are almost identical except i didnt left the previous URL in a comment.

<csantosb>gabber: See https://www.gnu.org/prep/ftp.html

<gabber>thank!

<gabber>s

<gabber>why does `guix shell -D guix -- make -j $(nproc)` all of a sudden (between my last pull ~1hr ago and now) fail with "No Guile development packages were found." at "configure: checking for guile 3.0" ?

<Rutherther>gabber: probably because the development packages changed and are no longer available, you will have to execute configure if that's the case. Possibly also bootstrap.

<gabber>Rutherther: thanks!

<FuncProgLinux>i've investigated more on the podman-docker thing I mentioned yesterday and it turns out the script should be already in the podman package and it does nothing but symlinks

<vagrantc>whew. 1.5 days to update my mnt/reform ... used to long updates, but that was a big one!

<ieure>vagrantc, Guix runs okay on the MNT Reform?

<vagrantc>with the rk3588 and 32GB of ram ... yes :)

<ieure>vagrantc, I'm MNT Reform curious, but last I looked, was a bit more expensive than I wanted for the performance.

<ieure>Love what they're doing, though.

<vagrantc>ieure: yeah, not cheap... but wow, so repairable

<vagrantc>the older CPU/RAM modules ... it was a bit painfully slow ... but one the current generation of cpu modules it is pretty workable

<gabber>vagrantc: i guess you had to build stuff locally during that upgrade?

<vagrantc>ieure: librewolf takes a long time, but last i tried still ran reasonably

<vagrantc>gabber: yeah ... big merge (mesa-updates?) hadn't yet been buitl for aarch64

<ieure>vagrantc, To build, or to launch/run/use?

<vagrantc>ieure: maybe takes a few hours to build ... and runs fine

<ieure>vagrantc, Gotcha, yeah, not ideal. But it's not fast to build even on fairly powerful x86 hardware.

<vagrantc>ieure: yeah

<gabber>i am in the process of installing/upgrading my pinebook pro which, well, is unable to build most packages (:

<ieure>I think CI is having issues with aarch64, last I looked, LW wasn't building because of a bunch of the inputs were borken.

<vagrantc>had to build the entire rust chain ... which took a ridiculously long time

<vagrantc>gabber: yeah, i ran guix on the pinebook pro for quite a while ... it was rough

<vagrantc>ieure: admittedly i have not yet tested building librewolf after the recent merge ... but did build it just before

<ieure>vagrantc, I'd wait, I'm going to PR the 140.0.3 update today.

<vagrantc>ieure: 143.x ?

<untrusem>ieure: https://blog.craigie.dev/introducing-glide/

<untrusem>I asked in the comments if this could be based librewolf, but no answer yet. I thing it could be possible, though we won't have the branding but we can take patches from librewolf I think

<FuncProgLinux>Btw, is any other desktop using libindicator? I don't understand something about the package

<ieure>untrusem, Looks interesting. There are also some FF extensions that give a more keyboard-focused experience.

<untrusem>yeah, found through lobsters https://lobste.rs/s/lm3isi/glide_extensible_keyboard_focused_web

<tesseract>guys, "guix package --list-installed" only shows main package names. how can i list all the packages including dependencies etc?

<untrusem>if you are on wayland, use this https://github.com/moverest/wl-kbptr to get that mouse click functionality using keyboard globally

<untrusem>FuncProgLinux: sorry I don't use that package

<FuncProgLinux>untrusem: np :) I just didn't understand why it's description says "ayatana" but I think it's not

<Rutherther>tesseract: it shows only the ones actually intalled, meaning accessible from your environment. While yes, dependencies are needed, they aren't installed in that sense. To get them you would use something like "guix graph --type=references $(realpath ~/.guix-profile)", which would give you full graph of the dependencies. Unfortunately it's not really showing packages, but rather paths in the store. I am afraid there is no built-in tool that would show...

<Rutherther>... you the packages with inputs transitively in a profile.

<tesseract>Rutherther: thanks

<tesseract>Rutherther: does "guix upgrade" also upgrades those dependencies etc?

<tesseract>i am still trying to understand guix!

<tesseract>i just installed it for icecat

<tesseract>maybe that's enough

<tesseract>but who knows

<Rutherther>tesseract: yes, the versions of dependencies are 'hardcoded' in guix channel that you update with guix pull. It's impossible to stay on older dependencies that guix doesn't know anymore, that's part of it being functional.

<tesseract>i was wondering if some companies use guix?

<ekaitz>tesseract: mine does but that just means that *I* use it

<tesseract>the only user? :D

<tesseract> https://i.imgur.com/Onwzj.jpeg

<Deltafire>thanks whoever did all the work on plugable sane backends - my scanner is now working under guix :)

<FuncProgLinux>I thought I needed the ayatana indicators for the mate-indicator-applet but whaaat?

<FuncProgLinux>it compiles & works well with the "libindicator" guix package. It detects the build as "using Ubuntu indicators" but the "libindicator" package says it's "ayatana indicators"

<FuncProgLinux>build with "--with-ayatana-indicators" and it dies lol

<old>hello

<old>when I use guix-time-machine, I get:

<old>guix time-machine: error: Git error: could not find appropriate mechanism for credentials

<old>any idea?

<Rutherther>old: what urls are you using for the channels you're pulling?

<old>Rutherther: this: https://paste.sr.ht/~old/9f5a917b6fe07564004380a5cb57324152b9452f

<old>eh

<old>I guess the link is broken

<old>well problem solve sorry lol

<old>I feel dumb, but perhaps the error message could be more explicit about the error

<ieure>Definitely not a great error message.

<attila_lendvai>how can i get the aarch64 linux headers? is that it? guix build --system=aarch64-linux linux-libre-headers

<attila_lendvai>running this on an x86 host

<vagrantc>or --target=aarch64-linux-gnu

<attila_lendvai>thanks vagrantc!

<gorilla>Is it just me, or is ftp.gnu.org incredibly slow?

<Rutherther>it really is incredibly slow

<ieure>If it's reachable at all, it's doing better than most gnu.org sites.

<untrusem>bruhh 😶

<gorilla>It seems to be unreachable on 1/2 my attempts

<gorilla>Is there a practical way to point guix-install.sh at a workable mirror?

<gorilla>I can't get beyond 5M of it downloaded from gnu.org

<kestrelwx> https://codeberg.org/guix/guix/pulls/3196/commits/18ea2ad1206ec265800959eec62782463cdd1645

<Rutherther>yes, download the script and change GNU_URL to "https://ftpmirror.gnu.org/gnu/guix/"

<kestrelwx>It's upstream, we have the technology.

<untrusem>gorilla: https://ftpmirror.gnu.org/gnu/guix/

<gorilla>thank you

<gorilla>still gnu.org, but not buried?

<Rutherther>it will redirect you to a close mirror, so you won't be downloading from gnu.org anymore

<gorilla>Why doesn't the shell script default that way?

<kestrelwx>It now does.

<Rutherther>because there weren't such problems in the past

<gorilla>The one I downloaded an hour ago doesn't. Did it change in the last hour?

<Rutherther>the change has been merged an hour ago to the repository. But it doesn't matter, the script you download at https://guix.gnu.org/guix-install.sh doesn't get updated automatically with that

<gorilla>:)

<Rutherther>don't worry about it 'now being upstreamed', it doesn't concern you now, it concerns future users after the script is updated

<gorilla>yep

<gorilla>good that it is changed

<gorilla>The Guix manual constantly frustrates me. It seems to assume that you know all the intermediate steps and the order that they have to be done.

<gorilla>After running guix-install.sh, I need to logout and back in. That's reasonable. But then I need to do Application Setup? It doesn't work.

<gorilla>Do I have to get the daemon going first?

<nebel>hi all, i just wanted to install xinit using `guix package -i xinit` right after a pull. i get a broken xinit (version 1.4.3), in which something about mcookie is not how it should be. i found issue #76878 which seems to fix it, but as i said, it still downloads the broken version. is there something that i still need to configure?

<peanuts>"gnu: xinit: Fix broken mcookie path in startx." https://issues.guix.gnu.org/76878

<Rutherther>gorilla: the daemon has to be running for most of guix commands. The guix-install script should start it afaik. So you shouldn't need to take care of that (unless you're using different init system than systemd)

<gorilla>Does each user have to `guix install glibc-locales`? Or is that a system-wide thing? It seems that I have to set an env specific to the user.

<gorilla>So the locales must be installed per user.

<Rutherther>guix doesn't have a way for system-wide installations on foreign distros, so indeed, every user needs to do that

<gorilla>The guix-daemon is, in fact, running. But `guix install glibc-locales` fails.

<nutcase>Can one of the commiters have a look at PRs 3188 and 3201 and tell me, if something is missing? Specifically I'm asking, because these are my first contributions via codeberg. Additionally, I'm not sure, whether the commit message are correctly formulated.

<Rutherther>gorilla: what does it fail with?

<gorilla>guix install: error: remounting /gnu/store writable: Permission denied

<gorilla>it seems I need to more than logout/login

<Rutherther>gorilla: ah, are you on distro with SELinux?

<gorilla>yes

<Rutherther>then see https://guix.gnu.org/manual/devel/en/html_node/SELinux-Support.html

<gorilla>it asked me about that and I answered yes

<Rutherther>yeah, the script should do it for you, not sure what went wrong, maybe someone has to debug if it still works

<gorilla>Rutherther: `semodule -l` shows guix-daemon

<Rutherther>okay, can you send the policy file it points to? if that are the right words... I don't really know much about selinux

<gorilla>should guix-install.sh be run as root?

<Rutherther>yes, it is written in the manual https://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html "As root, run: "

<gorilla>k. I didn't figure how it could do what it need to without root.

<Rutherther>right, it installs a system wide service, writes to system wide locations and sets up selinux optionally, so it cannot do that without root

<nebel>not trying to be too pushy, but i still need an answer to my question about the broken xinit :/

<Rutherther>nebel: using startx/xinit from xinit package directly is not supported, use the startx command service that will give you the necessary configuration for starting X

<nebel>thanks

<gorilla>Rutherther: /gnu/store was still mounted ro. I manually remounted and restorecon. Then things worked.

<Rutherther>it should be mounted ro most of the time though. Only the daemon should be changing it to rw when necessary. So if that doesn't happen for you, something is broken

<gorilla>... until the build failed :(

<gorilla> ah.https://guix.gnu.org/manual/devel/en/html_node/SELinux-Support.html says to remount it rw

<gorilla>do I need to put it back ro?

<Rutherther>yeah, that's just for setup. That should've already happened for you during guix-install.sh, that's why I am saying that I think something is wrong. But maybe it isn't and everything will work fine from now on even after reboots in the future

<gorilla>Sounds like I need to put it back ro.

<Rutherther>gorilla: having it as ro is definitely safer as the store is supposed to be immutable, ro makes sure most programs cannot decide to write there even in quite invasive cases. It is just a safety measure, it doesn't prevent any operation of guix etc.

<gorilla>hmm. Can't remount as ro because mount point is busy. Even though guix-daemon is stopped.

<nebel>is there a good way to configure emacs such that i can get documentation on guile functions directly in emacs?

<ieure>nebel, eldoc is the thing that Emacs has for this, maybe Geiser has integration?

<ieure>nebel, You can read the Guile infodocs inside Emacs (C-h i) and make bookmarks inside them (C-x r m), but I think eldoc is what you want.

<nebel>eldoc solved it thanks

<lordmzte>Hello everyone! I'm having a look at Guix as a NixOS user and was trying to understand how the Guix package repository is structured. It looks to me like the code for all packages is in the same repo as the package manager itself (guix/guix on codeberg). This seems odd to me. Why was this choice made instead of using a separate repository?

<identity>lordmzte: why would it be in a separate repository instead?

<ieure>lordmzte, Spot on with your diagnosis, not sure what the rationale is/was for doing it like that. It probably seems odder because you're used to how Nix is structured.

<nebel>i would guess that the package manager itself is basically just another package if you want

<vagrantc>partly because the bootstrapping cycles are much more complicated, woudl be my guess

<lordmzte>It might very well just be me, but I'd assume that the package manager (a tool that processes package definitions) and the packages themselves (the data that tool operates on) would be logically separate units.

<ieure>lordmzte, How do you define the packages for the dependencies of the package manager?

<lordmzte>Wouldn't those dependencies be defined in a package definition for the package manager rather than in the package manager source code itself?

<Rutherther>having the guix command inside of the repository also with all other packages and services means releases are less common for the command itself as well, because it's harder to get a release right. This means security patches are harder to apply for distros. And then we have the Debian situation where it removed Guix from the repos. I don't think this question is strange or that it's about expectations

<gorilla>I can't figure out why the mount point /gnu/store is busy

<identity>indeed, ‘guix’ is also a guix package

<ieure>lordmzte, So what do you do if you want the same, say, libc used for guix and the packages guix installs?

<ieure>gorilla, `guix shell lsof -- sudo lsof -n | grep /gnu/store'

<ieure>gorilla, There's probably better lsof flags to find this out, but I can never remember them.

<Rutherther>(guix shell won't work with the daemon stopped)

<ieure>Ah, well

<gorilla>I already lsof outside guix shell and found nothing

<lordmzte>ieure: 1. build guix with whatever libc version 2. use that version of guix in order to build guix again ("stage 2") 3. use stage 2 guix to build system and future updates of the package manager

<vagrantc>i would love it guix the package manager were split into it's own package repository ... but i suspect guix is a highly integrated project and ... perhaps most importantly, folks maintaining it have preferred to not have to think about the work it woudl take to split it all out and maintain it

<Rutherther>ieure: you make it a package in the same place as other packages. But that doesn't imply that you need to couple it with the repository hosting the packages. You can make it a separate repository that you can then individually build, either with the bigger repository where you make sure you build it with libc you want to use, or you can build it separately, like if you're making a distribution that should package guix

<lordmzte>Doesn't it already work like this despite it being in one repository?

<lordmzte>Yea; I don't find it strange that *packages* are in one repo, I find it strange that the packages are in the same repo that the source code for the package manager is in.

<gorilla>I don't see /gnu/store defined in /etc/fstab

<gorilla>Is it defined as a mount point somewhere else?

<Rutherther>gorilla: no, it doesn't need to be defined

<gorilla>ah. the daemon knows?

<gorilla>uh... no.. that doesn't make sense

<Rutherther>yes, the daemon knows it should call remount with rw/ro on the store

<gorilla>I mean, it would, but the mount doesn't disappear when the daemon shuts down

<Rutherther>the daemon just doesn't remove the mount when turning off

<gorilla>But the daemon will mount it when it starts?

<gorilla>if it needs to?

<gorilla>So if I can ever get it to unmount, restarting the daemon should mount it ro?

<vagrantc>it would be an interesting project for someone to try and decouple guix-the-package-manager, guix-the-daemon, etc. from guix the package respository

<vagrantc>i suspect it would be a lot of work

<gorilla>Now I just have to figure out why the selinux policy isn't permitting the daemon to remount

<levenson>Hi Guix!

<kestrelwx>o/

<gorilla>selinux person is sending a patch for the policy

<cow>where do I sent patches to?

<cow>I have a small patch for https://git.savannah.gnu.org/cgit/guix.git I'd like to send

<ieure>cow, Open a PR on Codeberg.

<cow>But the contribute link on the site is down

<cow>Oh I dind't realise there was a codeberg

<cow>Thanks a lot ieure!

<ieure>cow, Yes, we moved there earlier this year. https://codeberg.org/guix/guix

<cow>appreciate it <3

<simendsjo>Does cuirass support channels which requires authentication? In that case, how can I specifiy authentication?

<gorilla>It looks like the guix-installer I used is out of date somehow. (Even more than an hour apparently.)

<gorilla>The selinux policy it installed doesn't match codeberg's

<gorilla>How do I get something current? Build from repo?

<cow>just to add on from that (hence why I was looking for the repo), the patch that I was looking for that isn't there was two years old

<kestrelwx>gorilla: Have you downloaded the latest .iso or the standard one? The latter is 2022 release.

<gorilla>I'm not doing an sd install

<gorilla>I'm just doing guix via guix-install.sh, as instructed.

<tesseract>do guix users prefer wired keyboard over wireless?

<gorilla>tesseract: guix users prefer open firmware

<gorilla>is your wireless firmware open?

<tesseract>gorilla: i don't know

<tesseract>how can i check?

<tesseract>gorilla: does wired keyboards have firmware?

<gorilla>yes

<identity>tesseract: wireless keyboards have wires anyway, so why bother?

<gorilla>identity: ???

<tesseract>identity: what do you mean?

<identity>>buy wireless keyboard >look inside >wires

<gorilla>not helpful

<tesseract>my keyboard supports aes128 bit encryption

<kestrelwx>gorilla: Oh, I missed that.

<gorilla>tesseract: what is the keyboard?

<tesseract>so, which keyboards do you suggest?

<identity>gorilla: we regret to inform you that a joke has been told in your vicinity

<tesseract>gorilla: i have lots of keyboards. right now i am using hp wireless keyboard mouse set

<gorilla>kestrelwx: np

<tesseract>my keyboard use non-free firmware?

<gorilla>tesseract: does it rely on the bluetooth built into your host?

<gorilla>or does it have a usb dongle?

<tesseract>gorilla: it is usb dongle

<gorilla>tesseract: does dmesg show errors for it?

<gorilla>do you have a model number?

<tesseract>gorilla: i am using debian 13 by the way

<gorilla>uh. oh

<tesseract>i don't see any keyboard error in dmesg

<gorilla>with guix just as a package manager?

<tesseract>yes

<gorilla>is guix managing your kernel packages?

<tesseract>no. i just installed it for only icecat :p

<gorilla>then your problem should not have anything to do with guix, I'm guessing

<tesseract>but i am wondering you guys' thoughts about keyboards

<gorilla>guix is very rigid about open source.

<tesseract>do every keyboards work on guix?

<tesseract>rms will slap you lol

<tesseract>"open source"

<Deltafire>most keyboards should work, including wireless

<gorilla>some people have less of a sense of humor about freedom

<tesseract>Deltafire: so, their driver is free, rigth?

<Deltafire>standard USB HID

<Deltafire>or bluetooth

<levenson>tesseract: i have hhkb original and with Hasu HHKB Bluetooth Controller.

<tesseract>is it better to use keyboard wih bluetooth than dongle?

<levenson>what suits for you I would say

<tesseract>in the context of free software

<iama>why is Savannah so slow to download with git pull?

<gorilla>tesseract: I'm guessing that the wireless part of your keyboard invisible to the kernel anyway.

<kestrelwx>iama: GNU infrastructure struggling with traffic.

<gorilla>The dongle handles all the wireless so the kernel shouldn't have to.

<tesseract>gorilla: so, it is like the communication between keyboard and dongle includes proprietary stuff but after the dongle it is free?

<gorilla>The kernel should just see a usb keyboard

<Deltafire>i have a bluetooth and dongle version of the same mouse, the dongle one is better

<tesseract>Deltafire: in what aspect?

<levenson>tesseract: people can also hack and sniff bluetooth

<levenson>))

<gorilla>The vendor can have absolute control over both ends. If they do goofy stuff, it's on them.

<Deltafire>bluetooth one goes into standby after a while and needs a mouse click to wake, the dongle one doesn't.. the bluetooth one gets interference from wifi, the dongle doesn't

<tesseract>levenson: yes but what i am asking is in about freedom aspect

<gorilla>Nobody else has to figure out in what way they violated a protocol. And they don't have to worry about how some other vendor implemented a protocol.

<gorilla>If they do it right or wrong on both ends, it can still work. They don't have to cooperate with anybody else.

<tesseract>Deltafire: that issue is because of your mouse brand/model

<tesseract>i had no such issue on logitech mouse

<tesseract>Deltafire: what is your mouse brand?

<gorilla>kestrelwx: how can I get an up-to-date install script that points at mirrors and uses a current selinux policy?

<gorilla>kestrelwx: you did write that the URL has been updated, right?

<levenson>tesseract: AFAIK there are many opensource keyboard firmware. tmk, qmk

<Deltafire>tesseract: logitech

<Deltafire>i think the issue is with the laptop having a shared wifi/bluetooth chip

<gorilla>usb hid should not be any problem. Plenty of great open source there.

<Deltafire>downloading files makes the mouse pointer movement choppy

<ieure>TMK is pretty much dead, QMK is what most boards are using. ZMK is also decent, seems to be popular with people building wireless boards. Less features than QMK, but the main stuff is all there.

<gorilla>wifi/bluetooth, otoh, is a different story

<ieure>tesseract, There are proprietary blobs all over, in everything, there simply does not exist any system with 100% Free Software.

<Deltafire>somewhere in the guix manual is a section on setting up a local substitute server, but i can't find it :(

<ieure>Deltafire, guix-publish-service-type. https://www.futurile.net/2023/05/01/guix-publish-caching-substitution-server/

<gorilla>Can anybody point to a recent guix-install script? And a way to make sure the mirror is relatively up-to-date?

<Deltafire>ieure: thanks, i was reading that page the other day and had forgotten the url :)

<levenson>ieure: hmm i am curious what kind of *features* out there?

<ieure>gorilla, guix-install.sh comes from Git, this is the latest version: https://codeberg.org/guix/guix/src/branch/master/etc/guix-install.sh

<gorilla>I mean, something less than two years old?

<levenson>ieure: maybe you know something that I could read?

<ieure>levenson, Are you wondering what features these have, generally? Or the specific stuff ZMK is missing vs. QMK?

<gorilla>ieure: This patch has been in git for 2 years: https://codeberg.org/guix/guix/commit/3bf612eaa13cc39caab64567660b8a02d206d19a

<gorilla>ieure: but is not included in what just got installed

<gorilla>the installer makes sure things are cryptographically signed, which is good.

<levenson>ieure: generally, what people can do with the keys

<gorilla>But does it check any versioning?

<levenson>ieure: emacs macros?)

<ieure>gorilla, There hasn't been a release of Guix in that time, and I believe the install script installs the release. The comments in the script tell how to use something else, but, you'll have to bootstrap by building what it needs in a Guix container or VM.

<gorilla>*blink

<gorilla>You know that thing where people just pile on the back of the few who do all the work and don't even realize how few people are carrying the weight?

<ieure>levenson, You can do lots, the features I use most are layers, modifier macros, and mouse keys. I also used QMK's swap_hands when I broke a finger and had to type one-handed. The left-hand side of the docs has a lot of the features out there: https://docs.qmk.fm/

<gorilla>And all they can say is "go faster! go faster!"?

<ieure>gorilla, What?

<ieure>levenson, Layers let you stack up keymaps and use a key to toggle them off/on, or hold a key to activate them, like a modifier.

<ieure>levenson, So I have a base QWERTY layer, and a toggle that swaps super/alt keys for my work computer, which is a Macbook.

<gorilla>I'm shocked that there hasn't been a release in two years, but I haven't lifted a pinky to help.

<ieure>gorilla, Should hopefully have a release this year. It's fundamentally a rolling distro, so releases don't have a big effect on day-to-day use, which is how most contributors use it.

<gorilla>It has a huge effect on first time installs.

<gorilla>As in, they don't work.

<ieure>levenson, I also have a symbols layer, which puts all the programming punctuation (stuff like () [] {} $ ^ % etc) on home row. And that's on a mod-tap key, if I tap it, I get \, if I hold it down, it activates the syms layer.

<ieure>gorilla, Yes. For the install script specifically, though, it doesn't make much difference, since most users don't get it that way.

<gorilla>How do most users get it?

<gorilla>I was just following the documented method.

<ieure>gorilla, Packages from whatever distro they're already on. ex `sudo apt -y install guix'. NixOS also has packages.

<ieure>We have to get a new release out the door or the guix package will be removed from Debian, though.

<ieure>Or by installing Guix System.

<gorilla>no rpm for redhat, though

<ieure>You got bigger problems if you're running RedHat, lollll

<gorilla>I certainly seem to have a wheelbarrow full of problems every time I try to dip my toe into Guix so I can eventually move.

<kestrelwx>gorilla: There's a release planned for later this year as part of moving to a regular release schedule. https://consensus.guix.gnu.org/gcd/005-regular-releases.html

<levenson>ieure: Yeah, I was thought about emacs keymaps, but react on a hold, sounds cool. Are you able to *display* keymaps in order to continue?

<ieure>levenson, Not really. There's no special communication between the keyboard and OS to convey that sort of thing. Some boards have displays, they can tell you what layer(s) are active, but aren't really sufficient to show a keymap. All muscle memory.

<gorilla>Release in November. Beta out October 1? :-P

<kestrelwx>It might come later than outlined on GCD.

<ieure>gorilla, Yeah, I had a spare machine running Guix for 18 months or so, daily driver was still on Debian even when I became a committer.

<gorilla>RC1 due Oct 15?

<levenson>ieure: hmm. probably not a best place, but mac keyboard viewer maybe? It doesn't work on asahi at the moment/

<ieure>levenson, I'm not sure what you're saying.

<kestrelwx>gorilla: There's a milestone on the codeberg repository if you're curious about the release.

<levenson>ieure: I am running guix (asahi) on macbook pro 2020 to build aarch64 packages)) it has a touch bar which is a thing oled touch screen

<levenson>*thin

<gorilla> https://guix.gnu.org/manual/devel/en/html_node/Building-from-Git.html <-- Instructions from building from Git. Step 2: run guix

<gorilla>sigh

<gorilla>s/from/for/

<gorilla>This is a bad joke.

<ieure>levenson, Oh, yeah. Well, again, there's no protocol for communicating the state of layers etc from the keyboard to the computer. The host just sees a normal USB HID, which sends keycodes.

<ieure>gorilla, As the docs say, thats the easier

<ieure>gorilla, ...that's the easiest way. But you can install the build-deps manually and build that way, too.

<ieure>It even mentions which you'll want.

<gorilla>ieure: even with the deps installed, Can't exec "autopoint": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 318.

<kestrelwx>gorilla: Do you have GNU gettext?

<gorilla>yes. v0.23

IRC channel logs

2025-10-01.log