IRC channel logs
2025-10-09.log
back to list of logs
<ieure>nomike, Is your original problem that the build fails with that error, or that the build works, but the program fails with it? <ieure>Adding nss-certs to the package input won't fix either. <nomike>The latter. The build works, the program fails. Not completely. but it prints those errors to the console and some functionality is broken. <ieure>nomike, Are you certain the server it's communicating with has valid certs? <ieure>nomike, Guix System or foreign distro? <nomike>Yes. I'm running guix on Ubuntu Foreign and can run PrusaSlicer in Ubuntu (using flatpak) and it works just fine. <ieure>nomike, Are SSL_CERT_DIR / SSL_CERT_FILE set in the environment you're running prusa-slicer in? If they're set, are the pointing to places prusa-slicer can access? <nomike>No, they are not set. Let me try setting them accordingly... <nomike>When setting `SSL_CERT_DIR` to '/etc/ssl/certs/' the TLS error messages are gone. Which brings up the question why this is required for the guix version and not for the flatpack one... <nomike>There is a version check built in which works fine, but it might be a non-encrypted HTTP URL ¯\_(ツ)_/¯? <ieure>nomike, Version checks are discouraged in Guix packages, it probably shouldn't be doing that at all. <ieure>nomike, No idea about the WxWebViewPanel stuff, might be a question for upstream; or you can file a bug with Guix. <ieure>nomike, I believe certs work a bit differently in Guix for reproducability reasons, but I don't know exactly why it's how it is. <nomike>I will file a bug one codeberg. It's probably easier to sort it out there. <apteryx>would someone know how to make 'guix shell --container' usable in a 'guix system vm' or 'guix system container' ? <apteryx>I tried to make a system vm with --volatile (or not) and 'guix shell -C' complains about either the store being read-only (container) or some mirror.lock file being read only (vm) <robin>for just making it work, a podman container is maybe easiest, because the store isn't shared; i have a recipe from documenting icingaweb2 setup... <apteryx>before I jump to the docker image, I'll try just a plain image... it should work since it won't be sharing any of the store with the host <robin>(for "podman run", minus "-p" for port mapping, and "-v" ~= "--share", probably not useful beyond maybe a prebuilt guix dir for pre-inst-env'ing) <robin>along with https://paste.debian.net/1400116/ minus icinga services for a working container os (no in-guix examples i think, it's not quite minimal services, but it removes the ones broken in containers) <robin>podman being compatible with docker images (i don't know either system, some sysadmins i know prefer podman though) <robin>nope, that doesn't help, guix shell -C says: guix shell: error: while setting up the child process: in phase setPersonality: cannot set personality: Function not implemented <char>Hi is there a way to do a guix build and tell it to ignore (redownload) the source that has been downloaded to the store? <sneek>Welcome back char, you have 1 message! <sneek>char, untrusem says: here is an how you can make your own st packages with patches, this is easy that doing that in arch https://bpa.st/JU4A <kyoji>hey #guix! I've got a question. I'm browsing the source for guix service types (desktop.scm) and I'm wondering what the best way to discover where symbols are originally defined? <kyoji>For example, the symbol "program-file"" <kyoji>I'm in guix-system usign emacs, in case there is something in the 'guix' package I'm missing that would help <look>nutcase: a friend of mine asked to help on #3247 but I have too little free time :( <look>I sent a reply which might help, feel free to ask if any other issues <iamawack1>I've been trying to update some of the out-of-date Go packages, but it just seems like a massive pain. Most projects don't vendor anymore, and a lot of Go libraries aren't packaged yet, so I would just spend forever trying to get all of the dependencies in and working with guix import go, and even then it wouldn't really work. Are there any plans to do something like how Crate/Cargo/Rust works, but for <iamawack1>Go? The dependency management for Crate/Cargo/Rust seems so much cleaner and usable. <sneek>iamawacko, you have 1 message! <trev>does anyone know a more recent emacs-next commit that is working? very recent commits have breaking tests with just a commit hash replacement <sibl>I did the format/luks with cli but would be better if gnome-disks could work <sneek>efraim, kestrelwx says: I don't know if I should remove the patch for Skia code from the commit(it's not harmful, but also not sufficient, and not related to the rendering problem we see), so I won't rebase tonight, please see for yourself. <efraim>kestrelwx: do you mean your fix-qt6-libvulkan branch? <kestrelwx>Yeah, I could rebase it now without the snippet and only keep the upstream patch. <kestrelwx>So that master gets working WebViews, and then Vulkan fixes can be done later. <efraim>so without patching vulkan_implementation_qt.cpp? <kestrelwx>If you want we could first check if patching whatever `gpu_init.cc` calls is enough and then push that. <efraim>so I'm processing slower than I'd like this morning. "gnu: qtbase: Always find libvulkan." fixes libvulkan for qtbase, with qttools as proof. qtwebengine->6.9.3 with qtwebengine-revert-egl.patch fixes WebViews? and leaves qtwebengine w/ vulkan as TODO? <kestrelwx>It's either the `qtwebengine-revert-egl.patch` or bumping it to 6.10, yeah. <kestrelwx>And it'll have Vulkan disabled at `chrome://gpu` but otherwise work as it used to. <csantosb>Ey Guix ! I just noticed a discrepancy in the weather today, to the same over Bordeaux and Berlin <csantosb>`guix weather nextpnr`, it is not expected to be the same ? <ieure>csantosb, What are you seeing that's different? <csantosb>By the way, `guix size nextpnr` gives "total : 4940.2 Mio". Glups. <nutcase>look: thanks, this was helpful. I have still some questions and things to test and responded in the PR accordingly. <efraim>kestrelwx: without the snippet, `qutebrowser --temp-basedir --qt-flag disable-gpu-compositing` falls back to vulkan without crashing <kestrelwx>efraim: It should work ootb with no options. <kestrelwx>Vulkan never worked in out QtWebEngine in the first place. It's the upstream regression that caused the breakage. <csantosb>Anyone around using `openfpgaloader` ? Just noticed that I need to install `libftdi` with my local pkg manager to make it work <csantosb>I'd be interested to know if in a native Guix install it works as expected (ekaitz ?) <efraim>kestrelwx: `qutebrowser --temp-basedir` segfaults, `qutebrowser --target private-window` has some weird visuao artifacting but opens correctly <efraim>so I think we can count it as working <efraim>for qutebrowser I do hve set qt.force_software_rendering = software-opengl in a config file, don't remember why <kestrelwx>You have an Nvidia card with nouveau, right? <efraim>I have a small collection, drove my local computer store crazy :) <kestrelwx>Do you have `QSG_RHI_BACKEND` set to Vulkan? I get a segfault that way on nouveau. <efraim>I didn't get any visual artifacting with `QSG_RHI_BACKEND=vulkan qutebrowser --target private-window` <efraim>and --temp-basedir worked without issue <NegateThis>Are there any guix service types that show examples on how to generate TOML config files? <efraim>`git grep toml\)` suggests guix/build/pyproject-build-system.scm and guix/import/pypi.scm might have something, but I assume it'd be parsing <efraim>NegateThis: maybe wlgreet.toml in gnu/services/base.scm can serve as an inspiration? It looks like it's done fairly manually there <ekaitz>csantosb: i could try, but remind me later because I'm leaving in a few minutes <NegateThis>I'll take a look at wlgreet.toml. The config for the service I'm creating has a limited set of options anyways <ekaitz>csantosb: but openfpgaloader depends on libftdi <ekaitz>csantosb: maybe you were missing some udev rule that your package manager set up for you <ekaitz>now I think about it, I don't have any device for testing this... lol <kestrelwx>efraim: Would we rather load our `libvulkan.so.1` before the one at the default search paths? Like on a guest system it would load theirs, and we can't guarantee it's appropriate version, but ours always is. <nutcase>I'd like to start a guix system vm from my local source tree. How do I specify additional channels with pre-inst-env and/or guix system? ~/.config/guix/channels.scm is ignored. <csantosb>ekaitz: This is it: I don't understand why I do need to install it explicitely, it is already there <kestrelwx>Maybe it shouldn't look at the default paths at all, but I don't know if that's normally done. <Rutherther>nutcase: only guix pull works with ~/.config/guix/channels.scm, nothing else in guix does... but as to answer your question, either pull/time-machine with guix url as local checkout (after committing it) or by adding the channels you want to load path with -L arguments. <efraim>kestrelwx: looking at the failure modes, adding vulkan-loader to the environment didn't fix the problem with trying to find libvulkan.so.1, so I don't imagine having /usr/lib/libvulkan.so.1 would suddenly make it work, based on how Guix has the programs searching different locations for the library <nutcase>Rutherther: that means, I need to have the sources of the additional channels on my local drive as well, right? <efraim>oh no! I added it to the front of the list, not the end <kestrelwx>efraim: We could submit it as a CMake option then to Qt? <nutcase>Rutherther: packages from the extra channels are still not found with "./pre-inst-env guix system vm -L ~/git/channel-source-tree/" . Did I misunderstand your second suggestion or what am I doing wrong? <Rutherther>nutcase: what is the contents of the .guix-channel file in the channel? - are you sure it isn't using a subdirectory for the modules? <nutcase>Rutherther: the .guix-channel file of the extra channel contains "(channel (version ..) (news-file ..) (url))" only, nothing else <nutcase>no "(directory)" if you are asking for that <futurile>apteryx: practically, how do you want me to put forward mastodon posts for review? I could create a directory/file in the artwork repo and do PR's against that? Or I could create an Issue in the artwork repo and then assign it to you (?) for review. The second sounds less optimal - but adding a text file to artwork with "guix-toots" is also a bit odd <futurile>apteryx: I guess that a separate dir "mastodon/" and then "xxx-toots.md" will be the best option <futurile>the problem that creates is then you have to be a committer to take part in mastodon, which I had hoped to avoid - as it feels like it's something trusted community members who are not developers could get involved in <futurile>csantosb: you're not a committer right? (yet?) <kestrelwx>efraim: Could you also try `MESA_LOADER_DRIVER_OVERRIDE=zink qutebrowser --temp-basedir` <Rutherther>nutcase: then I do not know what would be wrong as long as you pointed the -L to the channels one -L per each channel <nutcase>Rutherther: I pointed to the channel's root directory. The scm files with actual package definitions are in a subdirectory, following the pattern of the modules declaration (like "gnu packages foo") <tesseract>do guix software on foreign distro provide additional security?_ <pinoaffe>tesseract: short answer: no, long answer: that really depends on your trust and threat model <ekaitz>csantosb: I do you know what udev rules are? <pinoaffe>tesseract: it does provide reproducibility <csantosb>ekaitz: if I know what udev rules are ? sure, but this is not the problem <csantosb>It works like a charm once I install libftdi (with Arch's pacman) <ekaitz>csantosb: it might be related somehow? I was just guessing! but packages in other distros have hooks that manipulate udev rules. <ekaitz>maybe in our libftdi or something that's not ready <ekaitz>and it doesn't work because of that <ekaitz>I'm just guessing! but I have had this issue in the past <csantosb>Good point: when one installs `openfpgaloader` with arch, the udev rules are installed along with it <ekaitz>maybe it's just we are missing them <csantosb>Unfourtunately, this is not the case with `libftdi` <ekaitz>our libftdi does not install the udev rules as far as I saw in the package <ekaitz>try to add a phase for that, and try again <csantosb>Here we go: libftdi1-1.5/packages/99-libftdi.rules <ekaitz>there are packages you can see as examples of this <ekaitz>csantosb: my first thought was that when you installed the lib from pacman that installed the rules that enabled the thing to work <ekaitz>because libftdi wasn't missing in the inputs of the package <apteryx>is there a way to do recursive containers with Guix, or the Linux kernel in general? <apteryx>$ guix shell -C guix -- guix shell -C bash -> guix shell: error: mkdir: Read-only file system: "/var" <apteryx>It also didn't work in 'guix system container' using guix-service-type <apteryx>kestrelwx: isn't namespaces what all Linux containers use as their fabric? <apteryx>at least that's what Guix does, and I reckon Docker & cie <apteryx>it boils down to a clone system call with some flags that specify which namespaces to isolate from the host <apteryx>inside a bare-bones.scm 'guix system container': guix shell hello -- hello -> error: remounting /gnu/store writable: Operation not permitted <apteryx>/gnu/store is a read-only bind mount in the container, I think <kestrelwx>apteryx: `$ guix shell -CW -- guix shell -CW -- guix shell -CW hello -- hello` -> Hello, world! <apteryx>fun, never heard about that option -W, --nesting <apteryx>kestrelwx: maybe this option could be added to the 'guix container' script <kestrelwx>$ guix shell -C --writable-root guix -- guix shell hello -- hello -> guix shell: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory <ekaitz>csantosb: it works? i just saw the PR <apteryx>yes, you'd need an actual deamon running to talk to in the container, which 'guix system container gnu/system/examples/bare-bones.scm' does for example <apteryx>ah, perhaps using it with --share=/gnu/store could do it <ekaitz>csantosb: but do you actually need to configure udev-rules in your system? isn't enough with adding the user to dialout group or whatever that is? <ekaitz>i'm comparing with `guix show light` and yep, i have the udev-rules service installed, too <csantosb>Problem is I'm not using a native Guix install, but a foreign one on top of Arch, so I cannot test <csantosb>I just copied-pasted from openfpgaloader <csantosb>I copy by hand the rules find to the right place, and I observe that I don't need anymore libftdi from Arch <apteryx>kestrelwx: hm, now I get error: remounting /gnu/store writable: Operation not permitted <ekaitz>csantosb: ok, i'll try to review it in detail but I can't promise <apteryx>same as earlier actually, as if --share=/gnu/store didn't do anything <ekaitz>csantosb: let me btw copy paste something: > csantosb | ekaitz: if I know what udev rules are ? sure, but this is not the problem <csantosb>Ah ! Good catch ! I was thinking on the udev rules we install with openfpgaloader, these doesn't fix the issue <csantosb>Unrelated: trying to reduce closure size in nextpnr by removing all qtWhatever and using cmake-build-system instead <csantosb>If someone has ideas on how to go down any further, I'll be happy to learn something new <csantosb>Sorry, forgot to mention, I get rid of the GUI, I only keep the cli <apteryx>instead of getting rid of it, you could move it to a "gui" output <apteryx>then the users of the main "out" output don't need to download all of the qt dependencies <apteryx>unless *cough* some grafts apply to the package <csantosb>I already removed all qt stuff to get the 3.4 GB version, built with the --no-grafts flag <apteryx>you can compare the closure of libjami:daemon vs libjami to get an idea of the potential gains :-) (with guix size) <kestrelwx>apteryx: Well launching guix-daemon in the container and then connecting to it it does write to the store. kestrel@themis ~ [env]$ cat "/gnu/store/b1kyy3z6lrmkp0hrjlpw1mbjvy58pjyi-spooky-plain-file"-> Boo! <kestrelwx>Hello was pulling too many dependencies in just `-CN guix`. <csantosb>apteryx: `guix size libjami:out` gives 1.3 GB; `guix size libjami:bin` gives 1.3 GB and `guix size libjami:debug` gives 1.4 GB <apteryx>ah, then my memory is outdated. must be the new dbus library is much smaller than the previous one <apteryx>so that's no longer a good example :-) <csantosb>Nevermind, I got it, who put all of those bba files in there ? <apteryx>kestrelwx: that's a nice find! For my use case (offering a sandbox environment for shared troubleshooting with the SSH exposed over the internet), 'guix system container' would be more handy though, because it can run services like SSH in it. <apteryx>kestrelwx: I've seldom used 'guix system container', still discovering it <apteryx>I guess we could mimick what --nesting does for 'guix shell' by using the --share option to share /var/guix, /gnu/store, etc. <kestrelwx>nutcase: Are you sure it requires setuid, btw? <nutcase>kestrelwx: I'm not setting setuid, do I? <kestrelwx>nutcase: I just remembered the conversation from a week ago. <nutcase>kestrelwx: I tried in a VM and espanso does not work without this capability and the operating-system modification makes it work. <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, apteryx says: can we get rid of most of the version-* branches, perhaps keeping only the last release (I think that's used by the website?). Rationale: it clutters the view, and we have tags for them. <civodul>apteryx: the branches have a few commits beyond the corresponding tags that exist nowhere else <apteryx>civodul: wouldn't we want these commits merged back to master? <apteryx>otherwise, what are these old branches or the commits on them useful for at this point? <apteryx>civodul: do you think it's achievable to have 'guix' fully working, including 'guix shell -C' inside a 'guix system container' containerized system? <apteryx>currently the guix-daemon fails remounting /gnu/store writable <apteryx>if I could make this work, I could share my unshare-crash-repo environment to you, robin or anyone wanting to take a peek. <apteryx>I tried in a VM but the latency introduces causes the issue to vanish (as does strace, rr, gdb, etc. <apteryx>I'm hoping in a container made accessible via SSH it could reproduce <apteryx>hm, I don't think that can work, because we've already unshared stuff and lost capabilities in the containerized system, so the daemon can't run as root. Perhaps the unprivileged daemon could cope better here. <nutcase>kestrelwx: I tried and it does not work with xorg: "This version of espanso was compiled to support wayland-based systems, but it seems you are on a X11-based desktop environment" <nutcase>kestrelwx: so I need to define two packages, one for xorg (no suffix) and one for wayland (suffix "-wayland")? <apteryx>hm, now the guix-ownership one-shot fails with a familiar: mount "/gnu/store" on "/gnu/store": Operation not permitted <kestrelwx>We could have a service for it that extends `privileged-program-service-type'. <Deltafire>is it not possible to build a package that supports both xorg and xwayland? <Deltafire>maybe espanso-x11 (or -xorg) so it's obvious it's xorg specific <kestrelwx>I see packages named like that - no suffix and `-wayland`. <Deltafire>there's an 'icedove' and 'icedove-wayland', but the 'icedove' package also works on wayland, it's not xorg specific <Deltafire>whereas 'espanso' without the suffix will only work on xorg <nutcase>Deltafire: NOW icedove works on both, but isn't the reason for why there are two packages that icedove didn't work on wayland in the past? <Deltafire>autohotkey is one of the things i miss from Windows, looks like this might be useful :) <klm`>for next time, what's a better way to debug early boot like this? I was dropped to a guile repl but the keyboard didn't work.n`n`n <civodul>apteryx: the old ‘version-*’ branches are history, dunno; but the release team could decide what to do with the next one <civodul>making that work would be sweet, but there’s no clear way <futurile>9th October 17:00 UTC / 18:00 UK / 19:00 France / 20:00 Jerusalem <futurile>yeah sorry about late notice - we're going to try and do them weekly - and I'll be better at emailing guix-devel <Rutherther>hm, isn't 17 UTC an hour and 25 minutes from now? <futurile>oh no have I got time conversions wrong again <futurile>actually the time conversion is right - it's just that I'm looking at the clock on my PC and it's in London time not UTC duh <characteristic>instead of using a calendar, just look for rise in time conversion mistake amount: summer time switch <postroutine>Did someone have example(s) of packaging web app for Guix and developing system service type for Guix System to setup and run the web app ? <postroutine>I dev web apps in Python/Django for many years. I have known the old virtualenv, Docker then Podman. And I wonder what would be the Guix way. <postroutine>With a goal to package Peertube and write a system service type for Guix System that let config and run Peertube in different ways. <ieure>postroutine, Maybe have a look through gnu/services or (guix)Services in the manual. cuirass-service-type has a web UI service, but I'm not sure it's the best starting point for you. <ieure>postroutine, I don't know of any production-grade web application services in Guix (this doesn't mean none exist). Thinking of stuff like running the service behind a reverse proxy, that sort of thing. Doable, I just don't know if/where it's been done before. <ieure>You can also use oci-service-type to run containerized stuff, if you like. <ieure>Handy for things that are difficult to bootstrap. <postroutine>For the services, I was thinking of creating 2 types: <postroutine>- `peertube-service-type`: Configure and run only the peertube process(es), letting the user integrate it in its already existing infra (database, reverse proxy, etc) <postroutine>- `peertupe-fullstack-service-type`: Configure and run everything needed, from peertube process(es) to database and reverse proxy, by extending the service types of each componant (peertupe, database, reverse-proxy, certbot, etc) <postroutine>My main concern is about the packaging of JS things for Guix. <ieure>postroutine, You don't need two service-types for that, you can do it with one and a configuration record. <ieure>postroutine, Okay, maybe I'm wrong about that. <postroutine>But can I make a service type that conditionally extend some service only when needed ? Or do you have another way of doing it ? <ieure>Yeah, I am definitely wrong about that. <ieure>You could maybe do something silly like have a function which returns the correct service-type based on your configuration. <postroutine>The advantage of having 2 service: The minimal one can be extended by the fullstack one, and re-use the config structure too. <postroutine>And the extension of the other services (database, reverse proxy) can be generated from the Peertube config and some default other settings. <postroutine>As the user set the domain name of the Peertube instance in the `peertube-config` structure, in the `peertube-fullstack-service-type` I can use it to configure the extension of `nginx-service-type`. <ieure>You might want to change those to peertube-service-type (fullstack) and peertube-minimal-service-type (peertube service only). <postroutine>If I understand correctly, the `guix import npm-binary` will only define a Guix package that will use the binary version of the javascript package ? <ieure>jlicht, Done, want to double-check? <jlicht>postroutine: binary in the sense that it won't be built from sources, and may in addition contain random binaries pulled from the Internet indeed <jlicht>ieure: should be fine, will see it work soon enough. Thanks! <postroutine>If I package a software that use `npm`, do I will also need to package every dependencies as a Guix package, or do the `node-build-system` will embedded them in the software package ? <ieure>postroutine, I believe you have to package them. `guix import --recursive' will give you package definitions for any dependencies `guix import' can't find, but that's a starting point, not the end. <jlicht>postroutine: you would need a guix package for each dependency <jlicht>sorry, didn't see ieure beat me to the punch <char>If someone has time, could they kindly help me debug my fork: <jlicht>postroutine: I've used the npm-binary importer recursively for a bunch of packages I use every day; the packages are just not upstreamable into guix due to the binary-ness of it all :-) <char>I would be grateful for any debugging tips too. If only I could see the arguments to "symlink" <ieure>char, Yeah, log is pretty frustrating. I'd recommend building with -K and comparing the source and destinations. <char>that befuddles me even more. looking at the failed build directory, it looks like all the source files are there. <ieure>char, Yeah. Maybe you can run the copy-source phase by hand in a Guix REPL to reproduce the problem? <char>ieure: Ill give that a go. I also dont understand why (debug-set! width 10000) didnt help me out. <mra>howdy! how've you been? <ieure>char, Yeah, not sure. Maybe ask #guile? <ieure>mra, Alright, summer busy with a bunch of stuff, now moving into fall/winter business... volunteering for a retro video gaming show most of next week, then holidays/ <mra>ooh, retro video gaming show sounds fun! <ieure>It is! I've been involved with it a long time now, since 2012 I think. <ieure>Started by loaning out some of my arcade games, now I help organize that part of the show. <mra>is it all arcade stuff, or retro consoles too? <ieure>Both! Plus computers, as well as kitch of various vintages. <char>ieure: where can I read about how to run phases in the repl? <ieure>char, Nowhere. I'm saying, look at what the copy-sources phase does, then do that in the repl. Probably have to copy/paste and hack a bit. <mra>ieure: lol, you guys got charles martinet as a guest? that's fun <mra>assuming i'm looking at the right event <ieure>mra, Last year, we had Eugene Jarvis and Nolan Bushnell, as well as Jeff Minter and most of the rest of the Tempest 2000 project team. <mra>hmm, i should get my irc bouncer set back up. server went down a while ago, and going without a bouncer has been annoying <ieure>mra, I got Nolan to autograph my Computer Space. And my Asteroids cabinet has an autograph from Ed Logg from a previous show he came to. <mra>ieure: i hate to admit to being young enough that i had to look up Tempest 2000, but that's super cool! <mra>the nolan bushnell autograph is pretty awesome :O <hugohugo>char: no idea what I'm talking about, but the directory structure between asdf-cli 0.1.1 and 0.2.1 seems very different. The old one seems to make more sense <hugohugo>old: /gnu/store/p3na96zwxqh5294cqhjsf2bpsd4p57sn-asdf-cli-0.1.1/share/common-lisp/sbcl/asdf-cli/ <ieure>mra, It's a good game. There was an updated version released some years back, Tempest 4000. <hugohugo>char: Oh now it doesn't matter much, I indeed don't know what I'm talking about :) <hugohugo>Tempest 4000 is definitely a different game from the brogue I know :) <mra>ieure: i've been meaning to set up one of those mister fpga systems <mra>during my bachelor's degree i managed to get my hands on a crt tv. carried the thing two kilometres across campus, set it up in my dorm room, hooked up a raspberry pi, and played earthbound lol <hugohugo>I should just shut up I think :) tomorrow another day <ieure>mra, Definitely a harder hobby to get into these days than when I started, much less stuff available and what's out there is more expensive. But I like my collection of all real vintage games with no emulation or LCDs. <ieure>MiSTeR is a good option if you're starting out now. <mra>yeah, i don't exactly care to spend actual retro console money, as cool as they are <ieure>Yeah, I have opportunistically hoarded where possible. <ieure>I have tons and tons of CRT TVs and monitors in storage. Honestly no idea how many. 75-100? Something like that. <mra>my god. do they go for anything much? i just found mine collecting dust in a storage room <ieure>mra, Gonna PM you since this is offtopic and getting lengthy. :) <FuncProgLinux>is it a bad practice not to ship static libraries built with libtool? <FuncProgLinux>I have compiled caja-actions but It doesn't work unless you build with --disable-static <anemofilia>I have been dealing with this for a couple months and now remembered to ask <anemofilia>Do someone here is dealing with spawn-shell-command (from shepherd) failing to be non-blocking? <anemofilia>I made a shepherd timer whose action is simply a thunk with (spawn-shell-command "mpv dir") <anemofilia>But it actually blocks the whole shepherd service, herd status won't return anything until mpv is killed <anemofilia>(I do know that in this case I commented I could simply use a (command ...) action, but my action is a little more complex than I said, not relevant to the spawn-shell-command blocking thing) <lilyp>you might want to use fork+exec-command for whatever you're trying to achieve <nutcase>Deltafire: I think "autokey" is something that you could also use with xorg. <Deltafire>i looked into that.. however i'm using Wayland <anemofilia>lilyp: That's reasonable, but still, spawn-shell-command is a simple procedure that calls spawn-command, which is implemented using fork+exec-command, and spawn-shell-command docstring says explictely it should be non-blocking <nutcase>Deltafire: me too, you also set it as a privileged program? <nutcase>Deltafire: I didn't use espanso before. It doesn't feel as smooth as I expected :D <Deltafire>since i'm testing it in guix shell i just copied the binary and used sudo setcap on it <Deltafire>was a bit surprised when i discoverd i'd already made some triggers for it in the distant past <Deltafire>yasnippets is only emacs though? i want something that works with thunderbird/libreoffice <nutcase>Deltafire: yes, yasnippets is emacs only (maybe we're getting too off-topic now?) <char>I did some print debugging and found what the problem is. asdf-cli has two files called system.asd as part of templates. those should never be loaded. asdf-build system copies (or symlinks?) all .asd files to one folder. the names conflict. <char>untrusem: do you get the error when building outside of guix build? <untrusem>yep, when I extended the dbus service to add waydroid to list, the python-gbinder failed to build failing waydroid along with it <char>if it fails outside of guix build, then it sounds more like a python problem than a guix problem no? <untrusem>tried building with pip to in a python venv, yet it doesn't build