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