IRC channel logs
2024-06-17.log
back to list of logs
<mange>Are we already aware that the certificate for issues.guix.gnu.org expired ~an hour ago? <freakingpenguin>Oh dang this RISC-V build is going to take way longer than I thought. I think its going through the entire rust bootstrap chain, and with QEMU that'll be at least a week. <jaft>redshift-shepherd-service, currently, cannot run on Wayland due to (requirement '(x11-display)) though, without the forced requirement and an additional env. variable of "WAYLAND_DISPLAY=wayland-1", it's able to perfectly. <jaft>I haven't been able to find a decent example for a home service that runs under Wayland that'd indicate how to modify the package properly (of haven't been able to self-identify one); would anyone have any pointers? <freakingpenguin>jaft: My suggestion would be a wayland? config option in home-redshift-configuration that, if truthy, changes the requirement for redshift-shepherd-service. <freakingpenguin>Not sure the best way to handle the environment variable. If it's always that value it's probably simplest to set it in the start field of the shepherd service, but if the value can change that might be trickier. <jaft>I don't think it changes, any; I was going to ask if there was a similar ~wayland-display~ that sets it or the $DISPLAY variable but I'm guessing it gets set automatically by a Wayland compositor as I can't find one anywhere in the repo. and yet both variables are already set for me. <freakingpenguin>Ah, there isn't a "wayland-shepherd-service" or similar for home services to only run if a wayland session is active it seems. <jaft>Of course, this whole thing makes me wonder why the x11-display service fails for me, anyway, as I'm running XWayland so the socket it needs is there and available; maybe since I'm not (currently) using a login manager? But that'd suppose x11-display looks for the socket /immediately/ as I have it in my bash_profile to launch Wayfire as soon as I login to TTY1… <wigust>jaft: x11-display has nothing to do with a display manager <jaft>I didn't say that it did; my musing was about when it starts (which could be generalized, I'd expect, to asking when services, in general, start). I would expect that a login manager would require X11 or Wayland (or XWayland) to be present, in order to display itself (in contrast to my launching it after logging in to a TTY). If services don't start until logged in, it's a moot point; if, however, they start once you get to the <jaft>login-screen (which I wouldn't expect), it might explain x11-display not finding the socket yet (as Wayfire, for me, won't get launched until I log in to the TTY). <wigust>jaft: do you have /tmp/.X11-unix/X0 or something else in the /tmp/.X11-unix directory? <jaft>I do (the former, exactly). <wigust>jaft: the service has a 10 seconds delay, after which it will be marked as failed. maybe you need to increase the delay <wigust>jaft: (service home-x11-service-type 30) probably, but i'm not sure <jaft>wigust: mmm; that's a good point. Is there a way to do that through the service I'm trying to use? I'm only having trouble due to trying to use the Redshift service (which requires it). <wigust>jaft: not through redshift service <wigust>jaft: either directrly (service home-x11-service-type 30) or via 'modify-services' <jaft>👍️; makes sense. Thanks a ton! <cbaines>I've restarted nginx on berlin to fix the certificate issue <ngz>cbaines: Did you have a chance to read my question about TeX Live version scheme switch on the dev ML? <cbaines>ngz, I did, although I'm not very familiar with how package versions are handled in Guix and I don't have any suggestions around how to change the version scheme <efraim>ngz: IMO, I understand how the package versions go, but with the texlive helper function to combine different bits and make a coherent collection to actually use bits of texlive, I figureit should be fine to just change the version <indigo-oce>can I make a package from just downloaded binaries? I would like to use a more updated version of android platform-tools (adb & fastboot)... can't just download & run them because there's a gcc library they don't find automatically... <ngz>cbaines: Oh, OK. Thanks anyway :) <indigo-oce>just getting an 'unpacking' error; unzip says No such file or directory... <ngz>efraim: Well, yes at the moment version value is not used to specify the contents of the package. IOW changing the version does not modify the hash. However, when I will update TeX Live to 2024.2, this may be an issue, because some hash strings will have to be changed, but guix update could refuse to do so because of the version scheme telling it the currently installed version is more recent. <ngz>I mean, guix update could refuse to download the modified package <efraim>seems like it's more of a problem just that once <ngz>I'm not sure to understand. What do you mean? <efraim>once it's switched over to the new version scheme everything is back to being an upgrade when comparing numbers <ngz>That's plausible, indeed, although I still have a doubt. But maybe the step would indeed be to first move everything to "2023.0", then "2024.2". <jakef>hi guix, question about the store: when i have e.g. home-files-service-type refer to something from an "origin", i am confiden that that thing will get put in the store and there will be a "root" that stops it from being gc <jakef>is that true for all references to origin things? or do these services do something special to add the root <wigust>jakef: guix home creates a profile for package outputs and other things like config files, which should prevent from gc - if i understand your question correctly <jakef>note im not putting a sym link to the file somewhere, but referring to the file in text <jakef>is the root still happening? <jakef>(at least that's what i'm trying to show, my guile is rubbish) <wigust>jakef: (if your plain-file will be provisioned by home-files-service-type) <wigust>jakef: also you could try to gc the file manually by finding it in the profile and trying 'guix gc --delete PATH' on it <wigust>jakef: you should get an error with a text like "it's used by ..." <wigust>jakef: where PATH is the /gnu/store/bla-bla.txt <futurile>Q: is there any easy way (or URL) to see in CI what's broken on the core-updates branch? <futurile>it gives a summary - I guess what I want to see next is "what's blocking those 3500 package's from building" <cbaines>futurile, if you click through you should be able to get more information <cbaines>QA doesn't seem to be loading for me at the moment... <futurile>cbaines: it keeps timing out on me - I did get it once a few days ago <hungry_ghost>I tried 'guix time-machine --branch=core-updates -- build <foo>' on a few packages, but Guix always reports that it will download /gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39 <f1refly>when using guix shell --container, can I somehow automatically set environment variables using the $GUIX_ENVIRONMENT ? <futurile>f1refly: maybe -- env BLAH=whatever progtorun ... <futurile>f1refly: it's a good question - I've wanted that a few times <f1refly>So my best shot is writing a wrapper script that sets the appropriate environment around a program I want to launch if I don't want to remember the specific command line for every launch? <f1refly>I was confused for a while because `info guix` told me, right after the --container section, that I could set GUIX_ENVIRONMENT dependent variables using my bashrc <f1refly>turns out those sections werent connected after all <futurile>f1refly: although it might also just be a rabbit hole <f1refly>another problem I can't get behind: I'm trying to launch a javafx application that runs on x11 through xwayland. In my manifest declaration I specified that it needs `mesa` among others, but during launch the application complains that it cannot find /gnu/store/.../lib/dri/i915_dri.so which is supposedly a component of mesa, or at least used to be. when I `find /gnu/store -name i915_dri.so` it is <f1refly>found in multiple mesa directories, all at 21.3.8, as opposed to the current mesa 24.0.4. I found a thread in the archlinux forums where they talked about the splitting of mesa in mesa and mesa-amber which allegedly contains the i915 lib, but there doesn't seem to be such a package in guix <f1refly>futurile: thanks for the link, I don't need to set up much so I'll tinker around with it <f1refly>hm, now it complains that the i915 driver failed to load, but the application launches. guess I'll take it. <mange>cbaines: Is bordeaux-singapore-mirror.cbaines.net having issues? I'm getting a lot of 404 and 500 responses when using it as a mirror for my substitutes. (I'm assuming you're the person to ask, given the domain.) <cbaines>mange, yeah, thanks for letting me know. I think I know what the problem is and I'll have a look to see if I can fix it ... <ebrasca>Hello, I get the following error "Error executing command as another user: Not authorized" with polkit <wigust>ebrasca: do you have polkit running? pgrep -fa polk <ebrasca>wigust: 598 /gnu/store/5za509lh42hs8raiv8c2pplym0ibgfxl-polkit-121/lib/polkit-1/polkitd --no-debug <wigust>ebrasca: ok, what are you trying to do with it? <wigust>ebrasca: well, i don't know how to fix it via polkit, but i think that obs tries to load v4l2loopback kernel module. You could load it manually with `modprobe v4l2loopback` as a root user and then start virtual camera <ebrasca>I have (kernel-loadable-modules (list v4l2loopback-linux-module)) in my config.scm file <wigust>ebrasca: the module should be present in `lsmod` <wigust>ebrasca: kernel-module-loader-service-type loads <wigust>ebrasca: kernel-loadable-modules only adds to a system profile <ebrasca>wigust: Thanks for the help. I was trying to fix it for a few days now and I was not able to find anything with google... <jpoiret>polkit is probably misconfigured, should be able to load the kernel module itself <jpoiret>like in a shell, try `pkexec whoami` <ebrasca>jpoiret: Error executing command as another user: Not authorized <dariqq>Is guix pull failing for anyone else or only me? <podiki>(I would fix it but I'm not at a Guix machine and I just remembered I should renew my key first...) <dariqq>a small problem is that the fix will cause rebuilds for all kernels <podiki>i haven't checked yet to see where that removed variable is being used. it could go through kernel branch first, but either way guix pull is critical to be fixed first <podiki>the commit could be reverted first <theesm>g'day folks, the dependency of libbpf on linux-libre-headers-6.8 slipped through while preparing the removal of 6.8; will send in a patch in a minute (cannot test if libbpf builds successfully against newer headers though as it would probably take ages on my machine) <podiki>do we have a linux-libre-headers variable that points to current version that should be used instead? <theesm>podiki, iirc we do have a linux-libre-headers variable (l813), but it points to 5.15.49 because of early bootstrap things (never updated it as it has a comment explicitly advising against doing so) so it probably cannot be used <taeltydes>hi all. I'm trying to enable docker on my guix vps, but after enabling elogind I can no longer remote in & have to rollback the server. Is there a way I can enable docker without elogind? <radio>Seems that some of the last commits removed the symbol linux-libre-headers-6.8, as well as linux-libre-6.8 <radio>Despite of that, the reference to linux-libre-headers-6.8 at line 9981 of (gnu packages linux) remains unchanged <radio>Making impossible to guix pull <theesm>radio, there's a patch for that in #71617 (can't apply it myself though, so someone with appropriate rights has to do it) <radio>Ah, nice, I may have skipped it when I was looking for issues regarding that <attila_lendvai>anyone around with the commit bit? guix pull is broken, see guix-devel. patch is there, but needs to be pushed. <ngz>attila_lendvai: OK. Give me a sec. <trannus_aran>I made a gist to help anyone who uses fish shell and got tripped up by sourcing the guix profile :) <trannus_aran>(I noticed replay, bax, and bass had some issues sometimes sourcing $GUIX_PROFILE/etc/profile) <trannus_aran>this also exports the environment vars so it'll work even if your root shell is using sh or bash instead of fish! <chubbymomo>Hey all, I'm having an issue with the oci-container-service-type where some containers exit (Properly, with a status code of 0) before their counterpart services are spun up (e.g. redis before searxng) and then the shepherd disables the redis service. Reasonably, redis needs to be up before the service that relies on it, but if it's not being "used" it just shuts itself off... I then have to enable and start the service agai <civodul>chubbymomo: what do you mean it “shuts itself off”? is it Docker that determines that it’s not being used and can be safely turned off? <chubbymomo>I think that's the case, I believe that docker is treating it a one-shot container. <chubbymomo>I basically took the docker-compose for searxng and made it into an oci-container-service-type. I tried adding searxng as a requirement for redis, but it just stalled the reconfigure indefinitely. Also, that wouldn't be a real solution for a program that uses redis and needs it up before launch. <civodul>i’m not familiar with redis; is there a command-line option to redis (or Docker?) to change that behavior? <civodul>how do people deal with it outside Guix? <chubbymomo>I guess the only factor that might be different is the "restart" policy. However, isn't that not correct to use in the context of a shepherd service? <civodul>dunno, what’s the effect of “restart: always”? <civodul>is that like #:respawn? #t in shepherd? <chubbymomo>Regardless of how the docker container stops, it restarts. <ieure>chubbymomo, What's making Redis stop due to inactivity? That sounds like very abnormal behavior. <chubbymomo>ieure The exit code is 0 (According to docker logs) and the exit code is 137 (according to /var/log/messages), though that doesn't make sense since I'm running redis on a server with some 126GB of RAM... <civodul>so #:respawn? #t is like “restart: always” i believe <chubbymomo>I've done some research and seen that exit code 137 can be shown in the case of anything external shutting the service down, which I believe is the shepherd. <chubbymomo>civodul I think so, but how do I use it with an already-defined service? <chubbymomo>I have another service that I assume has the same temporal nature, telegraf, and it has the exact same issue. <chubbymomo>Exit code 0 on docker's end, code 137 on shepherd's end and everything. <civodul>chubbymomo: looks like we’d need a new flag in ‘oci-container-service-type’ <civodul>currently, ‘oci-container-shepherd-service’ sets (respawn? #f) unconditionally <civodul>so you’d need a ‘respawn?’ flag in <oci-container-configuration> <civodul>that would passed down to ‘shepherd-service’ <civodul>if you feel like giving that a try, i’m happy to provide guidance <chubbymomo>It seems like the logic is kind of faulty, even on docker-compose's end, though. <chubbymomo>Why does it need to have that enabled to not exit? <civodul>right, it does feel weird that you have to respawn redis endlessly :-) <chubbymomo>This would be my first contribution to any repository that I haven't had the "metaphorical" keys to the kingdom. So, I would be a little lost on the process regarding that, especially on a finely-tuned machine like the Guix repository. <chubbymomo>Sounds great, thank you! I'll take a look at getting what I want added and working, should I need help from there. I'll let you know. <ngz>attila_lendvai: Actually, I cannot push =/ The news.scm file seems borked. <ngz>attila_lendvai: Ah! Done. <ngz>attila_lendvai I think so. Didn't I?