IRC channel logs
2026-07-23.log
back to list of logs
<lynx-guix>hey is anybody else getting very slow (~10KiB/s) substitute download speeds when running guix pull today? i'm using the official substitute servers. <vagrantc>fff9ae740d09eea88886452818837dc5fb1ade78 gnu: xdg-user-dirs: Update to 0.20. ... explains at least 1,500 per architecture... <vagrantc>10868cfba23449e074408e99424b277a0ccc6fe8 gnu: docbook2x: Fix build. ... another couple thousand <vagrantc>4c4ac6b5b60fad7b27cdbdac22b54a1ca5c8c252 gnu: rust: Fix compatibility with curl 8.18 and above. ... ~8000 packages, that sounds more plausible <vagrantc>ah, even bigger ... 3b12e462d590184860696c41810b87edb8494290 gnu: curl: Update to 8.20. ... 22000+ packages <vagrantc>well ... feel like i wasted a days work on guix. :( <vagrantc>and lots of "guix build: error: corrupt input while restoring archive from #<closed: file 7f55e7fe5a80>" not making it any easier ... <lavandula>I'm working on a service definition and I want to use a DSL within the configuration record. Can I like nest syntax-rules or something and have it work with define-record-type* ? I should say this is my first time using Scheme <lavandula>also my message history isnt working for just this channel for some reason but idk if thats just a me issue or libera issue or what <ieure>lavandula, Maybe a set of macros which expand to a form which instantiates the correct records. <lavandula>I did that for another part, but theres another part where I want the configuration to look like: (expression (match (if condition then value) ...) (else default-value)) where match is a field and if c then v is a macro <lavandula>and im unsure how that would work when reading the (configuration) and the if macro isnt defined in the file using the service <cnx>sneek, later tell vagrantc that the evaluation is the result of merging misc-world-rebuild, which completed on CI for amd64, and 2189455 seems to catch up for other archs <jonsger>pathera: it could be also sddm. With sddm I couldn't start Gnome anymore, so I switched to gdm <Nessah>Was it tested on the Qt5 or Qt6 version of sddm? I'm not sure if changing might solve it. <Nessah>I'm using guix 257b2b4, just tested lxqt. lxqt-desktop-service-type doesn't expose a window manager in the list for the x11 session. Even though guix system reconfigure appeared to pull openbox <Nessah>openbox does appear in /run/current-system/profile/bin/ <cnx>how does sddm detect wm/de? via desktop files? <Nessah>i understand it's based on the system config. lxqt-service-type will pull in lxqt x11, lxqt wayland and openbox sessions, for instance <Nessah>and plasma-desktop-service-type will do a similar thing <Nessah>so I tried the x11 session with openbox as wm from /run/current-system/profile/... <Nessah>it works. but black background and mostly black panel <Nessah>lxqt wayland session is fine too, but as with x11, you have to manually set a wm from the dialog <Nessah>I aught to hope all free software projects will shun use of LLMs, but more seem to be going down the opposite route lately <Nessah>"Maintained with heavy use of LLMs". The vanilla linux kernel appears to be sliding that direction especially <csantosb>I guess they have enough of being systematically scrapped. <csantosb>The "heavy use" and "mostly consist of" are the key points here, I guess. <Nessah>Yeah. I've seen too long RAM and disk prices skyrocketing. Even with the recent "plateau" on some stores, it's still high <Nessah>For heavy use, that checks out. Like, if it wrote most of a million lines of code, for instance <untrusem>csantosb, guix have bitcoin related project <untrusem>doesn't that fall under their new cryptocurrency clause? <Nessah>It technically doesn't, since the actual bitcoin program isn't in the guix repo <Nessah>And maybe one day they could make the rule apply to "build recipes" too <csantosb>untrusem: I don't think this clause refers to packaging it, not today. <csantosb>This would mean opening a huge pandora box, related to what is legit to package, beyond being free software. <trev>Nessah: Bitcoin and other nodes are in the guix repo <trev>I am open to moving them out since I maintain guix-bitcoin <trev>untrusem: I looked all over and couldn't find a cryptocurrency clause <allana>Hi guix! going down a bit of a rabbit hole here. I am attempting something a bit out of my experience trying to write a shepherd service for a piece of software that I have packaged locally (himmelblau) with intentions of eventually getting it into guix. I am looking at existing services for learning material and that seems to be fruitful. Back to the rabbit hole, I have noticed that "sssd" is packaged for guix, but there are no <allana>shepherd services associated with it. I have done some searching trying to find out why, but nothing has turned up. Does anyone know why there are no associated services for sssd? <cnx>the reason is usually no one wrote it <cnx>trev, the cryptocurrency term is under the ToS <identity>specifically, §2 Allowed Content & Usage, (1).6 «… We also /explicitly/ do not tolerate: … Content that harms the reputation of Codeberg, such as cryptocurrency related projects.» <identity>i do not see how that could be read as «a package definition somewhere in a subsubdirectory of Guix harms the reputation of Codeberg» <futurile>yeah the intent is usage of _their_ service <noxi>it's hard to believe the intent is usage of their service when the first thing you see logging in is a banner with the words "Cryptocurrency projects are no longer allowed" <noxi>the proposal is named "Disallow cryptocurrency projects" <noxi>and §2 Allowed Content & Usage, (1).6 can be reasonably read as "We also explicitly do not tolerate cryptocurrency projects, among other things that harm the reputation of Codeberg" <noxi>as in "any cryptocurrency project belongs to the subset of things that harm the reputation of codeberg, and will explicitly not be tolerated" <futurile>noxi: would you read it that guix can't have a cryptocurrency upstream in our archive then? <noxi>futurile: i think it's a reading that could be made, yeah <noxi>i'm _worried_ it's a reading that can be made <noxi>I don't know what are the relations between Guix and Codeberg, and how much Guix can push back on that, but on my part it's pretty clear that anything touching cryptocurrency on Codeberg with a 10-foot pole (even the cryptocurrency upstream) is at best in a grey area, because of how poorly worded this ToS is. <noxi>I don't know the folks at Codeberg at all either, but I want to give them the benefit of the doubt and assume this is imprecise wording. <futurile>understood, they also have a general statement that this list doesn't cover anything, they can just remove if they consider something is damaging their reputation <futurile>noxi: 4) Please be aware that this list is neither exhaustive nor complete (illustrating the spirit of the law, not its letter). Be aware that any account can get suspended at any time if it is used for activities harming Codeberg e.V. or its associated platform and services, directly or indirectly, even if these activities are not explicitly listed in the examples above. <noxi>note that this isn't the same section (and not the same list? possibly?), but I agree it probably applies to both categories <ishouldbeworking>futurile: good, since allowing LLMs would be a shit show given the new Codeberg ToS <csantosb>Any idea where the famous `delete-all-but` is gone ? See !5312. <csantosb>I was hoping to find it in `guix/build/utils.scm` after the world-rebuild merge, but it is not. <theesm>ishouldbeworking: gentoo also uses codeberg and as far as i can tell provides cryptocurrency related packages, so we're probably not the only distribution that needs clarification on this <sham1>I'd be very surprised if Codeberg would interpret providing package definitions for bitcoin et al as being bad for Codeberg's reputation. I'd say that the "reasonable" interpretation would be that Codeberg just doesn't allow for hosting projects that are explicitly about cryptocurrencies. I.e. that the bitcoin project couldn't migrate over to Codeberg <theesm>yup, it would surprise me as well if packaging, especially the way we do it, would be in conflict with the ToS <noxi>it would surprise me too, but I don't feel comfortable with <noxi>"it would surprise me" being the threshold there. <trev>worst case scenario is bitcoin and other crypto packages (outdated anyway) are removed and people use my (shameless plug hehe) guix-bitcoin channel which provides more up to date and complete solutions (shepherd services, wallets, etc) <noxi>aren't they hosted on codeberg <cnx>csantosb, it's now under the new world-rebuild branch (it along with another change to guix build utils were split from misc-* to debug bootstrapping on qa <sham1>Oh nice, curl has been updated to 8.20 <vagrantc>when updating etc/news.scm ... should you wait until the commit lands in master to know what commit to put in the field, otherwise you have to remember to update the commit at the same time as the final rebase ... ? <sneek>Welcome back vagrantc, you have 2 messages! <sneek>vagrantc, cnx says: that the evaluation is the result of merging misc-world-rebuild, which completed on CI for amd64, and 2189455 seems to catch up for other archs <vagrantc>cnx: still rebuilding all of rust on aarch64 ... and as far as i can tell bordeaux's rust builds were cancelled, and while in theory CI builds for aarch64 ... in practice i have not seen substitutes from CI for aarch64 in ages <vagrantc>really gotta look at cutting out more rust builds with a newer mrustc ... but i have not yet been willing to explore shaving that yak ... but would be really nice at times like this <vagrantc>ugh. and with the recent go updates, yggdrasil is failing to build ...