IRC channel logs
2026-08-14.log
back to list of logs
<optimal>does anyone know of what a good solution for a game streaming server be on Guix? Sunshine is the go-to solution for most Linux distros but it doesn't seem to be packaged on Guix <ieure>optimal, Seems like Sunshine requires GPU stuff which isn't available on Guix due to needing nonfree blobs. Other than that, it seems tractable to package. <optimal>ieure: it would only require nonfree GPU stuff if the driver you're running is also nonfree, no? i'm sure any nvidia and CUDA-related dependencies are optional <optimal>the biggest hurdle looks like the web UI, which i believe uses NPM <ieure>optimal, I do not believe there are any GPUs with libre drivers, <ieure>At least, not ones that will do video encoding/decoding, like that program needs. <optimal>video encoding/decoding is part of VAAPI which is part of Mesa <ieure>optimal, The drivers are free, but they load non-free blobs. <ieure>optimal, Guix has a node-build-system, I've never used it, but "uses NPM" may not be as big a blocker as you think. <optimal>it seems the NPM packages situation on Guix has changed since i last took a look :D <JessicaXP>this might be a bit of a dumb question but i'm writing a package and i need the store path to an (inputs) package in the #:configure part of (arguments) is there any simple way of doing that? <cnx>there is this-package-input for that, thou if <cnx>the package's input is transformed it will be the old input i think <JessicaXP>second question what is the * for at the end of (lambda*) as opposed to (lambda) <optimal>JessicaXP: lambda* supports optional and keyword arguments, lambda doesn't <ruined>Hello. I've been trying to upgrade a foreign guix (1.5.0) install using 'guix pull --no-substitutes' ever since the vulnerabilities that were announced in July. So far, I've been unable to complete a pull without errors. I can make progress, but eventually one derivation or another fails. Should I just go ahead and pull with substitutes, despite the vulnerabilities, or maybe install a 'latest' image? <cnx>ruined, could you file an issue listing the failing derivations? <ruined>Eventually, this derivation built for me. <acrow>After failing in the same manner as you describe on a guix system installation, I've created a newer usb boot image on another machine and hope to be able to run a regular guix system reconfiguration from that which I don't think will require --no-substitutes. <ruined>I was thinking of doing something similar for my guix foreign install. The only reason I haven't done so is that there are no checksums or signatures for the latest images. <ruined>cnx: I've kept a record of the problem derivations and can create an issue once I get set up with a codeberg account <acrow>atm - this remains a work in progress.. I added a FAT32 partition to the bootable usb image containing my target's config.scm and some other useful data that I hoped I could use. Unfortunately after the usb boot I cannot mount the new FAT32 data partition.... I have not unwound how to add the new device into the overlay fs... :( <acrow>mount -t vfat /dev/sdb3 /mnt2 causes a usb disconnect -- It is not the way. <ieure>acrow, That sounds like hardware issues maybe? A plain mount like that should not cause a USB disconnect. <acrow>hmmm... It's an old machine.... yet the other partitions on that same usb stay in place... I don't know... <acrow>ieure: you've given me an idea, thanks! I'll give it a try later. Maybe that particular usb partition is at fault.... The light is better there. :) <jonsger>is someone interested in overtaking my Hetzner root Server. Currently used for nonguix.org, but only a few weeks. The server has this specs: AX41-NVMe (AMD Ryzen 5 3600 6-Core, 64GB RAM, 2x Samsung PM981a 512GB NVMe SSDs) and costs 44€/month without VAT. <folaht>How do install npm libraries like pyright? <untrusem>folaht: maybe they are packaged with the prefix with "node-" <gabber>i run into: "error: %substitutable-references-procedure: unbound variable" when `./pre-inst-env guix size hello" on my test server <gabber>stupid(?) question but does the build daemon need free slots to answer a `guix size hello` query? <qzdl>gabber: surely right, if it's building or substituting <kratacoa>any guix-science maintainers here? I'm failing to `guix pull`, and I think the hint to the culprit is `WARNING: (guix-science packages chemistry): `which' imported from both (guix build utils) and (gnu packages base)` <kratacoa>the error is `(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (root)) (value #f))` <trannus_aran>So I get this is a basic ass Unix question, but is it considered good or at least okay practice to source your .profile in your shellrc? Wondering in the case of guix cause literally everything else works fine, I just have to source .profile with interactive non-login shells to use guix installed stuff <kratacoa>I think the closest related module is hep.scm <kratacoa>trannus_aran: what do you mean? .profile is meant to be sourced by your shell <noxi>trannus_aran: my .zprofile sources /etc/profile and ~/.profile, but it's Guix Home that installed that <trannus_aran>I'm running a foreign distro with guix, so guix profile is sourced in .profile, which should be/is called by the login shell <trannus_aran>But in terminal emulators, the interactive bash sessions don't have any awareness of guix profile (presumably bc they're not sourcing .profile but only .bashrc) <iyzsong>trannus_aran: it should be sourced via .profile (or .bash_profile) not .bashrc, due to source it multiple times will lead to duplicated entries. you can setup terminal emulators to start a login shell with 'bash -l' as its command or make the parent session (login from tty then start via startx/xinit/sway works here) source it somehow. <trannus_aran>Guix profile source by .profile, not .bashrc? Because that *is* what I'm doing currently <trannus_aran>I guess, is there any issue with sourcing .profile (which itself sources the guix profile) in the bashrc? Provided you just ensure that .profile contains no callback to source .bashrc? <trannus_aran>AFAIK, .profile just contains env vars and needs to be posix sh compatible, but other than that, it's fine to source it THAT direction (from bashrc) <iyzsong>not much problems, just some duplicated entriens in env vars, eg: PATH will contains multiple times of ~/.guix-profile/bin <trannus_aran>Wait where would it get the extra one from if it's only sourced .profile? Or you mean just for the login shell? <folaht>I'm trying to put lsp-guile-server in my system config, but lsp-guile-server seems to be an old version, thus I'm getting package conflicts. <PotentialUser-68>Hello. Would this community have an official (or semi-official) server on Matrix or Discord? <yelninei_>mwette: the cmake is trying to fetch qoco which does not work as the build container has no networking. <stanrifkin>How do I find a package with a certain file in it? <mwette>yelninei_: thanks! I was figuring something like that. Is there a pattern to use source from the store. Or can I add networking (though seems potentially unreproduceable). <yelninei_>mwette: I am not super familiar with cmake. If qoco has a pkg-config or cmake-config file then you could replace the FetchContent with find_package/FindPkgConfig but this requires patching the CMakeLists.txt as it does not look like to be designed to get qoco from anywhere else other than fetching it itself <mwette>yelninei_: thanks; I'll play with that idea <stanrifkin>For example I can use `apt-file search Scrt1.o' and it shows me every package with that file in it. How can I do that with guix? <stanrifkin>fanquake: It seems it only searches in already installed packages. <user_oreloznog>stanrifkin: maybe someting like ~$ guix package --list-available <ampinga>hello everyone, I need help. I try to install Guix System i686 but the installer has issue: when it boot there's a problem related to "waiting for partition '31393730-...' to appear" taking a long time and it start a guile REPL. How to resolve it please? <sneek>Welcome back ampinga, you have 1 message! <sneek>ampinga, cnx says: check if there is a typo in the partition's uuid in /etc/config.scm <untrusem>stanrifkin: you could do a `find` in /gnu/store <untrusem>and if its a library module, "guix locate --help" <mwette>Is there a guix package providing md5sum ? <mwette>If pkg foo is an input to pkg bar, is there guile expression for the path for foo's tarball in the store? (package-source foo) gives me an `origin' object <PotentialUser-95>Is anyone here doing air-gapped Guix? I'm excited at the prospect of being able to stash a build closure and a development environment, carry it offline, and continue, but hitting some rough edges. Wondering if anyone knows some writeups or procedures for building and carrying Guix archives on USB drives to computers that shall never see the <mwette>Building a package generates the downloaded source as a store object (I think). Can that object be specificed as an output of the build, so I can use it as input in another package def'n? <ieure>mwette, The build output is always the result of the build, but origins can be used as inputs: (inputs (list (package-source other-package))) <ieure>mwette, You can also abuse things even more, by using the origin in a build step, ex: (copy-recursively (package-source other-package) "./other-package-source") <mwette>The cmake build process under python-build wants a git repo or url. I guess the build does have network access for that so I was going to try to reference the source tarball in the store. This is not as boring as gabber thought it would be. <mwette>I'm trying a substitute on the CMakeLists.txt to have cmake fetch from the store. <ieure>mwette, The build environment does not / can never have network access. <mwette>But I guess the package def'n needs to "grant" access to the tarball in the store explicitly. <ieure>mwette, The LibreWolf build something similar to what you want, but that stuff uses plain make. The build uses `substitute*' to edit the Makefile so the variable that points to the source tarball to point to the store. <ieure>mwette, Mmmm, kinda, not really. I believe any store item is reachable from the build, but practically, you cannot know the path for it unless you can compute the hash, and it makes no sense to replicate that when you can use a package or origin and have Guix do it for you. <ieure>mwette, What I mean is, you can probably stick a static store path in the build and I would expect it to work... but it will break reproducability. <mwette>I hardcoded it in (for now), but I still get "File not found: /gnu/store/..." <mwette>So I concluded that maybe the access to that store item needs to be specified somehow. <ieure>mwette, Not sure, I suppose the build might only expose things in the store which the package references. But if that's how it works, it does it for packages/origins referenced by the package, there's not some special mechanism to grant it. <mwette>worked using the origin as an input; makes sense <mwette>but I don't have the subsitute path working from `inputs' arg <ieure>mwette, Looks good, though could use a cleanup pass. I think the (use-modules) in 'patch-source is not needed. Also, if there's some way to make the build use a source directory instead of checking out, it will reduce the disk space used. The current setup duplicates the source, one clone of the repo in the store, and a checkout of it in the build dir. <ieure>mwette, Load up your package in the REPL and eval (package-inputs python-qoco) with the origin in the inputs, and it will show the key you need to assoc-ref out of them in the build step. <ieure>mwette, You used to be able to provide an alias in the inputs, but I think that facility is deprecated now. <mwette>I did that. The key was "qoso-0.3.2.tar.gz" <mwette>The "list form" did not work in inputs. <ieure>mwettef, I think you can do (native-inputs (list qoco)) and then (package-source (assoc-ref inputs "qoco")) <mwette>Maybe the string-append form needs to be G-unquoted? <ieure>Does qoco actually build anything on its own? Or is it only used as part of the python build? <mwette>The qoco package does build a (usable) library. <ieure>Okay, then yes, this is IMO how you should do it. <untrusem>dnscrypt finally updated and ported to go