IRC channel logs
2026-10-15.log
back to list of logs
<oliverD>I was just trying to compile gnome console (I installed gstreamer and gst-plugins-base) but i got the error: <oliverD>gtk| Dependency gstreamer-play-1.0 found: YES 1.28.8.1 (overridden) <oliverD>gtk| WARNING: Subproject 'gstreamer-full' did not override 'gstreamer-gl-1.0' dependency and no variable name specified <oliverD>gtk| Dependency gstreamer-gl-1.0 from subproject subprojects/gstreamer found: NO <oliverD>subprojects/gtk/meson.build:499:20: ERROR: Dependency 'gstreamer-gl-1.0' is required but not found. <Choosechee>Is it not possible to read files in the code of a manifest? I'm trying to use `load` to load and run another manifest file and concatenate more entries to the result. I can find the manifest, and `access?` says I can read it, but when I use `load`, it says no such file or directory. <guix-newbie>anyone using mango and steam that can tell me what the hell is going on when it comes to setting cursor theme? Do I have to do some magic that I am not familiar with? <guix-newbie>$XCURSOR_{PATH,THEME,SIZE} are all set properly and xrdb shows correct values <lechner>Choosechee: Are you using an absolute path? <lechner>Choosechee: No, but the error message indicates that Guile can't find your file. I have a similar problem in guix.scm files. I think relative paths are assumed to be relative to the build folder or something like that. You may even have to get your file into the store first with something like local-file. <Choosechee>Hmmm, I see. I'll try canonicalizing the path before I use it <Heterochromium>I'm trying to chroot into an existing Guix System installation from another Guix System installation, but chroot is failing to run `/bin/sh`: `chroot: failed to run command ‘/bin/sh’: No such file or directory`. <Heterochromium>I used to be able to easily chroot a few weeks ago. I don't know what changed since then. <Heterochromium>lechner: I unfortunately don't see anything useful on those pages. I also forgot to mention that `/bin/sh` does indeed exist on the installation, but chroot can't run it. Maybe it's a library issue? <lechner>No such file or directory is a pretty clear message. How can it exist? <Heterochromium>lechner: I might've found the answer. It looks like the `/bin/sh` symlink somehow got redirected to something outside the chroot, so when I try to chroot into the system, it of course cannot find the right binary. <flurando>finnally got everything work after updating system, in case anyone else want to setup Yubikey or other pam-u2f compatible keys for passwordless auth on linux, feel free to check my channel, there is a yubikey service that handles pam and etc. THe only drawback recently is it could not use openasuser kind of opitions, otherwise pam-u2f would fail when trying to restore privilege, causing all auth attempt to <flurando>I use the same nick on GitHub and with an additional rw- prefix on codeberg <switchy>ah, good to know that's what the issue was <flurando>switchy: yeah, it took me dozens of `guix system vm ...` to narrow down, and even more to fix, along with several `grep -r` in guix source repo looking for examples :) <flurando>The result is pleasant, though. Also, if anyone else here face a problem of emacs not responding to fcitx5, just install emacs-pgtk and remove the GTK_IM_MODULE env var, instead put gtk-im-module=fcitx inside .config/gtk-x.0/settings.ini <Heterochromium>Is it bad if the config file of the system under chroot surgery and the host both have the same name for an unlocked LUKS partition? <Heterochromium>The host is called `cryptroot`, and the chrooted system's config also says that the main partition is to be mapped as `/dev/mapper/cryptroot/`. <flurando>Heterochomium: But it is impossible to have two decryted partition mapped to the same name <flurando>So there must only one active, if it is the exact one partition, then why do you care which system <Heterochromium>flurando: I'm chrooting from a persistant installation. So, `/dev/mapper/cryptroot` is already occupied. The config file of the chroot system also declares its root as `/dev/mapper/cryptroot`. So I was wondering if that would cause any trouble. <Heterochromium>Come to think of it, it might be easier to just chroot from a live system rather than deal with complicated namings. <switchy>it would probably be fine? the root device would be used for mounting, but that doesn't happen in a chroot since it's already mounted...?