16:00:56 <alebastr[m]> #startmeeting Fedora Sway SIG (2022-11-21)
16:00:56 <zodbot> Meeting started Mon Nov 21 16:00:56 2022 UTC.
16:00:56 <zodbot> This meeting is logged and archived in a public location.
16:00:56 <zodbot> The chair is alebastr[m]. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:56 <zodbot> The meeting name has been set to 'fedora_sway_sig_(2022-11-21)'
16:01:02 <alebastr[m]> #topic Roll Call
16:01:13 <alebastr[m]> .hello alebastr
16:01:14 <zodbot> alebastr[m]: alebastr 'Aleksei Bavshin' <alebastr89@gmail.com>
16:01:24 <jkonecny[m]> .hello jkonecny
16:01:25 <zodbot> jkonecny[m]: jkonecny 'Jiří Konečný' <jkonecny@redhat.com>
16:01:25 <anthr76[m]> .hello anthr76
16:01:27 <zodbot> anthr76[m]: anthr76 'Anthony Rabbito' <hello@anthonyrabbito.com>
16:02:12 <anthr76[m]> Zodbot even works better :)
16:04:07 <jkonecny[m]> probably also had a coffee 🙂
16:04:28 <alebastr[m]> let's hope it'll continue behaving for the next hour
16:04:35 <alebastr[m]> Fale: are you joining us?
16:05:17 <alebastr[m]> anyways, onto the first topic (checks an actual agenda mail, prepared and sent beforehand)
16:06:04 <Fale[m]> sorry, I'm in a call, joining at the bottom of the hour
16:06:15 <alebastr[m]> #topic wlroots update in stable releases - https://gitlab.com/fedora/sigs/sway/SIG/-/issues/14
16:07:02 <alebastr[m]> Just need to confirm if it's a good idea and whether we need to pull sway along :)
16:07:24 <jkonecny[m]> I agree with your proposal
16:08:50 <alebastr[m]> f36 is manageable with https://src.fedoraproject.org/fork/alebastr/rpms/wlroots/c/531eb5b0d428b3175dca395ae198022f07cd59ce?branch=rawhide, but I don't want to proceed with that
16:09:39 <alebastr[m]> at the very least, this patch makes connector ids inconsistent between f36/f37+ and breaks configurations
16:09:59 <alebastr[m]> (which is also a general concern for switch to wlroots 0.16)
16:10:14 <jkonecny[m]> how exactly it breaks the configuration?
16:12:54 <alebastr[m]> good question. new wlroots uses `drmModeGetConnectorTypeName` from libdrm to generate output identifiers, and it may have different result. hopefully not.
16:13:45 <jkonecny[m]> ohh, so monitors configuration could break
16:14:03 <alebastr[m]> there's another change, https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3446, which affects output description lines (manufacturer - model - serial stuff)
16:14:04 <jkonecny[m]> it happened to me in the past once (could be my fault)
16:14:09 <jkonecny[m]> I think that shouldn't be such a pain
16:14:33 <jkonecny[m]> and F37 was just released so I would think about this as 0day update like... 😄
16:15:13 <anthr76[m]> +1
16:15:37 <alebastr[m]> yep. gamescope is planning to switch to 0.16 as well, and the package is getting regular updates recently
16:15:47 <anthr76[m]> I was just catching up. I do agree with the proposal
16:16:13 <anthr76[m]> <alebastr[m]> "f36 is manageable with https://..." <- Is there any good reason to do this? Besides obviously having the "latest and greatest"?
16:16:16 <anthr76[m]> > <@alebastr:fedora.im> f36 is manageable with https://src.fedoraproject.org/fork/alebastr/rpms/wlroots/c/531eb5b0d428b3175dca395ae198022f07cd59ce?branch=rawhide, but I don't want to proceed with that
16:16:17 <anthr76[m]> * Is there any good reason to do this? Besides obviously having the "latest and greatest"
16:17:21 <alebastr[m]> it's requested for Qubes OS - apparently they're writing a wayland compositor to manage outputs from all these virtual machines, and their current base is f36
16:18:24 <alebastr[m]> I'll do a module build anyways, but regular f36 update seems too much
16:18:48 <anthr76[m]> I see I figured they would be on f37 shortly
16:19:27 <alebastr[m]> right. maybe I'll just ask if f37 is fine for them :)
16:20:49 <alebastr[m]> so the second part of proposal is to update sway in f37 when we're sure it's not bringing disaster to users :)
16:21:50 <alebastr[m]> and that's probably should be left for later discussion, when we get the release
16:22:35 <anthr76[m]> Is there signs they're cutting a release or is it assumed from new wlroots?
16:23:38 <alebastr[m]> they wanted to start publishing release candidates last week, but emersion didn't have time apparently
16:25:18 <anthr76[m]> Got it. Sounds good
16:26:09 <alebastr[m]> #action alebastr should prepare these f37 updates and wlroots compat package along with rawhide. Review Sway when we consider it stable
16:26:58 <alebastr[m]> #topic sway 1.8 pre-release testing
16:27:51 <alebastr[m]> technically, we don't have an rc yet. but 1.8 branch already exists and I can build a snapshot in my copr - https://github.com/swaywm/sway/tree/v1.8
16:28:39 <jkonecny[m]> having it in COPR seems like a great idea but I would avoid official repositories yet
16:29:02 <alebastr[m]> I'm using it right now, just want more people to take a look as there's a nice tradition of having a few day 0 issues :)
16:29:56 <alebastr[m]> the plan is to push release candidate to rawhide once it's tagged
16:30:13 <jkonecny[m]> agree
16:30:58 <alebastr[m]> the question is, should we do a temp branch of Sericea/f37 once it's available?
16:31:41 <alebastr[m]> seems like a safe way to rebase, test, rollback
16:33:34 <Fale[m]> it might be complex to bring sway 1.8 to f37, due to dependencies
16:34:07 <alebastr[m]> no, not really. everything necessary is already in f37
16:34:30 <Fale[m]> then it would work :)
16:34:35 <alebastr[m]> the last missing component, libdrm >= 2.4.113, was updated last week
16:36:28 <anthr76[m]> <alebastr[m]> "the question is, should we do..." <- I was thinking of doing a local client side override actually right before you brought that up. I'm fine with either.
16:37:26 <alebastr[m]> I remembered that you implemented image publishing for pull requests and thought it's better than local overrides
16:37:51 <anthr76[m]> I suppose the issue with that though is that PR will be frozen for updates
16:38:11 <jkonecny[m]> we can probably just layer new Sway to the Sericea
16:38:18 <jkonecny[m]> I don't think we need rebase
16:38:22 <anthr76[m]> For example, `rpm-ostree upgrade` will be updating against the image. Where as the "prod" branches get ran on a 24 hour schedule
16:38:26 <alebastr[m]> but maybe we should change the tags to something like CI_COMMIT_REF_SLUG :)
16:38:37 <anthr76[m]> alebastr[m]: Also very fine with that :P
16:38:42 <jkonecny[m]> I used Sway on SilverBlue long time before Sericea and it worked fine
16:41:16 <alebastr[m]> for the record, I'm still using classic Fedora. So I'm fine with either approach
16:41:58 <alebastr[m]> can't figure out a good packaging workflow with ostree system
16:42:11 <anthr76[m]> +1 for just doing something like this https://fedoraproject.org/wiki/Test_Day:2022-06-05_Kernel_5.18_Test_Week#Fedora_Silverblue_or_Kinoite_2
16:42:15 <anthr76[m]> alebastr[m]: Fedora in toolbox is all you need :)
16:42:24 <anthr76[m]> mock finally works...well
16:43:06 <jkonecny[m]> with distrobox even podman works well from a container 😄
16:43:12 <alebastr[m]> there are components that should be tested in the base system. and I do a few rebuilds/reinstalls for some updates
16:43:18 <anthr76[m]> The ostree branch is a good idea but I don't have a ton of time to re-work automation to make it upgrade
16:44:05 <anthr76[m]> I'm always happy to chat about SB workflows. In fact I think someone should write a good guide because there is quite a few nuances needed to be worked
16:44:11 <alebastr[m]> does it make easier to opt-in for testing (compared to layer) and is it worth the time spent?
16:45:01 <jkonecny[m]> I think it is not -- just simple overlay works well
16:45:05 <anthr76[m]> alebastr[m]: If opt-in for testing just a rebase I'd almost argue it's close to the same if we document it in our issue tracker
16:45:41 <anthr76[m]> You just need to know how to make the override and revert only the override to not intrude other overrides users may have made
16:45:52 <jkonecny[m]> and as a bonus with layer you can switch the target with login manager instead of commands and reboots when it's broken
16:46:13 <anthr76[m]> for example `rpm-ostree override reset sway` vs `rpm-ostree override reset`
16:46:34 <alebastr[m]> jkonecny: but you can't if you are testing updated sway package, right?
16:46:59 <jkonecny[m]> with sway-git repository it works
16:47:21 <alebastr[m]> yep, but it's not built from 1.8/wlroots 0.16 branches
16:47:55 <alebastr[m]> in fact it's not built at all, because we don't have the necessary pixman update :)
16:48:10 <jkonecny[m]> ahh ok
16:48:22 <jkonecny[m]> 😥
16:49:28 <anthr76[m]> alebastr: do you have an idea when you'll publish a COPR? I'll override to it locally and post up testing docs.
16:49:33 <alebastr[m]> ok. so the summary is - sway rc in rawhide, copr; no separate tree for sericea, someone should write an instruction for necessary overrides
16:50:08 <anthr76[m]> Oh wait I think you said you'll also publish a f37 copr is that write?
16:50:12 <anthr76[m]> s/write/right/
16:50:13 <alebastr[m]> anthr76: I can build an 1.8 git snapshot right after the meeting
16:50:37 <alebastr[m]> I have wlroots done in copr://alebastr/sway-testing and Sway locally
16:50:51 <jkonecny[m]> F37 please -- I'm not brave enough to use Rawhide for my daily work (I'm fine with Sway) 😄
16:51:01 <anthr76[m]> +1 ^ :_
16:51:04 <anthr76[m]> * +1 ^ :)
16:51:24 <anthr76[m]> alebastr[m]: Cool so I'll override and right the doc right after this meeting as well
16:51:31 <anthr76[m]> s/right/write/
16:51:39 <anthr76[m]> Man I can't type today :) .. more coffee
16:52:06 * anthr76[m] loves the bleeding edge but scared of rawhide
16:53:26 <alebastr[m]> #agreed Publish Sway release candidates in rawhide and copr. No Sericea test tree for 1.8, we'll provide an instruction for layering the packages to test.
16:54:23 <alebastr[m]> #topic Spin development updates
16:55:23 <alebastr[m]> AFAIK, nothing important happened since the last meeting :)
16:55:45 <alebastr[m]> #link https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html
16:55:48 <Fale[m]> do we have any updates on the submission of the change?
16:55:58 <anthr76[m]> +1 nothing much to report from my side besides sorry for inactivity
16:56:27 <anthr76[m]> And also another sorry to jkonecny for making a simple change to ssh and making his job harder :P
16:56:33 <alebastr[m]> yep, that's what I wanted to bring up - we should be looking at change submission, docs site and test infra
16:57:11 <anthr76[m]> But besides that we need to get the submission in. I was originally going to take that task but if someone else wants to run with it feel free.
16:57:16 <Fale[m]> imho the highest priority is the change proposal, so that once that is in, we can focus on the other elements
16:57:43 <jkonecny[m]> anthr76: wasn't your issue at the end, no problem 😄
16:58:17 <Fale[m]> I don't mind picking this up, if it helps
16:58:23 <jkonecny[m]> and unfortunately the same for me, I would like to get waybar configuration to our repositories but I'm completely drained during evenings ☹️
16:59:31 <jkonecny[m]> do we have the pending tasks lists somewhere?
16:59:43 <jkonecny[m]> s/lists/list/
17:00:27 <alebastr[m]> jkonecny: https://gitlab.com/fedora/sigs/sway/SIG/-/issues, just file a new issue if you don't see something there
17:02:31 <Fale[m]> @anthr76 do you want me to pick this item up?
17:03:02 <jkonecny[m]> maybe we should somehow get priority on the issues?
17:03:13 <jkonecny[m]> what is blocking us from the spin creation
17:03:49 <anthr76[m]> Fale[m]: If you would like that would be great.
17:04:23 <Fale[m]> I think priorities are: 1. change approval, 2. eventually clean the build process (if needed) 3. open PRs for the inclusion in official build process repos
17:04:28 <anthr76[m]> $dayjob has been in turmoil resulting in my schedule going sideways. Things are normalizing but I've been expecting that for the past month or so
17:05:49 <alebastr[m]> jkonecny[m]: there's https://gitlab.com/groups/fedora/sigs/sway/-/milestones, it allows to prioritize things
17:08:26 <jkonecny[m]> nice
17:09:22 <alebastr[m]> let me know if you need to add/edit milestones. I think everyone with developer access should be able to assign these
17:12:39 <alebastr[m]> #topic Open Floor
17:13:49 <alebastr[m]> anything to discuss here?
17:14:09 <philip_rhoades> I'm not clear - will there be a spin to test soon?
17:14:40 <Fale[m]> there is already a spin to test, but it is not official yet
17:14:49 <philip_rhoades> Right . .
17:14:51 <Fale[m]> hopefully soon there will be an official one
17:15:13 * anthr76[m] impatiently waits for a release on https://github.com/lbonn/rofi
17:15:17 <anthr76[m]> otherwise I don't have anything
17:15:38 <anthr76[m]> philip_rhoades: 👋 nice to see you here. I commonly see you on the mailing lists :)
17:16:05 <alebastr[m]> ah. I need to send a couple of patches to rofi-wayland.
17:16:06 <alebastr[m]> write and send...
17:17:41 <anthr76[m]> Related to the window searcher?
17:17:54 * alebastr[m] feels this 'need to send a couple of patches' applies to far too many projects
17:18:01 <philip_rhoades> anthr76[m] - thanks!
17:18:34 <alebastr[m]> yep. port of <https://github.com/davatorium/rofi/pull/1715> and a small improvement of icon lookup hack
17:20:35 <alebastr[m]> there's adaptive_sync option for kanshi (anyone wants to write a patch for this one?), utmp support for greetd, lots of things for waybar, not to mention my projects which look abandoned at this point
17:20:44 <jkonecny[m]> I wonder are we targeting Sway spin to F38 now ?
17:21:54 <anthr76[m]> I'm always open to trying a new thing. I just can't promise it'll be any good :)
17:22:23 <alebastr[m]> we are. there's nothing that suggests otherwise, right? we're not even late for change proposal deadlines)
17:22:25 <philip_rhoades> jkonecny[m] +1
17:22:41 <anthr76[m]> alebastr[m]: +1
17:24:45 <alebastr[m]> anything else before I close the meeting?
17:24:51 <anthr76[m]> Good here.
17:25:05 <jkonecny[m]> in that case we should move the date for Change proposal submission Milestone: https://gitlab.com/groups/fedora/sigs/sway/-/milestones
17:25:46 <alebastr[m]> ah. should I set it to Self-contained change deadline?
17:26:33 <alebastr[m]> I'm just afraid 2023-01-17 there won't look threatening enough
17:30:32 <alebastr[m]> 4 minutes of silence must mean we're finished
17:31:23 <alebastr[m]> #endmeeting