IRC channel logs
2025-04-07.log
back to list of logs
<zilti>Is the main Guix channel down for anyone else? I'm getting a 502 when trying to pull <Kabouik>mediasdk helped jA_cOp_, thanks a lot. Unfortunately now I see that that 100% I was seeing was just one step of the whole build. ._. <meaty>How can I make sure guile can find installed modules? Do guile and the module have to share the same profile? <meaty>I just installed Haunt to my user profile and I can't get use-modules to find it <meaty>it appears that my emacs-geiser runs guile 3.0.9, the `guile` available from my command line is 2.2.3, and $GUILE_LOAD_PATH is pointed at ~/.guix-profile...guile/site/2.2 but also /run/current-system/...guile/site/3.0? <meaty>according to env | grep guile, but I know there may be wrapper scripts at play here <meaty>how can I synchronize my guile environment across the profiles? <oriansj>weird, when did thinkfan stop working on x200 systems in guix? <apteryx>hm, something appears to be wrong with my network or guix refresh, it takes more than 1 minute to complete 'guix refresh python-dbus' <apteryx>network is zippy in a browser, so the network performance as a whole isn't foobar <ieure>apteryx, I was noticing this earlier today as well. <apteryx>it seems only python packages are super slow to refresh, so it points to pypi <apteryx>I guess they are throthling requests <ieure>I am going to hazard a guess that PyPI has deployed some kind of mitigation for badly behaving AI crawlers, like many, many FOSS projects have had to do. <lechner>it's probably that stupid new proof of work bot <ieure>Well, if it wasn't that everyone on Earth is deluded into thinking that slow computer programs that lie to you while they kill the planet were the future for some reason, we wouldn't need that stuff. <ieure>It sucks, but so-called "AI" sucks 100000x worse. <apteryx>ieure: I was told on #python it could be fastly's CDN, which are region specific. No throthling policy appears to be used for pypi.org <apteryx>their blog doesn't mention anything new either. and now my example is fast again.. hm. <apteryx>also, 'guix refresh python-dbus' appears to use the generic updater, not the pypi updater, so it could be that happens only when crawling html pages <apteryx>but no, I've had slownest on pypi too, 'python-dbusmock' was initially equally slow <meaty>Is the union of profiles that is the "current environment" represented by its own profile somewhere? Or is it entirely composed of environment variables pointing to its component variables? <apteryx>which python package provides PyGI (the gi module) in guix? <lfam>meaty: That union does not exist. It's created dynamically when all the different profiles are sourced at login <meaty>lfam: I see. And would each store item be considered its own profile? and if not, what makes it different from what is a "profile" <meaty>just making sure I actually know how all this works <lfam>'Store item' is just our jargon for the directories you'll find in /gnu/store. They could be built packages, profiles, single files, a lot of different things <apteryx>is it just mine, or is 'grep -P' broken? <apteryx>grep: Perl matching not supported in a --disable-perl-regexp build <apteryx>the definition of grep has it explicitly enabled <meaty>Does anyone know a guile equivalent to LASS? <meaty>or a better place for general guile questions <xelxebar>meaty: BTW, you can message alis to search for channels. It's a really nice service. <Lycomedes>I tried to install Guix System on my Librebooted X200, but the wifi card requires proprietary firmware. Too bad. <aldum>you can probably get a different one, one of the advantages of librebooting <civodul>Kabouik: most likely i just checked that it built fine <cbaines>civodul, I am back watching guix on bayfront carefully and slowly write out and delete narinfo cache files <Kabouik>It does build fine but unless I don't know how to use it on Guix (which is possible, I don't think there's documentation for it), in always tries to look for a /gnu/store/path/etc/nbfc/nbfc.json, which does not exist, instead of just ~/.config/nbfc/nbfc.json or ~/.guix-profile/etc/nbfc. I'm curious, there are many people using Guix on laptops I assume, so this could be a very, very useful package. <cbaines>I think we've discussed this before but it would speed things up a lot if this caching was optional <civodul>cbaines: you mean under /var/guix/substitute/cache, right? <civodul>we not only discussed it, i made changes in this area :-) <civodul>it’s not totally disabled but it’s much less aggressive <cbaines>I think the "thundering herd" problem around clearing the cache is now fixed <Rutherther>Kabouik: if you mean the service, have you tried -c config parameter to specify the full path to the config? <civodul>cbaines: this, and the cache expiry is also much lower (commit 7e00fb9f31f51ac2f9fa67b71a3eb8aaa23efdb6) <cbaines>but writing out the cache files (including the slow fdatasync), and deleting the cache files (even if this is only done by one process) is still slower than not having the cache at all <civodul>does it show in “strace -t” logs or similar? <Kabouik>Rutherther: I have not set up a service yet because I did not find documentation on how to do it, but `nbfc` itself has some `start|status|stop` commands, and even other manual commands like loading a config file or changing fan speed manually, so I wanted to try that before doing a guix system reconfigure. But maybe that's not how it's supposed to work? It's confusing that there would be a `nbfc start` command if the service has to be run by Shepherd <cbaines>just watching it in strace (through htop) shows it taking between 0.7 and 1.7 seconds per call, so per cache file write <Kabouik>I have now 3 distinct Guix laptops so I would really want to get that working. <cbaines>I also just saw a fdatasync call take 27 seconds... <Rutherther>Kabouik: I don't know why you're bringing shepherd into question, I didn't mention shepherd. I was talking about nbfc_service <Kabouik>Uh, I didn't see there was a nbfc_service Rutherther, sorry. Everytime I see service, I think shepherd. <Rutherther>Kabouik: if you mean the service, have you tried -c config parameter to specify the full path to the config? <Kabouik>I am trying right now but am facing unknown option issues (which may be related to outdated nbfc, possibly). Looking into it. <civodul>cbaines: it’s worth opening a bug for this one so we keep track of things; i think we could disable fdatasync in this particular case, but probably not for all the ‘with-atomic-file-output’ uses <civodul>cbaines: i was going to reconfigure bayfront, mostly for the guix.gnu.org/install.sh mirroring <cbaines>civodul, yep, I've been trying to reconfigure with d41d6fe71f54bf68d2a7cb4491bc5476289e15d5 or later this morning <civodul>ok; i’ve just pulled 6af680670bf9055b90e6f8b63c4c2ab7b08e7c56, let’s see how it goes <Kabouik>No, still having issue Rutherther. Basically this (https://github.com/nbfc-linux/nbfc-linux/issues/124#issuecomment-1971258071) says that one has to usr `sudo nbfc config -s custom_config` to set /etc/nbfc/nbfc.json accordingly, but this fails on Guix because /etc/nbfc is in a read-only folder. Using `sudo nbfc_service -c custom_config.json` directly does not work, I think it doesn't recognize the same options. <cbaines>civodul, note that if you restart nginx, you'll probably need to restart the whole machine <civodul>this machine is good at finding problems :-) <cbaines>I've also got a machine aflicted by this issue <civodul>if this is something smaller that can be spawned in a VM, that’d be great <futurile>cbaines: while you're here, isn't there a dashboard somewhere that shows builds as green or red dots? (can't find it and didn't note down where it is) <andreas-e>futurile: Concerning the games updates branch, I also think it does not need to be in a branch. How about pushing the games one by one? I think some of them were ready? <civodul>cbaines: do you know if the nginx bug shows up if you gently stop then start as opposed to ‘herd restart nginx’? <futurile>andreas-e: they are all 'ready' in that they build locally. I was trying to simulate the "everything gets build on a branch first" rather than pushing to master (also it scared me). <cbaines>civodul, yes, I think I've tried that <futurile>andreas-e: just because the idea of breaking master is scary as a new committer heh heh <cbaines>civodul, previously I've had issues with nginx on bayfront not stopping properly, so I usually do herd stop, check it's actually stopped, then herd start <cbaines>to avoid there being multiple nginx master processes running (which has happened in the past, and produces some interesting behaviour as requests get routed randomly to each process) <civodul>yeah, we’re relying on “nginx -s stop” to do the job here but apparently it’s asynchronous <civodul>i wonder how people set it up on systemd for instance <andreas-e>futurile: Well, breaking a game would not be a deal breaker for me :) But then I do not actually play games, playing with Guix is already a lot of fun. So I would say that you can go ahead and push the corresponding commits. <civodul>getting narinfos from bordeaux.guix.gnu.org seems to be super slow, at least from bayfront <civodul>andreas-e: yes, i think so! and move web sites to Hetzner <civodul>i can help with the sysadmin bits, but not with the financial bits :-) <civodul>(and gmail.com people don’t receive messages from me, apparently) <sneek>Welcome back janneke, you have 1 message! <sneek>janneke, yelninei says: I tried reverting the glibc update to 2.41 back to 2.40 and to try to narrow down the cause. the 4 gnulib tests are passing again and bison is working as well. So either a regression in glibc or something wrong with some of the patches <janneke>sneek: later tell yelninei: thanks for looking into this, that's so sad...creating a core-packages-team branch to support the 64bit hurd, only to have it break the 32bit hurd with an additional update. so...more work to do for 2.41 i guess <z572>civodul: I sent a patch to guix-sysadmin to add the jh7110 module. <mirai_>guix pull is giving me SSL error: … : resource temp. unavailable <futurile>Q: is there some upside to altering the source in one way over another? e.g. if the choice is (a) a snippet, (b) a patch or (c) a custom phase with modify-phases <hako>If you want the change show in `guix build --source`, snippet or patch. otherwise phases. <mirai_>a snippet that does something like 'delete …' will nuke those files from the source tar <hako>Also currently substitute* doesn't fail, you may want patches for this reason <andreas-e>futurile: We tend to use patches for upstream bugs, sometimes upstream commits fixing something, or a bug that we report at the same time. We tend to use snippets to clean the source - "guix build -S" will not contain deleted files for instance, so it is a good way of removing non-free bits or prebuilt libraries. And custom phases for things that are Guix related, when the standard build phases do not work etc. <ds-ac>Hi. I wanted to use the qemu-binfmt service. However, when I try to execute an arm32 executable, it complains that ld-linux-armhf.so.3 is not found. guix locate does not seem to find it either. Do you know how to get a working binfmt setup? <ds-ac>(At first I wanted to add something to LD_LIBRARY_PATH, but as I cannot find the .so file, I can't do that) <janneke>ds-ac: if this works: $(guix build --system=armhf-linux --no-grafts hello)/bin/hello , then you have a working binfmt setup <Rutherther>ds-ac: it is in gcc package, so "guix build gcc --system=armhf-linux". Note that guix system is not good for running randomly downloaded binaries. This what you're missing is not a regular library, it is the interpreter, so adding it to ld lib path probably won't work. <ds-ac>Thank you for both answers; the first one confirmed that binfmt works, the second helped me figure out how to run my program (I could patchelf the binary to run it). (NB: no worries about randomly downloaded binaries, I had simply built it on another machine some time ago ^^). <nckx>janneke: Is ‘--no-grafts’ here just for speeeed or is there a known bug? <civodul>our web servers are being hammered :-/ <civodul>cbaines: ci.guix, i was looking at the logs <civodul>but i’ve seen that in other places as well recently <cbaines>yeah, it might be worth using NGinx rate limiting for ci.guix.gnu.org <andreas-e>I have noticed the problem that "git push" does not trigger the evaluation hook any more because ci.guix.gnu.org does not respond. <cbaines>that's used for the data service instances to help reduce the impact of scraping <civodul>andreas-e: it’s AI + bots looking for php & co. vulnerabilities <sturm>if I want to load some udev rules from the libu2f-host package, would something like be on the right track? (udev-rules-service 'libu2f (file->udev-rule "70-u2f.rules" (file-append libu2f-host "/lib/udev/rules.d/70-u2f.rules"))) <z572>civodul: Did you see the email I sent to guix-sysadmin or the mastodon private chat? <civodul>oh, ‘limit_req’ in data-guix-gnu-org.scm i guess <cbaines>civodul, data-guix-gnu-org.scm in maintenance.git, look for limit_req <civodul>z572: if i didn’t answer, then no; i’ll get there eventually :-) <cbaines>the nginx configuration for the data service uses two locations, one of which is rate limited and blocks a couple of bots by user agent, and one which isn't <hako>sturm: (udev-rules-service 'libu2f libu2f-host) <sturm>thanks hako! I just found that section in the manual about using packages as udev rules <sneek>yelninei, you have 1 message! <sneek>yelninei, janneke says: thanks for looking into this, that's so sad...creating a core-packages-team branch to support the 64bit hurd, only to have it break the 32bit hurd with an additional update. so...more work to do for 2.41 i guess <civodul>cbaines: nice, i’m starting to see 429s in the logs, which is good, but still insufficient <cbaines>civodul, are the requests from crawlers blocking or slowing down other activity? <civodul>cbaines: they’re from bots of all kinds, and they contribute to slowing down other things (but there are other slowdown factors!) <cbaines>civodul, if too many requests are still coming through at once, reducing the burst value might help <cbaines>the other thing I've done in both the data service and build coordinator to try and keep things working under high load is use internal prioritisation or split resource pools <cbaines>so the data serivce has several resource pools for database connections, and the different resource pools are used depending on the importance of the endpoint <civodul>i would hope we could avoid this complexity, but maybe we can’t :-/ <cbaines>getting instrumentation on resource pool usage is probably a first step, as maybe it's not an issue <civodul>right, i have logs of resource pool contention, and that’s not an issue here <cbaines>wow, Greenbone OS is spamming requests <futurile>what a weird company, I can't figure out if they're real with a terrible web site, or made-up <andreas-e>I still cannot "git push" without the connection to CI failing. <civodul>andreas-e: failing how? but anyway, that’s fine: it happens after the push has been accepted by Git <andreas-e>Well, it connects to ci to trigger an evaluation hook; then a few seconds later it complains it could not do so, then reuses the connection to try again. <andreas-e>I have not got the error message around, since now I have trained myself to hit ctrl-c at the first sign of the problem. <zilti>When writing a package, is there a way to tell git-fetch to keep the .git directory? <ieure>zilti, No. What's your usecase? <janneke>yelninei: lovely, at least that's an important piece of the puzzle <sneek>Welcome back janneke, you have 1 message! <zilti>ieure: I'm trying to bootstrap Pharo (which is absolutely abhorrent, I've never seen a software so strongly resisting getting bootstrapped and packaged propery). One script wants its dependencies as git repositories, or not at all and then tries to clone them itself. <yelninei>janneke: Bison also works (4 tests still fail but at least it is not crashing immediately) <yelninei>in the failing tests it is still segfaulting though, hopefully not as big of a problem <janneke>any other patches that we're missing (or that should be modified?) <janneke>it's an easy question to ask and harder to answer...but it seams you bisected glibc to be the culprit so at least that helps? <yelninei>dont know . i didnt bisect, i just tested tried reverting glibc and then found the debian patch by chance. The feedback cycle can be a bit long <yelninei>janneke: maybe the pthread_sigmask patch as well (hoping it might fix test-pthread_sigmask1), but this is untested <Kabouik>My conclusion is I probably need to repackage it if I want to add new config files. <yelninei>does socket avtivation work on the hurd? after reconfiguring the daemon now prints "unexpected build daemon error: reading from file: Resource temporarily unavailable" <df>I was under the impression that the list of channels was just a value in guix-configuration that could optionally be loaded from a file <df>so my operating-system config currently uses modify-services to add an extra channel to guix-service-type <df>although now I think about it, that sounds like a potential chicken+egg problem... <df>and I never actually deleted my old channels.scm file so maybe that is still being used <df>I'm not entirely clear why package-database-service uses time-machine tbh <df>but perhaps understanding some of this stuff will help me understand why the update fails when run on schedule but succeeds when triggered manually with herd <janneke>yelninei: check on the "maybe the pthread_sigmask patch" <janneke>yelninei: oops, childhurd's are broken on master? -- what a day <df>would I be correct in assuming that shepherd timers configured in operating-system will run using the same instance of guix as was used for reconfigure? <Rutherther>df: that depends on how you will reference guix from them <civodul>janneke: i reconfigured less than 24h ago and my childhurd is fine! <civodul>(as of 6af680670bf9055b90e6f8b63c4c2ab7b08e7c56) <janneke>civodul: phew, that's good to know; yelninei^^^? <civodul>looks like guix-daemon is passed an O_NONBLOCK socket <yelninei>janneke: Will try to rebootstrap with the pthread_sigmask patch , will take multiple hours (gcc alone is 4-6h) <janneke>i saw there's also a new "mig_strncpy: ensure destination string is null terminated" patch... <janneke>but i have no clue what it could be needed for <janneke>(one would think the interface hasn't changed wrt to this, so...) <df>so... I guess that's a yes? <civodul>yelninei: could you confirm that the bug disappears if you add #:lazy-start? #f to the ‘make-systemd-constructor’ call in ‘guix-shepherd-services’? <Rutherther>df: no, that would be the guix package in guix channel that is pinned to a specific guix commit. Not the one used for reconfigure <Rutherther>if you wanted the one used for reconfigure, you would have to set this field to "(current-guix)" <df>Rutherther: would that package not normally be the one from the latest guix pull? <Rutherther>no, as I said it's pinned to a commit. See gnu packages package-management <df>so there's a package called 'guix', but it's not necessarily the same version of guix as the version that defines the package... <df>still, presumably the same version is being run whether by timer or trigger, so this is *probably* not related to my issue <df>actually, maybe the whole thing was just a bit of bad luck <df>2025-04-07 12:16:55 localhost shepherd[1]: [guix] guix time-machine: error: Git error: unexpected http status c <df>... except that the database was several days old <df>guess I'll experiment by getting it to run more regularly <yelninei>civodul: One moment, i need to rebuild my checkout <civodul>yelninei: cool, thanks! i’ve spotted the shepherd bug, i wonder why it’s fine on Linux <civodul>yelninei: pushed a fix in the shepherd (next version should be released next week) <yelninei>civodul: great, thank you. did not expect to stumble into a shepherd bug today <divya>I'm trying to get some binaries to work in Guix using patchelf. <divya>I added the necessary shared libraries into the rpath. But I get this error of: "no version information available" <divya>Anyone has any clue about this? <civodul>yelninei: yeah i guess Linux behaves in such a way that this bug went unnoticed <civodul>and there are relatively few socket-activated services anyway <yelninei>in case you were wondering the shepherd 1.0.3 systemd test is currently passing for me on the childhurd on guix master (some others are failing though) <gabber>can i define two source files in a package as a file-union of two plain-files? <divya>Checked the logs and civodul, you have did some ncurses packaging. Do you have any clue? It's the only think stopping from getting the GHC binary to work..and I need this version of GHC for some work. <civodul>yelninei: could you report the failures you’re seeing? <civodul>divya: no idea! could you provide more context re “no version information available”? <civodul>divya: the message comes from glibc (ld.so), but i don’t remember seeing that before <trannus_aran>speaking of weird glibc errors, I'm stumped with this one <trannus_aran>anyone know what to do for this weird guix make error with a hall project? guile3.0: symbol lookup error [...] /gnu/store/[...]-glibc-2.33/lib/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE <yelninei>cidodul: sure, once my childhurd is unblocked from building gcc on core-packages-team again <divya>civodul: I've asked the ncurses folks, let's see <decfed>I remember talk in this channel about a repository that has all the guix talks from hpc meetups and fosdem? Anyone has a link please? <decfed>speaking about slides here not video