IRC channel logs
2025-05-17.log
back to list of logs
<civodul>ci.guix is being hammered by the AI crawlers :-/ <old>Seems like AI and Cryptocurreny have something in common. They waste power and are an ecocological distaster <old>it baffles me that no law is being made to prevent them spamming everything on the internet <old>If I were to DDOS things, I would probably be charged with terrorism <civodul>yeah, these companies have blanket permission to ignore copyright, DDoS the world, drain energy, and more <old>late stage capitalism at it again I guess <civodul>here it’s interesting: we seem to be getting a lot of traffic from a web site that proxies ci.guix, and that itself prolly has no mitigation in place <old>civodul: have you put anubis in front of the CI? <civodul>only nginx rate limiting and user-agent filtering (which has no effect these days :-/) <Tadhgmister>what would it take to have `system init` also copy over the current channel info so the new system could do `system reconfigure` and it would just use the same commits of all channels instead of needing to do the really long pull operation? <Tadhgmister>like I don't have a clue where that stuff even gets stored, if I could figure out the store items and where the symlink to them goes is that all it would take? <Tadhgmister>or is the authentication process more complicated than just having items in the store <apteryx>hm, ./pre-inst-env guix refresh -r xdg-desktop-portal-gnome fails with: In procedure car: Wrong type argument in position 1 (expecting pair): () <apteryx>Tadhgmister: 'guix pull' is per user, and I believe the git checkout of guix is cached under ~/.cache/guix/checkouts <apteryx>refresh crash fixed with 3fadea42548 <ruther>hako: btw thank you very much for the guard over activation services, very helpful <ruther>my system wouldn't have booted without it actually, because I did some changes to /etc manually and the etc activation service has been failing for me. I think it's actually a bug of that service in the end, I will submit a new patch. But super helpful I was still able to get to my system even when that happens. <luca>Hi, does anyone have like a guide or cheatsheet as to what package goes where in guix.git? In particular how python pypi modules are placed and sorted <identity>luca: correct me if i am wrong: python modules go to python-xyz.scm, or if a more specific python-*.scm exists, there; packages are (or should be) sorted alphabetically <cow_2001>how do you run guix shell --container stuff in a M-x compile buffer without re-running guix shell each time you press g in the *compilation* buffer? <luca>Thanks identity I'll do that <cow_2001>like a make command that only runs in a guix shell --container <futurile>luca: make sure you check they don't already exist as there's other python* scm files <luca>Is it enough to grep for `pypi-uri "package-name"`? <futurile>luca: yes, that's the best way in my experience <Guest55>o/ just pondering intel-vaapi-driver and 'operating-system-firmware, and was surprised to learn that such 'firmware packages are not added to the system profile, and thus their outputs are not materialized <Guest55>I suppose the end-user must discriminate what is relevant for the kernel <ruther>Guest55: it is true that firmware packages are not added to system profile. That does not imply that their outputs aren't 'materialized'. They in fact are. <Guest55>ruther: ty for the info. Perhaps I am mistaken as to how this should propagate, but my native-search-paths were not amended (to include LIBVA_DRIVERS_PATH to my users) from the 'firmware package alone <ruther>Guest55: yes, search paths are obtained by putting packages to profiles, that is right. Still doesn't imply its output wouldn't have been materialized. Anyway, there are no firmwares in this package, so it doesn't go to operating-system-firmware anyway <Guest55>ruther: re search-paths & profiles, that really helps my mental model, thank you -- and indeed, I am now one step closer to not conflating "drivers" and "firmware" :) <df>hey guix, I'm trying to get spellchecking (british english for now, but potentially other languages) working in emacs <df>I've traditionally used ispell, but there doesn't seem to be a british english dictionary packaged for it <df>so ispell/emacs is looking for /gnu/store/pww3il9v82plmn514vcyhmq8fmjpz83d-ispell-3.4.06/lib/ispell/british.hash and not finding it <df>can I fix the dictionary issue without packaging it (which I'd love to do, but don't have the time for right now), or should I try a different spellchecker? <ngz>df: I guess aspell-dict-en is US-English, right? In any case, you may want to try Jinx spellchecker instead. <ngz>It relies on Hunspell dictionaries, which include a British-English one. <df>ah that seems to work, thanks <yelninei>yay finally won the automake test suite lottery in the 8th try <df>ruther: thanks also, but jinx/hunspell seems to be working and from a brief read of the internet it sounds like ispell is a bit out-dated <ruther>yeah, I can imagine, it's very old :) <ruther>ieure: it's not responding for more than a day for me <ieure>ruther, Ugh. I was able to load it yesterday. <ieure>Savannah also seems to be struggling. <ruther>ieure: I don't know, maybe it worked for a bit yesterday, but I was trying to reach it multiple times to get the current order of teams and couldn't <meaty>which python package provides the binary alias 'python'? (not 'python3' or 'python2' <meaty>is there any licensing reason why nerd font aren't packaged in guix? <meaty>from the upstream repo, it's a complicated licensing situation but all *seem* safe to distribute... <ieure>Any committers here able to run `git pull origin master'? I can `ssh ieure@git.savannah.gnu.org' and have it work, but `git pull' / `git remote update' both hang. <meaty>I ask because they are packaged in another channel, and it seems to be the only thing blocking kitty from being updated <meaty>also i guess, is there any reason why kitty is so old? <meaty>does translation work by just replacing each string literal in the program with its translated equivalent? or is there something more to it? <ekaitz>meaty: re: kitty: yes, dependencies are hard I think <meaty>also re: kitty, it also depends on a newer version of go, which it tries to download even if it's available (on the go-team branch)... <meaty>ekaitz: i am learning that lol <ekaitz>meaty: re: translation: basically are strings, but there's also pluralization and other kind of things <meaty>I wonder if once we are on codeberd there would be a better way to facilitate group collaboration on packaging <ekaitz>meaty: I updated kitty in the past but I don't use it anymore so... having guix people that use some software helps to keep things updated <ekaitz>we'll see about codeberg but I don't expect it <meaty>things like kitty would benefit a lot from having a group of people to chip away at it. it's technically possible now, but it's not easy <ekaitz>I try to keep the software I use updated, and I think many people do the same but Guix is quite a niche program and the set of packages guix users use have a very large intersection <ekaitz>those are well maintained, the rest... we could do better <civodul>Savannah has been unreachable for the past 4h, according to the Cuirass logs <civodul>seems to be worse than usual though since it’s not just cgit and not just 502 <clarkf>i've been getting timeouts for both cgit and git <civodul>probably scrapers, but also maybe combined with technical/organizational debt? <luca>I mean, if pretty much all git hosting services have to implement really strict limits can you blame technical/organizational debt :/