IRC channel logs
2026-05-22.log
back to list of logs
<yaircul>GNU Guix so good :-D but I did not upgrade it for a while, will it break when I decide to upgrade? <aloys>yaircul, you can try... and rollback if it does. <YARs2>I know guix doesn't support secure boot, but is there a way to manually add it? <sham1>You'd need the shim, most likely <GalaxyNova>Do any of you have any tips with working with Common Lisp in Guix? (specifically making / using libraries that depend on dynlibs) <GalaxyNova>I know there are packages like sbcl-sdl2 and such that provide everything set up for using that specific package but what if I wanted to use a CL library that was not packaged by Guix <GalaxyNova>Or if I wanted to make my own CL library that had to depend on some .so libraries <GalaxyNova>`cffi` seems to only search in LD_LIBRARY_PATH which is not set by default and direnv doesn't set it either <GalaxyNova>I can add all the paths manually and I've written a script that does it automatically using pkg-config but it does seem kind of confused <GalaxyNova>I suppose the Guix way would be to make a package for when I am developing a new CL library <yelninei>is there a world rebuild going on right now for anyone else? <yelninei>i guess e12b7e621717f7589d8d713942cf8040b934cd09 changes git-minimal/pinned and we are now rebuilding 10k packages per arch for zsh completion ... <adanska>it appears so... whoops! though i am glad that issue has been fixed, it has been bugging me for a while <yelninei>great, my deliberately minimal test system now depends on rust for the documentation for btrfs-progs ... <yelninei>at least the documentation is now memory safe! <yelninei>also I dont understand why there is a lot of fuzz about something with 3k dependants but 10k is fine because it fixes my issue? What if everyone starts yoloing things like that? <adanska>yelninei, well... it is bad. I think this was an honest mistake though... but the builds have already started and there will certainly be no new breakages so reverting would be a waste of energy. But yeah, perhaps some more diligence regarding rebuilds is due <adanska>although this doesnt happen too often <apteryx>can't seem to fetch codeberg at the moment <yelninei>the problem is that relying on "guix refresh -l" is not enough because it only counts for the arch you are running and does not consider inheritance, etc <adanska>yeah, a more aware guix refresh -l would be very welcome <yelninei>at least because of that i now founds out that my system depends on rust again ... <kestrelwx>apteryx: Yeah, I couldn't connect with SSH for a bit. <trev>yelninei: let me apologize to you for not checking the dependents before submitting the PR <adanska>could open a closure-size bug and try and get it fixed <yelninei>trev: You dont need to apologize, I am just grumpy that I cant update right now <trev>i am too. cancelled a reconfigure before realizing it was my fault. i'm kind of angry that such a stupid fix caused a world rebuild though <apteryx>is anyone successfully using using wildcard on domains with certbot-service-type ? <apteryx>currently it errors out with: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS. <apteryx>hm, looks a bit involved, with the dns plugin having to be able to talk to your dns server to dynamically change keys there <csantosb>Hi Guix ! I had an issue with "1ff6e687c05 * shadow: use emulate to source profile scripts"; I had to revert it to make my home config start as usual, anyone else ? <csantosb>Symptoms are, when I login, no command whatsoever is available <orahcio>Hi, a question about tex packages in guix. I found the ConTeXt tex engine inside a texlive-scheme, but the latest edition of ConTeXt uses luametatex as engine. Is it possible to package in guix? Is there some restriction between guix and latest ConTeXt? <trev>cnx: you mind if i re-open that catastrophic PR against core-packages-team branch? <trev>csantosb: that was another one of my zsh fix commits...i didn't notice anything with it <Duongph2098>Today during reconfiguration I saw my machine pulling KDE stuff out of nowhere. Can you please take a look at my configuration and tell me what depends on KDE? <trev>Duongph2098: probably the QT thing? <pastor>Don't mind me, I'm just testing a bot. <trev>Duongph2098: did it work? <Duongph2098>trev: still `Computing Guix derivation for 'x86_64-linux'` <stephen0>I didnt explicitly list the qt or gtk tools for fcitx5, just fcitx5, fcitx5-configtool, and fcitx5-chinese-addons -- no kde here. <Duongph2098>However it was there for weeks and today is the first day I saw it pulling KDE stuff <Duongph2098>Yes. It just that I checked and couldn't found what depends on KDE <Duongph2098>I messed up my ssh and gpg and I can't commit/push to git right now, sorry <pastor>Another test message for the bot <trev>pastor: why do you have to test it here? <pastor>trev: Because it's for mirroring this room <kestrelwx>Duongph2098: if you have already built the profile you can try `guix gc --referrers $(guix build kconfig)`. <Duongph2098>kestrelwx: No I haven't finish the build. I Ctrl C when I saw it building librewolf <stephen0>aw, damnit, fcitx5-configtool is pulling in kde deps <stephen0>I only added it to turn on the ime, now that my config exists, I'm just going to remove it. <stephen0>Removed it, cleaned, checked the referrers again, and kde stuff is gone <Duongph2098>stephen0: I asked claude before and it said it was fcitx5-configtool <Duongph2098>I just ignore it because fcitx5-configtool is not what I recently changed <stephen0>I wonder if there's a more guix-ified way to add the ime so I dont need it at system setup time <trev>yelninei: that world rebuild is still going. does it mean that we can eventually merge after it's done? <trev>oh i got confused at the pending count going down from 30,000 <Duongph2098>building /gnu/store/2agxnzw0i60xp82lzqr2kcl63311f75f-librewolf-150.0.3-1.drv... <kestrelwx>Yes, it was updated recently for security fixes. <Duongph2098>Does it means that I need to wait a little to use the binary in the substitute servers? <kestrelwx>Actually, if you pulled couple hours ago you might be on a commit that triggered a lot of rebuilds, so you might want to pull again. I would think the upadte already has subs. <kestrelwx>The arguments for LLM use on Codeberg discussion of the GCD are quite funny, with both Savannah and Codeberg being brought down at times due to the LLM crawlers. <kestrelwx>`guix weather librewolf` is sunny for me after a pull. <futurile>there's quite a bit of discussion - now's the time to get your thoughts and comments in ;-) <futurile>tusharhero-xmpp: heh, for sure - I'm really *behind* on reading it - important and controversial topic! <futurile>(maybe controversial is not quite the right word, but lots of interesting perspectives) <futurile>tusharhero-xmpp: yes. Copyright can only be claimed if a change is (not sure right word) substantial. A short-hand people have is that a change has to be 15 lines long for it to meet that level. <bjc>haven't we been telling people 10 for years? <bjc>am i misremembering? <tusharhero-xmpp>futurile, right, and it was a heuristic for FSF copyright assignments, and it applies globally not on a per patch basis. <futurile>tusharhero-xmpp: as with so many things in the legal space it differs by jurisdiction. Most discussion focuses on the USA treatment of copyright, but for example where I live in the UK it's slightly different etc <futurile>bjc: I'm not sure. Honestly, I think most people add their names in the files not for 'copyright' but to note their contribution, to have a bit of personal credit. Since technically you don't need to add a line to claim copyright, you just "have" it. <futurile>tusharhero-xmpp: I _think_ the idea is that we'd only accept contributions via LLM which are so trivial that they don't matter. I'm not sure if Ludo has replied on that specific point with his thoughts <tusharhero-xmpp>so you can't create a 100 patches with 15 line additions to add something nontrivial? <futurile>tusharhero-xmpp: I think that's the idea. The overall position would be to discourge use of LLM. Right now the legal position on LLM and copyright isn't settled (AFAIK), so I guess there will be some "inexactness" in what happens and we'll have to revise things as it becomes clearer. <tusharhero-xmpp>afaik fsf/gnu are advising to not install LLM generated code until they evaluate the legal questions <futurile>tusharhero-xmpp: yeah, fair enough. As you know Guix is a big community with a range opinions. Anyway my main point was to remind people that if they want their opinion to be part of the discussion/outcome now's a time to comment! <apteryx>hm, we can't do split-dns at the level of /etc/resolv.conf, can we? <apteryx>I wanted a wireguard peer to add a DNS entry just for its network, not overriding my local DNS server. <apteryx>(extend rather than override, just for its network) <apteryx>is that possible on Guix System? systemd-resolv seems to support this use case, but not openresolv, which wireguard is using. <switchy>apteryx: that's actually why I put !8607 in, you can do it with dnsmasq + NM <apteryx>that's what I was thinking, using PreUp and PostDown with nmcli instead <apteryx>I see; that seems useful on its own, but I want my peer to provision it, so I'll look into the PostUp/PostDown trick <switchy>ah yeah, fair. I use it with tailscale so I just need a fixed entry <apteryx>well, I'll give it some thoughts, as "provisioning" is moot since it's all happening in the user's conf anyway. <apteryx>I could also just use a /etc/hosts entry, but I was trying to have a neat wireguard peer template to share to others that "just works" will little extra hoops. <sham1>Speaking of DNS, what would be a way to do DNS-over-HTTPS on Guix System. Like what might be the service I'd have to configure for that <sham1>Hmm, actually dnscrypt might be the ticket <cluelessguixer>Was considering whether having a "guix pull" shepherd timer makes more sense in my home config or system config. It should be run as a user, right? <ieure>cluelessguixer, There's also an unattended-upgrades-service. <ieure>cluelessguixer, It doesn't matter much with containerized services, since they only have access to the container environment, which is typically either r/o (excepting bind-mounted data / config directories) or which discards writes on restart. <psycotica0>Hey folks! I have a question that might not have a good answer. I'm trying to build `electrum`, which is a kind of bitcoin wallet thing, but it was building for a while without me noticing it, and when I went to look it was in the middle of building inkscape, which is a vector image editor... I thought that was strange, and so I looked into the graph and it seems like the path goes "electrum@4.7.2" -> "py <psycotica0>thon-pyqt@6.9.1" -> "qtbase@6.9.2" -> "pulseaudio@16.1" -> "bluez@5.79" -> "libical@3.0.17" -> "gtk-doc@1.34.0" -> "dblatex@0.3.12" -> "inkscape@1.3.2" and I'm not sure if there's a good way to solve this... but it feels weird that in order to build a bitcoin wallet I'm building an audio stack, which is building a bluetooth stack, which is building gtk stuff, which is building an image editor. <psycotica0>All said, building electrum, the total closure of dependencies, is 1052 packages <psycotica0>But maybe I'm just being naive, I mean, I guess in _some_ sense these things must exist for guix to use them. But it feels nuts to me. <psycotica0>Also, for reasons I don't understand, `guix graph --path electrum inkscape` claims there isn't a path. I don't know why. So to find the above I had to have the graph command output the dot format and then process it with a python library <psycotica0>And, like, bluez depends on libical? I guess presumably because one of the things a bluetooth device _could_ receive is a calendar invite? But it feels like a bit much for these all to be required dependencies... I know my bitcoin wallet thing isn't going to be getting any bluetooth calendar invites via its audio stack... <kestrelwx>If there a particular package which causes your dependency graph to explode you might be able to define a variant that has a smaller closure and avoid this. <trev>psycotica0: a simple guix build electrum? <trev>i'm seeing a lot of junk too. maybe the package def needs some cleanup <psycotica0>The dependency graph is a bit hard to see, with over 1000 items on it, but I'm going to guess qtbase is a bit explody, given that this is what's pulling in all of pulseaudio <ieure>psycotica0, The majority of modern software is a dependency hell like this. <ieure>psycotica0, Do you have substitutes disabled? You shouldn't have to build the whole dependency tree, there should be binaries available. <psycotica0>I probably haven't noticed up until now, because I'm not on a guix-system system, and I suppose I've mostly used guix for cli programs <ieure>psycotica0, But, yeah, go look at the packages, each individual dependency makes sense in context. But when you only look at the top level package and see the deep dependencies, it seems absurd. <psycotica0>I _should_ have substitutes... but it didn't seem to be using them... <psycotica0>How are the substitutes identified? If I'm running off a branch of master, does that immediately disable any and all substitutes, or do they still match by closure if my fork didn't modify them? <ieure>psycotica0, It's based on the derivation. <psycotica0>Right, okay, that's what I would have expected, so I ought to have them. But it doesn't mean I didn't disable them for a dumb reason at some point... <ieure>psycotica0, Branch doesn't matter, neither does channel -- if you copy a package definition from the guix channel to a completely different one, substitutes will still work (as long as you didn't change the derivation moving the package definition). <psycotica0>Yeah, okay, there's something broken with my substitutes setup. I'll look into that. It won't reduce the _number_ of dependencies, but at the very least it'll reduce the time and energy the computer spends on them. Thanks! <trev>psycotica0: check systemd unit for --substitute-urls <psycotica0>Oh! I have another question! The reason I'm running a fork at all is because I have two patches, each of a few lines, that were required to get some software to build, but I haven't bothered to contribute them yet. But to use those patches, pre-contribution, on my main system I've run `guix pull --url=file:///home/psycotica0/src/guix --branch=MYBRANCH --allow-downgrades --disable-authentication`. Is that <psycotica0>the right way to do it? Because it doesn't _feel_ right <ieure>psycotica0, Are the patches to Guix itself, or just package definitions? <ieure>psycotica0, I'd recommend setting up a channel to hold modified package definitions rather than forking the whole Guix repo. <psycotica0>That makes sense, but when I went looking to do that, I found it hard because these packages obviously have any dependencies at all, and I think I strugged to get the channel packages to depend on main guix packages? <psycotica0>Or if that's wrong, then maybe instead it's because what I modified was a distant dependency of the actual package I wanted to build, and maybe I just failed to get the transform right to keep the guix base package definition, but patch out the deeper dependency <ieure>psycotica0, There is a mechanism to add channel dependencies, but the Guix channel is implicit. <cdegroot>Normally you can just say #:use-module (guix bla) and it automagically works. <psycotica0>Ah okay, so maybe it was the transform problem, where I wasn't actually trying to patch the endpoint, but one of the middle dependencies <psycotica0>And then would the transformed channel version shadow the upstream one? Or would I need to give my version a unique name? <ieure>psycotica0, Dependencies are explicit, if you need to change a dependency, you need to rewrite packages from the leaf packages you install down to your changed package. <psycotica0>By rewrite do you mean programmatically, or do you mean "copy and paste into the channel definition file"? <ieure>Example, if you're intalling Emacs, but need to patch libwebp (which it depends on), you have to create a libwebp variant package, then create an Emacs package variant which uses the libwebp package variant. <ieure>Creating a package with the same name/version as something already in Guix doesn't replace the Guix package definition, is what I'm saying. It's a completely different package, and you have to point other stuff at it. <ieure>psycotica0, There are `package-mapping' and `package-input-rewriting' procedures which help do this. <psycotica0>Right, okay, so in my channel I can see the upstream guix definitions in scope, but it's a one-way relationship. Adding a new package definition in my channel doesn't "pollute" the scope of the upstream <psycotica0>And then once the channel is done, if my channel defined a package "hello", does it take precedence when running `guix build hello`? Or is that just an error? Or is it undefined in some way? <ieure>psycotica0, If you package a newer version of hello, `guix build hello' will build your variant. If it's the same version, you probably need an -e argument to specify the correct definition. <psycotica0>Ah, okay, so they "merge" the versions, allowing a channel to offer alternative versions of upstream packages. That makes sense. <ieure>Essentially, yes. Guix builds an index of every package it knows about, in a `guix build foo' command, "foo" is a package specifier which it uses the index to resolve. Which is why you can do things like hello@2. <psycotica0>I've just had a thought that might be related to my busted substitutes. Whenever I run `guix pull` it's quite a lengthy and intensive process. <psycotica0>Is that just because I've broken substitutes, or is that true for you folks as well? Does guix use `substitutes` for `guix` in a `guix pull`, and I'm just the idiot building it for no good reason? <ieure>psycotica0, Yes, `guix pull' will use substitutes if available. <psycotica0>Right, so for normal people `guix pull` is fast? <ieure>It's not what I would consider fast, but it's not horrible. It takes around three minutes for me. But it depends how often you do it, longer time between pulls = more commits = less fast. <psycotica0>Oh yeah, it's definitely a lot longer for me, at least on my netbook. Like, I'd better pull now because I'm going to want to use it later and I need it to be ready! But it's usually not the commit downloading that's slow, I don't think, it's the building that comes after. Though if I'm using channels, do I end up having to build anyway, even if there's a substitute for upstream? Because IIRC the package d <psycotica0>efinitions are built-in, it's not just a datafile, so I assume channels requires a local compile <ieure>I'm not sure of the behavior in that case, but I don't think it works like that. <psycotica0>It would be great, in this case, if it didn't! 😉 <psycotica0>Anyway, thanks for your help! I'll see if I can get my system to do substitutes again, and also see about converting my patches into channels with package rewriting. Thanks! <folaht>Hello there. Does Guix work on a raspberry Pi 4? <ieure>folaht, I'm not sure if it works without firmware blobs. I am also trying (and, so far, failing) to get it running natively on a raspi4. <folaht>I just get a black screen if I try it. <folaht>I tried to see if it was something with the hardware, so I installed raspberry Pi OS on the SD card instead and that worked. <folaht>So I reinstalled Guix OS on it, but to no avail. <folaht>I ran signature verification on the iso just in case. <folaht>There's no flasher app on Guix is there? <folaht>I prefer using flasher apps instead of using dd.