IRC channel logs
2026-04-05.log
back to list of logs
<gnufairy>I noticed that the latest release of qutebrowser used the qtwebengine dependency. Was a fully libre solution found to this ? I though it was based on chromioum? <quassel-guy>Hello, can somebody help me make distrobox work properly <oreo639>noe: Hello, thank you for the work on gnome-session-shepherd. I'm currently working on GNOME 50 for Void Linux and I was able to login and logout with your implementation, however I noticed that the DBus API implementation is currently incomplete (it also changed between GNOME 49 and 50). I'm wondering if there is interest in using the upstream gnome-session for the DBus api with gnome-session-init-worker and gnome-session-ctl provided by gnome-session- <quassel-guy>when I try to enter into distrobox, I get this error: `Error response from daemon: path /sys is mounted on /sys but it is not a shared or slave mount`, any idea on how to solve this <tusharhero>Hello, can someone help me try out Guix system with Hurd? <tusharhero>Okay, it seems there is a simple "hurd-vm" service I can use. <YAR_Oracool>alright... now I have to figure out how to define substitutes in an external file and then imort them. Wile is there, module is understood but no luck on using in my config <YAR_Oracool>also if anyone can help me with joining non guix channel let me kknow because I can not send messeges there for some reason. I can read them but my messeges evaperate into the eather. <chris0ax>So a few days back i noticed the skribilo package builds .el files when you build it in guix. So i was wondering how to maybe make a "emacs" output for the package with just these .el files. I was able to make a package variant with this output, but i noticed thats not enough to get emacs to find the package, it needs to be in the load path, i was wondering if its valid to add some build phases from emacs build system to run for the <chris0ax>"emacs" output only or is there some other way to do this <identity>has anyone had any luck making darkman work with Emacs (pgtk) under niri? seemingly no matter what i do, org.freedesktop.portal.Settings does not want to show up in (dbus-list-names :session), and ‘toolkit-theme’ added in Emacs 31 stays on ‘light’. FTR, it works on GNOME. i tried putting org.freedesktop.impl.portal.Settings=darkman; in ‹~/.config/xdg-desktop-portal/niri-portals.conf›, still nothing. <identity>‹~/.guix-home/profile/share/xdg-desktop-portal/portals/darkman.portal› is present and looks fine to me <identity>chris0ax: not familiar with skribilo, but does that really need to be a separate output? <Rutherther>chris0ax: el files go under 'share/emacs/site-lisp'. Then as long as emacs is installed in the same profile you installed the package to, it's put to its load path. <trev>identity: how are you launching niri? <trev>I think the niri service is missing stuff, so i use `exec dbus-run-session niri --session' <Rutherther>users who use guix-home already do have dbus session so there is no point in running a nested one, it can even cause issues <trev>i was having issues without it heh <trev>i use guix home but niri is in my system config <identity>trev: with the (newly updated to not launch dbus-run-session) home service. it did not run either way <identity>err, work either way, it being darkman with Emacs <chris0ax>identity: you mean like, its probably better to make it a separate emacs package? id have tried that but they seem to do something with a makefile for one of the .el files so i thought its better to just work with the current packages build <Rutherther>identity: what's your XDG_CURRENT_DESKTOP set to and did you import it to dbus? If you start xdg-desktop-portal with -rv, what's the output? <identity>Rutherther: XDG_C_D is niri, and i am not sure how i am supposed to start xdg-desktop-portal with -rv, it does not look like it is in my PATH <Rutherther>identity: ~/.guix-home/profile/libexec/xdg-desktop-portal -rv <identity>Rutherther: it says, among other things, «Using darkman.portal for org.freedesktop.impl.portal.Settings (config)» <identity>not sure why Emacs is not picking that up <Rutherther>identity: right and now, did it start working by chance? <identity>i guess Emacs is the issue here, LibreWolf toggles the theme just fine when i run «Toggle darkman» <chris0ax>Rutherther: i just spent a few minutes checking to realize that XD. It works! Initially i did try putting skribilo and emacs in the same profile and seeing with 'M-x' if the modes were showing up but i forgot to require them that time <chris0ax>identity: honestly i thought itd be a good chance to see how packages with multiple outputs work, since this sounds like a case where it makes sense and after the initial first check i thought maybe theres some build phase in emacs thats causing the package to not load but i was wrong <Rutherther>so as a standalone instance, not a server then I understand. And have you tried starting it from a terminal as well? <chris0ax>still learnt something nice, the package with multiple outputs section doesnt talk about defining a package with it but it was easier than i thought <r-oracoolya>and it even tells me why I can't send a messege instead of nothing in thunderbird! Making progress <identity>Rutherther: just tried that, had to install a terminal, still does not work <Rutherther>identity: is (getenv "DBUS_SESSION_BUS_ADDRESS") giving you unix:path=/run/user/1000/bus? <Rutherther>and you aren't using anything like dbus-run-session yourself, right? <identity>i can see "org.freedesktop.impl.portal.desktop.darkman" and "nl.whynothugo.darkman" in (dbus-list-names :session), but not org.freedesktop.portal.Settings, and, again, LibreWolf toggles theme with darkman just fine, so this is probably an Emacs issue, but i have no idea what GTK3 uses to check for the theme to use <Rutherther>hm why do you expect the settings in dbus-list-names, though? doesn't it show only the service itself, being org.freedesktop.portal.Desktop, not its available interfaces? <identity>i am not really familiar with dbus, so i am not sure what to expect. there is "org.freedesktop.portal.Desktop" <identity>so i dug around in Emacs' C source, and it looks like it gets the theme from (the equivalent of) ‹gsettings get org.gnome.desktop.interface color-scheme›, and when i run that i get «No such schema “org.gnome.desktop.interface”» <trev>for the record, i have that (on niri too). it's set to 'prefer-dark' <trev>i once had this system on gnome, so i wonder if that is how it was added <identity>i figured out how to fix the problem, i had to add the gsettings-desktop-schemas package to my profile. i wish less problems could be fixed by installing a magical package you have no idea about <quassel-guy>nckx: thanks, I will ask here for probably a day more then report the issue <nckx>quassel-guy: Distrobox seems to want quite a bit of state to run so if you could provide the minimal number of steps to reproduce the issue it would be nice. <nckx>I.e. I have never used distrobox and have no vms configured, how can I get your error with the least effort/hunting for ISOs/random configuration files. <Rutherther>quassel-guy: are you using either rootless podman service or docker service? <Rutherther>I can't test right now, but I think you need to build distrobox with podman to use it with podman, ie. "guix shell distrobos --with-input=docker=podman" <ekaitz>i see myself asking about this over and over again, but does anyone have a proper way to set a system dark-light theme that works with gtk apps when not using gnome? <ekaitz>i've tried gsettings, setting a env variable with the theme to adwaita:dark and so on <ekaitz>i'll take a deep look into it later and probably ask more questions :) <ekaitz>Rutherther: but before anything else, do your apps recognize that you have the a system level "dark/light theme" config? <Rutherther>ekaitz: I haven't looked into dark/light themes yet, but it should be a matter of adding gtk-application-prefer-dark-theme true/false to the settings.ini <ekaitz>manually writing the config to settings.ini didn't work for me last time I tried <Rutherther>what gtk version apps are you using and where did you put the config? <Rutherther>gtk4 apps tend to ignore it sometimes when there is already dconf set up <ekaitz>dino, gajim... all of them ignore it <ekaitz>and where does dconf do things? how can I reset it so they read from the file instead? <Rutherther>I don't think it's worth it to fight them on that, just set the dconf options <zynx>hi looking to migrate a machine from alpine to guix and was wondering if there's a way to declare a vlan aware bridge? doesn't seem possible from the docs though <zynx>for reference my /etc/network/interfaces looks like this: auto br1 \n iface br1 inet manual \n bridge-ports none \n bridge-vlan-aware yes <zynx>then i create the vlans with auto br1.10 \n iface br1.10 inet manual \n vlan-raw-device br1 and auto vlan10 \n iface vlan10 inet manual \n bridge-ports br1.10 <Rutherther>zynx: what are you planning to use for network, probably networkmanager? <zynx>Rutherther: not sure tbh, just going through the docs at the moment without playing with guix (intend to do it in a vm first). is that what's recommended? also to add to the above as it might be relevant that vlan aware bridge is plugged into libvirtd <nutcase>ekaitz: I think, I managed to have dark/light mode running on sway, i.e. without gnome. gsettings is my friend to set gtk-theme, icon-theme and color-scheme. What is your specific problem? <ekaitz>nutcase: hey! first of all, i don't know where gsettings is <nutcase>ekaitz you mean, where it stores its values? <ekaitz>nutcase: I also tried with dconf directly, and I didn't manage to set it properly <ekaitz>I have org.gnome.desktop.interface set to prefer-dark <Rutherther>that will not work with gtk4's handling of dconf, you need to set color-scheme to 'prefer-dark' <nutcase>gsettings get org.gnome.desktop.interface gtk-theme ? <nutcase>I additionally set `org.gnome.desktop.interface gtk-theme to 'Orchis-Dark' and org.gnome.desktop.interface icon-theme to 'Papirus-Dark' (or without '-Dark' for light mode). <ekaitz>nutcase: that gives Adwaita:Dark <Rutherther>I don't think Adwaita:dark is the theme name. It's just Adwaita <nutcase>emacs auto-dark-mode follows the color-scheme <nutcase>is it Adwaita:dark or Adwaita-dark or Adwaita-Dark ? I think case matters <ekaitz>in my case the theme says Adwaita:Dark <nutcase>where do you check, if a theme is applied <Rutherther>but that's not really what Adwaita:dark stands for when you put it to GTK_THEME env var, it's choosing a variant of a theme called Adwaita. But when you use dconf, you're setting just the theme name and then the color-scheme separately <ekaitz>but that shouldn't matter, gtk apps don't recognize if the "color-scheme" is dark or not <Rutherther>hence gtk-theme should be set to Adwaita and color-scheme to prefer-dark <ekaitz>Rutherther: done that, still the same <ekaitz>do I need to restart the computer or something? <Rutherther>and you're getting light variant of Adwaita now? <ekaitz>i just get white themes, i don't know which theme they are really <ekaitz>(from my eye, i think it's adwaita) <ekaitz>my home config has it in `packages` <nutcase>here, not all apps switch to dark with gtk-theme set to 'Orchis' and color-scheme set to 'prefer-dark'. That's why I explicitly switch the gtk-theme. Furhtermore, I dont' have $GTK_THEME set, because I didn't find a way to overwrite that dynamically in a sway session. <ekaitz>nutcase: but some apps like gajim do have some configuration option to know if you have dark or light preference in your config <nutcase>ekaitz: yes, some apps need special care. Did you manage to switch any app by (g-)setting color-scheme + gtk-theme? Here, even web pages switch their color-scheme dynamically. <ekaitz>i have: gsettings set org.gnome.desktop.interface gtk-theme Adwaita <ekaitz>and: gsettings set org.gnome.desktop.interface color-scheme 'prefer-dark' <ekaitz>and libreoffice is white when I don't set GTK_THEME to Adwaita:dark <Rutherther>that is the correct way for apps that do support color-scheme. It is possible that the apps you use do not, and then you would have to use Adwaita-dark gtk-theme name. Or they're not GTK4 to start with and then these dconf settings do not apply at all <Rutherther>but if you change the gtk-theme to Adwaita-dark then you lose the possiblity to override to light theme I think <ekaitz>setting the theme to Adwaita-dark doesn't change anything <Rutherther>then I would be suspicious that they're not GTK4 to start with. Did you check that? <Rutherther>if they're GTK3, then they use a simple config file, not dconf <ekaitz>my gtk3 apps use GTK_THEME and work well, I also have the .config/gtk-3.0 set <ekaitz>wait a minute! now this looks different! <nutcase>I not also got rid of GTK_THEME env var, but also from settings in .config/gtk-3.0 . I don't understand what uses what, but it seems that everything works as expected. <ekaitz>i'll remove that var because I think since I unset it things changed <ekaitz>things like dino worked well until 4.11 <ekaitz>ACTION is afk but will come back soon <ekaitz>nutcase: as you say, .config/gtk-3.0 doesn't do anything <ekaitz>in summary, if anything was "working" before was because I had GTK_THEME=Adwaita:dark <nutcase>ekaitz: just to be sure, you have a dbus user session running, right? <Air4x>Hi everyone, I'm trying to use EDOpro, I donwloaded the release from github and already patched the ELF interpreter with patchelf, but the program doesn't work anyway because it tries to load libx11 at runtime with dlopen() (or at least I think is dlopen as the strace output says openat). Is there a way to patch? the binary to make it point to the right directory for libx11? <trev>how do you get ./pre-inst-env to stop doing the "source file newer than compiled" every single time you want to build something? <Rutherther>which is what you definitely should do for majority of the files in the first place, otherwise it would take eternity for each pre-inst-env call. And as for the few ones you're editing, do you really care about these messages? <ekaitz>nutcase: i think so, how could it be not running? <trev>Rutherther: i don't care about the messages, but i don't like the long build times each time i iterate on a package <trev>why isn't it building them once and then the next time not building them? <Rutherther>trev: right, then build the files - "make -j$(nproc) make-go" <Rutherther>trev: because they got updated, ie. you changed a branch, pulled and so on. As long as the files are the same version and compiled, you won't be getting those messages <Rutherther>or did you mean why pre-inst-env doesn't output the go files to filesystem? I am not sure that's possible with guile, to tell it to store the compiled files. Not even sure it actually creates the go format when you execute guile <trev>Rutherther: i definitely changed nothing but the package i'm working on. it's just all the guile files pretty much <yarl>trev: pre-inst-env runs scripts/guix which runs guile with --no-auto-compile. (Is it a relevant comment) <Rutherther>trev: are you saying you ran make to get the go files, then did nothing, ie. no git pull, no git checkout, changed one file and you're getting this? <nutcase>ekaitz if one doesn't use guix home, there is chance of not having dbus user session <Rutherther>nutcase: even with guix home, the dbus service is not a default service <trev>Rutherther: i'm running ./pre-inst-env guix build [package] <bjc>Rutherther: it isn't? on both gnome and plasma, user dbus starts automatically for me <Rutherther>trev: right, so what's unclear then? I've already answered that case <yarl>trev: Did you do what's in "(guix)Building from Git"? <yarl>If there's pre-inst-env then at least you ran ./bootstrap and ./configure <yarl>But how old is your last make? <trev>yarl: probably super old <yarl>Every time you you change files, manually or by pulling, checkouting, every file depending on these should be built again. Of course, if you are doing changes to a couple of scm files, no problem, running ./pre-inst-env something will run by interpreting (those changed files). <yarl>But this use should probably be reserved to "a couple of scm files for an ogoing hack" <yarl>I deliberately insisted on *scm* because if there's changes on Makefile, configure.ac, local.mk, file.in, C files, etc, then pre-inst-env won't take this into account I think. <yarl>I mean script/guix under pre-inst-env <yarl>But I'm far from mastering this. <yarl>And not completely awake. <trev>thanks yarl. doing a make again and seeing if builds are quicker <mwette>Is it correct for `guix package --list-profiles' to return both `~/.guix-profile' and `~/.config/guix/current' ? <Rutherther>mwette: yes, it lists all your user's gc rooted profiles <trev>thanks Rutherther and yarl. that resolved it. fast builds now <zynx>Rutherther: do you have any clue to the vlan aware bridge issue?