<qyliss>
although as Thomas says in his email, that'd make most sense to do as a modification to the wayland-virtwl-proxy he's already written in OCaml
<JJJollyjim>
ah yes
<qyliss>
mailing list web interfaces are down for an update. AFAIK the mailing lists themselves should still be working, as should public-inobx.
TheJollyRoger has quit [Remote host closed the connection]
edadqr has quit [Remote host closed the connection]
TheJollyRoger has joined #spectrum
edadqr has joined #spectrum
edadqr has quit [Remote host closed the connection]
edadqr has joined #spectrum
v0idify has quit [Ping timeout: 240 seconds]
v0idify has joined #spectrum
<qyliss>
grr, mailman-web update makes Hyperkitty use the path I was previously using for public-inbox
<qyliss>
really wish I'd picked more stable mailing list software
<Profpatsch>
Super nice that the ocaml(/mirageos?) people are picking up wayland
<Profpatsch>
Feels like a logical next step after they have the network parts mostly down iirc
<Profpatsch>
sterni might have some insightful opinions on whether ocaml is a good fit for spectrum deps
<sterni>
but it probably doesn't really hurt having it in nixpkgs either
<sterni>
(regarding the topic of ready to package)
<qyliss>
sterni: I haven't upstreamed chromiumOSPackages but mostly because that's quite a bit of work
<qyliss>
and pkgs/os-specific/linux/spectrum will probably never be upstreamed
<sterni>
I see
<qyliss>
mostly I try to do upstream first
<sterni>
well it's probably easier to have wayland-virtwl-proxy upstream tbh
<qyliss>
yeah please
<sterni>
I'll add it to the ocaml-wayland PR as soon as I know what to put in meta.license :)
<qyliss>
fwiw it's not exactly useful without a Chromium OS kernel
<qyliss>
I'd kinda like that in upstream Nixpkgs along with the other bits of Chromium OS but not sure I'd be able to convince samueldr ;)
<qyliss>
maybe I can put the points I get from removing all the *_xen_dom0 kernel variants toward adding just one more
<sterni>
I mean having it in nixpkgs so spectrum nixpkgs can have it is enough of a reason for me
<sterni>
and it is clearly simpler to maintain in nixpkgs with all the other ocaml stuff
<qyliss>
yeah I don't think it would hurt anything to have wayland-virtwl-proxy in upstream
<samueldr>
qyliss: if it's stated that it's for using kernel modules that are not present in mainline linux, it's probably fine
<samueldr>
ESPECIALLY, if it's their freshest LTS branch only
<qyliss>
that's what I'd want yeah
<samueldr>
and please do clean-up _xen_dom0
<qyliss>
samueldr: already did, it's gone
<samueldr>
haha
<qyliss>
samueldr: yeah, I agree we shouldn't be packaging random device kernels
<qyliss>
but the Chromium OS one is useful for all their VM stuff
<samueldr>
yes, and it eventually tricles back into mainline, I believe
<samueldr>
more of a staging grounds for their experimental (not really) stuff
<qyliss>
yeah
<qyliss>
virtio wayland probably won't end up in mainline, but a more generic thing based on it might
TheJollyRoger has quit [Ping timeout: 240 seconds]
<samueldr>
it would be better, but impractical, if instead we would apply the desired kernel subsystems required as distinct patches... but that sounds like a job in itself
<samueldr>
(optionally apply)
<qyliss>
I'd like to do that eventually
<samueldr>
yeah, but that sounds like a job in itself :)
<qyliss>
yeah
<qyliss>
cool, well once we get chromiumOSPackages up to date in Spectrum Nixpkgs again I'll try to upstream it
<qyliss>
it's pretty neat -- makes sure every Chromium OS thing in Nixpkgs comes from the same Chromium OS release, and has a fancy updateScript
TheJollyRoger has joined #spectrum
<samueldr>
nice
<samueldr>
might be useful to explain somehow that the Chrome OS kernel package is not really intended for usage with Chrome OS devices when contributing it into Nixpkgs
<samueldr>
and maybe adjacent to the package so that when a Chrome OS device ends up not working it'll be easy enough to point to
<qyliss>
yeah I will
cole-h has joined #spectrum
<qyliss>
cole-h: btw, wanted to say thanks for offering to review the other day, but you went offline before I could :)
<qyliss>
I should get a bot with ,tell in here
<cole-h>
:D
<cole-h>
Or I should set up weechat on my always-online rock64 lol
<qyliss>
I can offer you a ZNC account if you want
<cole-h>
Thanks for the offer, but I'm gonna play around with weechat first.
<qyliss>
okay :) it's here if you want it
<cole-h>
Though, I may or may not take you up on that at a later date, depending on how frustrating it is :P
<qyliss>
I run weechat locally, and it connects to ZNC on my server and fetches history and stuff
<multi>
if i weren't snowed under with deadlines right now, i'd be tempted to resurrect a halfway-implemented bot sitting on my laptop which does ,tell things XD
<cole-h>
qyliss: oh? does that setup let you have autojoins configured in weechat, as well as `/join #....`, or does that need to be configured in znc?
<qyliss>
the NixOS bot does it; I could probably get it in here if I asked
<qyliss>
not sure I want it though
<qyliss>
cole-h: joins are state in ZNC
<qyliss>
i.e., I /join a channel once and then I'm there forever
<qyliss>
when I start WeeChat the ZNC server will just join it to all my channels
<cole-h>
oh nice
<qyliss>
the only thing I really miss is that read state isn't synced between devices
<qyliss>
but that's not a big deal
<qyliss>
(you can set ZNC up so that it'll only deliver logs to the first device that wants them, but that's even worse IMO)
<samueldr>
using a "real" bnc in-betwee a fancy featureful client is always good imo
<multi>
<qyliss> not sure I want it though <-- this of course has me thinking "how hard can it be to run an instance?", which of course is the wrong thing for me to be asking right now ^^"
<samueldr>
e.g. I use Quassel through ZNC
<samueldr>
I can "break out" of quassel and use another client if needed
<qyliss>
samueldr: huh that's an interesting setup
<samueldr>
or even, {`-`} here, the logger bot, it's using znc!
<qyliss>
pretty cool
<samueldr>
so I can manually do interventions if the bot scripts does something weird
<multi>
i have my (always-on) weechat behind a znc too
<samueldr>
or additionally, I could run another bot script in addition to the logger!
<multi>
the various bots i run are all behind znc's these days too
<qyliss>
multi: AIUI the NixOS bot is a sort of meta-bot that farms out various services to other programs running on various people's computers
<multi>
can mux multiple behind a single external connection
<samueldr>
yep, once you realize that, it's pretty great
<multi>
qyliss: yeah, that sounds familiar
<multi>
i did look at this once
* multi
is in the process of making dinner right now, might take a look at the nixos bot later on
<Profpatsch>
so znc is like a IRC client multiplexer?
<cole-h>
qyliss: got them all applied; now going through your written-up steps for testing
<cole-h>
qyliss: when you say "After this, it's a good idea to reboot, to restore all the network devices to their default state." -- is this rebooting the host system?
<qyliss>
yeah
<qyliss>
it's optional if you know how to change the ethernet driver back to the default one
* cole-h
doesn't
<cole-h>
:P
<cole-h>
well, no matter, still compiling the kernel lol
<qyliss>
if you want to, you can probably figure it out by looking at the code in spectrum-testhost/default.nix
<qyliss>
that removes the ethernet port from its default driver and assigns it to the vfio-pci driver
<qyliss>
you just need to do that in reverse to get it back to normal
<qyliss>
I don't remember how you find out the default driver, or tell it to use the default one, but you can find out which driver it picked in dmesg
<qyliss>
probably e1000e
<cole-h>
lspci -nk
<cole-h>
mine is actually igb :P
<qyliss>
oh actually the VM probably doesn't have that driver!
<qyliss>
it might be time to put kernel modules in vm-net
<cole-h>
hehe
<qyliss>
I don't think we need loadable modules for VMs that don't touch hardware, but for ones that do it makes sense
<cole-h>
then I'll just give you a reviewed-by for now, and test it later :)
<cole-h>
looks like I'll have to reboot anyways. I just hung nouveau lol
cole-h has quit [Quit: Goodbye]
cole-h has joined #spectrum
<qyliss>
cole-h: if I make you a version that just compiles in the igb driver as well so you can test it, is that good enough for now do you think? would like to get this in if it works so I don't have to make it even more complicated by adding modular kernels
<cole-h>
yeah, sure
<qyliss>
cool
v0idify has quit [Ping timeout: 240 seconds]
v0idify has joined #spectrum
v0idify has quit [Ping timeout: 240 seconds]
v0idify has joined #spectrum
v0idify has quit [Remote host closed the connection]
v0idify has joined #spectrum
<qyliss>
cole-h: there you go
<cole-h>
cheers, building now
cation21- has joined #spectrum
cation21 has quit [Ping timeout: 265 seconds]
cation21- is now known as cation21
cole-h has quit [Ping timeout: 246 seconds]
cole-h has joined #spectrum
<cole-h>
good news: it works!
<cole-h>
bad news: I messed up the "rebind to igb" script, so I had to reboot anyways!
<cole-h>
haha
<qyliss>
nice!
<qyliss>
glad it works
<cole-h>
qyliss: I forget: should I do both reviewed-by and tested-by, or just tested-by?
<qyliss>
that depends -- did you review it? :P
<cole-h>
I did both :P
<cole-h>
just didn't know (or remember) if one implied / superceded the other
<cole-h>
(though I guess not)
<qyliss>
yeah, they're independent
<MichaelRaskin>
I mean, you can do either without another, how could they supersede
<cole-h>
yeah
<cole-h>
qyliss: woot!
<qyliss>
Excellent, thank you so much cole-h.
<qyliss>
I'll apply it tomorrow probably if nothing comes up in the meantime
<cole-h>
:D
<qyliss>
I have a bunch of further improvements for it planned already