16:00:12 <coremodule> #startmeeting F36-blocker-review
16:00:13 <zodbot> Meeting started Mon Apr 11 16:00:12 2022 UTC.
16:00:13 <zodbot> This meeting is logged and archived in a public location.
16:00:13 <zodbot> The chair is coremodule. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:13 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:00:13 <coremodule> #meetingname F36-blocker-review
16:00:13 <zodbot> The meeting name has been set to 'f36-blocker-review'
16:00:13 <coremodule> #topic Roll Call
16:00:27 <coremodule> Good morning everyone, who is around for a blocker review?
16:00:48 <bcotton> .hello2
16:00:49 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:04:03 <lruzicka2> .hello lruzicka
16:04:04 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:05:36 <frantisekz> .hello2
16:05:37 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:07:04 <coremodule> #chair bcotton frantisekz lruzicka2
16:07:04 <zodbot> Current chairs: bcotton coremodule frantisekz lruzicka2
16:07:08 <coremodule> #topic Introduction
16:07:08 <coremodule> Why are we here?
16:07:08 <coremodule> #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:08 <coremodule> #info We'll be following the process outlined at:
16:07:08 <coremodule> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:07:10 <coremodule> #info The bugs up for review today are available at:
16:07:12 <coremodule> #link http://qa.fedoraproject.org/blockerbugs/current
16:07:14 <coremodule> #info The criteria for release blocking bugs can be found at:
16:07:16 <coremodule> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:07:18 <coremodule> #link https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
16:07:20 <coremodule> #link https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria
16:07:22 <coremodule> #topic Proposed Blockers
16:07:40 <coremodule> #undo
16:07:40 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fccae3d5978>
16:07:45 <coremodule> We have:
16:07:46 <coremodule> #info 10 Proposed Blockers
16:07:46 <coremodule> #info 7 Accepted Blockers
16:07:46 <coremodule> #info 0 Accepted 0-day Blockers
16:07:46 <coremodule> #info 0 Accepted Previous Release Blockers
16:07:47 <coremodule> #info 5 Proposed Freeze Exceptions
16:07:48 <coremodule> #info 11 Accepted Freeze Exceptions
16:08:01 <coremodule> #topic Proposed Blockers
16:08:11 <coremodule> #topic (2073950) disable updates-testing, create a final release
16:08:11 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2073950
16:08:11 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/736
16:08:11 <coremodule> #info Proposed Blocker, fedora-repos, NEW
16:08:11 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-0) (+kparal)
16:09:04 <frantisekz> +1 FinalBlocker
16:09:11 <coremodule> yeah, easy one
16:09:13 <adamw> ahoyhoy
16:09:15 <coremodule> +1 FinalBlocker
16:09:17 <bcotton> +1 FB
16:09:21 <bcotton> a wild adamw appears
16:09:23 <lruzicka2> +1
16:09:30 <coremodule> hey adamw, you want to run this :D ?
16:09:37 <coremodule> #chair adamw
16:09:37 <zodbot> Current chairs: adamw bcotton coremodule frantisekz lruzicka2
16:09:49 <adamw> no, you go ahead, i'm out of the loop
16:09:51 <adamw> +1 fb
16:10:24 <adamw> we do also need a -1 or higher fedora-release if we don't have one yet
16:11:01 <coremodule> proposed #agreed 2073950 – AcceptedBlocker – The decision to classify this bug as an "AcceptedBlocker" was made as we need the correct version of the repos for F36.
16:11:11 <frantisekz> ack
16:11:18 <lruzicka2> ack
16:11:21 <adamw> there is a criterion to cite...
16:11:26 <bcotton> ack
16:11:38 <adamw> https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Release_identification
16:11:52 <adamw> i keep meaning to update that criterion to reference fedora-repos and fedora-release separately and never get around to it.
16:12:00 <coremodule> #undo
16:12:00 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fccae43dd68>
16:13:29 <coremodule> proposed #agreed 2073950 – AcceptedBlocker – The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion: "A fedora-release package containing the correct names, information and repository configuration for a final Fedora release must be present on release-blocking images and the appropriately versioned generic-release package must be available in the release repository."
16:13:47 <frantisekz> ack
16:13:49 <lruzicka2> re-ack
16:14:33 <adamw> ack
16:14:39 <coremodule> #agreed 2073950 – AcceptedBlocker – The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion: "A fedora-release package containing the correct names, information and repository configuration for a final Fedora release must be present on release-blocking images and the appropriately versioned generic-release package must be available in the release repository."
16:14:47 <coremodule> #topic (2061693) Unable to load VPN connection editor for SSH
16:14:47 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2061693
16:14:47 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/734
16:14:47 <coremodule> #info Proposed Blocker, gnome-control-center, NEW
16:14:48 <coremodule> #info Ticket vote: FinalBlocker (+1,1,-0) (+nielsenb, kparal)
16:15:50 <frantisekz> -1 FinalBlocker, +1 Final FE, I'd say openvpn is basic funcionality if that's the criterion we're talking about
16:16:04 <coremodule> I can't find a VPN criterion that this would violate...
16:16:17 <coremodule> Okay, I could see how it could be considered "basic functionality"
16:16:45 <coremodule> I seem to remember having a similar bug in releases past...
16:17:42 <adamw> I thought we fixed this?
16:17:56 <adamw> oh yes, ssh
16:18:22 <adamw> so we fixed this for openvpn and openconnect, which should be the most common
16:18:28 <bcotton> -1 FB, +1 FE. This seems to be a small enough use case to not count as "basic functionality" imo
16:19:44 <adamw> when this bug was originally filed in march, openvpn was broken as the original reporter said. we fixed that for beta - that was https://bugzilla.redhat.com/show_bug.cgi?id=2057719
16:21:50 <adamw> so as i tend to figure ssh-based VPN is less common, i'm probably -1 for this
16:22:26 <adamw> that's not really based on any hard data though, i guess.
16:23:48 <coremodule> proposed #agreed 2061693 – RejectedBlocker AcceptedFreezeException – The decision to classify this bug as a “RejectedBlocker (Final)” and an "AcceptedFreezeException (Final)" was made as we believe that ssh-based VPN is not widely used enough to warrant a blocker status, however we do see this as bad and grant it FE status.
16:24:40 <frantisekz> ack
16:24:59 <adamw> ack
16:25:13 <bcotton> ack
16:25:20 <coremodule> #agreed 2061693 – RejectedBlocker AcceptedFreezeException – The decision to classify this bug as a “RejectedBlocker (Final)” and an "AcceptedFreezeException (Final)" was made as we believe that ssh-based VPN is not widely used enough to warrant a blocker status, however we do see this as bad and grant it FE status.
16:25:30 <coremodule> #topic (2073206) interrupted dimming partly locks window switching
16:25:31 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2073206
16:25:31 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/730
16:25:31 <coremodule> #info Proposed Blocker, gnome-shell, NEW
16:25:31 <coremodule> #info Ticket vote: FinalBlocker (+4,0,-0) (+asciiwolf, +lruzicka, +kparal, +nielsenb)
16:25:48 <frantisekz> +1 FinalBlocker, sorry, could have changed that before the meeting to accepted
16:26:08 <frantisekz> pinged gnome shell maint about it today, didn't get a response
16:26:59 <adamw> i don't really love the criteria justification for this, but it does seem like a bad bug...
16:27:37 <adamw> i guess i'd maybe judo the default application criterion for this. but it probably isn't important.
16:28:00 <coremodule> Okay you get two options
16:28:03 <lruzicka2> adamw, I think this the default application criteria
16:28:06 <coremodule> Option one:
16:28:08 <coremodule> proposed #agreed 2073206 – AcceptedBlocker – The decision to classify this bug as an “AcceptedBlocker (Final)” was made as it violates the following criteria: “All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use.”
16:28:14 <coremodule> Or option two:
16:29:10 <coremodule> proposed #agreed 2073206 – AcceptedBlocker – The decision to classify this bug as an “AcceptedBlocker (Final)” was made as it violates the following criteria: “For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test:... ...for Fedora Workstation on the x86_64 architecture, all applications installed by default which can be launched
16:29:10 <coremodule> from the Activities menu must meet this requirement. ”
16:29:28 <coremodule> s/criteria/criterion
16:30:01 <adamw> well, that's too long
16:30:14 <bcotton> +1 blocker, with option one mostly because it fits
16:30:14 <adamw> so, uh, ack #1? :D
16:30:21 <coremodule> I can shorten it if we like the second one....
16:30:39 <lruzicka2> I like the second one, but I am fine with one if others want it better
16:31:31 <adamw> if #2 is shortenable, ack that!
16:32:21 <lruzicka2> ack#2. too
16:33:53 <coremodule> #agreed 2073206 – AcceptedBlocker – The decision to classify this bug as an “AcceptedBlocker (Final)” was made as it violates the following criterion: “For all release-blocking desktop/arch combinations, the following applications must start successfully and withstand a basic functionality test...for Fedora Workstation on the x86_64 architecture, all applications installed by default which can be launched… mus
16:33:53 <coremodule> t meet this requirement. ”
16:33:56 <coremodule> gah
16:33:59 <coremodule> #undo
16:33:59 <zodbot> Removing item from minutes: AGREED by coremodule at 16:33:53 : 2073206 – AcceptedBlocker – The decision to classify this bug as an “AcceptedBlocker (Final)” was made as it violates the following criterion: “For all release-blocking desktop/arch combinations, the following applications must start successfully and withstand a basic functionality test...for Fedora Workstation on the x86_64 architecture, all applications installed by default which can be launched… mus
16:34:20 <coremodule> #agreed 2073206 – AcceptedBlocker – The decision to classify this bug as an “AcceptedBlocker (Final)” was made as it violates the following criteria: “All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use.”
16:34:31 <bcotton> ack
16:34:40 <frantisekz> ack
16:34:41 <coremodule> I can't shorten it without losing important bits...
16:34:47 <coremodule> so we'll use this one...
16:34:50 <adamw> yes, that was the problem i saw :D
16:34:51 <lruzicka2> hehe
16:34:52 <lruzicka2> ack
16:34:54 <adamw> er
16:35:01 <adamw> fine
16:35:02 <adamw> let's move on
16:35:05 <coremodule> #topic (2074121) Enabling "Fedora Flathub Selection" repo doesn't show included apps in gnome-software until re-login
16:35:05 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2074121
16:35:05 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/737
16:35:05 <coremodule> #info Proposed Blocker, gnome-software, NEW
16:35:06 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-0) (+kparal)
16:35:07 <adamw> this is a highly professional operation
16:35:19 <coremodule> I was trained to run blocker meetings by the best.
16:35:34 <adamw> top men.
16:35:36 <coremodule> The most professional.
16:36:16 <bcotton> +1 final blocker
16:36:35 <adamw> i feel like this maybe isn't as bad as the case we took before
16:36:38 <adamw> the previous case was all repos, no
16:39:43 <adamw> this one is just one repo, possibly not the most important; i feel like in the other case we were worried about stuff like chrome and nvidia drivers...or is that what's in this repo?
16:39:58 <adamw> nope, don't think it is.
16:40:09 <coremodule> Yeah, I don't think nvidia stuff is in this one
16:40:36 <lruzicka2> in Flathub, there are no system drivers
16:40:59 <Southern_Gentlem> to me this is a commonbug candidate not really a blocker
16:41:20 <Southern_Gentlem> a PITA yes but easy work around
16:41:30 <lruzicka2> Southern_Gentlem, yeah ... sort of windowslike behaviour, but nothing really serious
16:41:31 <bcotton> yeah, this is the "filtered flathub view" repo
16:42:58 <Southern_Gentlem> it appears that not even a reboot is needed only logout and relogin
16:44:13 <Southern_Gentlem> i am sure eventually it will be tracked down to a permission issue somewhere in writing the repo file
16:44:27 <Southern_Gentlem> (what it sounds like )
16:44:37 <bcotton> i'd argue that a reboot and a logout/login are functionally the same to most users. either way, you have to interrupt your workflow
16:45:04 <adamw> yeah, that's not important to me, the key for me is 'the stuff in this repo isn't like super critical'...
16:45:15 <Southern_Gentlem> oh well, stuff happens with cutting edge software
16:45:33 <adamw> also note that the other bug affected g-i-s, which means it's less amenable to being fixed with an update
16:45:41 <bcotton> i think the question is "is this an official repository" as defined in the criteria
16:45:55 <Southern_Gentlem> now what happen at the cli does it do the same
16:46:23 <lruzicka2> bcotton, it is switched with the Third party repos.
16:46:45 <lruzicka2> bcotton, doing a clean installation will not bring this into the system
16:47:17 <lruzicka2> bcotton, only the Fedora Flatpak repo is installed by default
16:47:45 <bcotton> but we ship the config for it by default, no? it's just not enabled by default
16:48:07 <adamw> yeah, we took the other bug as a violation of the initial setup functionality criterion, that doesn't apply here
16:48:09 <lruzicka2> bcotton, yes
16:48:52 <adamw> "Configure software sources by enabling/disabling pre-defined official repositories and then adjust the available software pool accordingly" is the requirement here, i guess
16:49:31 <adamw> which...yeah, i guess this does violate that.
16:50:39 <bcotton> if the bug was "the minecraft flatpak doesn't install from this repo" I'd say "well it's a third-party repo, so sorry". but this is about the functionality of the repo config, essentially
16:52:10 <adamw> yeah. i guess i can be +1. i might also be +1 to waive this if we can't fix it, though.
16:52:53 <lruzicka2> +1 to what adamw is saying, I feel it the same.
16:52:58 <coremodule> proposed #agreed 2074121 – AcceptedBlocker – The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion: “The default graphical package manager for a given software type must appropriately… Configure software sources by enabling/disabling pre-defined official repositories and then adjust the available software pool accordingly".
16:53:05 <lruzicka2> ack
16:53:27 <Southern_Gentlem> -1
16:53:27 <adamw> ack
16:53:34 <frantisekz> ack
16:53:38 <Southern_Gentlem> its working but after a relogin
16:53:57 <bcotton> ack
16:54:07 <coremodule> #agreed 2074121 – AcceptedBlocker – The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion: “The default graphical package manager for a given software type must appropriately… Configure software sources by enabling/disabling pre-defined official repositories and then adjust the available software pool accordingly".
16:54:23 <coremodule> #topic (2053729) RPi4 wired network fails - eth0 (bcmgenet): transmit queue 1 timed out, due to gcc12 inline assembly miscompilation
16:54:23 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2053729
16:54:23 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/709
16:54:23 <coremodule> #info Proposed Blocker, kernel, POST
16:54:24 <coremodule> #info Ticket vote: FinalBlocker (+4,0,-0) (+nielsenb, +lruzicka, +bcotton, +jforbes)
16:54:35 <frantisekz> this should be closed imo
16:54:46 <coremodule> agreed.
16:54:49 <frantisekz> it's fixed, there is another bug tracking the gcc12 regression
16:54:51 <coremodule> it was reopened this morning.
16:55:08 <frantisekz> either closed or blocker tracking removed
16:55:12 <frantisekz> adamw: wdyt?
16:55:17 <jforbes> The bug being opened makes sense, just remove the blocker tracking
16:55:29 <adamw> just looking
16:55:44 <jforbes> Once the gcc fix is in, we will revert the kernel patch, and I want the history there if that causes issues
16:56:11 <adamw> yeah, drop blocker metadata seems appropriate
16:56:17 <frantisekz> will do
16:56:24 <adamw> if the 'wrong' fix is good enough, getting the 'right' one in doesn't need to be blocker/fe
16:56:29 <adamw> it can just happen normally
16:56:48 <frantisekz> will drop just the blocks: blockertracker?
16:56:55 <frantisekz> or even the whiteboard ?
16:58:04 <adamw> both
16:58:27 <adamw> i can do it
16:58:36 <frantisekz> done
16:59:00 <coremodule> #topic (2063156) Workstation Live is frozen in a VM with QXL video driver (Virtio works OK)
16:59:00 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063156
16:59:00 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/656
16:59:00 <coremodule> #info Proposed Blocker, mutter, NEW
16:59:01 <coremodule> #info Ticket vote: BetaBlocker (+1,0,-4) (+ngompa, -frantisekz, -chrismurphy, -nielsenb, -lruzicka)
16:59:02 <coremodule> #info Ticket vote: FinalBlocker (+0,0,-3) (-bcotton, -nielsenb, -kparal)
16:59:04 <coremodule> #info Ticket vote: BetaFreezeException (+1,0,-0) (+lruzicka)
16:59:06 <coremodule> #info Ticket vote: FinalFreezeException (+2,0,-0) (+nielsenb, +kparal)
16:59:18 <frantisekz> I've implemented the virt-manager workaround
16:59:36 <frantisekz> there can be some cases when either virt-manager or boxes fall back to qxl
16:59:51 <frantisekz> but those should affect only fraction of users
16:59:57 <frantisekz> *small fraction
17:00:33 <cmurf> sounds like -1 blocker now, but then i wonder if we heard from maintainers?
17:00:35 <adamw> so we cleared AcceptedBlocker but not blocks:
17:00:40 <adamw> which has the effect of making it proposed again
17:00:44 <bcotton> frantisekz: that workaround was for F35, right? so we shouldn't need anything additional for F36?
17:00:44 <adamw> was that the intent?
17:00:45 <frantisekz> yep
17:00:59 <frantisekz> yes, it affected only f35
17:01:06 <adamw> if the idea was that landing the workaround in f35 is already agreed to be a sufficient fix, we should've removed both
17:01:09 <frantisekz> virt-manager in f36 defaults to virtio in most cases
17:01:13 <cmurf> got it
17:01:27 <frantisekz> I wasn't sure about the ngompa's problem
17:01:33 <bcotton> +1 to f35 workaround is a sufficient fix
17:01:37 <lruzicka2> frantisekz, however, switching to QXL will bring instability into the VM, if people decide to choose so.
17:01:44 <frantisekz> talked with boxes maint, it shouldn't normally happen
17:01:53 <frantisekz> you can switch to bochs lruzicka2
17:02:05 <lruzicka2> what is bochs?
17:02:06 <frantisekz> or vga, or any other which might not be stable
17:02:32 <lruzicka2> ok, I did not know that most of the options are useless :D
17:02:36 <frantisekz> there is ton of different config options in virt-manager that could make your vm unstable, if you don't know what you're doing
17:03:55 <adamw> unless anyone thinks the f35 workaround wasn't enough, we should just strip the blocks: FinalBlocker from this and moveon
17:04:03 <lruzicka2> it is enough
17:04:10 <frantisekz> will do that from both then :)
17:04:31 <coremodule> I like that idea
17:04:37 <coremodule> moving on...
17:04:39 <coremodule> #topic (2071226) anaconda failed to start a live session on  a VM with QXL video driver (Virtio works OK)
17:04:40 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2071226
17:04:40 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/710
17:04:40 <coremodule> #info Proposed Blocker, mutter, NEW
17:04:40 <coremodule> #info Ticket vote: FinalBlocker (+0,0,-1) (-kparal)
17:04:41 <coremodule> #info Ticket vote: FinalFreezeException (+1,0,-0) (+kparal)
17:04:54 <adamw> presumably this is the same in effect
17:04:57 <Southern_Gentlem> -1
17:05:56 <bcotton> -1 unless someone can explain how this is substantially different :-)
17:06:09 <adamw> yeah, this is the same
17:06:13 <coremodule> -1 FB
17:06:17 <adamw> we removed AcceptedBlocker but didn't remove blocks:
17:06:23 <adamw> so it doesn't need a vote, we just need to clean up that removal.
17:06:28 <coremodule> ah, good
17:07:08 <coremodule> you good with that frantisekz?
17:07:32 <frantisekz> yep
17:07:35 <coremodule> cool
17:07:37 <coremodule> #topic (2073708) pyanaconda.modules.common.errors.installation.StorageInstallationError: device is active
17:07:37 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2073708
17:07:37 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/733
17:07:37 <coremodule> #info Proposed Blocker, python-blivet, NEW
17:07:38 <coremodule> #info Ticket vote: FinalBlocker (+2,0,-0) (+nielsenb, +kparal)
17:07:39 <coremodule> #info Ticket vote: FinalFreezeException (+2,0,-0) (+asciiwolf, +nielsenb)
17:09:18 <frantisekz> +1 FinalBlocker
17:09:25 <coremodule> seems to violate "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration. "
17:09:45 <frantisekz> these bugs you find completely by accident are best...
17:10:08 <coremodule> at least not intentionally like kparal :)
17:10:41 <adamw> i think there may be a better criterion, let me see
17:10:43 <bcotton> i'm not entirely sure it violates that criterion. if you deleted the old partitions first, would it work?
17:11:14 <bcotton> (i'm not saying we shouldn't support installing alongside an existing install, just trying to figure out where the line is)
17:12:11 <adamw> there's a beta "Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" (for custom storage)
17:12:32 <adamw> there's also guided "Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation"
17:12:46 <bcotton> +1 blocker based on either of those criteria
17:13:31 <lruzicka2> +1 blocker
17:13:37 <adamw> +1 , using the guided criterion i guess, as most of the reports in the bug are for guided.
17:13:43 <coremodule> proposed #agreed 2073708 – AcceptedBlocker – The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion: “When using the guided partitioning flow, the installer must be able to… Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation".
17:13:58 <cmurf> +1 finalblocker
17:14:05 <bcotton> ack
17:14:07 <cmurf> oh i'm late per usual
17:14:08 <cmurf> ack
17:14:09 <frantisekz> ack
17:14:32 <adamw> ack
17:14:38 <coremodule> #agreed 2073708 – AcceptedBlocker – The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion: “When using the guided partitioning flow, the installer must be able to… Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation".
17:14:47 <coremodule> #topic (2070764) selinux-policy is preventing flatpak from updating / installing  / removing flatpaks
17:14:48 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2070764
17:14:48 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/702
17:14:48 <coremodule> #info Proposed Blocker, selinux-policy, ON_QA
17:14:49 <coremodule> #info Ticket vote: FinalBlocker (+2,0,-0) (+nielsenb, +lruzicka)
17:14:50 <coremodule> #info Ticket vote: FinalFreezeException (+2,0,-0) (+asciiwolf, +nielsenb)
17:16:32 <bcotton> +1 blocker
17:16:41 <adamw> this seems a bit...confused
17:16:53 <adamw> only affects (some) upgraded systems?
17:19:58 <coremodule> so... votes?
17:20:03 <adamw> also, what criterion does it violate?
17:20:21 <adamw> "Can't have a system where flatpaks don't update" is not an actual criterion
17:20:54 <bcotton> I'd say https://fedoraproject.org/wiki/Basic_Release_Criteria#Installing.2C_removing_and_updating_software
17:21:24 <adamw> interpet "This includes - but is not necessarily limited to - non-module packages, official module streams that are enabled (including any enabled by default in a release-blocking deployment), and rpm-ostree updates and rollbacks for any release-blocking rpm-ostree-based deployment. The criterion should also be reasonably interpreted to cover any other form of software distribution that we invent in future and include in an otherwise
17:21:24 <adamw> release-blocking deployment of Fedora, but have not yet updated this text to specifically refer to. "
17:22:07 <adamw> do we include flatpak in workstation by default?
17:22:13 <cmurf> yes
17:22:22 <cmurf> but no flatpaks as far as i'm aware
17:22:47 <frantisekz> -1 FinalBlocker; +1 FE then?
17:22:52 <adamw> looks like we do
17:23:00 <adamw> so, hmm. bit tight.
17:23:37 <adamw> i'm at least +1 FE anyway...
17:23:45 <cmurf> +1 FE
17:23:51 <lruzicka2> +1FE
17:23:59 <cmurf> if there were a flatpak installed by default that can't be updated, then I'd be +1 finalblocker
17:24:34 <Southern_Gentlem> -1 FB +1 fe
17:24:46 <bcotton> the fact that it prevents installs makes it different, cmurf
17:24:58 <cmurf> so this would affect silverblue though until they get an update with a fixed selinux
17:25:09 <cmurf> silverblue and kinoite
17:25:26 <adamw> well, maybe not
17:25:29 <cmurf> oh it prevents installations of flatpaks too, hmm
17:25:35 <adamw> since it seems to involve some kind of ordering problem with scriptlets during upgrade
17:25:38 <cmurf> that's sounding a bit more blockery to me
17:25:38 <bcotton> if dnf couldn't install an rpm from our repos (that isn't shipped in the defaults), that would be a blocker
17:25:44 <adamw> and silverblue/kinoite do not upgrade the way rpm-based installs do.
17:27:17 <lruzicka3> \nick lruzicka
17:27:32 <cmurf> yeah didn't kparal mention this recently on test@ list?
17:27:54 <cmurf> treating flatpak like rpm in regards to the update criterion?
17:27:55 <bcotton> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/P22CVXIZMBWNRSMZCOYEI64WAJTHXH2Y/
17:28:01 <bcotton> i believe that's the thread in question
17:28:04 <cmurf> yesthat
17:28:19 <cmurf> so i just asked in #workstation:fedoraproject.org
17:28:23 <cmurf> we can punt and come back to it
17:28:34 <cmurf> i can bring it up in the meeting tomorrow and followup
17:29:27 <cmurf> sounds like a blocker to me - yes we can fix it with an update, but then it means folks can't use the Live to install a flatpak
17:30:09 <Southern_Gentlem> and the later is bad why
17:30:40 <adamw> we can at least give it +1 FE so the update can be pushed
17:30:57 <cmurf> +1 FE
17:31:08 <coremodule> proposed #agreed 2070764 – PuntBlocker AcceptedFreezeException– The decision to delay the classification of this bug as a blocker and classify it as an “AcceptedFreezeException (Final)” was made as we would like more information from the Workstation group before making a blocker decision. We do accept it as an FE.
17:31:14 <lruzicka2> ack
17:31:48 <bcotton> what information are we waiting for exactly?
17:31:53 <Southern_Gentlem> ack
17:32:19 <coremodule> cmurf can you answer bcotton's question?
17:34:18 <cmurf> whether workstation wg considers flatpak equivalent to rpm as it relates to the install/update/remove release criterion, i.e. the thread on test@ list
17:35:09 <cmurf> the answer is going to be yes, they're equivalent, i just don't know if that time is right now with this release
17:36:15 <bcotton> okay. i don't know that we need to punt for that, but since we gave an FE and it's ON_QA, yolo
17:36:16 <cmurf> yeah so mcatanzaro says it's surely a blocker
17:36:16 <bcotton> ack to the proposal
17:36:29 <MichaelCatanzaro> Ah you're discussing this now
17:36:33 <cmurf> FE is fine for now it progresses the bug...
17:36:35 <cmurf> yes
17:36:38 <MichaelCatanzaro> I haven't read the backlog, is there no explicit criterion for this?
17:36:50 <MichaelCatanzaro> I was going to suggest special blocker if not
17:36:53 <cmurf> the criterion doesn't explicitly mention flatpak
17:37:10 <bcotton> Michael Catanzaro: arguably it's https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Installing.2C_removing_and_updating_software which doesn't mention rpms or flatpak explicitly
17:37:10 <cmurf> but it also doesn't explicitly mention RPM either
17:37:19 <adamw> we can read the basic criterion as covering it since we ship flatpak in workstation
17:37:21 <adamw> it's not really a stretch
17:37:27 <cmurf> right that's my take on it
17:38:03 * bcotton remains +1 blocker
17:38:09 <MichaelCatanzaro> "The criterion should also be reasonably interpreted to cover any other form of software distribution that we invent in future and include in an otherwise release-blocking deployment of Fedora, but have not yet updated this text to specifically refer to." that's clear enough to me, whoever wrote that anticipated this discussion
17:38:26 <cmurf> yep
17:38:41 <coremodule> sounds adamw-y
17:38:59 <cmurf> ok so nack on the proposed, and let's just take it as a blocker and move on :)
17:39:01 <cmurf> any revotes?
17:39:05 <cmurf> +1 blocker for me
17:39:19 <adamw> +1 blocker
17:39:35 <coremodule> okay, give me a minute to write the proposed
17:39:36 <MichaelCatanzaro> (Aside: Why are basic release criteria separate from beta release criteria still a thing? Are they being kept separate just on the off chance that alpha releases might return in the future?)
17:39:42 <frantisekz> +1 FinalBlocker then :)
17:39:53 <coremodule> MichaelCatanzaro, can you paste where you got that criterion from?
17:40:14 <adamw> Michael Catanzaro: it's to support gating rawhide composes
17:40:29 <MichaelCatanzaro> coremodule: https://fedoraproject.org/wiki/Basic_Release_Criteria#Installing.2C_removing_and_updating_software first dropdown under "software types"
17:40:35 <coremodule> thank yo
17:40:36 <coremodule> u
17:40:40 <cmurf> my view is that basic criterion apply all the time to rawhide and it can be at least leverage to getting obviously busted shit fixed sooner than later :)
17:40:42 <adamw> in theory, if we start gating rawhide composes, they would be gated on the basic criteria but not the beta criteria
17:40:47 <adamw> this is why they got renamed Basic
17:41:01 <cmurf> and the gating would be neat
17:41:26 <coremodule> proposed #agreed 2070764 – AcceptedBlocker – The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion: “The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated. The criterion s
17:41:26 <coremodule> hould also be reasonably interpreted to cover any other form of software distribution that we invent in future and include in an otherwise release-blocking deployment of Fedora...".
17:41:29 <coremodule> gah
17:41:55 <adamw> trim "remove and update" and the "e.g." section and the "downloading" bit
17:42:25 <bcotton> can also trim "The decision to... was made". we know the decision was make because it was marked as an accepted blocker :-)
17:43:22 <coremodule> proposed #agreed 2070764 – AcceptedBlocker – Marking “AcceptedBlocker (Final)” as it violates the following criterion: “The installed system must be able appropriately to install software with the default console tool for the relevant software type. This should be interpreted to cover any other form of software distribution that we invent in future and include in an otherwise release-blocking deployment of Fedora...".
17:43:39 <bcotton> ack
17:43:41 <cmurf> ack
17:43:42 <frantisekz> ack
17:43:53 <adamw> ack
17:44:01 <lruzicka2> ack
17:44:04 <coremodule> I'm removing the spurious "appropriately"
17:44:04 <coremodule> #agreed 2070764 – AcceptedBlocker – Marking “AcceptedBlocker (Final)” as it violates the following criterion: “The installed system must be able to install software with the default console tool for the relevant software type. This should be interpreted to cover any other form of software distribution that we invent in future and include in an otherwise release-blocking deployment of Fedora...".
17:44:24 <coremodule> #topic (2072070) F36 Silverblue won't connect to WPA2 Enterprise network (PEAP + MSChapv2)
17:44:24 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2072070
17:44:24 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/729
17:44:24 <coremodule> #info Proposed Blocker, wpa_supplicant, NEW
17:44:24 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-1) (+asciiwolf, -nielsenb)
17:44:25 <coremodule> #info Ticket vote: FinalFreezeException (+2,0,-1) (+asciiwolf, +bcotton, -nielsenb)
17:48:21 <adamw> this seems like a commonbugs/release notes sort of thing
17:48:25 <cmurf> huh why does this only affect silverblue
17:48:31 <adamw> seems to be an intentional change that disallows something considered unsafe
17:48:33 <adamw> i don't think it does
17:48:39 <adamw> further comments indicate workstation is affected too
17:48:49 <cmurf> oh i see
17:49:39 <coremodule> -1 blocker, +1 CommonBugs
17:49:59 <frantisekz> and isn't this a feature? as workarounding it by "UnsafeLegacyRenegotiation" might suggest?
17:49:59 <adamw> yeah, it's an openssl 3.0.0 change
17:50:15 <adamw> "In Openssl 1.1.1, the SSL_OP_LEGACY_SERVER_CONNECT flag was turned on by default, but It is turned off by default as of Openssl 3.0.0." (sez stackoverflow)
17:50:42 <frantisekz> it's not even a CommonBug then?
17:50:47 <frantisekz> just a change...
17:50:55 <adamw> frantisekz: well, we're not 100% strict on the definition of "bug" :D
17:51:07 <frantisekz> :D okey then
17:51:13 <adamw> i used to try and hold the line that feature changes go in release notes and bugs go in commonbugs, but these days i'd take this just for a quiet life...
17:53:03 <adamw> so yeah, -1/-1
17:53:07 <adamw> nothing to 'fix' here
17:54:20 <coremodule> proposed #agreed 2072070 – RejectedBlocker – The decision to classify this bug as a “RejectedBlocker” was made as this is a feature of openssl and not a bug. We will mark it in commonbugs for reference.
17:54:53 <bcotton> ack
17:55:31 <Southern_Gentlem> ack
17:55:58 <lruzicka2> ack
17:56:01 <coremodule> #agreed 2072070 – RejectedBlocker – The decision to classify this bug as a “RejectedBlocker” was made as this is a feature of openssl and not a bug. We will mark it in commonbugs for reference.
17:56:14 <coremodule> this coming bug was submitted during the meeting
17:56:16 <coremodule> #topic (2074157) Critical GCC 12 bug causes functions which comprise mostly volatile assembly to be dropped.
17:56:16 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2074157
17:56:16 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/738
17:56:17 <coremodule> #info Proposed Blocker, gcc, NEW
17:57:24 <adamw> so, uh
17:57:30 <adamw> if we accept this as a blocker, what happens?
17:57:45 <adamw> we pull in a new gcc, and...what? rebuild everything that was built with a 'bad' gcc? rebuild just the kernel? or...?
17:58:44 <Southern_Gentlem> and if we dont aarch64 is borked ?
17:58:59 <adamw> or, you know, might possibly be borked but nobody has checked for sure yet?
17:59:06 <coremodule> it seems like one arm dev board is borked
17:59:20 <adamw> and apparently all sorts of things might be broken but nobody seems to be reporting that they are?
17:59:45 <bcotton> this kinda feels like a thing we might waive under the too hard to fix if we do accept it
18:00:07 <bcotton> we can do a mass rebuild in a few days, but i worry about what issues that would bring out
18:00:32 <coremodule> and the arm dev board that is borked is a $3000 board that is probably not very widespread in it's use
18:00:45 <coremodule> at least that we see here in Fedora-land
18:01:02 <jlinton> Its more than one dev board AFAIK, two different ones exhibiting the same boot failure.
18:01:13 <pwhalen> it affects the mustang and seattle, as well as the root cause of the network issue in the rpi4
18:01:25 <adamw> jlinton pwhalen: so what's the practical proposal here?
18:01:38 <adamw> what would you envisage happening to fix this
18:01:39 <jlinton> I think at a minimum a corrected GCC should ship, and we rebuild the kernel.
18:02:39 <Southern_Gentlem> for just aarch64 or all arches
18:03:38 <adamw> just a gcc+kernel rebuild seems manageable, if a bit late
18:03:51 <jlinton> It sounds like the compiler bug is all arches, why its only hitting aarch64 is sorta an open question, but at least part of the assembly bug can be avoided if the code in question is using memory clobbers or m= attributes in the inline assembly
18:03:52 <adamw> i'd kinda want to have a firmer indication we know of an actual major problem on a blocking platform...
18:04:23 <adamw> mustang and seattle are the dev boards in question? are they on the list of supported devices?
18:04:58 <pwhalen> The mustang/seattle didnt boot at all until 5.17.2, which iiuc is the shipping kernel.
18:04:58 <jlinton> Given that it hits inline assembly that removes most packages from having the problem.
18:05:13 <bcotton> yeah, the fact that we're not seeing a lot of related problems is concerning: is it really not a problem or are we just not finding it yet. i don't like trying to make a decision in this state :-)
18:06:20 <adamw> it's a tough call to make for sure
18:06:24 <lruzicka2> I am sorry, need to put children to bed.
18:06:37 <coremodule> no worries, have a good night lruzicka2
18:06:42 <adamw> i wish we had a bit more time, i'd be much more comfortable with a gcc+kernel rebuild last monday than...now
18:08:24 * bcotton nods
18:09:17 <Southern_Gentlem> i am afraid of what breakage this will could cause to the rest of the ecosystem
18:09:50 <bcotton> just looking at the status of accepted blockers, it seems like we probably won't have them all fixed by tomorrow, so maybe we have some time, but...
18:10:01 <adamw> i think i'm gonna come down on -1 without a more solid indication of a specific outstanding major bug here
18:10:08 <jlinton> If you look at the patch (and i'm not much of a gcc expert) it actually just looks like the worse case is you could get some extra functions here/there, but then again, those should be there.
18:10:11 <adamw> i could be +1 fe to do the fix if we slip
18:11:58 <bcotton> yeah, i guess i'm: 0 blocker, +1 fe
18:12:38 <Southern_Gentlem> -1 fb +1 fe
18:13:29 <coremodule> So we have -2 FB, +3 FE...
18:14:01 <Southern_Gentlem> and i am iffy on the fe
18:14:20 <coremodule> I guess I'm leaning more towards -1 blocker, +1 FE
18:15:14 <adamw> like I said, I'm only +1 FE in case we slip
18:15:30 <Southern_Gentlem> i guess we will see if it makes it into a RC so we can test
18:15:44 <cmurf> agree with adamw, +1 FE if we slip
18:15:49 <coremodule> should we punt for slip then?
18:16:03 <Southern_Gentlem> +1 punt for now
18:16:15 <adamw> well, it saves us having to revote if the slip happens, but i'm easy.
18:16:25 <adamw> we can still create the update and send it to testing
18:16:37 <cmurf> i prefer to vote the conditional FE
18:16:50 <cmurf> the slip only FE
18:18:08 <coremodule> proposed #agreed 2074157 – RejectedBlocker AcceptedFreezeException – The decision to classify this bug as a “RejectedBlocker” and a conditional “AcceptedFreezeException (Final)” was made as we are wary of what breakage this could cause this late in the cycle, and we don’t have any reports of major issues that this bug causes. We are willing to accept this as an FE if we slip F36 this week.
18:18:54 <bcotton> ack
18:18:56 <adamw> ack
18:19:53 <Southern_Gentlem> ack
18:19:55 <coremodule> #agreed 2074157 – RejectedBlocker AcceptedFreezeException – The decision to classify this bug as a “RejectedBlocker” and a conditional “AcceptedFreezeException (Final)” was made as we are wary of what breakage this could cause this late in the cycle, and we don’t have any reports of major issues that this bug causes. We are willing to accept this as an FE if we slip F36 this week.
18:20:29 <coremodule> okay, lets do FEs
18:20:39 <coremodule> #topic Proposed Freeze Exceptions
18:20:45 <coremodule> #topic (2073406) Win+P (or the multimedia key) doesn't configure monitors properly, always switches to Mirror and native resolution
18:20:45 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2073406
18:20:45 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/735
18:20:45 <coremodule> #info Proposed Freeze Exceptions, gnome-control-center, NEW
18:20:46 <coremodule> #info Ticket vote: FinalFreezeException (+2,0,-0) (+kparal, +asciiwolf)
18:21:21 <coremodule> +1 FE
18:21:49 <bcotton> +1 FW
18:21:51 <bcotton> +1 Fe, too
18:22:51 <frantisekz> +1 FE
18:23:08 <coremodule> proposed #agreed 2073406 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
18:24:56 <frantisekz> ack
18:25:14 <Southern_Gentlem> ack
18:25:55 <bcotton> ack
18:25:56 <adamw> ack
18:25:58 <coremodule> #agreed 2073406 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
18:26:09 <coremodule> #topic (2062619) IBus stop working after locking screen
18:26:09 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2062619
18:26:09 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/731
18:26:09 <coremodule> #info Proposed Freeze Exceptions, ibus, NEW
18:26:10 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-1) (+asciiwolf, -nielsenb)
18:26:11 <coremodule> #info Ticket vote: FinalFreezeException (+2,0,-0) (+asciiwolf, +nielsenb)
18:26:25 <frantisekz> +1 FE
18:26:53 <Southern_Gentlem> _1 fe
18:26:59 <Southern_Gentlem> +1 fe rather
18:28:46 <bcotton> +1 fe
18:28:58 <coremodule> proposed #agreed 2062619 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
18:29:09 <frantisekz> ack
18:29:24 <adamw> this might be a blocker
18:29:41 <frantisekz> I'll need to run, will finish the FE secretary stuff later in the evening, blockers should be all secretalized :)
18:29:47 <adamw> hmm, well, if you can work around by changing focus maybe not, but...
18:30:02 <coremodule> thanks frantisekz
18:30:24 <frantisekz> thanks coremodule for leading the mtg and rest for attending :)
18:31:45 <adamw> anyway, i'm at least +1 FE
18:32:03 <bcotton> yeah, i can see a case for making this a blocker. i don't know how ibus works well enough to say with any certainty
18:32:19 <bcotton> so i guess ack to the proposal and if someone wants to nominate it as a blocker, we can have that conversation
18:33:24 <coremodule> #agreed 2062619 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
18:33:40 <coremodule> #topic (2063156) Workstation Live is frozen in a VM with QXL video driver (Virtio works OK)
18:33:40 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2063156
18:33:40 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/656
18:33:40 <coremodule> #info Proposed Freeze Exceptions, mutter, NEW
18:33:41 <coremodule> #info Ticket vote: BetaBlocker (+1,0,-4) (+ngompa, -frantisekz, -chrismurphy, -nielsenb, -lruzicka)
18:33:42 <coremodule> #info Ticket vote: FinalBlocker (+0,0,-3) (-bcotton, -nielsenb, -kparal)
18:33:44 <coremodule> #info Ticket vote: BetaFreezeException (+1,0,-0) (+lruzicka)
18:33:46 <coremodule> #info Ticket vote: FinalFreezeException (+2,0,-0) (+nielsenb, +kparal)
18:34:19 <bcotton> didn't we do this during the proposed blockers section?
18:34:40 <adamw> yeah
18:34:44 <adamw> but
18:34:53 <adamw> i think kparal wanted to discuss it as fe even with the f35 workaround
18:35:10 <adamw> since there are still the cases of f34 or people running on VMs with qxl already set
18:37:13 <adamw> i guess i'd be +1 for a safe fix for that, though there doesn't seem to be much prospect of one
18:37:50 <bcotton> yeah, that's how i feel
18:38:12 <bcotton> +1 fe knowing it probably wont' happen 🤷
18:38:23 <coremodule> Okay, +1 FE here too
18:38:29 <coremodule> proposed #agreed 2063156 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
18:38:48 <bcotton> ack
18:38:55 <Southern_Gentlem> ack
18:40:47 <adamw> ack
18:40:54 <coremodule> #agreed 2063156 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
18:41:04 <coremodule> #topic (2071226) anaconda failed to start a live session on  a VM with QXL video driver (Virtio works OK)
18:41:05 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2071226
18:41:05 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/710
18:41:05 <coremodule> #info Proposed Freeze Exceptions, mutter, NEW
18:41:05 <coremodule> #info Ticket vote: FinalBlocker (+0,0,-1) (-kparal)
18:41:06 <coremodule> #info Ticket vote: FinalFreezeException (+1,0,-0) (+kparal)
18:42:25 <bcotton> same, I guess?
18:42:25 <bcotton> +1 fe
18:42:47 <adamw> yeah, same
18:42:49 <adamw> +1 FE
18:44:52 <coremodule> +1 fE
18:44:55 <coremodule> proposed #agreed 2071226 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
18:45:26 <bcotton> ack
18:48:23 <adamw> ack
18:48:30 <coremodule> ack
18:48:32 <coremodule> can I do that?
18:48:35 <coremodule> #agreed 2071226 – AcceptedFreezeException – The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a noticeable issue that cannot be fixed with an update.
18:48:53 <coremodule> #topic (2072070) F36 Silverblue won't connect to WPA2 Enterprise network (PEAP + MSChapv2)
18:48:53 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2072070
18:48:53 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/729
18:48:53 <coremodule> #info Proposed Freeze Exceptions, wpa_supplicant, NEW
18:48:53 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-1) (+asciiwolf, -nielsenb)
18:48:54 <coremodule> #info Ticket vote: FinalFreezeException (+2,0,-1) (+asciiwolf, +bcotton, -nielsenb)
18:49:05 <coremodule> this isn't a bug, it's a feature!
18:49:16 <coremodule> -1 FE
18:50:37 <adamw> coremodule: you can't do that, but never mind :D
18:51:00 <coremodule> hah, for the sake of time, I bent the rules!!
18:51:35 <bcotton> adam goes on pto and coremodule becomes ungovernable
18:52:01 <coremodule> absolute power corrupts! there's no stopping me now!
18:52:47 <adamw> oh lord, what have I done
18:52:58 <adamw> didn't we cover this earlier?
18:53:14 <coremodule> yeah, we did
18:53:22 <adamw> yeah, this is the 'feature; one. right
18:53:26 <adamw> so, same conclusion.
18:53:48 <coremodule> proposed #agreed 2072070 – RejectedFreezeException – The decision to classify this bug as an "RejectedFreezeException (Final)" was made as the bug in question is actually expected behavior in openssl. We reject it as an FE on this basis.
18:55:09 <bcotton> ack
18:56:56 <adamw> ac
18:57:01 <coremodule> ack
18:57:07 <coremodule> #agreed 2072070 – RejectedFreezeException – The decision to classify this bug as an "RejectedFreezeException (Final)" was made as the bug in question is actually expected behavior in openssl. We reject it as an FE on this basis.
18:57:19 <coremodule> okay...
18:57:38 <coremodule> considering the 3 hour time limit, we have just a minute or two for...
18:57:43 <coremodule> #topic Open Floor
18:58:24 <bcotton> we survived
18:58:44 <coremodule> #info we survived
18:58:47 <adamw> woohoo
18:59:01 <adamw> thanks coremodule
18:59:15 <coremodule> you got it, hope the UK is treating you well...
18:59:18 <bcotton> an idea that i don't want anyone to talk about, just ruminate on: what if we had the criteria as an ordered list so that we could just use alphanumeric references when referring to them
18:59:57 <bcotton> if i remember, i'll propose this post-release, but i wanted to plant the seed
19:00:18 <coremodule> that could be a good idea. I also had an idea regarding criteria during the meeting, what if we *require* that a user submit a violated criterion when they submit a bug as a blocker?
19:00:35 <coremodule> so we don't have "this is a bad bug and should be fixed" as a blocker justification?
19:00:52 <bcotton> i've thought about that. i worry it might be hostile to folks who don't spend a lot of time wallowing in the blockers
19:01:13 <adamw> coremodule: i've thought about that but i'm not sure how it would work
19:01:15 <adamw> yeah
19:01:18 <adamw> and just the practicalities
19:01:29 <adamw> does that mean we reject all proposals without a cited criterion?
19:01:38 <adamw> even if it's obvious to us that it does violate one?
19:01:59 <coremodule> adamw, maybe, just as a matter of course... people would get the idea. though it does feel rather orwellian
19:02:00 <adamw> to me it makes more sense for the onus to be on us at the meeting to only accept bugs that do violate a criterion, but it's fine for us to identify it
19:03:45 <coremodule> yeah, it makes it easier for new contributors, that's for sure. Anyway, thanks for staying through to the end.
19:03:48 <coremodule> See you... later
19:03:59 <adamw> yup! cya
19:04:06 <coremodule> #endmeeting