IRC channel logs
2025-12-16.log
back to list of logs
<JodiJodington>does anyone have experience using bluetooth headphones on guix? Everything works fine but for some reason, the handsfree_head_unit profile is unavailable. It worked fine on every other distro by default so I'm not sure how to troubleshoot it. <noe>JodiJodington, I also don’t see it <meaty>any CMake wizards in the house? <meaty>I wanna de-vendor a package that uses CMake, but my dilemma is that the build system expects a locally-built library named 'LZMA::LZMA' and all pkg_check_modules can do is declare some variables with a given prefix (I think) <meaty>the kicker (in the event that in CMake 'library'~='variables') is that that prefix cannot have ':' characters <meaty>JodiJodington: That's strange, I had to jump through hoops to get my headphones to *stop* using handsfree mode <meaty>though since my last guix pull they don't work at all <basicnpc>If I help update sbcl from 2.5.8 to 2.5.10 in the guix channel, I should also make sure that all other packages that depend on sbcl should also build based on 2.5.10, right? <ieure>sneek later tell basicnpc Yes, you need to make sure that packages taking it as an input build. The command to do that is in the pull request template, along with a checkbox to say you ran it without issue. <basicnpc>ieure: Hmm that means if a package is used by many other packages.. it becomes increasingly harder to update them? <sneek>basicnpc, you have 1 message! <sneek>basicnpc, ieure says: Yes, you need to make sure that packages taking it as an input build. The command to do that is in the pull request template, along with a checkbox to say you ran it without issue. <basicnpc>So say a package is heavily relied on is getting upgrade, who has the ability to check carefully that all dependencies are actually going to work too? <basicnpc>And what if a package simply doesn't work for later version of sbcl? <basicnpc>Who will make the judge to keep that package or to move on to the newer sbcl? <ieure>basicnpc, Yes, packages lower in the package graph are harder to update. This isn't unique to Guix. <ieure>basicnpc, If your update breaks another package, it's generally on you to come up with a solution, though you can of course ask for help here, guix-devel, from reviewers, etc. <basicnpc>What then is the advantage of packaging in guix? In other distro, with their package definitions kept in a git repository, one can expect the packages to 'work' for an extended period of time too. <basicnpc>I used to imagine since all older versions of the same packages 'work' (by using inferiors), we don't have to care about all packages above while updating any package. <graywolf>I would like to think so, yes. But depends a lot on your needs. <ximon9>graywolf I would like to have a non sudo oss <ximon9>I would like to have isolated system <luca>What is a "non sudo oss"? <ximon9>luca simply not installing gui or apps inside the / <graywolf>In that case guix would fit, in general you do not need sudo to install applications for your user. <ximon9>but it is probably a pain in the ass to install it or? <luca>"it depends" :P, there are a lot of programs to install in a lot of configurations. And some even require "sudo" to install properly. Off the top of my head screen lockers come to mind <graywolf>GNU Guix definitely has steeper learning curve compare to other distributions. <graywolf>For me the trade-offs are worth it, but that will not be the case for everyone. <ximon9>it seems like in there is a make command <graywolf>This specifically is a "channel". You can think of it as an extra repository in other distributions. <ximon9>could I give you my apps that I have in arch and you could tell me if I am able to install all of em in guixß <rhuijzer>Hi ! Is guix home still actively maintained ? I'm running into a gazillion bugs since reconfiguring a couple of months ago. (eg home-bash-service-type aliases broken, home-zsh-service-type producing an empty zshenv)? Not trying to flame but checking if maybe i'm the problem <gabber>rhuijzer: i guess there might be a problem with your configs? wanna share them and the exact problems you are experiencing? <Rutherther>rhuijzer: an empty .zshenv? that's something the home-zsh-service-type can never output. It should always have at least "source /etc/profile", so rather check there aren't any corruptions with "guix gc --verify=contents" <rhuijzer>Whatever I try, .zshenv is always empty. Great suggesion, will try <Rutherther>either there is a corruption or the zshenv you're looking into is not actually managed by guix home <ximon9>can you install from guix installer sway? <Rutherther>not yet, that will come in the next version. But installing sway is easy afterwards <ximon9>oh wait you dont even have systemd? <ximon9>so bluetooth and stuff will not work? <rhuijzer>Rutherther: It really should be handled by guix, because it's empty when invoking guix home container as well. Also; I see the symlink happening from .zshenv to a guix store path with a hash, but the path is empty. So Symlinking /home/rhuijzer/.zshenv -> /gnu/store/%hash%-zshenv-auxiliary... done <- that path is an empty file <Rutherther>ximon9: shepherd is used as init system. I am not sure how you've reached the conclusion that bluetooth will not work. Bluetooth should work <ximon9>but maybe I have proprietary parts in my system? <Rutherther>you may do whatever you want, it's your system. The main guix channel doesn't have any proprietary parts, but there are channels that do <rhuijzer>guix gc --verify=contents does have some mismatches, its still busy, no relevant ones yet. Is that normal or maybe indicative of a HW problem? <ximon9>Rutherther so guix is rather hard <Rutherther>ximon9: definitely, imperative ways are usually easier to get by than declarative ones <graywolf>rhuijzer: It is not normal, but it does not have to be HW issue. Some time back there were some bugs in clean unmount of filesystem, and that lead to store corruption for some (me included) people <rhuijzer>ximon9: its harder to install proprietary firmware than in e.g. ubuntu yes. Thats by design <ximon9>Rutherther what would be a better choice if it should be easy but a bit isolated <Rutherther>rhuijzer: what paths are the ones corrupted? That can sometimes give out for the causes a bit. If it's quite random, hw issue likely, yeah <rhuijzer>Rutherther: all random things. polari, ungoogled chromium, nvim <ximon9>requirements are to not infect people in my network <Rutherther>rhuijzer: yeah, then I would be afraid of a hw problem, you can try out sw to test it. Either the disks or RAM <rhuijzer>Rutherther: oh crap zshenv appeared ! oh dear, "that's a lot of damage". Thanks for the suggestion <rhuijzer>I should probably run memtest and stuff. <Rutherther>rhuijzer: it's ufortunately not easy to recover from corruptions that are all over the place like that. You might try adding ",repair" to that verify argument, but it will not repair everything. After running the memtest and stuff that is, otherwise I would be worried about it coming back <graywolf>ximon9: If your main goal is security, Qubes OS is a candidate. <ximon9>it should not be insanely hard to use :P <rhuijzer>Rutherther: tnx. I will try to run --verify=contents, repair, do some hw tests and fully reinstall if necessary, creating a new btrfs filesystem in the process. <rhuijzer>It certainly explains the weird small bugs everywhere of the latest weeks <ximon>probably systemd is the most convenient <rhuijzer>Rutherther: I have never used mint before what do you mean? Are you replying to to the right person? <graywolf>To a degree it is fascinating how systems can functions with holes and error everywhere ^_^ (tbh feeling I get every time I open browser console on any webpage...) <ximon>I could try to put freebsd on it <rhuijzer>graywolf: In the past I always got scared when running openZFS on consumer hardware. Always a lot of small errors reported that don't really hinder day-to-day end user tasks. Eventually I reverted to ext4 so that I didn't have to see them again lol <rhuijzer>error: error parsing derivation, error: cannot repair path, error: cannot repair path, error: cannot repair path So I'll probably have to create installation media.... <graywolf>I would be scared to create installation media from that system... <ximon>do you think freebsd is virus? <rhuijzer>My anecdote about zfs is years and years ago and not this pc lol <rhuijzer>I will do some HW tests and reinstall. Have a nice day everyone <untrusem>so I found out about `gpg refresh -u` today <untrusem>anyway so I was using it on a package and the build fails due to it gpg key <untrusem>gpgv: keyblock resource '/home/<username>/.config/guix/upstream/trustedkeys.kbx': No such file or directory <untrusem>I imported their key but i have encountered this in a package <untrusem>do I need to make the trustedkeys.kbx myself, I think now <basicnpc>If I update a package, I should also be using them for a while to detect runtime bugs, before I merge it into the official repo? <basicnpc>And how often do we have the case where a runtime bug is later found, and we need to undo a package update change in the official channel (just curious). <gabber>basicnpc: that would be great, but usually we somewhat rely on the maturity of the software. meaning we assume usability regressions would be caught by their unit tests (which are to be executed in our package build process) <untrusem>so why guix refresh is looking in the ~/.config/guix folder and not the ~/.gnupg folder? <gabber>basicnpc: on the frequency of what? <gabber>it lies in the very nature of software (or even computing) that there are bugs. if we push updates to packages that essentially break the software we are quick to roll the changes back <basicnpc>and sometimes we need to maintain several versions of the same package in the channel (e.g. guile)? Is it because of that? <gabber>i have no idea. you could skim the logs for such things. but i guess we usually try to fix things instead of reverting (and not push breaking changes) <gabber>basicnpc: no. that is due to bootstrapping efforts and thus the need of different versions of packages because significant packages rely on either version <basicnpc>Usually we don't have different versions of the same package in the channel? <basicnpc>Before I studied guix I thought we kept all package defs for all versions in the channel 😂 <gabber>basicnpc: most software is backwards-compatible, so an update should still work with software that depends on an earlier version <gabber>basicnpc: that'd be quite a challenge to maintain! <basicnpc>gabber: Why would it be a challenge? We just kept everything that has known to work to be there. If I update one package, I don't even have to worry about the others.. just let them depend on the older one. <gabber>if you wanted dependent packages to update to a never version, you'd have to manually go through all the dependents and change them, no? <basicnpc>I will be back soon and I will read log. <gabber>basicnpc: i'll leave the answer to that question as an exercise to the reader (you) <basicnpc>`guix package --show=guile` shows their locations. E.g. gnu/packages/guile.scm:77:2 <basicnpc>Where in my guix system can I get to this file? <gabber>untrusem: i know. that's the (hidden) irony of our `guix edit` command <gabber>but you get the definition and can save the file to a location where you can edit it (if you want) <untrusem>its fine if you just want to copy the package defination <basicnpc>gabber: I just realized that was for me. <basicnpc>`guix build -f file.scm` => error: git-version unbound var <basicnpc>What's the simplest way for me to independently find which module to import? <ieure>basicnpc, grep -rE '(define.*the-thing-you-want' ~/path/to/guix/checkout <ieure>git-version is likely in (guix git-download) <basicnpc>So I need to keep a copy of the guix repo. How do I know which git commit my guix is at though? <basicnpc>Should I use the info from ``guix describe ``? Or that's just the channel? <ieure>basicnpc, There's a copy in $HOME/.cache/guix/checkouts/4mbc7ep4mp2takmrharjqx55abg243hlrae62jjg6rqieztbnttq <basicnpc>ieure: I have two relevant dirs under .....guix/checkouts, which one should I use? <basicnpc>I guess there is a command I can use `guix self-describe` to see the location of the exact copy? <ieure>basicnpc, ??? I gave you the exact path to it? <ieure>There is no `guix self-describe', where are you getting that from? <basicnpc>ieure No, I don't have the hash 4mbc...... under that dir. I do have 7x37p6..., l74zyeb3lg..., pjmkglp... <ieure>7x37p6bub2newlthjx5kk2mco2aq44vxbqp5gwa3sifqxzfb3aqq <ieure>Sorry, 4mbc7ep4mp2takmrharjqx55abg243hlrae62jjg6rqieztbnttq is a local clone I pulled from for some testing. <ieure>The IDs are stable per channel across all machines. <Rutherther>yes, it's a cache of git checkout, you also typically not have N repos for all the refs you want to work on, you have just one checkout and checkout the refs you wanna go to <ieure>basicnpc, Why the alarm? It's hash of the channel, it's the channel identity. It doesn't change because the commits in the channel do, it changes if the channel name/uri/etc change. <basicnpc>My real question.. when it updates, how can I independently figure out what the new path is? <ieure>What I have just explained twice is that the path does not change when the channel updates. <ieure>Otherwise I wouldn't be able to tell you what the path is, or that it's the same for every Guix machine. <ieure>The checkout updates when you `guix pull', so its HEAD should match your `guix describe' in most cases. <Rutherther>it's not wlroots not building, that's a dependency of wlroots <Rutherther>is that a package in guix or are you packaging it? <basicnpc>I'm trying to package mahogany-heart in guix. <Rutherther>wlroots has changed to using "wlroots-0.XX" package names, including the version. So presumably the package that's being used here didn't really follow that new scheme <Rutherther>oh no I misunderstood they do depend on a specific version inside of a subproject indeed <Rutherther>but you are probably missing recursive cloning, so the wlroots that's in the repo is not cloned <basicnpc>Hmm.. the latest wl-roots is wl-roots-0.19 , which points to wl-roots. <Rutherther>anyway it would probably be easier to tell it to use wlroots from guix rather than to try to build wlroots <FuncProgLinux>I never quite got the difference from the manual but I think that, if you need something at build time use native-inputs, if it's a runtime dep leave it at "inputs" <ieure>If it's needed *only* at build time, it goes in native-inputs. <FuncProgLinux>propagated inputs I've seen are rarely used on user desktop packages <basicnpc>Rutherther: Any idea how I may make it work..? <ieure>FuncProgLinux, Propagated inputs get added to the profile along with the package propagating them. They're often used to pull in libraries for interpreted languages like Python -- since they just "import blah" instead of referencing a store path, Guix doesn't know what thing should be added to the package closure. <basicnpc>To tell it to use from guix..? Thinking.. <bdju>So happy that qutebrowser is working normally again! Thanks to all who worked on that. <basicnpc>So I need to figure out how meson tried to find wlroots systemwide, and I need to make a copy of wlroots to that path? <basicnpc>Yeah, new to meson. I read the meson file, it's asking for wlroots >=16<17. But we only have 15 and 17 :-D What a fortunate coincidence. I guess that's why they skip the 'systemwide' one (that I put as 'inputs')? <basicnpc>Anyway, I'm trying to package wlroots 16 now. <basicnpc>I guess I found a bug.. `guix install wlroots-0.15` doesn't work. Why? Is that package definition broken in the official channel? I had a very similar error when trying to package wlroots-0.16 <ieure>What does it print when you run that? <basicnpc>Btw, `guix install wlroots-0.17` => unknown package, even though it's defpublic'd in my ~/.cache/guix/checkouts/7x37.../gnu/packages/wm.scm <ieure>basicnpc, `guix install' expects the package name -- the value of the name field of the package record -- not the symbol the package record is bound to. <ieure>ex. if you have: (define-public flurple-wurple (package (name "foo"))) -- then `guix install foo' will work, and `guix install flurple-wurple' will not. <ieure>If you need a specific version, you need a specifier, ex `guix install wlroots@0.17'. That will look for (package (name "wlroots") (version "0.17")) <ieure>And it understands semver, so @0.17 will match the newest package version of 0.17.1, 0.17.2, etc. Same for wlroots@0. <basicnpc>( Sorry. I'm still trying to pipe that output to termbin.com.. but even with 2>&1 it didn't work. ) <ieure>basicnpc, Is it building and failing the build, or something else? <ieure>What Guix commit are you on? (`guix describe' shows this) <ieure>I'm on commit b385d38 on x86_64, and I see wlroots 0.17.4 substitutes are available. <basicnpc>I'm specifically building wlroots-0.15 to see how I can package wlroots-0.16. <basicnpc>>=0.17 works, yes. But the package 'mahogony' only depends on >=0.15 <0.16. <ieure>Have you tried loosening its dep requirement? <basicnpc>ieure: By changing the meson file line? I dunno how to do it, so no I haven't. <ieure>basicnpc, It's probably very simple, find the line, then add a phase that calls substitute* to change it. Many such examples in the Guix repo. <ieure>basicnpc, Also, have you looked at the Git history of Guix to see if there was a wlroots 0.15 which was packaged in the past but removed? <Rutherther>loosening won't work, wlroots does breaking changes every release <basicnpc>But still, why would wlroots-0.15 fail when it's in the guix channel? <basicnpc>Do you mean I could be using an older guix, which contains that failing package def of wlroots-0.15? <ieure>basicnpc, I don't see wlroots 0.15 in the Guix repo at all. <ieure>`guix show wlroots | grep ^version' shows 0.19.2, 0.18.2, and 0.17.2. <basicnpc>Same for me too .. 0.19.2, 0.18.2, 0.17.4. <FuncProgLinux>I dread the day MATE completes it's wayland migration. I don't want to think how much things will need to get reworked to get the wayland session working x.x <basicnpc>But ~/.cache/guix/checkouts/7x37...../gnu/packages/wm.scm has that definition. <ieure>Oh, the package *name* is wlroots-0.15, not wlroots. I guess that changed. <ieure>FuncProgLinux, It does in this case, however, that is not universally true. <ieure>Inputs uses the symbol the package is bound to, it can be anything. <FuncProgLinux>ieure: I already shot myself with that when packaging libwnck 43.0 <basicnpc>ieure Yes, the name is wlroots-0.15. Does installing that break in your system? <ieure>basicnpc, There are no substitutes, so presumably it will reproduce. Run `guix pull' to get the commit FuncProgLinux linked and it will probably work. <basicnpc>I need to fix lunch for my family. It'd be helpful if someone can provide tips from how I go from here. Should I make it work and test the WM myself, before even considering making a contrib to the channel? <basicnpc>(Lemme post my definition here. I will read log.) <basicnpc>It was taken from some old attempt 2 years ago in the mailing list though :-P still <ieure>basicnpc, Yes, you should make sure things actually work before contributing them. <ieure>This is preferred. You can also put up a WIP PR and label it, I believe the label is "help-wanted" or similar. <ieure>But things will be easier if you make it work first. <basicnpc>Ok then. I need to figure out how to get rid of my temporary desptop env service and make that WM works :) <basicnpc>(I'm currently on a veery stupid desktop env...) <csantosb>I'm not familiar enough with apt-get, is there an equivalent to packages.guix.gnu.org for apt-get ? <csantosb>I'm trying to guess why I'm unable to pass the tests in one package, whereas github actions does <ieure>csantosb, packages.debian.org <ieure>It is a very nice setup, I wish ours was as nice and fast as theirs. <csantosb>At least, we're not expected to know what "bullseye (oldoldstable)" means 🥴 <ieure>I know, but I still run Debian for my servery stuff. <ieure>Local machines ZFS, which is very poorly supported in Guix, remote ones are on a VPS and Debian is fully supported / Guix isn't supported at all. <ieure>And it's still comfortable, since I've been using it for nearly 30 yeras. <identity>csantosb: bullseye is the release name, oldoldstable means it is the ($current_relese−2)th stable release. after 1.5 releases, we should spend 50 emails bikeshedding which $media will be the one we take character names from to start naming our releases (plural!) after <ieure>Yes, codenames are always consistent for the release, but for the "stable" channel, they prepend an "old" to it for each release after until it's no longer supported. <identity>iirc oldoldstable is then moved into the archive, so there is neither oldoldoldstable nor oldoldoldoldstable <ieure>I agree, though it is rather funny to think that since I started using Debian with 1.3.1 "bo," that is now considered oldoldoldoldoldoldoldoldoldoldoldoldoldoldoldstable. <csantosb>Regarding codeberg/crypto-team, could someone rebase on master ? I'm not allowed to push there. <attila_lendvai>i use tlp-service-type to set battery charge thresholds. it used to work, but now it silently doesn't apply the limits. any hints how to debug this? "2025-12-16 21:07:22 localhost shepherd[1]: [tlp] Setting battery charge thresholds...done.", and yet it's unchanged as per tlp-stat -b <attila_lendvai>it seems to work on my main laptop, but it's possibly a couple of weeks behind on updates <ieure>attila_lendvai, I also use tlp on my laptops, and have found that it doesn't always work consistently. Might not be a new problem. <ieure>attila_lendvai, It seems like the thresholds get reset either during sleep or wake, or don't get reapplied on wake. At least, I have noticed it more when doing a sleep/wake cycle than a fresh book. <attila_lendvai>ieure, i haven't noticed any issues on an x1 carbon, but it doesn't work now on a thinkpad x250 <ieure>attila_lendvai, Usually `sudo herd restart tlp' solves it. <attila_lendvai>ieure, my problem is that restart tlp doesn't apply it, contrary to the log in messages. if i `echo 80 >/sys/class/power_supply/BAT1/charge_control_end_threshold`, then it works <attila_lendvai>shell scripts are driving me mad every time i interact with them (tlp is a shell script)... <ieure>attila_lendvai, Yeah, X240 through X270 used the Battery Bridge system, with a small internal battery (BAT0) and a big external pack (BAT1). <ieure>It was a very good system, you could swap out a dead pack for a freshly charged one and keep going. Still annoyed that's not a thing. <ieure>The T480 my dad gave me recently is awesome, it's got nearly 100wH of battery and lasts something like 18 hours on a charge. <ieure>It also has the battery bridge system. <ieure>My kids' grandma (ex-wife's mom) is in pretty bad shape this year, she got lung cancer recently and had surgery to remove it. Then the week after, had an alcoholism-induced stroke. <ieure>She's been smoking for decades at least. At one time, she told me she didn't have to worry about cancer because "You only get it if you don't detoxify yourself." <ieure>Don't smoke, that's my message. Also don't listen to Coast to Coast AM for medical advixe. <yin>hi i'm interested in trying out guix. where should i look first if i want to start from a first principles approach? <FuncProgLinux>yin: I'm an advocate of learning by doing. If you are on a foreign distribution I recommend you starting there first (I did on trisquel), then move to Guix System if you want to experience the true power of GNU <yin>i'm spinning up a vm <ieure>I agree with learning by doing and trying things out in a low-impact way. <ieure>I ran Guix on a spare laptop for a good while, until I was really comfortable (and had built some things I wanted). It was a bit over a year until I switched my daily driver over. <FuncProgLinux>I switched "blindly" from Trisquel and I had to either learn or die trying lol <FuncProgLinux>It also kind of makes you embrace "minimalism" as a user in a sense of "try to install just what you use" and leave development things to shells per git project <FuncProgLinux>the packaging system is kinda hard to grasp at first but having done .deb/.rpm and EBUILD packages it turns into heaven instantly. <yin>are you constantly tinkering with the system or does guix make it easy to just set and forget stuff compared to your usual minimal distro? <ieure>yin, It depends. I'd say a bit more tinkering than other distros, but it depends on the distro. <ieure>Some of that is that while Guix is a fine daily driver / dev workstation OS, it's missing some of the more administrator / operations / IT stuff which I also care about. I contributed stuff to run autofs recently, and collectd support is next up.