IRC channel logs
2025-12-22.log
back to list of logs
<ham5urg>Rutherther, this https://termbin.com/8zsd went ont step further, now lacking opencl-clang: "Cannot find opencl-clang tool-chain, please provide sources or install it on system." <gabber>is it possible that `guix shell -CPWN -- make check` does not work (guix shell: error: make: command not found) whereas entering the shell and /then/ running the tests works just fine? <ieure>Huh, well, that was unexpected. I ran `sudo herd restart udev' to pick up some new udev rules, and it killed my GUI session and GDM. <ieure>gabber, Maybe the shell dotfiles manipulate $PATH and leak another profile into the container. <gabber>ieure: yes, udev is kinda high up in the desktop services tree <gabber>ieure: but why would the same work when not using the double-dash -- shortcut? <gabber>can somebody check if they can reproduce this behavior? <ieure>gabber, The command you gave lists no packages whatsoever, so you're going to get an empty profile. What do you expect to do with that? <gabber>ah, context is doing that in the root of the Guix repository <gabber>where a guix.scm is ready (as described in 22.2 Building from Git) <ieure>I see. I can reproduce the behavior, sort of. At least, I get different results. <gabber>ieure: WDYM? do you or do you not get the "guix shell: error: make: command not found" error? <ieure>gabber, I mean, I get different results for each command, but `make check' doesn't work when I run a shell. <ieure>gabber, The difference is that when you use "-- command" style, you're running the program directly, and when you don't do that, you're running a shell, which runs the program. So the difference must be in the shell dotfiles. <gabber>huh. it works when i explicitly pass `-m manifest.scm` <gabber>so, strangely (or is this by design)? when omitting a manifest then the `-- COMMAND` shortcut does NOT work, whereas entering the (implied) `-m manifest.scm` the shell works just fine. in the former case guix complains about an empty environment, in the latter case it doesn't <ieure>gabber, When I'm building locally, I always use `guix shell -m manifest.scm --pure' <gabber>ACTION raises one thumb in silent approval <gabber>but there's some sort of a mismatch of UI/UX, no? why would omitting any packages ever enter an "empty" env (what good could that be)? <ieure>gabber, Before you told me you were running this command in a Guix repo, I was running it from $HOME, where there is no manifest.scm, so it created a profile with nothing in it. <gabber>yes, sorry. should have given more context right away <gabber>ACTION succumbs to their bedtime <old>Is there a way to make my home shepherd persistent? When I connect to a remote machine and shepherd start, it stop right when I kill the SSH connection <old>killing my other daemons like Emacs <old>Any way to basically keep Shepherd alive once it's started for a user? <old>usually this is not a problem if I have a X11 session already opened on that machine but that's kind of a bummer right now <mroh>if the remote machine uses systemd: maybe add an user service for shepherd. <old>mroh: it use Shepherd for the system <old>but I don't have a home service yet. maybe that would solve it? <bdju>I ctrl-c'd out of guix pull -l because it looked like not-what-I-wanted / slow, but now trying to do it again it tells me the index is locked. Is there a file to delete or process to kill to fix that? I wanted to read the guix news for older generations. <noneofyourbusine>cbaines: thanks for the info; is there a plan for the steps required? If I had to translate by hand from C++ to any other language, I'd first expand to C90, which allows partial rewrites with testing, since C90 is more or less in-source compatible with C++. This was a plan I had, until I noticed the nlnet project, which has the more ambitious (and less portable, i.e. not r7rs) goal of doing it in guile. Are patches (codebe <noneofyourbusine>rts of the guile-daemon in C90 welcome? I'd have started with sqlite.cc and everything that calls it - sqlite's API is declared in C anyway <cbaines>noneofyourbusine, personally I'm more interested in continuing the Guile implementation <noneofyourbusine>identity: atm yes, guix is lazy in terms of portability: linux+glibc+guile *only* ; not using any of these 3 is not a supported configuration - this restricts one's individual choice, perhaps I want a smaller system? ; I'd rather not dig a deeper hole by rewriting some C++ beast to be even less portable, since I would enjoy having more choice in kernels, C libraries, and scheme implementations to choose from.. <identity>i think we have enough problems with just linux+glibc with a little hurd on the side <noneofyourbusine>identity: hence the "atm" (at the moment) - most of the .scm files are written in a guile dialect instead of rnrs (==> packages and their hashes would change) - what's the issue with writing them in r7rs instead? e.g. package definitions don't need to know about the C ABI (FFI); I know that this isn't a priority, it's feasable hypothetically <identity>but what would be the practical benefit of being able to choose, say, Loko or Chibi instead of Guile? <noneofyourbusine>identity: characteristics of the output; e.g. size, performance, reliability, compiler bugs <noneofyourbusine>identity: for example chicken scheme outputs are much smaller than guile outputs, even after compression <identity>i think the size of compiled scheme artifacts is a non-issue, especially when compared to, e.g., programs retaining references to compiler toolchains in their outputs <noneofyourbusine>identity: check out https://codeberg.org/guix/guix/issues/938 - guile bytecode is a factor of 4 larger, and highly redundant (zstd -9 yields ratio of 5); and re: compiler toolchain - a C compiler is required anyway xD - that would be the case for chicken scheme, which outputs C code <identity>you would need guile anyway for Shepherd, especially that it is now getting ported to Goblins from its own hack of an actor model, which means you either need a *second* Goblins implementation, or you need to have both Guile and your scheme implementation of choice around <noneofyourbusine>identity: well, that is a decision of the sheperd project; having both could be fine, being able to choose my own init is even better <noneofyourbusine>identity: better for me, because I like to pick my init for myself as I see fit <csantosb>Good morning Guix ! Weird question of the day: how to pull from a local checkout with a remote called `codeberg`, not `origin` ? 🤔 <noneofyourbusine>well, one could stop hardcoding around a specific init - instead using some portable interface from ye olde <identity>i think using portable interfaces is going to degrade the experience of using either init system <noneofyourbusine>identity: if you count the programming part of it a part of the experience, sure; just using a scheme wrapper on top of that legacy should leave one oblivious <identity>and, anyway, does using an alternative init system/kernel/scheme implementation solve an actual problem or does it only bring new ones? <noneofyourbusine>identity: using an alternative init system/kernel/scheme implementation: surfaces existing problems, introduces new problems, but also lets you pick according to your needs - [maybe you don't care, maybe you prefer the smallest possible system, maybe you need very high reliability and need to make sure that your system is fit for something safety-critical (hence preferably small, that is easier to verify)] - most important <noneofyourbusine>hich can help segregate parts of the codebase that don't belong together <identity>i believe that adding even more configurations to test is going to decrease the quality of all of them—we barely manage with linux+guile+shepherd, and there is Hurd not that far away <identity>the least we can do is deal with problems we already have, instead of chasing the pie in the sky. <noneofyourbusine>identity: perhaps; yet these problems are coupled to the choice of packages and how we package them: a system with exclusively portable interfaces is easier to debug, with the assumption that we can switch out any of the interface implementations out for another, to check where the issue stems from <noneofyourbusine>this isn't a new learning btw, that's what unix (later plan9) was all about: the same interface everywhere (directories, files, text), you don't need to know the implementation. <Rutherther>hey, when updating the guix package, should one make sure it's first substitutable by ci/bordeaux or is it fine to push an update to master? <Rutherther>(after making sure it builds on my end of course, I wouldn't skip that step, especially not with such an important package) <cbaines>Rutherther, there's not currently a mechanism to build things so that substitutes are already available when changes are pushed <Rutherther>cbaines: I am not sure what you mean by that exactly. What I was thinking about is having a CI jobset for it and/or a merge request for QA. Even putting it to next-master first would accomodate what I had in mind. True it doesn't work 100%, but in this instance it should be fine. Or what exactly are you thinking about here? <Rutherther>_I think next-master would accomodate it, I would have to check to make sure no inputs to guix changed, but I think they haven't_ <untrusem>btw I am seeing spam wave in #emacs and #emacsconf, is guix next? <cbaines>Rutherther, yeah, I guess you could use a branch and get CI/QA to build it, but there's not really any reason to <Rutherther>cbaines: the reason I was thinking about is that it takes some time to build it. On my machine it's like 30 - 50 minutes <cbaines>Rutherther, right, but at the moment there's no mechanism in place to do this generally, so don't feel like you have to do it for an individual package <cbaines>at some point it would be nice to set something up again <Rutherther>cbaines: Makes sense, thanks. I think I could upgrade it later today, as there have been some changes in both the daemon and guix itself in the past two months it hasn't been updated. Though still I would like to first merge few more PRs that are touching it first <identity>and, i think, it is «personal» reason, so the spammer has no reason to get in here <ximon>Guix compiles with guix install? <identity>you mean, «does Guix compile software when you install it with ‹guix install›?»? usually it does not, but you can do that with --no-substitutes <civodul>also merged the fixes for ‘guix archive’ & co. <paranoid-android>How to configure gdm so that it does not hibernate/suspend/sleep when it's on mains power? <Rutherther>paranoid-android: that's not gdm, that's elogind, see the elogind-configuration options in the manual <Rutherther>or maybe I misunderstood, did you mean sleep after some time of inactivity? <Rutherther>(I somehow defaulted to notebook lid switch, sorry) <Rutherther>paranoid-android: okay, then sorry, it's not elogind, that would be just for the lidswitch. This is indeed gdm itself. <Rutherther>paranoid-android: there is auto-suspend? option in the gdm-configuration that you presumably want to set to #f. <tachymelia>hey y'all! I just got added to a team and now I'm getting emails and notifs for like every pr. is there any way to only get notified for my team? <identity>tachymelia: i assume it is somewhere in the account settings? <tachymelia>ah it was, it set me to watch the guix repo automatically <hanker>hello, is there a way to modify Shepherd's `default-environment-variables` at runtime? <hanker>i tried `herd eval root "(default-environment-variables (cons* \"WAYLAND_DISPLAY=$WAYLAND_DISPLAY\" (default-environment-variables)))"`, seems it doesn't change anything... <yelninei>yes and no.the environment variables with the default make-forkexec constructor and similar get fixed when shepherd reads its config file. There are some services that work around it (redshift service with x11-display) but the situation is not ideal <ximon>Guys why don't you just use arch <fhang>I recently switched from Arch to Guix, and I'm loving it. <ekaitz>hi! i just moved to guix home and GPG doesn't find pinentry anymore <ekaitz>I just have them both installed in my packages <ekaitz>graywolf: but is that necessary really? like... I didn't have any of that before. Just installing things in my profile worked! <graywolf>Sadly I do not have a useful answer here, maybe it is not necessary, not sure. <ekaitz>graywolf: I tend to bother people with my questions, don't feel pressured. Thank you for your input. <ekaitz>I'll try it and see what happens <fnat>In case it helps for comparison. <graywolf>Stupid question, did you restart gpg agent after installing guix home? Maybe it does not have the right PATH? <ekaitz>graywolf: I think it doesn't have the proper path, because it says pinentry is not available, but I sure did restart the agent <ekaitz>fnat: reading it, thanks! (i just stole a few things) <graywolf>you can check the PATH via /proc/pid/environ <ekaitz>fnat: do you have pinentry configured anywhere? <ekaitz>graywolf: it's just gpg that fails, everything else is fine... hm <fnat>ekaitz: Perhaps you need to select loopback in your pinentry config? <fnat>That's the only relevant bit of config I see under my Emacs' pinentry settings. <ekaitz>graywolf, fnat: thanks for your assistance, the thing worked with the extra config and restarting the agent <fnat>Aha, that's cool, well done. <yelninei>does anyone know if it is possible to use go-build-system with gccgo and no go-std? doesnt gccgo come with that? <csantosb>People still mix them both, and with good reason <yelninei>hmm does cross compiling even work with go-build-system? lots of very funny errors <meatoid>I wanted to confirm, are we trying to move away from using labels to refer to/manage inputs in packages? Should we still be using (this-package-input ...), for example? <meatoid>It's very concise relative to (dirname (search-input-files ...)), but it does use labels <Rutherther>it does rely on labels currently, but it doesn't have to rely on labels, you can also treat it just as package names. I would say it's more of an implementation detail that it relies on labels now <FuncProgLinux>guix download: error: mkdir: Permiso denegado: "/home/fplinux/.cache/guix/checkouts/zbh2crxy674dr2qp2lgsnqrmxnxzeykjexerlh3zfkpbfbtl4e4a" <Rutherther>FuncProgLinux: who is that checkout owned by? or ~/.cache/guix/checkouts? <FuncProgLinux>Rutherther: ~/.cache/guix/checkouts but "ls -lah" shows root:root for some reason <FuncProgLinux>I haven't updated my system in a week +- but the sudo -E guix i only do to reconfigure my machine, not to build or anything else <Rutherther>but that's exactly when it would happen, on reconfigure <Rutherther>that's when it uses the checkouts folder of your user, wrongly <FuncProgLinux>should I just chown -R and call it a day? is it safe to do so? <Rutherther>and see the shared-cache-service for mitigation of this issue <FuncProgLinux>Rutherther: AH so it's a bug? I haven´t had much time to check, maybe I should upgrade and read that on the manual. <Noisytoot>It says it was merged into core-updates, but I can't find that commit in the current master <Rutherther>FuncProgLinux: no, it's not a bug, it's a user error. You shouldn't run sudo -E, it's dangerous <Rutherther>or accept the consequences when they do happen :) <FuncProgLinux>Rutherther: Wait what? That's the way I've read many months ago when reconfiguring a Guix system <FuncProgLinux>guix home reconfigure and sudo -E guix system reconfigure for systems and users <Rutherther>then tell me where so I can message the author to correct it <FuncProgLinux>Rutherther: Third parties. Not really something in the guix documentation <FuncProgLinux>I learned by reading code, repos and blogs from the community and it seems to be a common pattern. But if it's not recommended I think I should stop doing that ASAP <fnat>Am I right in thinking that the current WireGuard service only supports one wg interface? Is there any known workaround to set up a second interface, say wg0 and wg1?