15:00:08 <bcotton> #startmeeting Prioritized bugs and issues
15:00:08 <zodbot> Meeting started Wed Feb  9 15:00:08 2022 UTC.
15:00:08 <zodbot> This meeting is logged and archived in a public location.
15:00:08 <zodbot> The chair is bcotton. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
15:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:08 <zodbot> The meeting name has been set to 'prioritized_bugs_and_issues'
15:00:08 <bcotton> #meetingname Fedora Prioritized bugs and issues
15:00:08 <zodbot> The meeting name has been set to 'fedora_prioritized_bugs_and_issues'
15:00:28 <bcotton> #topic Purpose of this meeting
15:00:28 <bcotton> #info The purpose of this process is to help with processing backlog of bugs and issues found during the development, verification and use of Fedora distribution.
15:00:28 <bcotton> #info The main goal is to raise visibility of bugs and issues to help  contributors focus on the most important issues.
15:00:28 <bcotton> #link https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/#_process_description
15:00:51 <bcotton> #topic Roll Call
15:01:38 * bcotton twiddles thumbs
15:03:08 * dustymabe twiddles back
15:04:03 * bcotton nudges mattdm
15:04:35 <mattdm> I am here!
15:04:35 <mattdm> S
15:04:46 <mattdm> Sorry got distracted by electrians :)
15:04:58 <bcotton> zap!
15:05:05 <mattdm> haha no
15:05:07 <bcotton> #topic Common Bugs review
15:05:08 <bcotton> #info Let's start with a check of the Common Bugs pages for supported releases and see if any should be nominated as Prioritized Bugs
15:05:08 <bcotton> #link https://fedoraproject.org/wiki/Common_F34_bugs
15:05:08 <bcotton> #link https://fedoraproject.org/wiki/Common_F35_bugs
15:06:33 <mattdm> also https://ask.fedoraproject.org/c/common-issues/141/none
15:06:43 * mattdm needs to talk to the QA team about that
15:07:10 <bcotton> ohai dusty!
15:08:06 <mattdm> I mnot really seeing anything that's jumping out
15:08:26 <bcotton> same
15:08:43 <bcotton> let's move on then
15:08:46 <bcotton> #topic Nominated bugs
15:08:46 <bcotton> #info 1 nominated bugs
15:08:46 <bcotton> #link https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&f1=flagtypes.name&f2=OP&list_id=10871664&o1=substring&query_format=advanced&v1=fedora_prioritized_bug%3F
15:08:54 <bcotton> #topic SELinux preventing systemd-network-generator from creating files in /run/systemd/network/
15:08:54 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=2037047
15:10:03 <mattdm> read read read
15:10:04 * dustymabe notes this affects f35 and rawhide
15:11:19 <bcotton> what's the effect of the service failing to start?
15:11:23 <mattdm> is coreos using systemd networkd by default?
15:11:39 <mattdm> if you're using networkd, pretty severe: no network
15:12:06 <dustymabe> the systemd-network-generator generates systemd-networkd files but also files for udev
15:12:17 <bcotton> so it's the secure configuration :-)
15:12:20 <walters> mattdm: ```... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/24ab5eca35cdd63b5c8e8819bbb661b45c72ddd2)
15:12:33 <walters> (yes it is that easy now - you can run FCOS as a container for exactly this type of thing)
15:13:27 <mattdm> Colin Walters: wait, coreos _in_ the container, running systemd?
15:13:51 <walters> No, not running systemd.  This is a requirement and benefit of https://fedoraproject.org/wiki/Changes/OstreeNativeContainer
15:14:28 <mattdm> Sorry I'm slow -- what's the connection to the bug?
15:14:37 <dustymabe> none
15:14:42 <walters> nothing - this is just an aside but I want to be sure that the "let's rethink our ostree builds as base image containers" propagates into the mindset
15:15:15 <walters> it is hopefully less typing to `podman run` than ask on chat for this type of stuff, that's all :smil
15:15:46 <walters> * it is hopefully less typing to `podman run` than ask on chat for this type of stuff, that's all
15:15:58 <walters> * mattdm: ```... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/abc54b052df4c52038f5ee036823a32c9e3e3454)
15:16:02 <bcotton> so dustymabe, is it fair to assume that passing network params to the kernel is a pretty common use case here?
15:16:06 <walters> * mattdm: ```... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/b6d6a93670630a0f34a7d9efbee573e4dcb9cf69)
15:16:26 <dustymabe> i mean - it's been supported for a long time
15:17:00 <dustymabe> any static networking that you want to apply in the initramfs is going to happen via kernel arguments (for the most part)
15:17:44 <dustymabe> this also happens to break our CI checks that verify no systemd stuff fails on boot
15:18:04 <bcotton> okay, this feels pretty prioritized to me :-)
15:18:11 <mattdm> yeah I agree
15:19:44 <bcotton> proposed #agreed 2037047 is accepted as a prioritized bug as it affects a common use case among a flagship offering
15:20:24 <dustymabe> to be clear even if someone isn't using networkd - if they pass in networking kargs they will see this failure (even if it is just cosmetic to them)
15:20:40 <mattdm> I think the first action is to note that in the bug and ask the team to prioritize it based our call here. If that doesn't get noticed we can escalate to the team directly.
15:21:15 <mattdm> Also, this is a systemd network directory and it makes sense for the default to be for systemd network generator to be able to write to that
15:22:05 <bcotton> #agreed 2037047 is accepted as a prioritized bug as it affects a common use case among a flagship offering
15:22:40 <bcotton> #topic Accepted bugs
15:22:40 <bcotton> #info 2 accepted bugs
15:22:40 <bcotton> #link https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&f1=flagtypes.name&f2=OP&list_id=10871665&o1=substring&query_format=advanced&v1=fedora_prioritized_bug%2B
15:22:53 <dustymabe> should I move the bug to f35 because that's where we're feeling the most pain right now?
15:22:57 <bcotton> #topic Lenovo ThinkPad T490, unable to boot following clean install, stuck at splash screen
15:22:57 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=1955416
15:23:37 <bcotton> dustymabe: i would, yeah
15:23:40 <dustymabe> k
15:24:02 <bcotton> so for the ThinkPad issue, it looks like there's a candidate fix upstream, but no good way to test it?
15:25:10 <bcotton> I don't see Mark in here
15:25:45 <mattdm> "in here" meaning "in this room"?
15:25:52 <bcotton> yes
15:26:03 <mattdm> good thing matrix has an invite feature :)
15:26:11 <bcotton> it sounds like he and Robbie Harwood were going ot have an out-of-band discussion, so I can check with Mark
15:26:19 <mattdm> +1 to that
15:26:21 <bcotton> is he actually on matrix? I thought he was on the IRC side last time
15:27:04 <bcotton> I can't invite him (I may still be going through the IRC bridge instead of on the native Matrix room) but for now...
15:27:15 <bcotton> #action bcotton to follow up with mpearson to see if he's able to make progress on testing
15:27:31 <bcotton> anything else on this one before we go to the next?
15:28:33 <mattdm> lgtm
15:28:44 <bcotton> #topic Flatpak using excessive space in /var/lib/flatpak/appstream
15:28:44 <bcotton> #link https://bugzilla.redhat.com/show_bug.cgi?id=2032528
15:29:24 <bcotton> doesn't seem like there's any progress on this. although i'm not sure there's a shared understanding of how much space we expect that directory to use, either
15:29:56 <mattdm> Yeah I talked to the desktop team about this yesterday. No progress on it.
15:30:26 <bcotton> But they are working on it?
15:30:27 <mattdm> No.
15:30:29 <mattdm> Hence no progress.
15:30:40 <bcotton> Ah
15:31:08 <mattdm> If you look in e.g /var/lib/flatpak/appstream/flathub/x86_64 you should see a long random directory name
15:31:17 <mattdm> that's the active one, and it's about 50mb
15:31:38 <mattdm> but if you do ls -la, you'll see a bunch of hidden ones (with . prefix)
15:31:43 <mattdm> those, aiui, are junk
15:32:05 <mattdm> on my system, the "good" directory takes 48mb, and then there's another 150mb of junk
15:32:29 <bcotton> i don't see it on either of my systems
15:32:40 <mattdm> Which is not great, but not gigabytes
15:33:11 <mattdm> Not sure what causes it -- maybe unclean shutdown, maybe mixing command-line and gui, maybe something else?
15:33:48 <bcotton> okay, so did the desktop team say what it would take to get them to work on it?
15:34:05 <mattdm> My other system is somewhat worse -- about 400mb of junk.
15:34:08 <bcotton> i feel like we should be getting either "yes, we're working on this" or "no, you can't make me"
15:34:40 <mattdm> I think maybe worth another push. It's definitely a problem. The issue is that they're between flatpak maintainers
15:35:22 <mattdm> i will take this action item
15:35:40 <bcotton> #action mattdm to follow up with Red Hat Desktop Team
15:35:48 <bcotton> cool, then i think that brings us to the end o' the list
15:36:11 <bcotton> #topic Next meeting
15:36:12 <bcotton> #info We will meet again on 23 February at 1600 UTC in #fedora-meeting-1
15:36:30 <bcotton> spoiler alert: that will probably be cancelled due to lack of participation
15:36:39 <bcotton> oops
15:36:41 <bcotton> #undo
15:36:41 <zodbot> Removing item from minutes: INFO by bcotton at 15:36:12 : We will meet again on 23 February at 1600 UTC in #fedora-meeting-1
15:36:51 <bcotton> #info We will meet again on 23 February at 1500 UTC in #fedora-meeting-1
15:37:06 <bcotton> it will still probably be cancelled due to lack of participation, though :-)
15:37:26 <bcotton> anything else before we call it a day?
15:37:33 <mattdm> yeah I won't be here
15:37:49 <mattdm> or on the 2nd for that matter. So see you March 9th
15:37:53 <mattdm> thanks for running, ben!
15:37:59 <bcotton> :-D
15:38:02 <bcotton> #endmeeting