14:03:31 <alebastr[m]> #startmeeting Fedora Sway SIG (2022-08-10) 14:03:31 <zodbot> Meeting started Wed Aug 10 14:03:31 2022 UTC. 14:03:31 <zodbot> This meeting is logged and archived in a public location. 14:03:31 <zodbot> The chair is alebastr[m]. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 14:03:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:03:31 <zodbot> The meeting name has been set to 'fedora_sway_sig_(2022-08-10)' 14:03:41 <alebastr[m]> .hello alebastr 14:03:42 <zodbot> alebastr[m]: alebastr 'Aleksei Bavshin' <alebastr89@gmail.com> 14:04:03 <anthr76[m]> .hello anthr76 14:04:04 <zodbot> anthr76[m]: anthr76 'Anthony Rabbito' <hello@anthonyrabbito.com> 14:04:23 <JackHildebrandt[> .hello onemorebyte 14:04:24 <zodbot> JackHildebrandt[: onemorebyte 'Jack Hildebrandt' <jack@jackhil.de> 14:05:52 <alebastr[m]> I think we can reorder some stuff since Jiri is busy, so let's start with rhel9 14:06:26 <Fale[m]> .hello fale 14:06:27 <zodbot> Fale[m]: fale 'Fabio Alessandro Locati' <me@fale.io> 14:06:41 <alebastr[m]> #topic Bug 2099901 - Please branch and build sway in epel9 14:07:19 <alebastr[m]> The main question is if anyone is interested and have time to work on this 14:07:42 <anthr76[m]> I have yet to do anything epel related, but I think it would be neat to see sway there 14:08:13 <JackHildebrandt[> I have some free time, but I've never worked with epel before. 14:09:06 <alebastr[m]> Sway 1.5 should build there with the wayland 1.19 downgrade patch (unfortunately wayland 1.20 did not get into rhel9) 14:09:29 <Fale[m]> usually the pain in epel is dependencies, but el9 should be new enough to not be a huge pain 14:10:05 <defolos> at the moment 14:10:16 <defolos> epel will stay mostly frozen 14:10:30 <defolos> please just keep that in mind 14:10:48 <Fale[m]> @defolos: yes, that's the issue. the risk is committing to maintain sway 1.5 for years to come 14:10:58 <defolos> yep 14:11:02 <defolos> I wouldn't do it tbh 14:11:18 <defolos> that's why I don't do this with i3 14:11:38 <defolos> and I'm afraid that sway upstream is even less enthusiastic about lts maintenance than i3 upstream 14:12:32 <Fale[m]> the biggest risk I see is that sway 1.6 will require wayland 1.20+ with no downgrade patch, and at that point we will not be able to update sway anylonger and the full maintenance work is on us at that point 14:12:58 <alebastr[m]> It's not like there's a lot of maintenance. We'll just have to freeze epel9 at 1.5. 14:13:41 <alebastr[m]> And I have to admit that I've been mostly ignoring crash reports anyways :) 14:13:59 <alebastr[m]> especially the weird ones pointing to the mesa's iris_drv.so 14:14:17 <Fale[m]> @alebastr if we agree to close all bug filed as "not going to fix it", yes, otherwise the amount of bugs will increase over time 14:15:36 * alebastr[m] prefers to ignore bugs until they EOL, but... in epel's case that's not a viable strategy 14:17:16 <alebastr[m]> but there are no el9 desktop users here, right? 14:17:25 <Fale[m]> * epel9 should eol in 2032 14:17:53 <Fale[m]> there surely are some EL9 desktop users, otherwise we would not have the request in the first place ;-) 14:18:18 <Fale[m]> probably not very many, though 14:20:40 <alebastr[m]> hm. I'll just ask the bug reporter if they are interested in testing/providing patches to reduce our maintenance burden. as it looks like we don't want to commit to that 14:21:00 <alebastr[m]> or we can do things unofficially in copr 14:21:32 <defolos> Facebook/Meta is atm deploying CentOS stream for a subset of their devs as desktop machines 14:21:55 <defolos> at least that's what I've heard Michel Alexandre Salim say 14:22:14 <defolos> so there are el9/rhel9 desktop users, just not so many π 14:25:17 <alebastr[m]> #info There are no EL9 desktop users among the SIG and we're not ready to commit to a long-term maintenance of a frozen sway version (1.5) 14:26:16 <alebastr[m]> #action alebastr to reply in the bug and offer unofficial (copr) maintenance/request for assistance 14:27:03 <alebastr[m]> Now let's move on to the next item 14:27:25 <alebastr[m]> #topic Included software 14:27:39 <alebastr[m]> #link https://gitlab.com/fedora/sigs/sway/SIG/-/issues/1 14:28:45 <alebastr[m]> We briefly mentioned `system-config-printers` and I see that a few other spins also ship it. 14:30:05 <alebastr[m]> There's a cups web admin ui, but it's not as user-friendly and I started suspecting that nobody knows about it. So do we want to add s-c-p to the comps? 14:31:12 <Fale[m]> I like the web UI, but I agree it is probably not very well known/discoverable. I'm +1 with `system-config-printers` addition 14:32:08 <defolos> I'd suggest to add it, not many are aware of the webui and expect a gui app to exist 14:32:17 <Fale[m]> (I wonder though, does it depend on X11? If so, I don't like it :-D) 14:33:09 * anthr76[m] just learns `system-config-printers` exist. For better or worst I always configure printers in the CUPs web-gui mostly I guess because I use a zebra label printer and most easy-guis restrict some options needed to get it set up correctly. If we're thinking about shipping gui things for printer one minor annoyance I've had is the lack of simple-scan in workstation-ostree base packages. This has some context 14:33:09 * anthr76[m] https://github.com/fedora-silverblue/issue-tracker/issues/242 14:33:10 <alebastr[m]> Fale: don't worry, we won't be able to get rid of X11 _libraries_ anyways. There's a ton of software that supports both Wayland and X11. 14:34:33 <anthr76[m]> Given that and this is a sway spin I will vote -1 to include `system-config-printers` to keep things "minimal", but I have no obligations if that get's vetoed and we ship with it 14:35:41 <anthr76[m]> Does i3-spin include `system-config-printers` ? defolos 14:35:45 <defolos> anthr76: please consider that a spin is intended for newcommers and should offer a simple UX 14:36:00 <alebastr[m]> I need to check what our QA considers base criteria of working environment :) 14:36:48 <alebastr[m]> but if we default to web ui, we'll need to add a 'How do I do X' style list of tips to the documentation 14:37:39 <anthr76[m]> Yes understood defolos and brought it up a few times including packages for file-managers, network-manager(nmtui, or graphical), and etc. I just think If we ship a somewhat incomplete printing experience we might as well keep it at 40% instead of 60%. The web gui *isn't that bad* 14:37:53 <defolos> anthr76[m]: yes 14:38:00 <defolos> https://pagure.io/fedora-kickstarts/blob/main/f/fedora-i3-common.ks#_26 14:38:04 <anthr76[m]> ,but this begs the question we commonly seem to run into. Our target audience 14:38:15 <defolos> your target audience are newcommers to sway 14:38:26 <defolos> that's what we get with i3 as well 14:38:40 <defolos> most people who get the spin don't even know how to use i3! 14:38:55 <defolos> they just saw cool screenshots and someone told them to use fedora 14:38:57 <defolos> so they grab the spin 14:39:01 <anthr76[m]> * Yes understood defolos and I've brought it up a few times including packages for file-managers, network-manager(nmtui, or graphical), and etc. I just think If we ship a somewhat incomplete printing experience we might as well keep it at 40% instead of 60%. The web gui _isn't that bad_ 14:39:22 <defolos> don't optimize for power users, they will tweak their environment to their liking anyway 14:39:31 <defolos> and they know how to 14:39:47 <jkonecny[m]> .hello jkonecny 14:39:48 <zodbot> jkonecny[m]: jkonecny 'JiΕΓ KoneΔnΓ½' <jkonecny@redhat.com> 14:39:52 <defolos> optimize for the newcommer, who expects a nice polished desktop experience 14:40:08 <defolos> .hello defolos 14:40:09 <zodbot> defolos: defolos 'Dan ΔermΓ‘k' <dan.cermak@cgc-instruments.com> 14:40:14 <defolos> might as well join π 14:40:42 <alebastr[m]> btw, I believe we ship enough of cups to have working printing in the ostree. 14:40:45 <anthr76[m]> I agree. I also do fantasize about having a 'as minimal as possible' base and let users develop some of their own opinions . It's just a really hard line to walk not breaking new comers 14:41:20 <Fale[m]> @defolos although I agree with you, I wonder if for ostree spins this still applies 14:41:36 <alebastr[m]> defolos: some tinkering and knowledge is still expected. Notice how we're trying to be careful with not going too far from the upstream sway config 14:41:36 <defolos> Fale: for ostree even more 14:41:56 <defolos> in ostree it's an even larger pita to add things 14:43:09 <jkonecny[m]> I don't think that a few packages more is that problematic? 14:43:29 <Fale[m]> @defolos yes, also to tweak for power users. At the same time I wonder if a new user would choose an rpm-ostree based spin 14:43:48 <defolos> Fale: yep 14:43:57 <JackHildebrandt[> Ya, I agree. I think this isn't too much of a divergence from minimalism and would help newcomers. 14:43:57 <jkonecny[m]> I know that OSTree makes this harder but in general I'm using SilverBlue with layered Sway now and it works just fine 14:43:57 <defolos> because it's marketed as indestructible π 14:44:00 <anthr76[m]> Agreed. I think on FCOS you should try much hard to not overlay packages, but it's really hard not to overlay a few critical packages 14:45:34 <jkonecny[m]> sorry, I'm a bit lost, are we still debating the `system-config-printers`? 14:46:22 <anthr76[m]> There's are my current overlays from a 'power user' which I consider critical for my day to day tasks.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/5f0c1cdac3392397d9784becfea467472cfa29c5) 14:46:29 <anthr76[m]> s/You/I/ 14:46:38 <anthr76[m]> Which is why I usually maintain my own tree 14:46:38 <alebastr[m]> wait, fprintd is not in a base package set? 14:47:06 <anthr76[m]> Not to my knowledge no, I was messing around with getting finger print working but I haven't done much with it yet 14:48:06 <alebastr[m]> ah. it's not a part of any base groups, so DEs are including it explicitly 14:49:59 <pxl_sg[m]> Hi guys, am I allowed to weigh in? 14:50:16 <alebastr[m]> hm. it's in `standard` but that's not a part of `workstation-product-environment` which is the base layer for ostree 14:50:29 <alebastr[m]> pxl_sg: sure 14:50:43 <jkonecny[m]> pxl_sg: this is a private discussion π π -- not really feel free to say what you have on your mind π 14:51:20 <defolos> jkonecny: you meant **not** a private discussion, right? 14:51:23 <defolos> π 14:53:16 <pxl_sg[m]> π not used yet to contributing. 14:53:16 <pxl_sg[m]> I think the whole point of having a spin with a specific WM is to bring it closer to a more complete DE, so having the basic necessary graphical tools seems to make sense to me. I think having system-config-printers would then make sense 14:53:47 <defolos> can only agree to that pxl_sg 14:54:00 <alebastr[m]> > <@anthr76:mozilla.org> There's are my current overlays from a 'power user' which I consider critical for my day to day tasks.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c29c7187654e92c4e945b282cf05e89aa9a4114c) 14:54:16 <pxl_sg[m]> Power users might build their Fedora from a minimal install, they donβt need a spin 14:55:00 <defolos> pxl_sg[m]: exactly my point from above π 14:55:12 <anthr76[m]> alebastr[m]: Indeed, but seems like 'extra-bloat' if you don't have thunderbolt doesn't it? 14:56:11 <alebastr[m]> fair enough. I'll be fine with layering it 14:56:49 <anthr76[m]> I would like to know if bolt acts as a back-end for DE's like gnome and KDE in that case I think we should include it. I'd much rather see bolt added then `system-config-printers` :P 14:57:17 <alebastr[m]> fprintd though is a part of the authselect generated configs (is it enabled by default?), so I'd rather see it in the base image 14:58:06 <anthr76[m]> Me too. 14:58:13 * alebastr[m] sends blessings to Lenovo for an actual working OOTB fingerprint reader without repackaging binary drivers from .deb 15:00:00 <anthr76[m]> Without getting too off-topic from printing if we're in agreeance we should ship `system-config-printers` we should at least see what it takes to include `simple-scan` 15:00:06 <anthr76[m]> IMO 15:01:41 <alebastr[m]> anthr76: want to look into that and see how it affects the dependencies/tree size? 15:01:47 <anthr76[m]> Sure 15:03:02 <alebastr[m]> I'm not going to propose xsane because the name is not quite compatible with our spin, but that's what I keep using for many years. So there are alternatives :) 15:04:22 <alebastr[m]> #action anthr76 investigate including `simple-scan` (or an alternative scanning utilities) and post results into gitlab ticket 15:04:52 <alebastr[m]> but I fear that scanning stack may be a bit heavier than cups 15:04:55 <jkonecny[m]> honestly I would include also `bolt` 15:05:54 <jkonecny[m]> I know it's not on all the machines and there it could be taken as bloat but still it's not that rare these days 15:06:17 <alebastr[m]> anthr76: kde requires bolt via plasma-thunderbolt 15:06:20 * anthr76[m] hope's USB4 kills TB 15:06:44 <jkonecny[m]> sorry for late reaction - was on the meeting (third one during this meeting) π 15:07:17 <alebastr[m]> and gnome-shell requires it as well 15:07:32 <anthr76[m]> In that case I say we add it 15:07:56 <alebastr[m]> ok. so anyone against including `fprintd-pam` or `bolt`? 15:08:12 <alebastr[m]> (note that we can always reconsider that at a later point) 15:08:15 <jkonecny[m]> in general I would like us to include HW support stuff (even the `fprintd`) because it's not that painful to have it in case you don't need it than trying to discover what you need to make it work... 15:09:08 <alebastr[m]> might have to do a tree size optimization step closer to the release and revisit all the choices :) 15:09:38 <anthr76[m]> +1 at this moment I think we're doing fine 15:09:44 <Fale[m]> +1 15:10:02 <pxl_sg[m]> +1 15:10:52 <alebastr[m]> #action alebastr to add `system-config-printer`, `fprintd-pam`, `bolt` to the comps 15:11:33 <defolos> π 15:11:44 <alebastr[m]> we're already behind the schedule, but do we want to talk about software a bit more or move to the ostree spin name? 15:12:56 <StefanoFiguraret> QQ out of curiosity. Are you guys planning to have also a customised toolbox version along with the ostree spin? 15:13:17 <jkonecny[m]> I don't think that is necessary or really much helpful 15:13:26 <jkonecny[m]> but maybe I'm missing something 15:13:43 <anthr76[m]> No, I do maintain my own but I find doing that against the grain of what other spins do is a bit off-putting and opinionated 15:14:11 <jkonecny[m]> alebastr: I would like to discuss everything but times fly and we can return to the software selection in the future meetings. It could take a lot of time to decide π 15:14:44 <jkonecny[m]> So I'm for moving to the names 15:15:03 <alebastr[m]> ok. so we can have foot vs. alacritty holywar next time 15:15:17 <anthr76[m]> I'd be happy to work with others on developing a opinionated toolbox image outside of the sway-sig. I've maintained a arch variant for sometime and slowly trying to get my tooling into fedora so packaging and UX is easier 15:15:59 <alebastr[m]> #topic Name for the ostree spin 15:16:01 <alebastr[m]> #link https://gitlab.com/fedora/sigs/sway/SIG/-/issues/5 15:17:13 <anthr76[m]> Of what was suggested so far `Sodalite` has been my favorite 15:17:47 * anthr76[m] is really bad at naming things 15:18:02 <alebastr[m]> I know we want to unblock the development, but I had the idea of bringing that to a wider community. Post to discussion.fp.o, /r/Fedora, etc. 15:18:40 <jkonecny[m]> np with that if we have an action item what to do with that. My point to bring it here was mainly to push it a bit 15:18:56 <alebastr[m]> Not that I dislike `Sodalite`, I'm ready to accept it and rebuild forked fedora-release right now :) 15:18:56 <anthr76[m]> I like that idea 15:19:10 <anthr76[m]> +1 15:20:18 <Fale[m]> I think we can extend to other people to propose options, but I belive not many will chip in. So, as long as we decide a deadline (ie: next meeting) we can ask around 15:21:07 <pxl_sg[m]> Fale[m]: Shall it be a closed question? (Few options to chose from) or open question? (Any new idea welcome) 15:21:09 <Fale[m]> also, to extend to other people, I guess we should clarify the criteria we are going to use 15:21:34 <jkonecny[m]> I wonder if Sway community would be interested in helping us with the name? Maybe it's too Fedora specific to ask them but could be fun for them 15:22:13 <Fale[m]> at the moment, the only mineral that is blue/grey and starts with 's' is sodalite. So, if those are the criteria we want to use, the only option is an open question 15:22:21 <jkonecny[m]> pxl_sg: I think it should be an open question, we are looking for another alternatives. Seems that internally we have a favorite already 15:22:39 <anthr76[m]> IMO, I think the world knowing a Fedora sway spin is coming is still quite "under the radar" and I think some community outreach and involvement is a good idea 15:23:29 <alebastr[m]> Fale: starts with s is not a mandatory. general similarity may be better, see XFCE - Vauxite. 15:24:33 <jkonecny[m]> I wonder where and how to ask? Maybe a blog post, Fedora change (probably not), or fedora-devel list with sway list? 15:25:08 <Fale[m]> I can make a blog post (that will endup on planet) 15:26:05 <jkonecny[m]> We can push the blog post to Fedora Magazine too https://fedoramagazine.org/ 15:26:09 <alebastr[m]> I believe the most active community for sway is /r/swaywm. But we can just drop the link to the blog post there 15:26:46 <alebastr[m]> and our list is just too empty :( 15:26:57 <Fale[m]> Fedora Magazine usually has a fairly strict editorial line, not sure if this would be within it 15:31:00 <Fale[m]> if we agree on this, I can pick up the creation and pubblication of the blog post on my blog (which is syndacated on fedora planet) and we can then share it in various places 15:31:24 <alebastr[m]> +1 15:31:44 <alebastr[m]> (reactions are not visible in IRC and don't get into the meeting log) 15:32:23 <anthr76[m]> +1 15:32:38 <Fale[m]> I can publish it between tomorrow and friday and we can put a deadline for the 23rd so that by next meeting we can pick the name 15:32:43 <anthr76[m]> I can post to discussion.fp.o if there's no takers 15:32:48 <jkonecny[m]> +1 15:33:17 <jkonecny[m]> +1 for discussion.fp.o and also the blog post 15:33:42 <jkonecny[m]> then sent mail to fedora-devel and sway Redit 15:34:19 <pxl_sg[m]> How to collect all the ideas? Thru the gitlab ticket? 15:34:53 <Fale[m]> I suspect the gitlab ticket write access is limited to fedora contributors 15:34:58 <alebastr[m]> that would require gitlab account 15:35:11 <jkonecny[m]> I would go with something which don't require login in general? 15:35:19 <alebastr[m]> Fale: should be open to everyone logged in, not just fedora contributors 15:35:19 <Fale[m]> a google form? not the best option, but should be fairly easy to use 15:35:31 <jkonecny[m]> google form seems good to me 15:35:55 <jkonecny[m]> I wonder if that needs login but most of the people probably have it anyway 15:36:00 <jkonecny[m]> compared to gitlab 15:36:10 <Fale[m]> another option would be blog comments 15:36:31 <Fale[m]> @jkonecny iirc, you do not need it, but an "email" field will be required 15:36:46 <jkonecny[m]> kk, good 15:36:48 <pxl_sg[m]> Fale[m]: Blog comments and reddit replies. I think they are more organic and genuine 15:37:16 <Fale[m]> yes, collecting then the data from the various platform we shared it on 15:37:42 <jkonecny[m]> we probably won't get so many ideas so should be fine 15:38:26 <Fale[m]> oki, so I propose to go with the organic system 15:39:38 <jkonecny[m]> np with that, don't have a preference here 15:40:14 <anthr76[m]> +1 15:40:45 <alebastr[m]> #action fale to write a blog post about the spin name and share it 15:41:43 <alebastr[m]> #agreed to make a decision on the next meeting (in 2 weeks) based on the community feedback 15:42:16 <alebastr[m]> #topic Open floor and general progress discussion 15:43:18 <anthr76[m]> We'll make this quick as work is getting a bit busier. I will check out our new config mechanism alebastr implemented and jkonecny helped out with. Overall looks good and appreciate the work :) 15:43:23 <anthr76[m]> I shall actually test it tonight 15:43:26 <jkonecny[m]> what is the state of the normal spin variant? Is someone working on that now? 15:44:14 <jkonecny[m]> I was mainly annoyed people with my feedback, credit goes to alebastr here π 15:45:12 <alebastr[m]> The comps work is common and is in progress. Other than that we need installer and live system configuration. 15:46:08 <jkonecny[m]> the installer support should probably go on me. I can try to look on those during evenings. What exactly is required right now? Configuration for Anaconda? 15:46:15 <alebastr[m]> installer is pretty much anaconda profiles + copy-paste from i3 kickstart 15:46:53 <alebastr[m]> and we can keep anaconda profiles in our repo for now (as long as it gets into the installer live system, right?) 15:47:16 <jkonecny[m]> yes, it could be distributed 15:47:23 <jkonecny[m]> most of these are part of the Anaconda repository 15:47:30 <jkonecny[m]> but I don't see i3 there 15:47:43 <jkonecny[m]> I guess they have it in separate RPM? 15:48:00 <alebastr[m]> i3 relies on generic profile being good enough, I guess 15:48:33 <jkonecny[m]> ok 15:48:40 <jkonecny[m]> should be probably fine 15:49:19 <alebastr[m]> the question is, how do they pre-select the environment group if that's the case 15:49:19 <jkonecny[m]> so I can pick the ks files if you want 15:49:29 <jkonecny[m]> at least I would learn the process 15:50:11 <anthr76[m]> Does anyone have any idea how to make a ostree iso? I presume that requires a special kick-start? 15:50:33 <anthr76[m]> s/kick-start/kickstart/ 15:50:46 <jkonecny[m]> alebastr[m]: I think it's solved by a diferrent repository / comps there? I'll find that out π 15:50:58 <jkonecny[m]> anthr76[m]: no 15:51:08 <jkonecny[m]> it's not a kickstart because it's not live 15:51:08 <alebastr[m]> jkonecny: sure, go ahead. I guess you'll need to add @sway-sig/sway-spin-dev to the installer, as it's where our comps groups and fedora-release-sway are currently published 15:51:16 <jkonecny[m]> these are handled by lorax templates 15:52:09 <jkonecny[m]> "@sway-sig/sway-spin-dev to the installer" what do you mean by that? 15:52:46 <alebastr[m]> copr repository. you won't be able to see the sway groups in the package selection without it 15:52:59 <jkonecny[m]> alebastr: ok 15:56:14 <alebastr[m]> I've been trying to write docs for a config system and realized that my priority system (20-.conf, 30-,etc...) is quite inconsistent. I'll try to publish a merge request later, but in the meantime I'm open to an ideas on splitting and sorting the config snippets. 15:57:34 <alebastr[m]> how do we want to group things (settings, bindings, window rules, workspaces, system components, autostart apps, etc) and what is the expected order 15:59:00 <anthr76[m]> Can't answer that well without reviewing again 15:59:18 <anthr76[m]> So maybe have that as a topic for next meeting? 16:00:45 <alebastr[m]> or just discuss in the merge request 16:01:03 <anthr76[m]> That works 16:02:25 <alebastr[m]> if there's no other things to discuss, I'm going to close the meeting in a minute or two 16:03:27 * anthr76[m] get's increased amounts of pings at $dayjob 16:04:12 <anthr76[m]> So I will chat soon. I will leave you all with this https://twitter.com/sysrich/status/1557101373996650504 looks like another sway immutable variant might be coming soon :) 16:04:28 <pxl_sg[m]> <alebastr[m]> "I've been trying to write docs..." <- Happy to help on this 16:04:28 <alebastr[m]> I guess I'm not biking to the office today. Too late for that :) 16:05:50 <pxl_sg[m]> Day is over for me! Midnight here, i go sleep 16:06:20 <alebastr[m]> #endmeeting