IRC channel logs
2026-05-06.log
back to list of logs
<cdegroot>guix/ui.scm:921:18: error: go-1.23: unbound variable <-- does that ring a bell with anyone? I'm on latest master for guix (plus a bunch of other channels) <cdegroot>ah , nm - I found it, some old stuff got pulled in. I'm dumb, so much is clear. Reading stacktraces is too hard for me :P <loquatdev>Hello, everyone. What's the proper way to set a working directory for a custom shepherd service? <loquatdev>Found it in the shepherd manual. There's a #:directory key in make-forkexec-constructor <mwette>looking like many packages on aarch64 right require patchwork <mwette>I have been trying to build prusa-slicer on aarch64. First problem is that cereal needs fix. I fixed that and created package cereal-local. Then I run into problem wth embree; fixed that but wait. embree is not listed as input for prusa-slicer and `guix graph --path prusa-slicer embree' says "no path". How can I track this down? <bdunahu>there is two versions, try `guix graph --path prusa-slicer embree@3.3.15` <mwette>bdunahu: thank you -- that yielded an intermediary libigl@2.4.0 <bdunahu>I remember libigl since I tried to update it a few months ago due to it being old and CVEs, it looks like embree@3.3.15's only dependent is libigl. I don't remember why it was hard <mwette>In my case embree broke because the configure-flags in the package were x86_64 specific. I'll work on libigl next. <bdunahu>mwette: if you get a version bump building or partway can you notify me on your pull request? <mwette>bdunahu: What arch(s) are you using? <bdunahu>just x86, I was only wondering about version bump if you tried <bdunahu>okay I looked at the package definition again and I think I remember why I didn't want to mess with it that much :D <efraim>does i686 support SSE2 instructions? <civodul>M-x fj-list-issues stopped working for me <civodul>“fj-list-issues-do: Repo does not have issues” <csantosb>civodul: I read somewhere there are backwards incompatible changes in fj.el <csantosb>Mine is broken since then, for example; I didn't spend any time figuring out the changes. <penisilvania>Try to install gnome-software and try to make it work with guix packagemanager <sham1>And the process of refactoring the guix library so that the installs et al can be done programmatically would probably be a gigantic undertaking <efraim>I have test_ssl failing on the python-team branch for python@3.12 for riscv64. going to wait until the end of the check phase <joe->just testing out the circe package for IRC from inside Emacs. To be honest, it seems already like a better fit for me, simpler and with sensible defaults. I am but a casual in IRC :) <mwette>bdunahu: I am working on embree-3 now. It's complicated. <civodul>oops, expired cert on doc.guix.gnu.org <civodul>cbaines: did you renew the doc.guix.gnu.org certificate? <civodul>somehow the location block for /.well-known added by certbot-service-type has no effect <cbaines>civodul, nope, at least not recently <civodul>cbaines: sorry for the noise: i was looking into it and thought it had “fixed itself”, hence the ping <civodul>anyway, after a bit of trial and error, this is now fixed <ph>Hello, I am working on something that I think need to use requirements in shepherd services, and that relationship need to be dynamic based on the configuration. I have 3 services (A, B, C). They can all be configured manually. But depending on the configuration of A or B they could need C to work. I want to make this dependency an implementation detail, ideally hiding that logic behind something like (service e-service-type <ph>(e-configuration ...)) that will take care of starting the following services combination: A with C, B with C, A or B. Any pointer for this or recommandations? <ieure>ph, See my autofs-shepherd-service, which dynamically computes requirements based on the configuration. <ph>ieure: thanks, just looking at it I think it's what I am looking for. <loquatdev>Does anyone have an example of using #:input-port in a shepherd service? I'm trying to write a custom action that will write a line to the stdin of a currently running process. <loquatdev>It looks like I need to do something with mknod... <ieure>loquatdev, You'd use mknod if you wanted a named pipe, I don't think that's what you want. But I'm also wondering what the usecase is that requires a daemon to read from stdin? <ieure>That is very atypical for a *nix daemon, which makes me suspect that your approach may not be correct. <loquatdev>It probably isn't correct. I'm running a non-free binary that I've packaged as a shepherd service. This particular piece of software accepts commands from stdin, like "foo bar baz\n". <loquatdev>Which, I don't think I'm supposed to elaborate on because I know that non-free software isn't supposed to be discussed here. That's why I'm asking that specific question. <loquatdev>I do have another idea for a solution. Would shepherd be able to restrict networking from a service to only be public on a specific port, forcing the others to stay on localhost? <loquatdev>This particular software has the option to open an insecure admin protocol on another port, but it unfortunately defaults to listening on 0.0.0.0 without the ability to configure it. Would shepherd be able to manipulate that somehow? <sham1>You'd probably have to contain it somehow <sham1>Thankfully it's rather easy to contain packages and shepherd services <wonko`>loquatdev: I would either setup a net namespace for that process (start the service with ip netns exec ...) or restrict what ports are open to the outside with nftables <loquatdev>Yeah, nftables is probably the best option in this case. Especially since this software is supposed to run on a server. <mwette>bdunahu: now fixing spectra, input to libigl, input to prusa-builder <ieure>loquatdev, The address to listen on is determined by the program being run and cannot be (directly) influenced by other processes. If you need to change that, you need containerization or to change the way the program behaves (which sounds difficult in this case). <lilyp>loquatdev: the status of a shepherd service can be anything that's returned by the start command, so if you want to open a pipe, you can do that <lilyp>i did something similar to implement a dbus service once <lilyp>once you have the port as status, you can implement actions which would write to it <lilyp>as for the networking thingy, i think namespaces might get you there, but you have to configure the forwarding quite manually <kestrelwx>Not yet, I think this decision would arrive via a GCD. <lilyp>of course the LLM forgot to check for "or later" <ekaitz>nutcase: so the issue of texlive is related with the fonts. You are using a font in your documents that you don't have installed or is not found <ekaitz>so it's trying to build a cache of fonts by itself basically traversing all your home folder <ekaitz>it just didn't match the name properly and started to read everything for no reason <ekaitz>if you `strace -e openat` the tool, you can see how it opens hundreds of files <nutcase>ekaitz: strace: yes, I see that now. It looks like scanning my whole home directory including my home profile. <ekaitz>it happens because its expecting a font that its unable to find <ekaitz>or at least is not cached with the name it expects <nutcase>ekaitz: Your linked diff: you removed the explicit declaration of the font (Lota in your case, Opensans in my case). That could solve the issue, IF it is fine to use another font. <ekaitz>i don't know a lot about latex really <ekaitz>because they are not that easy to find by name <ekaitz>if your fonts are installed manually they may have a name you don't expect. Lato vs Lato-Regular <nutcase>ekaitz: side note: I am using opensans, and texlive-opensans is included in my profile via "texlive-collection-fontsextra". I also tried after adding "texlive-opensans" explicitly to my profile. <ekaitz>hmmm also there was some difference between lualatex and xelatex and pdflatex <nutcase>yes, I am also neither latex nor a font guru, just a simple user. <ekaitz>some do use fontconfig some others use their own mechanism <ekaitz>that's why in my case lualatex worked ok but others didn't <ekaitz>i think that might be part of the problem <nutcase>yes, font handling is something that distinguishes the lualatex from xelatex from pdflatex <loquatdev>I'm writing a shepherd action. Output sent to the terminal by functions like (display) works fine, but for some reason I cannot get the output from (spawn) to display. Any ideas? <loquatdev>I've verified that the command is running successfully. It's just that the output is not visible when called from `herd myaction service arg1 arg2` <nutcase>ekaitz: any idea, which environment variable could cause lualatex and xelatex to scan the whole home directory? I mean, if I run them in a container with shared home directory, both terminate and don't scan the whole home directory