IRC channel logs
2025-06-12.log
back to list of logs
<moshh>hello. I am new and running guix in a vm. I want to launch sway but I"m having trouble setting XDG_RUNTIME_DIR. I have elogind installed and running as a herd service. <podiki>mesa-updates merged, let me know if anyone has any issues in the aftermath (though just a handful of updates and substitute coverage should be good) <postroutine>Hello. I think one of my e-mail to the help-guix list is blocked. It a reply to a discussion. <jjba23>Hi all, I was wondering if you know how I can achieve inside Emacs, that Scheme mode docstrings are applied `font-lock-doc-face` instead of `font-lock-string-face` <postroutine>Thank you for having unblocked my e-mail. I can see it on the archive. <identity>jjba23: probably a better question for #emacs or #guile <jjba23>identity: I guess you have a good point indeed, will ask there! Good morning to you all by the way <fnat>Hi, I get a "guix substitute: error: fport_write: No space left on device" error when installing Guix from a USB pen with the usual "guix system init config.scm /mnt". <fnat>Anything in particular I should check first? <fnat>Interesting, now the installer no longer works and exits with a "Git error: no error". <fnat>Ha, no, scrap that, `guix system init ...` works fine (perhaps I had a temporary network glitch). I'm rerunning the init phase. <fnat>I'll see if I hit the "No space left on device" error again. (Which is odd, because I have plenty of disk space.) <fnat>Ha! No, I didn't! Thanks efraim! I'll do that now. (Now I remember I was hit by this in the past already.) <fnat>Hm cow-store fails to start. Investigating... <fnat>Aha... I was missing the last bit "herd start cow-store /mnt". It seems ok now. <fnat>Hm, nope, not there yet. Rerunning "guix system init ..." gives a "No space left on device" straightaway (whereas it took a couple of mins before). <fnat>Restarting cow-store now seems to generate all sorts of errors, e.g. "In procedure mount: mount "none" on "/.rw-store": Invalid argument". <fnat>I might try and restart the installation. <fnat>I rebooted and restarted the installation process, this time making sure I started the cow-store service at the right time. <fnat>Perhaps I can just try and rerun the init command... <loskutak>Hi, I wanted to try guix. installed guix on my nixos computer, run guix pull, it fails while building gnutls-3.7.2 - hash mismatch - it tries to download gnutls-3.7.2.tar.xz from artfiles.org -> 404 not found, then it tries from crysys.hu/gnutls/v3.7 downloads only a html page (not found, but without the HTML 404 return code?). Any ideas what is going on and how to fix this? Thanks <fnat>(Update: it worked. Installation completed.) <csantosb>loskutak: are you using the binary installer ? <jakef>hako: looking forward to trying the new rust packaging! thanks for all your work on it <janneke>after a fresh pull, exwmx-dmenu broke for me, ideas or ring any bells? <loskutak>csantosb: that is not the way stuff is installed on nixos, if you think the way guix is installed in changes anything, I could still try. From what I understand, I have guix installed ok, the "guix" command seems to be working, "guix pull" does stuff (pulls, updates substitutes, builds (downloads pre-built?) various derivations. It just fails at the particular gnutls-3.7.2 package. I am new to this, <loskutak>but I don't think this is connected with the way in which I installed guix <meaty>anyone got any pointers on how I can simulate a wayland environment for tests? <janneke>hmm, my exwmx-dmenu--commands contains \... whatever that may be... <dariqq>hello, whats the current status of core-packages-team? <dariqq>i found a TODO to merge patch with patch/pinned, v2.8 is available and it would remove the hidden gnulib dependency but it touches commencement.scm <luca>Hi, is there a way to run "static analysis" on guile/guix files? To make sure there are no missing variables or imports? (not packages or home definitions, but service definitons in particular) <ieure>luca, I don't believe there's an existing tool for that. Dynamic languages like Lisps tend to be difficult to do static analysis on. <luca>heh, I wonder if `echo '(use-modules (luca home services home-wvkbd-service-type))' | guix repl -L .` has any side effects :P <luca>it's not static, it's code execution <apoorv569>Hi am trying to update the neovim package, but it look s like the tree-sitter package needed to update as well for that. Do I send a patch for tree-sitter and neovim separate or as a single commit/patch together? <ieure>luca, Yeah, "static analysis" on a Lisp is pretty much "evaluate the code." <apoorv569>Also can I update them both to latest version or will it break other packages? <ieure>apoorv569, One pull request, one commit per package updated. <ieure>apoorv569, "Will it break other packages?" It might! You'll have to build them to see. <apoorv569>ieure: I see. But do I mention in the PR that this is need for this other package? <ieure>apoorv569, It's usually obvious, but feel free to put it in the PR description. <ieure>apoorv569, `guix refresh -l tree-sitter' will tell you what package a tree-sitter update would rebuild. <apoorv569>I tested neovim v0.10 with tree-stter v0.22 seem to work.. but I was wonder no other package on guix breaks, I can't test everything on guix. <ruther>apoorv569: please don't send pr to update tree-sitter nor neovim. They are both already updated on rust-team branch <apoorv569>ruther: I see. so newer versions for both are available already? or do you mean a PR has been sent? <ruther>apoorv569: I mean what I said, there is newer version in rust-team branch. <ruther>and yes, one PR has already been sent, and declined, as this job has already been done... <ruther>and I think like two patches were open before the switch to codeberg... <apoorv569>ruther: I didn't say you didn't mean what you said, I am clarfying if I understood you correctly. This is text chat, I can read your mind from here. <ruther>I really don't know what's not clear about 'they are on branch X' <identity>apoorv569: i think you meant to write "I can *not* read your mind from here", but, well, i can not read your mind from here <ieure>I can read all of your minds, stop thinking dirty stuff. <ruther>ieure: at least you can't control our minds! <identity>ruther: that is what ieure wants you to think <luca>When will rust-team merge to master? Is there a lot of work left? <abbe__>I wonder why is udev-shepherd-service not require user-processes ? <ieure>abbe__, Why do you think it should? <abbe__>ieure: because it's a daemon and runs after root-file-system is mounted ? <abbe__>it seems i and a few other lucky people exhibit this problem <abbe__>I'd a few custom shepherd services configured which were not depending on user-processes, so I updated them to require user-processes <ruther>abbe__: and did that fix the issue? <abbe__>i'm still looking if I missed something else, but i noticed udev is also a daemon but not depending on user-processes <ieure>abbe__, What if some FS is on a device udev creates the node for? <meaty>If a dependency is just a header file library, should it go in inputs or native-inputs? <meaty>I would guess native-inputs should be added to conservatively right? <abbe__>ieure: by the time udev runs root filesystem is mounted <abbe__>and also i don't see udev service ever being stopped in /var/log/messages <abbe__>i'm just hypothesizing if it's preventing / from being remounted readonly, apparently logs are not helpful <dariqq>last time i investigated this on my system I had it every time after a system reconfigure / the upgrade-shepherd-services.scm script ran but I never figured out the reason <Ironsmith>heya! does anyone have a trick to just build english manual and cookbook when running `make` ? i just want to do a quick build locally and was looking for a command-line way, so without manually editing doc/local.mk each time. i tried `make MANUAL_LANGUAGES= COOKBOOK_LANGUAGES=` but that doesn't work <Ironsmith>or maybe a way to skip doc building altogether? <identity>Ironsmith: "make guix.texi" and "make guix-cookbook.texi" should work <abbe__>dariqq: so it stopped happening with you? <dariqq>abbe__: i still get the 'recovering journal' message on the next boot after a reconfigure but never noticed any corrupted files. maybe i am just lucky? <abbe__>my zsh history gets corrupted ocassionally <Ironsmith>identity: trying from scratch, did a git pull not too long ago ( June 8 ), doing `make clean`, `git clean -fxd`, `./bootstrap`, `./configure`, `make scripts/guix` (<- because it seems required now?), then i try your suggestion `make guix.texi` but i get: `make: *** No rule to make target 'guix.texi'. Stop.` <identity>Ironsmith: it may be called doc/guix.texi, not sure about the exact name <Ironsmith>doing `make doc/guix.1` which i got from autocomplete and it seems to be doing something without building all the other languages first, so it looks promising <podiki>anyone have some basic troubleshooting tips for when cuirass isn't building? service and worker vm are up, builds bending on web front end, but no action <podiki>usually you see builds failing but maybe just so happened it filled up exactly after a build or some other action <podiki>hrm, it is the /var/cache/publish directory, so i'll need to (properly somehow) remove old nars <podiki>anyone happen to know about this? or can i just delete from that cache directory directly? <abbe__>i usually would just guix gc, and don't use cache <podiki>this is for a substitute server, i'm not very familiar with these details but i think the caching is helpful when you have more than just a user or two <podiki>although this does seem tangential to the problem of cuirass not building: the disk and store are all available with space, but maybe something is hung trying to bake a build to cache? <abbe__>i use cuirass server as substitute server <civodul>podiki: ‘guix publish’ has a ‘--ttl’ option, which can help <civodul>if you delete manually, you must delete the .narinfo files and nars that go together <ieure>Yeah. I don't think `guix gc' knows anything about the NAR cache. <podiki>guix gc just for store; would be nice to have similar for publish (though i guess some bash-fu to find/delete older files; or this ttl option) <podiki>civodul: thanks. if changing ttl though, that doesn't affect already cached entries (still need to be removed)? <podiki>still, i'm not sure why a full cache for guix publish would affect cuirass not building? <civodul>podiki: sorry i thought you were saying /var/cache/guix/publish was taking too much space <podiki>yes, /var/cache/publish (where guix-publish puts cache) is full, but i only noticed because cuirass (not guix, another channel) has stopped building <civodul>‘cuirass remote-worker’ instances stop accepting new builds when disk is almost full <podiki>i wasn't sure it could be related, i figure if cache is full either not more caching or users can't access, but i guess this is separate <podiki>rest of / is mounted on different (not full) disk <podiki>yes, /var/cache/publish is from a network filesystem <podiki>the worker is a vm, on same one machine <podiki>but just that cache directory is full and i can't find any builds failing due to e.g. full disk or other issues. just see lots of pending builds. restarted cuirass, worker,... <ieure>podiki, I've had this happen a few times, never worked out what was going wrong. <ieure>podiki, At least in my setup, guix-publish-service is handling serving NARs, Cuirass just builds stuff and drops it in the store. <podiki>yes, same here on the setup i believe (i didn't set up, just trying to un-stick it) <ieure>podiki, Is /var/log on the same FS as /var/cache/publish? <ieure>Maybe Cuirass wants to write logfiles and can't. <podiki>i'm not sure i can reconfigure/reboot the machine though, as i hear sometimes it needs some host intervention <podiki>no, just the cache directory is separate and full, which does seem like a red herring to me now <ieure>Hmm yeah, I don't see how that would impact Cuirass at all. <ieure>podiki, Like I said, I've had this happen a few times. I've had to remove Cuirass and PostgreSQL from the system config, reconfigure, rm -rf all their state, readd, and reconfigure again. You lose all the build history. <ieure>That's probably too big a hammer for your case. <podiki>anyway, if cache is full for guix-publish what happens anyway? continues publishing without cache? <civodul>podiki: i think ‘guix publish’ does awry in that case <jonsger>civodul: podiki: I will just increase the network share where /var/cache/publish/zstd is laying :) <podiki>civodul: guix publish still seems happy enough so far <abbe__>depending udev on user-processes broke booting :) <podiki>the fact that this server stopped building on my mesa-update merge makes me fell guilty by association :) <Kolev>Curious: Did Guix consult with Codeberg before moving hosting there? I'd imagine Guix would bring a lot of traffic to Codeberg. <podiki>Kolev: yes, it was discussed with them the storage/bandwidth issue, i believe the response was "it will be fine" :) <podiki>Kolev: i think the issue might be lots of forks of guix on there and the resources that needs, but they are aware <podiki>and so far things have been good on codeberg, though personally i haven't had a chance to read up on agit workflow and get comfy. easy issue making and interactions so far <ieure>ghodawalaaman_xm, Pinentry is for gpg-agent, which needs to run as a daemon. `guix shell' doesn't start any daemons. <podiki>gpg-agent needs to be aware of it, do you have it in your gpg config? and did you restart the agent? <podiki>sure, but it needs to know about pinentry via ~/.gnupg/gpg-agent.conf usually <podiki>and needs to be started in that same guix shell, if that's what you are trying to do <abbe__>gpg-agent --daemon $(which $SHELL) <abbe__>and then in the child shell gpg should work <abbe__>perhaps kill the existing gpg-agent <podiki>what is gpg-agent.conf? i don't know what the default pinentry setting is <abbe__>i think default pinentry is 'pinentry' in PATH <podiki>oh right yeah you need to kill the first gpg-agent <abbe__>just kill all gpg-agents, and then start this "gpg-agent --daemon" shell <abbe__>if that doesn't work, then "gpg-agent --pinentry-program $(which pinentry) --daemon $(which $SHELL)" <ghodawalaaman_xm>"gpg-agent --pinentry-program $(which pinentry) --daemon $(which $SHELL)"