<dok>
do you know what's needs to be done for proper input handling in xwayland ?
<f_>
Just the news announcement thing and a git tag and we're done :)
<axtlos>
no i havent looked into it yet, im not even sure if its possible with how xwayland works right now
<dramforever[m]1>
we'd essentially have to parse libinput config or something from Xorg.conf
<axtlos>
no that wouldn't solve it
<axtlos>
we need to give xwayland direct access to the input devices
<axtlos>
so that it doesn't only have the stub ones
<f_>
14:19 <axtlos> afaik xwayland doesn't read any xorg config files at all
<f_>
yeah that's an Xorg-specific thing
<axtlos>
thats what i figured
<dok>
also one typical usage for xinput, is to bind an input to a screen: a graphic tablet with an integrated screen.
<axtlos>
more complexity yay!
<dramforever[m]1>
oh, you mean the devices themselves
<axtlos>
yes
<dramforever[m]1>
i would have thought xwayland handled that
<dramforever[m]1>
wait what specific device are we talking now?
<axtlos>
any input device
<axtlos>
xwayland doesn't see any input devices
<dramforever[m]1>
so i was thinking we "just" need to provide these devices as wayland devices?
<axtlos>
wayback-compositor already sees them
<axtlos>
to xwayland its either a pointer device or a keyboard device
<axtlos>
they're all collected as the same xinput device
<f_>
hmmmm yeah that's a problem
<ConanKudo[m]1>
significant work on xwayland is going to be required
<axtlos>
yes
<dramforever[m]1>
so if i run Xwayland in kwin_wayland, i see an extra xwayland-tablet device
<dramforever[m]1>
actually four but it's some weird evdev thing
<f_>
yeah so that'd be fixed with proper input handling
<ConanKudo[m]1>
wayback-compositor is also going to need work necessarily
<dramforever[m]1>
so this evidently works in xwayland
<f_>
yep
<dramforever[m]1>
so, what is the significant work required in xwayland?
<ConanKudo[m]1>
it is also possible that work is required in wlroots too, since that's our compositor library of choice
<ConanKudo[m]1>
dramforever: gluing inputs, outputs, and adding mechanisms to synchronize config
<ConanKudo[m]1>
* synchronize config state
<dramforever[m]1>
ah, config is the big one
<f_>
Anyway, is there anything else that should be in 0.1?
f_|cat has joined #wayback
<axtlos>
i dont think so
<dramforever[m]1>
how often are we going to do future 0.x releases?
<f_>
hmmm good question
<f_>
Maybe one each month or so?
<f_>
they're preview releases after all
<dok>
maybe do a release when there is new stuff?
<f_>
there's always new stuff :)
<dok>
release every other week !
<dok>
j/k
<dramforever[m]1>
i think 0.x every month and important fixes in 0.x.y whenever?
<dramforever[m]1>
and for 0.x at least no branches we just ship the tip
<f_>
Hmm but what qualifies as an "important fix"
__0x1eaf has quit [Quit: Lost terminal]
<dramforever[m]1>
hypothetically thinking stuff like fixing regressions
<dramforever[m]1>
so, hypothetically "oops 0.3 just crashes if you don't have a mouse plugged in, let's make a 0.3.1"
<dramforever[m]1>
this could also just be 0.4
<f_>
hmm ok that kind of thing
<f_>
well hopefully that wouldn't be needed but w/e
<dramforever[m]1>
if we're only going to be loosely sticking to a schedule 0.4 would work just as well
<ConanKudo[m]1>
I think the only real point where we would want to have release branches is to deal with the inability to maintain support for a wlroots release branch
<ConanKudo[m]1>
otherwise just tag a new release in MAIN
<ConanKudo[m]1>
s/MAIN/main/
<dramforever[m]1>
yes, no branches in 0.x
<ConanKudo[m]1>
I am even saying as much when we make 1.0
<ConanKudo[m]1>
there is very little value in making release branches pre-emptively
<dramforever[m]1>
i don't disagree, i think "we'll see"
<f_>
yeah for this project it's pretty pointless (currently)
<dramforever[m]1>
it's mostly that we have a defined interface (it's /usr/bin/X)
<ConanKudo[m]1>
there are two constraints that might force a branch: wlroots and xwayland compatibility
<ConanKudo[m]1>
I don't expect the latter to be a forcing function
<ConanKudo[m]1>
but I do expect us to eventually hit this with wlroots
<f_>
I mean
<f_>
IIRC TinyWL has been basically untouched for a number of years
<ConanKudo[m]1>
wayback-compositor will not remain as simple as tinywl
<f_>
yes, of course, but right now in wayback-compositor's current state, I think branching is not necessary
<ConanKudo[m]1>
yeah, I agree
<dramforever[m]1>
imagine wlroots 0.20 getting uh, absolute wheel or something and we have to plug it in
<ConanKudo[m]1>
O.o
<dramforever[m]1>
absolute dial
<f_>
We can always revisit the option later
<ConanKudo[m]1>
I do expect wiring up protocols to become the underlying constraint
<dramforever[m]1>
we can always decide to branch
<ConanKudo[m]1>
yeah, my expectation is that we probably won't
<dramforever[m]1>
i agree
<ConanKudo[m]1>
maintenance branches are for funded projects, which we aren't
<dramforever[m]1>
i don't think we need them even if we get funded. the interface of /usr/bin/X isn't changing
<f_>
Oh that's not the issue dramforever[m]1
<dramforever[m]1>
users just get better support of stuff when they come (e.g. depending on new xwayland for new features)
<f_>
The concern is wlroots doing breaking changes
<f_>
but we depend on fixed versions of wlroots so ...
<dramforever[m]1>
we can still try to #if our way out of it right?
<f_>
like, we currently depend on wlroots0.19 IIRC
<ConanKudo[m]1>
yes
<ConanKudo[m]1>
we can try ifdeffery up to a point
<f_>
hmmmm I'd rather not :/
<ConanKudo[m]1>
we haven't hit the case yet, so 🤷♂️
<ConanKudo[m]1>
we can also say that wlroots breaking is just a fact of life and not use it as a branching point either
<ConanKudo[m]1>
plenty of projects do that
<ConanKudo[m]1>
and I am okay with that too
<f_>
What do you mean?
<f_>
you mean upgrading wlroots and fixing breaking changes along the way "as usual?"
<dramforever[m]1>
something like "hello everyone, wayback n.x released, changes: wlroots-0.19 is no longer supported. wlroots-0.20 is required"
<f_>
oh ok
<ConanKudo[m]1>
exactly
whitequark[cis] has joined #wayback
<whitequark[cis]>
if you do that i will gently insist on adding a submodule with wlroots and an option to vendor it in with meson
<ConanKudo[m]1>
I would steadfastly refuse that
<ConanKudo[m]1>
I don't want to promote bad practices like that
<ConanKudo[m]1>
and we don't support any version of wlroots that isn't version namespaced anyway
<dramforever[m]1>
Catherine: not sure what vendoring helps, tbh? distros won't like it, and it's not like we're talking about making our own changes to wlroots
<dramforever[m]1>
i do think meson lets you use a local version of wlroots already
<ConanKudo[m]1>
it does
<ConanKudo[m]1>
but it also doesn't matter in practice
<ConanKudo[m]1>
distributions will introduce new versions of wlroots as soon as something needs it
<ConanKudo[m]1>
since every version series is parallel installable for runtime and development files, it doesn't matter that much anymore
<ConanKudo[m]1>
it's up to distro policy how they want to handle it
<dramforever[m]1>
i think we should support the case where someone would want to build wayback with a wayback.tar.gz and a wlroots-0.19.tar.gz, but that's... as mentioned, just meson
<whitequark[cis]>
to be clear, i'm not saying you should make that the build option
<whitequark[cis]>
i'm saying you should have it as an option, because it's a fucking pain to manage up-to-date versions of libraries for every project that wants to be on the bleeding edge
<whitequark[cis]>
and i find it offensive that you would call something that makes the project tangibly more accessible a "bad practice"
<ConanKudo[m]1>
it is a bad practice
<ConanKudo[m]1>
it also adds overhead to us
<ConanKudo[m]1>
because now we are responsible for wlroots
<whitequark[cis]>
it's a perfectly fine practice
<whitequark[cis]>
your opinion isn't absolute
<dramforever[m]1>
would you accept "download two tarballs" as good enough?
<whitequark[cis]>
"bad practice" is just a code word for "something I dislike but can't justify besides invoking authority"
<ConanKudo[m]1>
it's a bad practice because it promotes dependency stickiness
<ConanKudo[m]1>
it also increases the overhead of maintenance for the codebase because we now have to test and support two ways for everything
<ConanKudo[m]1>
technically three if wlroots is built statically through vendor mode
<whitequark[cis]>
i acknowledge the increased overhead
<ConanKudo[m]1>
in addition, it complicates separation of wayback from wlroots in development
<ConanKudo[m]1>
it's much easier to abuse or do weird things with vendored stuff
<ConanKudo[m]1>
and I really don't want to make it easy to rely on git commits of wlroots
<whitequark[cis]>
i do it anyway because i want my projects to be more accessible, but i can see there not being enough resources, potentially
<ConanKudo[m]1>
because that's asking for a new level of pain
<whitequark[cis]>
ConanKudo[m]1: that is a question of values, not of technology
<ConanKudo[m]1>
yes, and vendoring is a value-oriented proposition, not a technology one
<whitequark[cis]>
if i want to abuse something, i will check in a custom ELF loader that does binary patches
<whitequark[cis]>
"vendoring" vs "not vendoring" barely changes that tradeoff
<ConanKudo[m]1>
it changes the expectations of ownership
<whitequark[cis]>
yes, actually, that's exactly what i want to see
<ConanKudo[m]1>
and I don't
<whitequark[cis]>
that sucks. but alright
<ConanKudo[m]1>
it is much easier to firmly stay in release versions of wlroots if that's the only path we support
<ConanKudo[m]1>
as it is, we will likely support building against multiple versions of wlroots and have a falloff period
<ConanKudo[m]1>
we already do support 0.18 and 0.19
<whitequark[cis]>
that also works; i only think you should be vendoring if you stay at the bleeding edge release at all times
<whitequark[cis]>
there's not really any point in doing both ifdefs and that
<ConanKudo[m]1>
yeah, I firmly want to stay away from there
<ConanKudo[m]1>
we haven't gotten there yet, but we will see how things evolve
<whitequark[cis]>
alright, no problem then
<ConanKudo[m]1>
the true test will be when we wire up brand new wayland-protocols
<ConanKudo[m]1>
I also expect that there won't be that many of such cases after we get over the initial hump
<dramforever[m]1>
oh, yes, only the latest released version
<dramforever[m]1>
not the latest trunk or whatever the branch is
<ConanKudo[m]1>
the only protocol that I know of that will force us to upgrade to a new wlroots version is pointer-warp
<ConanKudo[m]1>
but pointer-warp is not implemented in either wlroots or xwayland yet
<ConanKudo[m]1>
there's not even an MR for wlroots, kwin's was only merged yesterday
<dramforever[m]1>
oh, not necessarily the latest one released version
<Ariadne>
we can technically implement pointer-warp ourselves, no?
<ConanKudo[m]1>
yes
<ConanKudo[m]1>
but xwayland still needs it too
<Ariadne>
anyway, i do think it makes sense to cut a wayback 0.1 release today
<ConanKudo[m]1>
I will cut a release later today after some readme updates
<ConanKudo[m]1>
one open question: how do we want to explain wayback-session, given that we intend to eventually remove it?
<ConanKudo[m]1>
do we want to say it'll be removed before 1.0 explicitly?
<ConanKudo[m]1>
I retargeted #14 to the 1.0 milestone, and I would expect full implementation of that ticket will render it redundant as xinit would work just fine
<dramforever[m]1>
i think we just do this for now and figure out fixing the collision later
<dramforever[m]1>
if we want to fix the collision
<f_>
I'm not sure why this bit uses optind though
<f_>
it doesn't run getopt
<f_>
anyway sorry for the trouble everyone
<f_>
If someone could add a note to the announcement that'd be awesome
<f_>
Else I'll do it tomorrow
<dramforever[m]1>
caught this technically after the release but hopefully before this has went to any unknowing user
<f_>
Yeah that's awesome of you
<f_>
Thank you so much
arraybolt3 has joined #wayback
<dramforever[m]1>
today's an unlucky lucky day
<dramforever[m]1>
if i may go off topic for a little while i accidentally threw my yubikey out in the trash and if i hadn't been pushing code i would have probably permanently lost it. fortunately i also caught that in time
<bigmac>
Oh good for you, this will probably teach you to never loose an eye contact with it ever again. Personally, I printed my most important keys on a piece of paper :/ I also have a digital backup in the *cloud*, which I am not too happy with because it is a third party (a well known company) that I trust with all my passwords, but keys might be too much
<bigmac>
...I get the point of yubikeys for when you need to work with many previously untouched devices, but I prefer the safe currently
<bigmac>
dok: "nice, i am going to try the fix for #50" Have you tried, is everything as expected?
<dramforever[m]1>
i don't have backups for my ssh key so if i lose that i lose that and have to go reset everything. i don't have 2fa on there
<whitequark[cis]>
this is kinda why i don't use yubikeys
<whitequark[cis]>
having totp in my password manager is enough to solve the "got phished once and someone has access forever and for any number of operations" problem
<dramforever[m]1>
resetting my ssh key on github is not very inconvenient, and honestly it's more of a sentimental value thing
<whitequark[cis]>
that's true
<dramforever[m]1>
servers i also consider having to go boop the web console acceptable
<f_>
I like pass-otp
<f_>
Pass is awesome and I have a backup stored on my server in case
<f_>
Regarding ssh I don't really mind all that much
<f_>
Rotating keys out once in a while is good practise I think
<dramforever[m]1>
rotating the physical key at surprise timing isn't as nice :P
<ConanKudo[m]1>
<dramforever[m]1> today's an unlucky lucky day
<ConanKudo[m]1>
I lost _all_ my YubiKeys two years ago
<ConanKudo[m]1>
imagine how much fun it is to rotate ~100 accounts
<ConanKudo[m]1>
(hint: it isn't)
<phogg>
Never underestimate the security of keeping a mysterious code written somewhere quasi-public without explanation. You could put a recovery key in an HTML comment on your blog with little chance of anyone figuring out what it's for. It's the modern equivalent of a key under the flower pot.
<whitequark[cis]>
<ConanKudo[m]1> imagine how much fun it is to rotate ~100 accounts
<whitequark[cis]>
i would not be able to manage this, which is why i just don't sign up for it
<whitequark[cis]>
which is like fine, except some people are mfa maximalists
<ConanKudo[m]1>
it was part of my job unfortunately
<whitequark[cis]>
oh no.
<whitequark[cis]>
condolences
<ConanKudo[m]1>
I don't choose this insanity
<whitequark[cis]>
i talked to some people who are a little security obsessed and sincerely argued for sth like that
<whitequark[cis]>
it's alien to me, like how much free time do they have, and the stress too
<whitequark[cis]>
being locked out of my bank in a foreign country was bad enough, if it was also my infra...
* arraybolt3
is noe of said security-obsessed people, but it's also part of my job
<arraybolt3>
s/noe/one/
<arraybolt3>
granted, I don't have the free time or threat model to warrant using extreme measures myself (yet... I might go extreme someday as an experiment or if my work ends up needing it...), but I get to write quite a bit of software from a "paranoid security" perspective.
<arraybolt3>
(mostly when working with Whonix and Kicksecure)
<ConanKudo[m]1>
my personal, most critical accounts are MFA'd
<arraybolt3>
same here. Most of my accounts are just protected with a random password in KeePassXC, but if something is hyper-critical or requires MFA, I have it handy.
<arraybolt3>
I'm just paranoid enough of losing my password database to keep me from going full boar...
<ConanKudo[m]1>
the rest are chained through secured password manager
<arraybolt3>
(I actually deleted my entire Passwords.kdbx file the other day doing `rm -rf ~` on accident, but I was able to recover it with the help of PhotoRec)
<arraybolt3>
(that should have taught me to do backups more often, but... :grimace:)
<f_>
<dramforever[m]1> rotating the physical key at surprise timing isn't as nice :P -- lol of course
<whitequark[cis]>
i really need to set up LVM based incremental snapshots
<dok>
bigmac: yes i've tried and yes it fixed the issue i was having
Saijin_Naib[m] has joined #wayback
<Saijin_Naib[m]>
0.1 landed in Alpine edge and works great. OSNews made a nice writeup as well. Congrats, all