16:01:02 <adamw> #startmeeting F32-blocker-review
16:01:02 <zodbot> Meeting started Mon Mar  9 16:01:02 2020 UTC.
16:01:02 <zodbot> This meeting is logged and archived in a public location.
16:01:02 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:02 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:01:02 <adamw> #meetingname F32-blocker-review
16:01:02 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:01:02 <adamw> #topic Roll Call
16:01:18 <adamw> morning morning
16:01:20 <adamw> how is everybody?
16:01:25 * pwhalen is here
16:01:34 <pwhalen> doing well, yourself?
16:01:36 <coremodule> good morning adamw, pwhalen
16:01:52 * kparal is here
16:02:01 * kalev is here
16:02:06 <adamw> doing great
16:02:13 * coremodule is here
16:02:14 <adamw> i met william gibson yesterday! still internally squealing
16:03:25 <cmurf> haha
16:03:26 <pwhalen> adamw, very cool :)
16:03:27 <kparal> adamw: does he use Fedora now? :)
16:04:11 <adamw> haha, i don't think so
16:04:12 <adamw> he had an ipad
16:04:45 * jsmith joins a bit late, sorry
16:05:25 <adamw> .fire jsmith
16:05:25 <zodbot> adamw fires jsmith
16:05:35 <jsmith> Didn't that happen like years ago?
16:05:51 * jsmith ducks and hides
16:05:57 <adamw> probably!
16:06:47 <cmurf> adamw rehires just so he can fire
16:06:58 <adamw> always at a worse salary, though.
16:07:11 <adamw> #chair coremodule jsmith
16:07:11 <zodbot> Current chairs: adamw coremodule jsmith
16:07:16 <sgallagh> .hello2
16:07:16 <adamw> #topic Introduction
16:07:16 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:07:16 <adamw> Why are we here?
16:07:16 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:07:16 <adamw> #info We'll be following the process outlined at:
16:07:18 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:18 <adamw> #info The bugs up for review today are available at:
16:07:20 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:22 <adamw> #info The criteria for release blocking bugs can be found at:
16:07:24 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:07:26 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria
16:07:28 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria
16:07:47 <adamw> #info for Beta, we have:
16:07:48 <adamw> #info 5 Proposed Blockers
16:07:48 <adamw> #info 4 Accepted Blockers
16:07:53 <adamw> #info 1 Accepted Previous Release Blockers
16:07:53 <adamw> #info 12 Proposed Freeze Exceptions
16:07:53 <adamw> #info 1 Accepted Freeze Exceptions
16:07:56 <adamw> #info for Final, we have:
16:08:05 <coremodule> I can act as secretary, but I have an appointment in an hour that will prevent me from doing the secretary work right after the meeting.... It'll be more like 3 hours later that I'll be able to get to it
16:08:07 <adamw> #info 3 Proposed Blockers
16:08:07 <adamw> #info 3 Accepted Blockers
16:08:13 <coremodule> oops...
16:08:20 <adamw> coremodule: that should be fine, i'll do any that really need doing in the middle
16:08:30 <adamw> #action coremodule will secretarialize, with adamw as emergency cover
16:08:35 <coremodule> cool, then consider me your secretary
16:08:38 <adamw> doh
16:08:39 <adamw> #undo
16:08:39 <zodbot> Removing item from minutes: ACTION by adamw at 16:08:30 : coremodule will secretarialize, with adamw as emergency cover
16:08:43 <adamw> #info coremodule will secretarialize, with adamw as emergency cover
16:08:55 <adamw> alrighty! let's get right in there
16:09:00 <adamw> #topic Proposed Beta blockers
16:09:06 <adamw> #topic (1807252) bootloader entry missing after installation on armhfp
16:09:06 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1807252
16:09:06 <adamw> #info Proposed Blocker, anaconda, MODIFIED
16:09:08 <adamw> oh crap
16:09:15 <adamw> i was supposed to follow up on this with...someone
16:09:32 <adamw> i even started doing it at some point! i must have been distracted by something shiny
16:09:58 <Southern_Gentlem> +1 blocker
16:10:05 <adamw> oh right i got distracted by noting we accepted it as an FE. and there's a fix. so, we can probably just punt and it'll go away
16:10:20 * adamw gets Punt And It'll Go Away: Fedora Blocker Crew t-shirts printed
16:10:31 <Southern_Gentlem> +1 punt then
16:10:38 <sgallagh> I'm a medium, FTR ;-)
16:10:46 <pwhalen> adamw, and we have a build now
16:10:53 <adamw> progress!
16:11:43 <sgallagh> Criteria should apply to all blocking images, right?
16:11:56 <sgallagh> There are no longer any blocking 32-bit images to my knowledge
16:12:07 <pwhalen> sgallagh, minimal is blocking
16:12:15 <lruzicka2> .hello2
16:12:16 <sgallagh> ah
16:12:16 <zodbot> lruzicka2: Sorry, but you don't exist
16:12:26 <pwhalen> but this is for installations, disk images arent affected.
16:12:34 <kalev> pwhalen: should it be blocking still or is it just an oversight?
16:12:42 <adamw> sgallagh: that was the question
16:12:47 <adamw> that i was supposed to follow up on this week
16:12:48 <lruzicka2> .hello lruzicka
16:12:49 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:12:49 <adamw> and sort of forgot to
16:12:51 <adamw> hence the punt
16:12:51 <pwhalen> so installing our builders
16:13:34 <pwhalen> kalev, minimal should be blocking, yes. The only change was removing the desktop.
16:13:43 <kalev> ok
16:13:48 <adamw> proposed #agreed 1807252 - punt (delay decision) - we still don't have definitive word on whether we should block on 32-bit ARM installer issues currently, but this is accepted FE and a fix will be included in the next build
16:14:06 <kalev> ack
16:14:07 <pwhalen> its built. we just need to pull it in
16:14:09 <Southern_Gentlem> ack
16:14:17 <sgallagh> adamw: I thought pwhalen just said 'minimal is blocking'
16:14:18 <adamw> pwhalen: the minimal *disk image* is blocking :)
16:14:22 <sgallagh> ah
16:14:38 <adamw> from what we could tell last week, no 32-bit installer image has been listed as release blocking for quite a while
16:14:50 <kparal> ack
16:15:19 <lruzicka2> ack
16:15:32 <pwhalen> ack
16:15:33 <coremodule> ack
16:15:35 <sgallagh> ack
16:15:49 <Southern_Gentlem> ack
16:17:02 <adamw> #agreed 1807252 - punt (delay decision) - we still don't have definitive word on whether we should block on 32-bit ARM installer issues currently, but this is accepted FE and a fix will be included in the next build
16:17:11 <adamw> #topic (1810963) Support OpenDNSSEC 2.1 in FreeIPA
16:17:11 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1810963
16:17:11 <adamw> #info Proposed Blocker, freeipa, ASSIGNED
16:17:15 <adamw> ab: around?
16:17:33 <adamw> so here's my best understanding of the situation:
16:18:04 <adamw> this is basically a request to include opendnssec and an updated freeipa in Beta. the update *as it stands now* is not good enough; more work needs doing on freeipa, apparently. ab was requesting we pull it in once that's done.
16:18:42 <adamw> if that understanding is correct, for me this is clearly -1 blocker (the opendnssec and freeipa we have in stable right now work fine) and i'm also -1 FE as it's too late to be waiting for them to do major work and then pulling it into beta.
16:19:52 <pwhalen> -1/-1 based on that understanding
16:20:07 <kalev> I agree. -1 blocker, -1 FE
16:20:13 * lruzicka2 shrugs
16:20:26 <coremodule> -1 blocker, -1 FE
16:20:27 <sgallagh> -1/-1
16:23:12 <cmurf> well an FE would necessarily need to be a tested and revertable thing, but yeah this week is go/no-go kinda late but what are the chances of go?
16:23:45 <sgallagh> I'm -1 FE even if we are No-Go this week
16:23:46 <adamw> proposed #agreed 1807252 - RejectedBlocker (Beta), RejectedFreezeException (Beta) - as we understand it this bug is a request to pull a new opendnssec and a FreeIPA build updated to work with it into Beta. This is clearly not release-blocking as it doesn't fix some criteria-breaking bug we have in current Beta packages. We also reject it as for FE status as we think it's not 'baked' enough yet given where we are in the Beta cycle
16:23:51 <adamw> I think I would be too
16:24:02 <sgallagh> I don't want to introduce potentially breaking changes that might extend the delay further
16:25:03 <Southern_Gentlem> -1/-1
16:26:02 <cmurf> ack
16:26:12 <Southern_Gentlem> ack
16:26:33 <pwhalen> ack
16:26:51 <kparal> ack
16:26:54 <kalev> ack
16:27:06 <lruzicka2> ack
16:27:07 <adamw> #agreed 1807252 - RejectedBlocker (Beta), RejectedFreezeException (Beta) - as we understand it this bug is a request to pull a new opendnssec and a FreeIPA build updated to work with it into Beta. This is clearly not release-blocking as it doesn't fix some criteria-breaking bug we have in current Beta packages. We also reject it as for FE status as we think it's not 'baked' enough yet given where we are in the Beta cycle
16:27:14 <adamw> #topic (1807661) Display corruption on aarch64 virtual machines
16:27:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1807661
16:27:14 <adamw> #info Proposed Blocker, kernel, NEW
16:28:11 <Southern_Gentlem> is this a release blocking arch
16:28:21 <pwhalen> *sigh* so this breaks openqa for all server testing
16:28:41 <pwhalen> Southern_Gentlem, yes for server and workstation
16:29:01 <adamw> yeah.
16:29:10 <adamw> so, as far as can grok it at present, this bug affects all aarch64 VMs
16:29:17 <Southern_Gentlem> +1 blocking
16:29:18 <adamw> it does not seem to affect bare metal
16:29:47 <Southern_Gentlem> not effecting bare metal then is it a kernel issue
16:29:47 <pwhalen> right, just vm's so primarily breaks automated testing
16:29:57 <adamw> so i suppose as well as the 'it breaks openqa so affects test coverage' argument, we can cite the virt criteria: "The release must be able host virtual guest instances of the same release" - OK, it *can*, but you get a ton of screen corruption
16:30:15 <adamw> Southern_Gentlem: kernel, qemu or edk2 would be the main suspects
16:30:43 <sgallagh> adamw: I'd be in favor of +1 FE and leaving a blocker decision up to the Go/No-Go meeting
16:30:45 <pwhalen> yea, its not fun. It seems to affect 5.5 but not as much. Going back to 5.4 it works fine
16:30:46 <kparal> that's a good criterion for having it as a blocker
16:30:56 <pwhalen> so installing 5.4 on the vm
16:31:04 <sgallagh> (Because I'm not so sure this would pass the "last blocker" test)
16:31:14 <adamw> i think i'd +1 this even as last blocker
16:31:16 <adamw> i mean
16:31:21 <adamw> would we release if x86_64 was like this?
16:31:29 <kalev> definitely no
16:31:33 <kparal> +1 per criteria, why wouldn't we want to accept this?
16:31:33 <pwhalen> sgallagh, nor I. Just means its harder to do the hero testing sometimes needed before a release
16:32:13 <cmurf> +1 blocker
16:32:16 <kalev> I feel convinced. +1 blocker from me as well then
16:32:29 <Southern_Gentlem> +1 blocking
16:32:50 <sgallagh> 0/+1
16:35:00 <adamw> any other votes?
16:35:07 <adamw> at present we're at +4 / -0
16:35:32 <pwhalen> +1 final blocker for me, gives more time to work it out
16:35:39 <pwhalen> 0 beta blocker
16:36:19 <kparal> the criterion is beta, right?
16:36:21 <adamw> yes
16:36:33 <Southern_Gentlem> pwhalen, wouldnt it still be a beta since it cannot be released unless this is fixed
16:37:02 <Southern_Gentlem> then you are holding up all of Beta over this
16:37:12 <adamw> proposed #agreed 1807661 - AcceptedBlocker (Beta) - accepted as a violation of "The release must be able host virtual guest instances of the same release" and for its impact on aarch64 testing coverage
16:37:15 <pwhalen> the criterion being the testing one?
16:37:28 <adamw> pwhalen: kparal was referring to the virt criterion, i believe
16:37:33 <Southern_Gentlem> ack
16:37:43 <cmurf> ack
16:38:22 <pwhalen> well, it does host the same release, graphics are broken but its still possible to use
16:38:26 <lruzicka2> ack
16:38:45 <pwhalen> ack
16:39:17 <kalev> ack
16:39:26 <adamw> #agreed 1807661 - AcceptedBlocker (Beta) - accepted as a violation of "The release must be able host virtual guest instances of the same release" and for its impact on aarch64 testing coverage
16:39:54 <adamw> pwhalen: yeah, we tend to read the criterion as covering sufficiently serious non-showstopper virt bugs too, like this one. we'd definitely cite it for an equivalent x86_64 bug.
16:40:02 <adamw> #topic (1809117) mdadm udev rules are installed in a wrong folder
16:40:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1809117
16:40:02 <adamw> #info Proposed Blocker, mdadm, ON_QA
16:40:10 <adamw> so, there's a question about precisely how bad this is
16:40:14 <adamw> i'm definitely +1 FE at least
16:40:27 <adamw> there's also a question of whether this and 1804080 are the same
16:40:39 <adamw> with 1804080 being an accepted blocker already
16:42:55 <adamw> so, couple of open questions :P
16:43:30 <kalev> I've no idea how bad this is, but definitely +1 according to current information
16:43:34 <kalev> +1 FE, that is
16:43:39 <cmurf> i'm 99% certain it's the same bug
16:44:44 <kparal> +1 final blocker, +1 beta fe
16:44:50 <Southern_Gentlem> +fe
16:45:03 <lruzicka2> -1 fe
16:45:08 <adamw> lruzicka: ?
16:45:09 <lruzicka2> + 1 fe, sorry
16:45:12 <adamw> ah :)
16:45:35 <adamw> so i'd suggest: punt on blocker, accept as FE, if we determine it's the cause of 1804080 simply close it as a dupe of that, effectively rendering this a beta blocker
16:45:56 <pwhalen> ^ +1 on that
16:47:05 <Southern_Gentlem> +punt blocker/+1 fe
16:47:09 <cmurf> +1 FE same as in the bug
16:47:20 <kalev> good plan
16:47:34 <lruzicka2> +1
16:48:29 <adamw> proposed #agreed 1809117 - punt (delay decision) on blocker status, AcceptedFreezeException (Beta) - this is clearly a bad bug and we'd like it fixed for Beta. there are a couple of outstanding questions that prevent us deciding blocker status yet. There is a possibility the bug is the same as 1804080, which is already a blocker: we will test to confirm this, and close the bug as a dupe if they turn out to be the same
16:48:45 <pwhalen> ack
16:48:52 <cmurf> ack
16:48:55 <Southern_Gentlem> ack
16:49:24 <adamw> #agreed 1809117 - punt (delay decision) on blocker status, AcceptedFreezeException (Beta) - this is clearly a bad bug and we'd like it fixed for Beta. there are a couple of outstanding questions that prevent us deciding blocker status yet. There is a possibility the bug is the same as 1804080, which is already a blocker: we will test to confirm this, and close the bug as a dupe if they turn out to be the same
16:49:37 <adamw> #topic (1810070) LUKS password prompt is not shown with more displays connected
16:49:38 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1810070
16:49:38 <adamw> #info Proposed Blocker, plymouth, ON_QA
16:51:35 <adamw> so, the criterion would be "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility", in the case that the system is encrypted (that's in the Beta criteria) and - as hans puts it - "monitor hotplug events happen after plymouth has started (e.g. slow DP-MST enumeration on a DP-MST dock)"
16:51:37 <kparal> +1 beta FE. I'd like to also give it +1 Final blocker, but I'm not sure we have a criterion to apply to this
16:51:53 <adamw> there *is* a known workaround: disable plymouth
16:51:58 <adamw> but of course you have to know/guess to do that
16:52:19 <kparal> or disconnect the screens
16:52:22 <adamw> definitely +1 Beta FE, i'm really on the fence for Beta blocker
16:52:24 <adamw> right
16:52:25 <cmurf> +1 FE or commonbugs the workarounds
16:52:26 <kalev> +1 FE
16:52:32 <adamw> probably +1 Final blocker
16:52:36 <kparal> I don't think this is a Beta blocker
16:52:36 <cmurf> +1 beta FE that is
16:52:42 <cmurf> and +1 final blocker
16:52:52 <lruzicka2> copy cmurf
16:52:56 <cmurf> well, assuming we have a criterion
16:52:56 <adamw> yeah, i think i'll come down a weak -1 Beta blocker, +1 Final blocker
16:53:07 * kalev agrees.
16:53:17 <pwhalen> +1 beta fe, +1 final
16:53:24 <kalev> +1 beta FE, -1 beta blocker, +1 final blocker
16:55:29 * adamw counts
16:55:32 <adamw> i think that's enough for all
16:56:41 <adamw> proposed #agreed 1810070 - RejectedBlocker (Beta), AcceptedFreezeException (Beta), AcceptedBlocker (Final) - rejected as Beta blocker but accepted Final blocker under "A system installed with a release-blocking desktop must boot to a log in screen..." for encrypted installs with affected display configurations. Accepted as a Beta FE as we obviously would like affected systems to work in Beta as well
16:57:01 <kalev> ack
16:57:33 <pwhalen> ack
16:57:55 <kparal> ack
16:58:12 <cmurf> ack
16:58:38 <lruzicka2> ack
16:58:40 <adamw> #agreed 1810070 - RejectedBlocker (Beta), AcceptedFreezeException (Beta), AcceptedBlocker (Final) - rejected as Beta blocker but accepted Final blocker under "A system installed with a release-blocking desktop must boot to a log in screen..." for encrypted installs with affected display configurations. Accepted as a Beta FE as we obviously would like affected systems to work in Beta as well
16:58:58 <adamw> #info since Beta is close, and we have a lot of them, let's move onto...
16:59:06 <adamw> #topic Proposed Beta freeze exceptions
16:59:20 <adamw> #topic (1811708) Include GNOME 3.36.0 in F32 Beta
16:59:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1811708
16:59:20 <adamw> #info Proposed Freeze Exceptions, distribution, NEW
16:59:28 <adamw> oh, okay, it's a re-run!
16:59:47 <kalev> same as last week, except that we're much more schedule-constrained this time
16:59:59 <adamw> yeah
17:00:17 <adamw> i think my instinct on this would be a sort of conditional +1
17:00:25 <adamw> i'd be +1, *but* not land it yet
17:00:42 <adamw> as long as there's a chance we actually do a compose and sign it off on Thursday, i don't think we should pull 3.36.0
17:00:51 <kalev> yeah, I was going to suggest something like this as well
17:00:57 <adamw> but if we get to the point where we are clearly not going to be shipping Thursday, we might want to pull it in at that point
17:01:05 * kalev agrees.
17:01:08 <adamw> (if it's already in Bodhi and feedback is good)
17:01:22 <adamw> brb, call of nature
17:04:06 <jsmith> Seems reasonable to me... (the conditional +1)
17:04:16 <pwhalen> +1 to adamw's suggestion
17:04:55 <cmurf> i'm +1 as well
17:06:35 <lruzicka2> +1. too
17:07:21 <Southern_Gentlem> +1 adamw
17:07:52 <adamw> proposed #agreed 1811708 - AcceptedFreezeException (Beta) - this is accepted, but provisionally: we do not intend to actually pull 3.36.0 in if we stay on schedule to sign off Beta this week, but will consider pulling it in if it becomes clear we will not be signing off on Thursday
17:08:05 <pwhalen> ack
17:08:10 <lruzicka2> ack
17:08:18 <kalev> ack
17:08:31 <Southern_Gentlem> ack
17:09:35 <adamw> #agreed 1811708 - AcceptedFreezeException (Beta) - this is accepted, but provisionally: we do not intend to actually pull 3.36.0 in if we stay on schedule to sign off Beta this week, but will consider pulling it in if it becomes clear we will not be signing off on Thursday
17:09:40 <kparal> ack
17:09:47 <adamw> #topic (1809831) Firefox outdated (72.0.2) on Fedora 32 due to multiple build failures
17:09:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1809831
17:09:47 <adamw> #info Proposed Freeze Exceptions, firefox, MODIFIED
17:09:54 <adamw> +1 FE for me, i think we should get latest firefox in beta.
17:10:00 <kalev> +1 FE
17:10:05 <Southern_Gentlem> +1fe
17:10:13 <pwhalen> +1 FE
17:11:41 <lruzicka2> +1FE
17:12:36 <adamw> proposed #agreed 1809831 - AcceptedFreezeException (Beta) - this is accepted as there are clear obvious benefits to ensuring latest Firefox is in Beta release images (security, avoiding negative first impressions)
17:12:41 <Southern_Gentlem> ack
17:13:03 <kalev> ack
17:13:10 <pwhalen> ack
17:13:14 <lruzicka2> ack
17:13:20 <adamw> #agreed 1809831 - AcceptedFreezeException (Beta) - this is accepted as there are clear obvious benefits to ensuring latest Firefox is in Beta release images (security, avoiding negative first impressions)
17:13:37 <adamw> #1810963 we already considered and rejected
17:13:42 <adamw> #topic (1774746) iscsi login fails during install with "buf[20] !sufficient to decode string[66]" since Fedora-Rawhide-20191119.n.2
17:13:42 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1774746
17:13:42 <adamw> #info Proposed Freeze Exceptions, iscsi-initiator-utils, ON_QA
17:13:52 <adamw> this has been a final blocker forever but somehow i forgot to propose it as Beta FE
17:13:58 <adamw> i think it'd be good to fix iSCSI installs for beta
17:14:04 <adamw> can't fix it with an update
17:14:20 <Southern_Gentlem> +1 FE
17:14:31 <kparal> +1 fe
17:14:36 <lruzicka2> +1fe
17:14:43 <pwhalen> +1 FE
17:14:54 <kalev> +1 FE
17:16:02 <adamw> proposed #agreed 1774746 - AcceptedFreezeException (Beta) - accepted as a clear installation bug that can't be fixed with an update or worked around
17:16:04 <Southern_Gentlem> ack
17:16:55 <kalev> ack
17:18:19 <lruzicka2> ack
17:19:15 <adamw> #agreed 1774746 - AcceptedFreezeException (Beta) - accepted as a clear installation bug that can't be fixed with an update or worked around
17:19:26 <adamw> #topic (1809681) kernel-5.6-rc#: Only 1 of 2 monitors lights up on DP-MST docks
17:19:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1809681
17:19:26 <adamw> #info Proposed Freeze Exceptions, kernel, VERIFIED
17:19:33 <adamw> this one's a pair with the plymouth one from earlier
17:20:02 <frantisekz> .hello2
17:20:03 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:20:27 <adamw> the plymouth bug is to handle things from the plymouth side when kernel hotplug is slow; this bug is to fix kernel hotplug being slow in this specific known case
17:20:53 <adamw> aiui fixing on kernel side will make all displays light up, where plymouth fix only makes one light up
17:21:00 <frantisekz> yes
17:21:10 <frantisekz> seen that today on lruzicka's laptop
17:21:12 <adamw> so i'm inclined to take both changes, as i said in the bug, though if the kernel update comes with many other changes, might not want to take it this week
17:21:35 <adamw> so i'm +1 FE, but with the note we may decide not to pull in a kernel build depending on timing and how much other change it has
17:21:48 <frantisekz> +1 FE
17:21:53 <Southern_Gentlem> +1 adamw
17:21:53 <pwhalen> +1 FE
17:21:58 <kalev> +1 FE with what adamw said
17:22:10 <frantisekz> but I don't expect kernel to have too much changes this late in the cycle
17:22:29 <lruzicka2> +1 fe, I am running the kernel already and finally I have my monitors back.
17:22:44 <lruzicka2> havent tested plymouth, though
17:23:13 <frantisekz> one monitor stayed off if I remember it correctly with plymouth fix missing and only having fixed kernel lruzicka2
17:23:16 <kparal> +1 fe
17:23:35 <adamw> proposed #agreed 1809681 - AcceptedFreezeException (Beta) - this is accepted as it's a significant fix that can't be fully deployed via update for affected systems, but note we may exercise restraint and not pull an available fix if it comes with much other kernel change, depending on timing
17:23:43 <kalev> ack
17:23:47 <Southern_Gentlem> ack
17:23:55 <lruzicka2> during plymouth, I experienced blinking of screens, but with gdm it stopped and I got all three screens
17:23:57 <lruzicka2> ack
17:24:28 <pwhalen> ack
17:24:40 <adamw> #agreed 1809681 - AcceptedFreezeException (Beta) - this is accepted as it's a significant fix that can't be fully deployed via update for affected systems, but note we may exercise restraint and not pull an available fix if it comes with much other kernel change, depending on timing
17:24:56 <adamw> #topic (1807737) lzo 2.10-1 violates ISO C alias rules
17:24:57 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1807737
17:24:57 <adamw> #info Proposed Freeze Exceptions, lzo, NEW
17:25:09 <adamw> quick! someone call the ISO C alias police!
17:25:12 <adamw> *whoopwhoop*
17:26:20 <kalev> hahaha
17:26:26 <cmurf> totally interpol's jurisdiction
17:26:29 <cmurf> punt
17:26:34 <kalev> +1 FE
17:26:47 <jsmith> +1 fe
17:26:48 <pwhalen> +1 FE
17:26:52 <cmurf> +1 FE, ok fine
17:27:33 <Southern_Gentlem> +1fe
17:28:07 <adamw> i mean
17:28:13 <adamw> i don't really see a clear FE justification here
17:28:40 <adamw> well
17:28:47 <Southern_Gentlem> other than broken vpns for people
17:28:55 <kparal> lzo sounds as pretty core tool to make sure it works
17:28:57 <adamw> if it's affecting package builds i guess pushing it stable is cleaner than doing a buildroot override until freeze is lifted...
17:29:08 <lruzicka2> +1fe
17:29:18 <adamw> hmm, no, doesn't seem like it is
17:29:18 <kparal> +1 fe
17:29:40 <adamw> proposed #agreed 1807737 - AcceptedFreezeException (Beta) - we don't really know why but it sounded scary?
17:29:44 <Southern_Gentlem> ack
17:29:54 <cmurf> ack
17:29:55 <adamw> har, you ate my brown m&m
17:29:56 <cmurf> LOL
17:29:57 <adamw> wait
17:29:59 <pwhalen> LOL ack
17:30:05 <adamw> no-one was meant to ack that!
17:30:06 <adamw> stoppit
17:30:12 <frantisekz> ack
17:30:13 <frantisekz> !
17:30:16 <adamw> it was meant to shame you into writing a better justification
17:30:19 <cmurf> we have officially gone off the rails
17:30:23 <cmurf> we took the bait
17:30:31 <adamw> i can't EVEN with you guys right now
17:30:36 <kalev> nack!
17:30:50 <cmurf> adamw got us 21 days before April Fool's Day
17:31:35 <Southern_Gentlem> NM manager to use vpn is borked  so thats desktop stuff should work
17:31:35 <kalev> I think this breaks things like openvpn when using lzo compression etc
17:31:38 <kalev> not 100% sure :)
17:31:44 <kparal> ack
17:32:02 <kalev> ahh yes, they mention openvpn in the ticket
17:32:33 <kalev> so if openvpn is included in the release media, that would be a good reason for FE; if not, it doesn't matter I think
17:34:04 <kalev> in all fairness, I think it's not worth going too deep in discussing this, let's just take the fix :)
17:35:17 <adamw> fiiine
17:35:33 <Southern_Gentlem> openvpn, NM-openvpn NM-openvpn-gnome are all in f31 Workstation
17:35:35 <adamw> proposed #agreed 1807737 - AcceptedFreezeException (Beta) - accepted as a freeze exception because *handwave* VPN in live images and stuff?
17:36:05 <kparal> ack
17:36:06 <kalev> PATCH: accepted as it breaks openvpn using lzo compression on live images
17:36:16 * kparal sighs
17:36:20 <kalev> :D
17:36:21 <adamw> proposed #agreed 1807737 - AcceptedFreezeException (Beta) - accepted as a freeze exception as it breaks openvpn using lzo compression on live images
17:36:23 <adamw> thank you
17:36:28 <kalev> ack
17:36:31 <Southern_Gentlem> ack
17:36:32 <adamw> now our reputation for impeccable professionalism will be maintained!
17:36:34 <adamw> ...
17:36:35 <adamw> ......
17:36:37 <pwhalen> ack
17:36:37 <adamw> ..........
17:36:38 * kparal is all for funny justifications
17:36:39 <jsmith> ACK
17:36:43 <adamw> *bursts out in uncontrollable laughter*
17:36:44 <kparal> ack
17:36:54 <adamw> #agreed 1807737 - AcceptedFreezeException (Beta) - accepted as a freeze exception as it breaks openvpn using lzo compression on live images
17:37:02 <jsmith> +1 to adamw's laughter
17:37:13 <adamw> #1809117 we already accepted
17:37:19 <adamw> #topic (1811178) Include llvm 10 instead of llvm 9 on F32 Beta media
17:37:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1811178
17:37:19 <adamw> #info Proposed Freeze Exceptions, mesa, MODIFIED
17:37:34 <adamw> i'm kinda -1 here, i think it can just be a regular update
17:37:42 <kalev> I just wanted a second opinion here, not really pushing at all for this
17:38:06 <jsmith> Yeah, I prefer not to push new versions of compilers at the last second...
17:38:20 <Southern_Gentlem> -1 fe
17:38:24 <lruzicka2> -1
17:39:04 <adamw> proposed #agreed 1811178 - RejectedFreezeException (Beta) - we don't think there's a strong enough justification to include this and think it'd make more sense for it just to go out as a regular update
17:39:10 <kalev> ack
17:39:20 <Southern_Gentlem> the chances of this breaking something else i think is too high this close to beta
17:39:21 <pwhalen> -1 fe/ack
17:39:22 <Southern_Gentlem> ack
17:39:54 <adamw> #agreed 1811178 - RejectedFreezeException (Beta) - we don't think there's a strong enough justification to include this and think it'd make more sense for it just to go out as a regular update
17:40:02 <adamw> #topic (1810907) upgrade to F32 changes the default image viewer from eog to gimp
17:40:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1810907
17:40:02 <adamw> #info Proposed Freeze Exceptions, shared-mime-info, VERIFIED
17:40:09 <adamw> hah! i was wondering about this
17:40:18 <adamw> only i got it in EXTREEEME mode
17:40:23 <adamw> my default image viewer became wine...
17:40:28 <kparal> :D
17:40:57 <kparal> well, +1 fe
17:41:13 <kalev> kparal has done some nice bug reporting
17:41:18 <kparal> I don't think it affects default installations so we can't block on it
17:41:29 <kparal> unless we get creative
17:41:34 <kalev> +1 FE
17:41:39 <jsmith> +1 FE
17:41:44 <kparal> but +1 fe and it will go away soon, no need to discuss blockers
17:41:54 <adamw> +1 FE as an upgrade issue
17:41:56 <frantisekz> +1 FE
17:42:00 <lruzicka2> +1
17:42:05 <Southern_Gentlem> +1fe
17:42:09 <adamw> kalev: that's what we pay him the medium-sized bucks for!
17:42:12 <pwhalen> +1 FE
17:43:01 <adamw> proposed #agreed 1810907 - AcceptedFreezeException (Beta) - this is accepted as a visible and annoying upgrade issue: we tend to grant FEs to upgrade issues as upgrades usually run with updates-testing disabled, so it is good to push fixes for annoying upgrade issues stable
17:43:33 <pwhalen> ack
17:43:38 <Southern_Gentlem> ack
17:43:50 <kparal> ack
17:43:55 <kalev> ack
17:43:56 <lruzicka2> ack
17:45:17 <adamw> #agreed 1810907 - AcceptedFreezeException (Beta) - this is accepted as a visible and annoying upgrade issue: we tend to grant FEs to upgrade issues as upgrades usually run with updates-testing disabled, so it is good to push fixes for annoying upgrade issues stable
17:45:25 <adamw> #topic (1810705) PipeWire has been requested for inclusion in Fedora Jam
17:45:25 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1810705
17:45:25 <adamw> #info Proposed Freeze Exceptions, spin-kickstarts, NEW
17:45:38 <adamw> Fedora Jam: definitely the most *delicious* Fedora
17:45:45 <adamw> (aside from Beefy Miracle, of course)
17:45:56 <pwhalen> +1
17:45:58 <lruzicka2> +1fe
17:46:03 <frantisekz> +1 FE
17:46:05 <kalev> +1 FE
17:46:18 <Southern_Gentlem> +1fe
17:46:35 <adamw> +1 FE, sure, just a kickstart change
17:46:39 <kparal> +1 fe
17:47:13 <adamw> proposed #agreed 1810705 - AcceptedFreezeException (Beta) - this looks like a reasonable change which can't have an effect outside the spin it's intended for
17:47:41 <Southern_Gentlem> do we even do fedora jam in beta?
17:48:10 <adamw> we do everything in beta that we do in final
17:48:13 <Southern_Gentlem> ack
17:48:15 <Southern_Gentlem> ok
17:48:39 <lruzicka2> ack
17:49:25 <adamw> one more ack?
17:49:35 <kparal> ack everything
17:49:52 <adamw> =)
17:49:58 <pwhalen> ack
17:49:59 <adamw> proposed #agreed kparal gives me all his money
17:50:10 <cmurf> nack
17:50:10 <lruzicka2> ack
17:50:11 <adamw> #agreed 1810705 - AcceptedFreezeException (Beta) - this looks like a reasonable change which can't have an effect outside the spin it's intended for
17:50:12 <cmurf> nack
17:50:14 <adamw> =)
17:50:15 <cmurf> nack
17:50:19 <cmurf> give him a raise
17:50:28 <adamw> proposed #agreed cmurf to fund kparal's raise
17:50:37 <lruzicka2> ack, too
17:50:37 <kparal> ack
17:50:51 <adamw> ALRIGHTY
17:50:52 <adamw> #topic (1808564) Wi-fi networks not displayed in F32 SoaS (works in F31 SoaS) spin
17:50:52 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1808564
17:50:52 <adamw> #info Proposed Freeze Exceptions, sugar, ON_QA
17:51:10 <kalev> I have to go now, sorry guys
17:51:16 <adamw> +1, sugar is meant to be run live, so we should fix stuff like this obcs
17:51:18 <adamw> kalev: thanks!
17:51:25 <Southern_Gentlem> +1 fe
17:51:27 <kparal> +1 fe
17:51:47 <lruzicka2> +1
17:51:54 <pwhalen> +1
17:52:05 * Southern_Gentlem hates SOAS
17:52:10 <adamw> why
17:52:21 <Southern_Gentlem> pita to test for respins
17:52:51 <adamw> proposed #agreed 1808564 - AcceptedFreezeException (Beta) - this is a significant issue in Sugar, which is mainly used live and so obviously cannot be fixed with an update
17:53:00 <cmurf> ack
17:53:05 <pwhalen> ack
17:53:08 <Southern_Gentlem> ack
17:53:44 <adamw> #agreed 1808564 - AcceptedFreezeException (Beta) - this is a significant issue in Sugar, which is mainly used live and so obviously cannot be fixed with an update
17:53:48 <adamw> #topic (1738982) sugar-pippy depends on Python 2
17:53:48 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1738982
17:53:49 <adamw> #info Proposed Freeze Exceptions, sugar-pippy, ON_QA
17:54:00 <Southern_Gentlem> also less then .01% downloads as far as we can tell
17:54:17 <Southern_Gentlem> +1
17:54:41 <adamw> same deal, +1, obviously good to try and get py2 out of sugar images, can't do it with an update
17:54:53 <Southern_Gentlem> +1fe
17:54:57 <lruzicka2> +1fe
17:55:25 <cmurf> +1fe
17:56:13 <adamw> proposed #agreed 1738982 - AcceptedFreezeException (Beta) - accepted as it's clearly good to try and get Python 2 out of the Sugar image compose, and we can't do it for Beta with an update
17:56:18 <kparal> ack
17:56:21 <Southern_Gentlem> ack
17:56:31 <frantisekz> ack
17:56:39 <adamw> #agreed 1738982 - AcceptedFreezeException (Beta) - accepted as it's clearly good to try and get Python 2 out of the Sugar image compose, and we can't do it for Beta with an update
17:56:59 <adamw> one more showed up since the meeting started:
17:57:00 <adamw> #topic (1811740) Move back grubby to @core group
17:57:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1811740
17:57:00 <adamw> #info Proposed Freeze Exceptions, comps, NEW
17:58:00 <adamw> mmm
17:58:08 <adamw> i would like more questions answered here
17:58:26 <cmurf> i might be able to answer
17:58:29 <Southern_Gentlem> its for a release blocking Desktop
17:59:54 <adamw> this has been the same the last three releases
17:59:58 <adamw> why does it suddenly need changing now?
18:00:01 <cmurf> yeah it's an oversight
18:00:04 <adamw> why does workstation not include standard?
18:00:09 <adamw> why does grubby need to be on workstation?
18:00:17 <adamw> if anaconda can deploy grubby, why isn't it in the group for things anaconda can deploy?
18:00:55 <adamw> is this purely for extlinux support?
18:01:03 <cmurf> i think the idea is that grubby should be everywhere because it includes something that lets upstream kernel to actually install the kernel and update the bootloader config
18:01:56 <cmurf> in fact i run into that problem myself when i build upstream kernel from source, but i just fix it manually
18:02:36 <cmurf> on the one hand it's not risky
18:02:46 <adamw> okay, so https://pagure.io/fedora-comps/pull-request/463 has a better justification
18:02:52 <adamw> cmurf: har.
18:03:12 <pwhalen> famous last ..
18:03:13 <cmurf> well nothing uses it these days except for, AFAIK, upstream kernel source
18:03:46 <cmurf> and this is not just for workstation, it's everything that has core
18:03:53 <Southern_Gentlem> +1 FE
18:03:56 <adamw> well that makes it more risky than otherwise :P
18:04:01 <adamw> i think i'm +1 fe but grumbling about it
18:04:08 <cmurf> and i don't know why workstation doesn't use standard, i was asking nirik that question last week
18:04:11 <adamw> *if* it makes sense to change this, it probably makes sense to change it in beta
18:04:19 <cmurf> and i guess workstation WG folks don't want everything that's in standard *shrug*
18:04:41 <cmurf> what i don't understand is whether this can fix things for people who upgrade from f30 and f31
18:05:05 <nirik> kalev removed it a while back.
18:05:16 * nirik thought grubby was no longer used in the bls world
18:05:16 <pwhalen> +1 EF
18:05:39 <cmurf> it isn't strictly needed, unless you're building the kernel from upstream source
18:05:44 <cmurf> i don't know if anything else needs it
18:06:14 <frantisekz> hmm, I don't think we need it in default install just for kernel building...
18:06:35 <adamw> last i checked, there is actually a codepath in anaconda somewhere which assumes a bit of grubby is present
18:06:41 <adamw> i can't remember what all exactly doesn't happen if it isnt
18:06:44 <cmurf> i've pinged javier maybe he can join
18:07:29 <cmurf> not sure what in anaconda would use it these days, seeing as it's not on any install media
18:08:12 <adamw> new-kernel-pkg
18:08:21 <adamw> it's part of grubby-deprecated, though, so this wouldn't affect it
18:08:28 <adamw> i'd have to go look that up again and see if it's really a problem
18:11:45 <adamw> sorry
18:11:47 <adamw> uh
18:12:30 <adamw> proposed #agreed 1811740 - AcceptedFreezeException (Beta) - it's not entirely clear whether this change should happen as requested, but *if* we're going to change it, it would make sense for the change to be in Beta to help discover any issues it causes.
18:12:40 <lruzicka2> ack
18:12:42 <pwhalen> ack
18:12:46 <frantisekz> ack
18:12:47 <cmurf> ack
18:12:52 <Southern_Gentlem> ack
18:12:58 <adamw> #agreed 1811740 - AcceptedFreezeException (Beta) - it's not entirely clear whether this change should happen as requested, but *if* we're going to change it, it would make sense for the change to be in Beta to help discover any issues it causes.
18:13:04 <cmurf> javier__: i think it fell together already
18:13:08 <adamw> okay, that's all the beta FEs
18:13:10 <cmurf> we'll see if it falls apart later :D
18:13:41 <Southern_Gentlem> if it breaks beta we can back peddle
18:14:43 <cmurf> it won't break beta, i will bet a quart of blueberries on it
18:16:26 <Southern_Gentlem> next
18:16:34 <adamw> #topic proposed Final blockers
18:16:52 <adamw> just three of these, is the good news!
18:16:54 <adamw> #topic (1811382) anaconda failed to login to the iscsi target
18:16:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1811382
18:16:54 <adamw> #info Proposed Blocker, anaconda, ASSIGNED
18:17:58 <Southern_Gentlem> i thought we did this as a beta fe
18:18:23 <adamw> it's a different report
18:18:28 <adamw> but i strongly suspect it's a dupe
18:18:33 <adamw> so i'd suggest punt while we confirm that
18:18:42 <Southern_Gentlem> +1 punt
18:19:53 <lruzicka2> +1 punt
18:20:08 <frantisekz> +1 punt
18:20:51 <pwhalen> +1 punt
18:21:10 <adamw> proposed #agreed 1811382 - punt (delay decision) - we believe this is very likely to be a duplicate of 1774746, so we will delay the decision while we confirm that
18:21:17 <lruzicka2> ack
18:21:28 <Southern_Gentlem> ack
18:21:32 <kparal> ack
18:21:34 <adamw> #agreed 1811382 - punt (delay decision) - we believe this is very likely to be a duplicate of 1774746, so we will delay the decision while we confirm that
18:21:34 <frantisekz> ack
18:21:34 <adamw> #topic (1803996) systemd-ask-password-console.service: Unit configuration has fatal error
18:21:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1803996
18:21:35 <adamw> #info Proposed Blocker, dracut, ON_QA
18:22:53 <Southern_Gentlem> +1 fe
18:23:00 <cmurf> -1 beta FE, +1 final blocker
18:23:14 <adamw> this is proposed as a final blocker
18:23:16 <Southern_Gentlem> ok -fe +1 fB
18:23:17 <adamw> pay attention people!
18:23:21 <adamw> =)
18:23:22 * cmurf has been burned by dracut FE's too may times
18:23:25 <frantisekz> +1 Final Blocker
18:23:27 <lruzicka2> +1 fb
18:23:55 <adamw> ooh
18:23:56 <adamw> so
18:24:02 <adamw> we have a special consideration here
18:24:05 <cmurf> yes?
18:24:23 <adamw> anaconda team tell me dracut 050 will break kickstart installs
18:24:27 <adamw> and fixing it is 'not a trivial patch'
18:24:42 <adamw> <jkonecny> 07:54:25> adamw, it seems that we have a problem in our dracut modules which worked before but not from 050
18:24:53 <cmurf> oooh
18:24:55 <adamw> <jkonecny> 07:55:33> adamw, also we will fix the bug but it's possible that there will be bugs
18:24:55 <adamw> <jkonecny> 07:55:53> adamw, it won't be a trivial patch
18:25:20 <Southern_Gentlem> that has to do with this?
18:25:39 <jkonecny> I'm here if you have any question about that
18:25:42 <cmurf> so we need a backport
18:25:44 <cmurf> for final
18:25:48 <adamw> Southern_Gentlem: it does because the proposed fix for this is...dracut 050
18:25:59 <cmurf> and not accept dracut-50 once freeze is lifted
18:26:03 <cmurf> does harold know?
18:26:11 <adamw> dunno. i can add a note to this bug.
18:26:15 <adamw> um, so.
18:26:19 <jkonecny> cmurf, we know this solution thanks to harald
18:26:19 <Southern_Gentlem> -fb
18:26:24 <adamw> i am also not sure i'm +1 fb on this bug anyway
18:26:27 <jkonecny> he helped with debugging
18:26:29 <cmurf> jkonecny: ahh OK cool
18:26:41 <adamw> there is clearly a problem, but it doesn't actually exhibit as a failed service, right?
18:26:54 <cmurf> it does exhibit as a failed service
18:26:54 <adamw> if you run 'systemctl --failed' you don't see a listing for this?
18:26:58 <cmurf> at least the last time i checked
18:27:01 <adamw> only buried i nsystem logs
18:27:06 <adamw> it's not really visible
18:27:55 <adamw> i'm not seeing it in 'systemctl --failed' output, and openqa isn't either
18:28:03 <cmurf> HUH
18:28:15 <adamw> hmm
18:28:19 <adamw> i don't see it in system logs either..
18:28:29 <cmurf> ok so get this, it's a static service and with all updates applied, it isn't show up as ever having started
18:28:33 <cmurf> thus not failing
18:28:43 <cmurf> so i have no idea what triggered it before the latest updates
18:28:50 <jkonecny> if you mean our the Dracut 050 issue with Anaconda then Anaconda is working correctly, except it doesn't download Kickstart
18:28:51 <cmurf> it was failing last week, and I do not have dracut-50
18:29:02 <jkonecny> and even that is under certain condition
18:29:10 <adamw> okay, i do see "Mar 06 09:59:37 adam.happyassassin.net systemd[1]: initrd.target: Requested dependency OnFailure=emergency.target ignored (target units cannot fail)." in system logs
18:29:16 <adamw> but systemctl --failed is not showing any failed service
18:29:37 <cmurf> no failed service, and this service isn't even started for me today
18:29:43 <adamw> the 'no failed services' criterion itself is effectively a polish criterion
18:29:54 <adamw> we don't want people seeing failed services prominently and complaining
18:29:59 <adamw> so, i'd say this doesn't violate *that*
18:30:07 <cmurf> not now
18:30:07 <adamw> presumably there is a practical impact of the bug, though?
18:30:23 <cmurf> but as reported it was a big fat red fail, something else has changed
18:30:34 <adamw> is this the thing where if early boot fails it tried to ask for root password before dumping you in emergency mode? is that breaking?
18:30:48 <cmurf> not that i recall
18:30:52 <adamw> hmm
18:31:00 <cmurf> it was with all the selinux AVCs blocking stuff
18:31:01 <adamw> i think i'm at a general 'punt' on this
18:31:09 <cmurf> and the setsched whatever stuff
18:31:10 <adamw> punt to figure out what the hell's going on
18:31:20 <cmurf> maybe that was wigging something out
18:31:31 <adamw> whether this does manifest as a prominent failed service at all, and whether it has an identifiable practical impact
18:31:32 <cmurf> +1 punt
18:32:04 <Southern_Gentlem> +1punt
18:32:22 <cmurf> i'd go so far as to say if it fails and it's just cosmetic and isn't easy to fix, then get an exception rather than block
18:32:42 <cmurf> but right now as it is, it's not even starting (and thus not failing)
18:32:48 <adamw> proposed #agreed 1803996 - punt (delay decision) - it's not clear whether/when this actually manifests as a failed service in systemctl --failed, and it's also not clear what its practical effect is. also, anaconda team has alerted us that dracut 050 breaks kickstart installs, so we cannot simply pull in dracut 050 to fix this. with all of those considerations, we will punt on this for now to try and investigate the bug further and come up with
18:32:48 <adamw> a plan
18:33:00 <adamw> (that'll fit on one line without the 'proposed' :>)
18:33:16 <Southern_Gentlem> ack
18:33:45 <cmurf> ack
18:33:53 <kparal> ack
18:34:06 <lruzicka2> ack
18:34:19 <pwhalen> ack
18:34:34 <adamw> #agreed 1803996 - punt (delay decision) - it's not clear whether/when this actually manifests as a failed service in systemctl --failed, and it's also not clear what its practical effect is. also, anaconda team has alerted us that dracut 050 breaks kickstart installs, so we cannot simply pull in dracut 050 to fix this. with all of those considerations, we will punt on this for now to try and investigate the bug further and come up with a plan
18:34:52 <adamw> jkonecny: can you add a comment and -1 on https://bodhi.fedoraproject.org/updates/FEDORA-2020-e8ed29f8bc ?
18:35:10 <adamw> #topic (1795524) SELinux denials for 'setsched' force glib down a fallback path with performance implications
18:35:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1795524
18:35:10 <adamw> #info Proposed Blocker, selinux-policy, MODIFIED
18:35:13 <adamw> erf, why is this here.
18:35:18 <adamw> what is even going on with this.
18:35:54 <jkonecny> jkonecny, np with that, even thought that this is not really a failure of Dracut it's only discovering a problem in Anaconda thanks to the Dracut behavior change
18:36:02 <jkonecny> adamw, ^ :)
18:36:39 <adamw> jkonecny: sure, but in practical terms we still cannot just push the update stable and break kickstart installs, it's not a question of whose 'fault' the problem is, just a question of not breaking stuff =)
18:36:56 <jkonecny> agree
18:37:02 <cmurf> nope it's adamw's fault
18:37:38 <adamw> everything's always my fault
18:37:42 <cmurf> haha
18:37:45 <adamw> okay, so. right now we still get avcs for this stuff
18:37:59 <adamw> there's an update pending to not generate avcs (the denial will still happen, it just gets dontaudit'ed)
18:38:11 <adamw> the proposal is to block on that. i think.
18:38:39 <adamw> so, we have a criteria about AVCs appearing on the desktop, but we don't actually show desktop AVC alerts any more in GNOME or KDE I don't think, by default
18:38:45 <adamw> so i'm probably -1, i think?
18:39:27 <cmurf> sounds right
18:39:38 <cmurf> i'm not sure about KDE and avc denials
18:40:22 <adamw> oh, but then there probably isn't anything installed in KDE that hits this
18:40:33 <adamw> i think i'm -1 till someone actually says 'i did a default install and something popped up or broke'
18:40:53 <cmurf> right
18:41:12 <pwhalen> -1, I didnt see any functionality issues when I hit them
18:41:45 <jkonecny> adamw, another thing is that Dracut is most probably the problem on Rawhide but we can't say for sure this will happen also for F32
18:41:49 <Southern_Gentlem> at this point i am punt
18:42:38 <adamw> jkonecny: okay. let's follow up on that in the bug report and stuff
18:43:57 <kparal> can I +1 because I'm annoyed by those popups?
18:44:11 <cmurf> kparal :D
18:45:46 <cmurf> i don't like the popups either, but since sealert isn't installed by default, users won't see the alerts by default either
18:46:17 <kparal> I'm talking about me, I don't care about users!
18:46:21 <cmurf> haha
18:48:05 <adamw> kparal: so long as i can ignore you because i feel like it!
18:48:35 <adamw> so we're at about -2, a jokey(?) +1 and a punt
18:48:45 <adamw> and we have 12 minutes
18:49:09 <Southern_Gentlem> this is for final so we still have time
18:49:40 <kparal> sure, -1
18:49:42 <cmurf> yeah we'll hear about it during beta period if it's still a problem
18:49:57 <Southern_Gentlem> -1
18:50:07 <kparal> adamw: and you don't already? you should learn your lesson!
18:50:15 <adamw> =)
18:50:17 <lruzicka2> -1
18:50:29 <lruzicka2> but there is something right about kparal
18:50:37 <lruzicka2> and his view
18:50:53 <kparal> who? never heard of him
18:51:04 <adamw> proposed #agreed 1795524 - RejectedBlocker (Final) - this is a bit messy, but it seems there is no criteria violation. We do not install the component that shows AVCs as desktop notifications any more, so that criterion is not violated even though AVCs are occurring
18:51:18 <Southern_Gentlem> ack
18:51:19 <lruzicka2> ack
18:52:14 <kparal> ack
18:52:28 <Southern_Gentlem> but of course someone said saw it logging into cli
18:52:39 <cmurf> ack
18:53:02 <adamw> #agreed 1795524 - RejectedBlocker (Final) - this is a bit messy, but it seems there is no criteria violation. We do not install the component that shows AVCs as desktop notifications any more, so that criterion is not violated even though AVCs are occurring
18:56:00 <adamw> #topic Open floor
18:56:03 <adamw> I don't see any new proposals
18:56:10 <adamw> i do have one thing to mention quickly for open floor
18:56:17 <cmurf> amazing time management
18:56:26 <adamw> aiui, IoT is meant to be a release-blocking edition for F32
18:56:39 <cmurf> and CoreOS
18:56:43 <adamw> however, we really are not set up fully to validate IoT release
18:56:47 <adamw> yeah, coreos is less of an issue here
18:57:00 <adamw> https://pagure.io/fedora-qa/issue/623 and https://pagure.io/fedora-qa/issue/618 are still open
18:57:41 <adamw> in https://pagure.io/fedora-iot/issue/24#comment-626541 mattdm assured qa we'd be included in "the (very nascent) plans", but i don't really see much evidence of that. unless i'm missing something.
18:58:02 <adamw> so i'm pretty unclear on what the actual status is here. are we supposed to ship something and call it Fedora IoT 32 Beta? who's meant to sign off on that? when? does anyone know?
18:58:45 <kparal> I see very little response from people who should know
18:58:45 <cmurf> ask mr cotton?
18:59:18 <pwhalen> adamw, generally the IoT groups signs off on it, myself leading the testing.
18:59:32 <adamw> i mean
18:59:44 <adamw> if it's a Fedora edition it can't really just be signed off on a nod from the dev team
18:59:54 <adamw> if we're gonna ship fedora like that the rest of us might as well just go on vacation
19:00:01 <pwhalen> We had a test day last week, didnt go very smoothly with a few things that should be ready this week
19:00:03 <kparal> \o/
19:00:07 <adamw> but if we don't know, we don't know
19:00:09 <cmurf> shhh adamw! just go on vaca!
19:00:12 <adamw> =)
19:01:20 <adamw> alright, we're over time
19:01:22 <cmurf> ok so what about punt to f33? sometimes drastic and realistic are actually in alignment
19:01:33 <adamw> #info IoT status still unclear for Beta, I will try and follow up with appropriate authorities
19:01:38 <adamw> thanks for coming, everyone
19:01:43 <cmurf> cya!
19:01:52 <lruzicka2> thank you, have a nice time
19:03:16 <adamw> #endmeeting