<MortimerHoughton>
novakane: you were right, seems to only work in GTK programs. It works pretty much everywhere in Sway, but I heard they've got a pretty hacky way of getting it to do so.
<plumeus>
I would like to try tbh, as I really like River and IME support is fairly important for me.
<MortimerHoughton>
I see. Same for me, I have been impressed with river, but do want to use an IME also
<plumeus>
I'm Japanese and I'm interested in software stenography, so that's 2 reasons for me.
Ordoviz has quit [Ping timeout: 246 seconds]
Szadek5818 has joined #river
Szadek581 has quit [Ping timeout: 260 seconds]
Szadek5818 is now known as Szadek581
Ordoviz has joined #river
Ordoviz has quit [Ping timeout: 252 seconds]
ayushnix has quit [Remote host closed the connection]
ayushnix has joined #river
ayushnix has quit [Changing host]
ayushnix has joined #river
leopoldek has joined #river
waleee has joined #river
Ordoviz has joined #river
<mvnx>
Anyone using River from nixpkgs-unstable? I can't get it to start. Looking at strace output it seems I'm missing a whole bunch of mesa, pixman, libxcb .so's.
Guest78 has joined #river
Guest78 has quit [Client Quit]
notzmv has joined #river
ayushnix has quit [Remote host closed the connection]
ayushnix has joined #river
ayushnix has quit [Changing host]
ayushnix has joined #river
<plumeus>
I'm using nixos-unstable but I'm compiling River from source...
<plumeus>
the only thing I changed is that I made it build a slightly newer commit
<plumeus>
Just because I wanted to play with the latest features; not because something was broken
<waleee>
mvnx: this is still with qemu I presume?
<mvnx>
Yes, still with QEMU ;/
<mvnx>
I feel I've made it a step closer by adding `-device virtio-gpu` as it seems to have surpassed my previous issue.
<waleee>
it clicked that this might be the issue when you wrote "mesa"
Ordoviz has quit [Ping timeout: 246 seconds]
<mvnx>
Thanks! I'm not seeing "unable to load driver" specifically but it is showing "No such file or directory" for these .so's. It gives me something to try. Unfortunately having issues with nixGL installation instructions but now this outside the scope of this channel I suppose. Gives me something to work with - I appreciate it
<plumeus>
Does glxinfo show anything suspicious? idk
<plumeus>
or well, does it not find a GL driver?
Ordoviz has joined #river
<plumeus>
I just realised that hardware.opengl.enable is set to false for me (can be checked with nixos-option)
<plumeus>
idk how I have programs running OpenGL if it's not properly enabled...
<plumeus>
okay, nixos-option is lying to me as I literally see a line in my config enabling it...
<plumeus>
and yeah, my /run/opengl-driver is populated properly
<mvnx>
I'm just using the Nix package manager, not NixOS. I took a look at that option and it seems to do a bunch of things that Guix may or may not be doing with my configuration - likely not.
<mvnx>
My /run doesn't have opengl-driver so there's that
<plumeus>
I've personally never used Nixpkgs outside of NixOS, so can't comment.
<plumeus>
There's a zig-build-system by ekaitz, and that could help for building Zig in River but... Guix has outdated wlroots iirc
<plumeus>
yeah, 0.14.1, ouch
<plumeus>
I blame that outdated package for being the major reason why I keep considering and giving up Guix. iirc, some dependencies of wlroots is also outdated so patching the wlroots package wasn't enough
<mvnx>
Oh I see core-updates is a branch. I'm new to all of this. So yeah still not merged
<plumeus>
I think the idea is that it's supposed to get merged to master within every 6 months or so for the next release of Guix
<plumeus>
but I'm pretty sure wlroots patches have been in core-updates multiple times without ever getting mainlined
Ordoviz has quit [Ping timeout: 246 seconds]
angry_vincent has quit [Remote host closed the connection]
<mvnx>
Interesting. I tried it out in my NixOS QEMU VM that was failing before I discovered `-device virtio-gpu-gl` and now I have the same issue. Trying nixGL there but ran out of disk space on my qcow2 >_> but at least I have /run/opengl-driver here
<waleee>
mvnx: sounds like a nix-collect-garbage is in place
<plumeus>
-d for better results
<mvnx>
Thanks I was using nix-store --gc been a while since I've done this manually
<plumeus>
nix-collect-garbage manpage says it's essentially the same as a nix-store --gc, so I think that's fine.
<mvnx>
The -d flag was the significant miss
<mvnx>
This is clearing a lot!
<plumeus>
I think it's just guix gc in Guix. Overall, I like Guix's design more.
<mvnx>
Same - that's why I want to stay
<mvnx>
but I'll be easily swayed if river works after I try nixGL on NixOS
<mvnx>
I'm at like 2 weeks trying to get this going lol
<plumeus>
I like Guix more but I refuse to use GRUB on my laptop.
<plumeus>
I kind of want secure boot and FDE working properly.
<mvnx>
LVM/LUKS works on Guix doesn't it?
<plumeus>
Not that I have Secure Boot working on NixOS atm. But a recent RFC passed to make it more feasible.
<mvnx>
I've long wanted Secure Boot but given my inability to run this window manager in a timely manner I just threw in the towel on Secure Boot
<plumeus>
NixOS uses systemd-boot, which depends on systemd. I guess other bootloaders like rEFInd exist, idk much about them
<plumeus>
Well, to be more correct, NixOS defaults to systemd-boot on systems supporting UEFI, and GRUB on other systems. You can configure it to use other bootloaders as well.
<qyliss>
systemd-boot does not depend on systemd
<qyliss>
it's a bootloader, after all
<plumeus>
oh, welp, never seen it outside of a systemd distro.
<plumeus>
I know it was originally called gummiboot and didn't depend on it.
<mvnx>
Default luksFormat is pbkdf2 right? You also want to use hardware keys?
<plumeus>
Guix supports LUKS2 but modifies the default to use LUKS1 simply because LUKS2 doesn't support encrypted /boot. No idea why they thought that was a good reason to default to LUKS1 when other use-cases exist.
<plumeus>
The default luksFormat should be argon2id
<mvnx>
Maybe some third party channels exist with these packages but yeah it feels like an endless hole
<plumeus>
At least according to Arch wiki
<plumeus>
I'm also not fond of how installing packages like Zathura adds an env var to the system in order to for Zathura to find the plugin path.
<plumeus>
It doesn't seem very pure to me and it requires the user to log out and back in for the changes to take place.
<mvnx>
I think I just wanted an excuse to learn a Lisp more than anything lol
<plumeus>
I don't know if I learned Scheme from using Guix, but I agree that learning Scheme made Guix make a lot more sense.
<mvnx>
Also nice that `guix home` doesn't feel as hacked on, even though it sort of seems to be. Like home services aren't the same as system services, iiuc
<plumeus>
(I've been reading SICP and every time I progress with the book, I get an urge to revisit Guix)
<mvnx>
but I guess Nix flakes is unifying everything
<plumeus>
Oh, guix home is so much better. If only the bash setup wasn't broken.
<plumeus>
Nix Flakes is great but it's still marked experimental. I think Guix Inferiors can possibly compete in the same space if it becomes a bit easier to use.
<mvnx>
Experimental but seems the community is really pushing forward - just my perspective. I was between moving to Guix or updating to Flakes/home-manager. I'd be willing to contribute to Guix to fix the things I want/need but I don't know nearly enough (Guile or building some of this complex software) and feel less inclined if I invest in Nix first. ;/
<mvnx>
First I heard of Inferiors. Guix just keeps drawing me in
ayushnix has quit [Remote host closed the connection]
<mvnx>
getting the same "Couldn't find current GLX or EGL context" and core dump on NixOS with nixGL
<mvnx>
It's hard to evaluate which direction I should go without trialing in a VM but there are too many differences in a VM from hardware (gpu, wifi, etc)
<waleee>
mvnx: is your host system guix?
<mvnx>
Host is NixOS
<mvnx>
I'm getting new hardware "late Q3"
<waleee>
you use a nixos vm on nixos?
<mvnx>
Yes, but I suppose I could try the wayland stuff on this host
<mvnx>
I went down this QEMU route because I started with Guix and then also had plans to run it on a MacOS host too
<waleee>
just to double check, you did run nixgl inside the vm?
<mvnx>
Yes I have a `start-river` script in my guest VM config adapted from someones dotfiles, now with nixGL.
<waleee>
hm ... now I'm wondering if it would be worth trying running qemu with nixgl instead
<mvnx>
oh interesting, I'll give it a try
<leon-p>
encrypting /boot always seemed a bit weird to me
<leon-p>
I'd do it if GRUB or whatever boot loader supportedd it
<leon-p>
but realistically encrypting only the rest of / is enough to protect your data against a rando script kiddy who might find your laptop you lost somewhere
<leon-p>
encrypting boot proteccts against evil made attacks, but at that point you are worried about basically government level actors (in operations capacity, not forensics capacity), meaning you definitely have bigger problems anyway
<leon-p>
s/made/maid/
<waleee>
I went with gocryptfs for some truly important stuff, but otherwise my reasoning was basically the same
<leon-p>
also checksumming the kernel and initrd gets you 80% of the way there as well
<waleee>
with some tweaking the result of gocryptfs looks a bit like a git registry re the file names used
<plumeus>
Encrypting boot is kind of pointless. If you want to protect against evil maids, shouldn't one use SecureBoot and TPM?
<leon-p>
depends on how hardware-savvy the maid is
<leon-p>
a small camera pointed at the keyboard defeats all of that anyway
<waleee>
plopping in one of those rubberducky usbs on the backside of your desktop probably counts as "not that savy"
<plumeus>
Well yes, just meant that I don't think encrypted boot offers any merit over what can be achieved with leaving the boot unencrypted
<leon-p>
encrypting boot allows you anti-maid protections without TMP and secure boot, which is probably nice for distros that are not microsoft blessed, or update their kernel / initrd often
<plumeus>
I know a few people who roll their own Secure Boot keys, and I would do so if it worked on NixOS without much configs... oh well. SoonTM
<leon-p>
supposedly its a bit easier if you use coreboot over whatever garbage proprietary uefi is shipped on your device, but I have not really played around with that a lot
<plumeus>
Also, I guess encrypted boot is helpless to tampering once the partition is decrypted, while something like fs-verity might be able to achieve a tad more.
<mvnx>
waleee: Same core dump on that GLX/EGL context assertion when running QEMU through nixGL on my host. Just updating if you were curious. At this point I need to reassess my life goals.
<plumeus>
Life goals: get River working via Nix
<leon-p>
had it once, found out nix is too annoying for me, went back to traditional distributions
<leon-p>
like, neat idea, but damn does the implementation suck
<plumeus>
I find Nix annoying but I find traditional distributions worse.
<plumeus>
I'm kind of glad I never bothered with Darcs/Pijul as I might start saying the same thing about Git.
<waleee>
from a straight user perspective if you would do zero developement nixos should be fantastic
<plumeus>
Huh? I think NixOS is better for developers than random end users.
<plumeus>
From an end-user's perspective, dynamically linked binaries not working without patching sucks
<leon-p>
nix lost me basically when I found out I can't install arbitrary versions of packages, after it got advertised as an easy way to build custom dev environments
<waleee>
a end user wouldn't really notice the FHS gymnastics you might need to do
<mvnx>
NixOS has been a blessing for me. Annoying, yes, but the most stable and resilient distribution I've used. It takes me forever to do major system changes like move from Xorg to Wayland and so I felt now was ready enough. Seems it is but I dunno how much of my problem is QEMU VM guest versus my Nix config.
<plumeus>
An end-user will get really confused when the FHS issues occur.
<leon-p>
for a true non-techie end-user, you'll want something that has an transactional update thing with automatic roll-back on breakage
<waleee>
mvnx: are you sure you have all the necessary stuff enabled for qemu in your nixos config?
<mvnx>
I'm always wiring up a bunch of things I know nothing about and takes me forever but once it works it's relatively stable.
<mvnx>
waleee: No. Not entirely. I'll share it one moment.
<plumeus>
Regarding non-techie, I wonder if something like Fedora Silverblue is okay
<plumeus>
Actually, nah, the immutable root screwed me over
<plumeus>
Can't install certain softwares like Nix or Guix
<plumeus>
Well, could use toolbox or some container but that's not a very non-techy thing to do
<leon-p>
immutable root is actually good for non-techies
<leon-p>
for non-devs, flatpak is actually a decent piece of software
<leon-p>
I once spent three days de-screwing an ubuntu installation of a friend that messed itself up after she installed some random package
<leon-p>
we could not re-install, because she had some global configuration nobody knew how to replicate
<plumeus>
It's okay. It also has transactional upgrades. Rebooting after installing/upgrading every non-flatpak package is a tad annoying but it's tolerable.
<leon-p>
so I am massively in favour for immutable root for end-users
<plumeus>
tbh, that sounds more like a motivation for declarative systems than anything
<leon-p>
(or in favour of scientists no longer using python, whatever is more realistic)
<plumeus>
Scientists will use Python until you tear it from their cold dead hands.
<plumeus>
I hate Python but I kind of want to look into Julia.
<leon-p>
although at least micro-python is ok, it allows pretty much everyone to write the firmware for our lab equipment without actually knowing anything about embedded
<leon-p>
which in turn allows us to give labview the boot
<leon-p>
labview is the ultimate argument against anyone who argues that GUI is always more user friendly than CLI
<leon-p>
</rant>
<plumeus>
I can never understand people's obsession against CLI.
<leon-p>
🤷
<waleee>
mvnx: don't you need to belong to the kvm user group?
<mvnx>
Let's see
<waleee>
otherwise I think you might have hardware acceleration for some virtual stuff
* waleee
scrolls back to check the qemu incantation
<plumeus>
although to be fair, terminals annoy the crap out of me on DEs in which there's no keybind for opening it automatically, and always spawns as this small floating window that has very little space to display anything
<leon-p>
I am not attached to terminals at all, just CLI
<plumeus>
QEMU is indeed an incantation
<waleee>
you had -enable-kvm in the qemu call
<waleee>
iirc from some wiki that it was one of those "it shouldn't be needed but it is groups"
<waleee>
ah. No it was from when I tried to use qemu and didn't belong to the kvm group
<mvnx>
Yeah I think I want that and I guess "kvm" on my user groups right? I made that change and then tried that with nixGL on the host and from the guest (but not together) - both failed in the same way
<waleee>
mvnx: could you check what glxinfo says if you run it with sway?
<mvnx>
Yes for sway. My config is likely different and maybe even my qemu incantation. I didn't keep it. Also when it "worked" it had no cursor or anything but at least made graphics. I now set `boot.kernelModules = [ "kvm-intel" ];` and it said "kvm: no hardware support" when I did a nixos-rebuild