IRC channel logs
2025-05-02.log
back to list of logs
<pinoaffe>hey guix, I've been having issues with the certbot service, its activation phase seems to not be run (or maybe not be fully run?) - is there a way I can see the logs and/or forcefully re-activate the service? <pinoaffe>I'm running it on a server using guix deploy, but the /var/lib/certbot/renew-certificates script is not being generated <Tadhgmister>what would be the intended way to get `~/.nix-profile/share/` into `XDG_DATA_DIRS`? (ideally with a home configuration) <Tadhgmister>I'm sure I can just add a line to my `home-shell-profile-service` to do the addition but if there was a way to make use of the native-search-path or a way to append to existing variable definitions instead of setting them I'd love to know <nomike>I'm trying to update openscad and I've stumled upon another cmake issue where I need some advice. <nomike>I figured it's better to ask this in #cmake. <dcunit3d>i really wonder why they have to scrape so much. shouldn't traditional good have been scraping more? or is it that they don't honor things like robots.txt <dcunit3d>all those lonely little clone bundles... <sham1>They absolutely don't honour robots.txt. If they did, none of this would be a problem (of course, they probably wouldn't get the training data they're looking for if they did, because people would just add a robots.txt, and while good for everyone else, it's not good for the corpos collecting training corpora for LLMs) <sham1>But it is certainly curious why they keep pounding the same stuff over and over again <dcunit3d>yeh but why don't they just grab a list of repositories from a PyPi dependency graph (if their interest were python repositories), then just clone the repos? <dcunit3d>the dependency graphs are far more useful, as you get a sense of how important the code is by the number of times it's referenced by other repos/packages <dcunit3d>i guess that would require a little too much structure ... but it's not exactly easy to spider at scale either <dcunit3d>maybe the authors should ask their AI's "are we idiots?" <sham1>I'm very cynical about this stuff and from that point of view it seems that they are using the Commons™ like this, because hey, it's technically legal and who cares about them anyway, we're the big guys trying to disrupt "${SYSTEM}" and thus everything we're doing is right and proper <dcunit3d>i mean when their behaviors are generally not scalable, it's a bit like littering. it's not ethical. <sham1>It's easier for them to scape the entire Internet than to be thoughtful at the people providing the content they're scraping. Also, think about if them scraping things "properly" would eat into whatever LLM profits they can make, can't have that <dcunit3d>yeh, but does that mean the limiting factors to their processes are "talented developers"? that's not a good sign <sham1>Limiting factor seems to be "do they care", and short of a proper legal action, it seems to be "no" <dcunit3d>well. it may be difficult to determine "who" is scraping. which LLM approaches are problematic? Is this RAG? i had thought that RAG was pretty dumb. <sham1>As you said, it's like littering. Or not returning the shopping cart back to a designated area <dcunit3d>yeh. the terminology of the "tragedy of the commons" is probably better, as you were alluding <dcunit3d>is there any way to hook into Anubis logs to get insight into who is responsible for significant load? <dcunit3d>i mean, at some point, only legal action will set a meaningful precedent. <sham1>Might require some sort of a class-action equivalent thing <sham1>I'm just thankful that Anubis exists <dcunit3d>maybe there's a version of Anubis that will redirect requests to the wrong URL ... something like Cobol or Microsoft Sharepoint <meaty>Hi guix, I have a package that tries to run tests in a directory defined by an environment variable. What's the right way to set an env var during the build process and how can I set it to an appropriate temporary location? <sham1>setenv and then you can use dynamic-wind to set it back afterwards <meaty>what about the temporary dir? <meaty>sham1: is dynamic-wind needed for building? aren't builds isolated? or do they actually leak env vars <meaty>see qt.scm::472 , there setenv is used without dynamic-wind <sham1>IIRC things might leak. And even if not, it'd probably be cleaner to set and reset it <Ironsmith>heya! is it me or is git pulling the https source failing consistently with 502 over at least the last 2 days? <simendsjo>Ironsmith: Everyone is having problems with savannah these days. Probably scraping for AI bots overloading the servers. People are migrating to the codeberg mirror as they have better infrastructure/mitigation for the DoS attacks/license-violations/malware/call-it-what-you-want. https://codeberg.org/guix/guix-mirror <zilti>How do I add patches to my own Guix channel so Guix can find them? I tried zilti/packages/patches, and also creating a gnu/packages/patches in my channels, both don't work <zuki>just installed guix in a wm to give it a test drive and picked the awesomewm option. <zuki>I can't find the awesome config file i need to copy to my .config dir, the awesome config edit button doesn't do anything and Its not at the normal /etc/xdg/awesome/rc.lua spot? <identity>zuki: maybe you can find it around `realpath $(whereis awesomewm)` <identity>zuki: maybe you can find it around `realpath $(whereis awesomewm)` <identity>or whatever the awesomewm executable is called <ruther`>zilti: if you want to use search patch directly, you would have to put it to root of your channel. you can of course make your own search function instead and search them wherever. <ruther`>zilti: you could also just parameterize the patch search paths it uses in your own procedure and call the original search path with that <zilti>ruther`: Ah. I guess I could also leave the search function out I noticed, and make the paths channel repo relative <ruther`>s/the original search path/the original search patch <ruther`>zuki: Guix packages cannot write to /etc, so their example configs will be under the package output, not under global /etc. <Ironsmith>ruther`: to follow up with my circular dependency issue i mentioned a few days ago, i gave up and placed the refactored package in the original file. basically refactoring package `esbuild-node` and renaming it to `node-esbuild` and trying to add it to `(gnu packages node-xyz)`. i created a patch for it https://issues.guix.gnu.org/78183 <ruther`>Ironsmith: thanks for the update. do you know, why was the package previously built with go build system? <Ironsmith>my guess is because esbuild itself, the machine code binary, is built with go <Ironsmith>the node package version, is supposed to be a node package with that go-built binary <Ironsmith>probably whoever created esbuild-node wasn't experienced with node packages <Ironsmith>the package itself was also missing something in the structure, i forget exactly what i was, but now it's matching closer to what the package looks like from npm <Ironsmith>let me dig up those details and add them to the patch description <Ironsmith>i did this a while ago, was out of the country for a while <m4xxed>Hellou, I have just run into a tricky problem that others might run into aswell: In order to have a complete testing system (including the system config AND the home config), I have to pass my dotfiles directory into the `guix system vm` command using either `--expose` or `--share`. Since the dotfiles directory is per usual located in my home <m4xxed>directory, this will be reflected in the VM aswell. However, passing the dotfiles directory in via `--expose` or `--share` creates the home directory as owned by `root`, not by the user. This leads to the following issue: The vm cannot create the user directory with the default files like `bashrc`, `profile` etc, because it doesn't have appropriate <m4xxed>permissions, and therefore is useless. Any ideas? One idea I am tinkering with is having my dotfiles directory not in my home but rather in `/dotfiles` ... but I figured in this chat there might be some config-experts that have had similar issues and found smoother solutions :) <m4xxed>If anyone has an idea they want to discuss, feel free to slide into my dm's. If a working solution can be found, I will post it back into this main channel <ruther`>m4xxed: have you considered making a shepherd service that will chown the home folder? <m4xxed>ruther` I thought about using `activation-service-type`, but could not find any documentation on the exact time that service would be run. I'll check whether this works <ruther`>m4xxed: activation is ran very early, basically just after everything is mounted. it is probably the best place to put it, better than a shepherd service I suggested before <m4xxed>ruther` alright thank you for the pointers :) I'll see whether this fits into my config flow <zuki>Im running into a issue with a new guix install were trying to run <zuki>sudo guix system reconfigure /etc/config.scm <zuki>(note the ... are commits but I don't have copy paste and don't want to type them out unless it helps) <zuki>gives a error about aborting reconfiguration because commit ... of channel 'guix' is not a descendant of ... <ekaitz>zuki that happens when the commit histories are not matching... <ekaitz>the easy "fix" is to --allow-downgrades, but it has some security implications <apteryx>you delete it from %desktop-services <zuki>and how would i do that? <apteryx>it's done for example in some templates under gnu/system/examples in the source <apteryx>there also happens to be anxample doing that in the manual, see (info "(guix) X Window") <zuki>I think I got it working thanks! <apteryx>the main change of interest is relabeling the name of the Guix System OS in libvirt from 'Guix' to 'Guix System'. <ieure>lechner, I did end up getting that ARM laptop. It's currently running Guix on Ubuntu while I screw around with building a working Guix image. <ieure>lechner, Glad that Linux 6.14 just landed in Guix, it has important fixes for the platform. 6.15 would be better, but 6.14 should be workable. <ieure>It takes <10m to compile the kernel on this thing. <Tadhgmister>I am not understanding something about cross compiling go projects, when I try to cross compile syncthing it gives me an error that `go install` isn't allowed when `GOBIN` is set and the internet suggests I should just be using `go build` instead... but it looks like the go-build-system just sets `GOBIN` and runs `go install` so I don't see how <attila_lendvai>i've spent a ridiculous amount of time messing with the certbot-service-type and it's still not working... current error: service 'certbot-certificate-renewal' provided more than once <ieure>attila_lendvai, You have >1 certbot-service-type in your services. <attila_lendvai>but if i don't provide two services of certbot-service-type, then i cannot provide separate webroot fields... which is obviously different for the two sites on this machine. <attila_lendvai>ieure, there's a single webroot field for the certbot-service-type, and the certbot doesn't seem to append the domain name to it. what am i to do if i have two domains on this machine? <ruther>attila_lendvai: I suppose it's just unsupported use case <sneek>Naran, nckx says: No, there's only one ISO(hybrid) installer image. You should ask on help-guix@gnu.org as well; the person whom I know has the most experience with partitioning the installer is hardly (ever?) on IRC. <ruther>attila_lendvai: you could workaround it by inheriting from it, changing the name and changing shepherd service provision <ieure>Naran, Savannah has been deeply horked for weeks on end. <Naran>ieure, oh really? So this has been going on for a while? <ieure>Naran, An unreasonably long time. <Naran>ieure, okay, good to know, thank you <ieure>Naran, Several people a day roll in here to complain about it. There are reports on savannah-users from March, with no reply or action taken, as the situation worsens. <ieure>I don't blame FSF/GNU for the problem existing, but am startled that -- at least from what I can see -- the situation is unaddressed, worsening, and doesn't seem to be getting treated with much urgency. <Naran>I guess I should switch to codeberg permanently then <ieure>I switched my stuff over this week. <luca>they put up a robots.txt at least. Unfortunate it's not enough :/ <ruther>there is a GCD to switch to codeberg completely, no mirror. So far it hasn't been rejected by anyone <ieure>luca, The so-called "AI" industry is built on theft and abuse, robots.txt is the one URL they *don't* hammer. <Naran>Made the switch to codeberg will help then, if it happens. <Naran>So the assumption is the problem is caused by bot traffic? <ieure>I don't know 100% that this is the case, but it seems very probable, since basically every FOSS repository has been getting decimated by them. <luca>I'd even say every git repo out there <ieure>GitHub probably has the resources to repel them, and cuts out the middleman by just automatically stealing anything you're careless enough to host there in the first place. <ieure>I have nothing but contempt for these outfits wrecking the internet and the planet to make bad software. <luca>github also has rate limiting, as well as the infinite power of microsoft behind them <ieure>identity, It's infringement. <luca>identity: maybe, depends on how you interpret licenses and stuff <ieure>If it's "stealing" to download MP3s from a friend, it can be "stealing" to violate the license of the code I write. <luca>Which the courts have not fully decided on yet <luca>and what? Legally speaking we wait <ieure>If they say it's fine, I should be okay with GPL'd code getting laundered into proprietary, closed-source projects? <ieure>I will not be fine with that, no matter what the courts say. <luca>I mean not "okay". But legally speaking it will be "okay" <ieure>This won't change my opinion or lower my contempt. Quite the opposite. <luca>It mostly depends on how much money these AI companies can pump into the courts and stuff. Which is a lot <mfg>How do i change the url where guix fetches the guix repo from? <ieure>mfg, Temporarily or permanently? Guix System or foreign distro? <mfg>ieure: permanently, guix system <ruther>mfg: if you want to make it effective for every user you can just modify guix-configuration of guix-service-type, specifically the channels field. Then pull will pull those channels <ieure>mfg, In your operating-system, modify your services and update guix-configuration, replacing the `channels' field with one that points to Codeberg. Give me a sec and I'll push some code for this. <ieure>I'm gonna write a blog post about this today, I think. <ieure>You can also just copy %default-channels into your config and edit it. <ieure>This is all set up for my channel, you can just use that stuff, or extract it into your config.scm, whatever your taste is. <mfg>ieure: reconfiguring now, let's see if i did it correctly :) <ieure>mfg, You'll also need to `sudo herd restart guix-daemon' <ieure>ruther, Pretty sure it doesn't pick up the config changes until you do. <mfg>i haven't rebooted since 3 weeks, now is the time <ruther>ieure: what doesn't pick up what changes? /etc/guix/channels.scm is created on activation <ieure>ruther, Does the Guix daemon read that on every action, or only on startup? <ruther>ieure: guix daemon doesn't read that <ruther>guix-daemon doesn't care about channels, channels are encoded in guix executable <ruther>/etc/guix/channels.scm is one of the default channel files, the first one is the user's one - ~/.config/guix/channels.scm <ieure>ruther, Not 100% sure of the interactions here, will test a bit more before I write a blog post. <luca>Do you have a blog? And if so mind sharing a link? <ieure>ruther, But on a foreign-distro Guix machine, I had to update both ~/.config/guix/channels.scm and /etc/guix/channels.scm. With only the former updated, `guix pull' worked, but `guix system image' failed because it was still talking to Codeberg. <ieure>Updating /etc/guix/channels.scm and restarting guix-daemon fixed it. <ruther>ieure: guix system image is something else. How did the config look like? <ieure>ruther, It was the nonguix installer image. <ruther>ieure: to clarify, you mean that guix system image was the one fetching from savannah, right? <ruther>ieure: that one uses (current-guix), so it depends on what guix you currently had, if you just changed /etc/guix/channels.scm, it would have no effect, you also need to pull <ieure>ruther, I had changed my user Guix, pulled, and reloaded the profile, and it still wanted to talk to Savannah. <ieure>Honestly not sure why `guix system' is doing anything with channels. <ruther>ieure: because of the (current-guix) and the way guix works, it will just remake the guix package from the commits of current guix, it cannot really reuse the current guix. <ruther>s/reuse the current guix/reuse the output of current guix or a computed derivation of current guix/ <ruther>btw do you think you could've ran guix system image with sudo? <ieure>Only sudo for `guix system reconfigure'. <ruther>because if you did, it would explain why it had to git pull. If you didn't, I would expect the commit to already be present in the checkout <ruther>ieure: and you're 100% sure if you did guix describe you would see codeberg at the time you ran guix system image? <ruther>if that's so, I don't currently see how that's possible then <ieure>I'll see if I can reproduce the issue. <Noisytoot>Is there any reason why guix is on go 1.23.5 (and not 1.24) or is it just that nobody's updated the package yet? <ieure>Noisytoot, The answer is almost always "nobody's gotten to it" and sometimes "It's done, but on a branch waiting to merge." <mfg>i can't find the info what part of guix home sets the default channels file, this overwrites the channels i set in the operating-system spec <ruther>mfg: so ~/.config/guix/channels.scm is a symlink to the store for you? <ieure>mfg, home-channels-service-type <ieure>mfg, Others disagree, but I've moved to *only* setting channels in my operating-system. <mfg>ieure: i didn't set channels there, this must be the default or something i didn't actually wanted to do :D <mfg>At least not intentionally <ieure>Yes, agreed, only way ~/.config/guix/channels.scm would be a link to the store is if you used home-channels-service-type at some point. <ruther>mfg: so guix home graph on your config doesn't show home-channels service? <ieure>Guix is not very good at removing things from the filesystem after you remove them from your configurations. <sham1>ieure: ah, I do the exact opposite. I set my channels on my home and go from there. (not with home-channels-service-type tho because I can't really figure out how to get the channel pinning to work properly) <ieure>sham1, I've put large chunks of my operating-system configuration into my channel, so literally cannot bootstrap a machine without having the channel configured at the system level. Easier to keep everything there in that case, IMO. <sham1>I tried the channel method but it was somewhat annoying in practice <mfg>ruther: guix home graph is not a known action of my guix <ieure>ruther, I'm not sure where I can send 400kb of output from script(1), but I can confirm that `guix describe' showing no Savannah channels at all still talks to Savannah when I `guix system image'. <mfg>ieure: ah i see, i'll unlink the file <ruther>mfg: it's extension-graph. But don't worry about it, you probably have the file because you used it at some point, as ieure pointed out <sham1>Speaking of guix home services, how would I have my service depend on the home D-Bus service being up for my service <ruther>ieure: hm, guix system image is producing 400kb output? <ieure>ruther, No; I used script(1) to capture my complete session, and its output is 400kb. <ruther>sham1: add dbus to requirements of your shepherd service <ieure>ruther, Where I start from `guix describe' on the 1st generation of Guix (the state the Ubuntu package gives you when you install), configuring ~/.config/guix/channels.scm, pulling, `guix describe' showing those channels, `guix system image' failing because it's still talking to Savannah. <sham1>I'm honestly surprised that there's not a home-dunst-service-type yet, so I guess it's time to get the gloves out <ruther>ieure: I think 0x0.st has 512 MB max file size <ruther>ieure: and the config you're building is from nonguix nongnu/system/install.scm? What commit? <ieure>ruther, I'll send the file I'm using. <mfg>unlinking and reconfiguring home, was all it needed. Thanks for the help ierue and ruther :) <ieure>Well, the config for the image I want to generate. <ruther>you're using (guix-for-channels %channels) where %channels is going to contain the savannah guix <ieure>Ah yeah, okay, that'd certainly do it. <vagrantc>hrm. ci.guix.gnu.org seems rather unresponsive <vagrantc>or at least ... was ... seems fine looking at a web browser, but slow as a substitute server <luca>Is there anything more I need to do to use pipewire on guix system other than use home-pipewire-service-type ? I assume there's some system wide permissions or something I need to configure (other than the audio group) <luca>Any tips as to how to figure out why it's not finding my laptop speakers? <sham1>Do you have elogind as a service on the operating-system <sham1>Because IIRC it might need that to get access to a bunch of things <luca>Yes, enabled and started (as part of %desktop-services) <ruther>I don't think elogind is required, seatd should work as well <luca>Audio through bluetooth does work, so it's only the speakers that don't. It worked on arch so I expect them to be working <ruther>luca: did you check dmesg for errors? <luca>Nope. What should I look for? <luca>Not too easy to grep. But this sounds suspicious `sof-audio-pci-intel-tgl 0000:00:1f.3: Check if you have 'sof-firmware' package installed.` <luca>and it's propriatery, which would make sense why it worked on arch and not guix <ieure>Yeah, everything needs firmware blobs these days :( <ieure>The firmware is packaged if you need it. <luca>Yep, found it. Will give it a shot. Thanks! <luca>Yep, that firmware did it. For better or worse /shrug. Thanks for all the help! <eikcaz>Hmm. It seems /run/user/1000 is created, but /run/user/1001 is not. Both users are configured the same in my system config. Why is one being created but not the other? <eikcaz>(/run/user/* existing is necessary for guix home services to run) <keinflue>It should be created on first logon (assuming elogind or alternative is running). <ieure>keinflue, Guix doesn't have a facility to verify upstream signatures that I'm aware of. But every source (tarball or SCM repo) has a fixed hash provided. <eikcaz>keinflue: thanks. I guess su --login doesn't work, but when I ssh'd directly in, things seemed to work <sham1>I guess I figured out why there was no home service for dunst configuration. That stuff is *dense* although I hope that once it's done, it could become very helpful for those of us on more "lightweight" desktop setups like sway and the like <keinflue>ieure So if I am writing a new package definition or updating one and I am not confident that TOFU on the hash is enough, I will have to do one source download and verification manually or is there some more convenient way to do it? I think it would be nice to have that feature. I guess I should be able to implement it as a snippet, at least for my <identity>keinflue: i guess you could add a phase to the build that fails if you can't gpg --verify the source