17:00:08 <adamw> #startmeeting F36-blocker-review
17:00:08 <zodbot> Meeting started Mon Feb 28 17:00:08 2022 UTC.
17:00:08 <zodbot> This meeting is logged and archived in a public location.
17:00:08 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:08 <zodbot> The meeting name has been set to 'f36-blocker-review'
17:00:10 <adamw> #meetingname F36-blocker-review
17:00:10 <zodbot> The meeting name has been set to 'f36-blocker-review'
17:00:13 <frantisekz> .hello2
17:00:14 <adamw> #topic Roll Call
17:00:14 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
17:00:15 <cmurf> .hello
17:00:16 <zodbot> cmurf: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
17:00:24 <adamw> morning folks, who's around to review some blockers?
17:00:28 <cmurf> .hello cmurf
17:00:29 <zodbot> cmurf: cmurf 'Chris Murphy' <chris@cmurf.com>
17:00:40 <cmurf> i exist!
17:01:09 <coremodule> .hello2
17:01:10 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
17:01:14 * coremodule willing to act as secretary.
17:01:15 <geraldosimiao> .hello geraldosimiao
17:01:16 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
17:01:23 <adamw> cmurf: [citation needed]
17:01:32 <lruzicka> .hello2
17:01:33 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
17:02:48 <cmurf> I'm not canucking today
17:03:35 <bcotton> .hello2
17:03:36 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:04:03 <adamw> ahoyhoy everyone
17:04:11 <lruzicka> hoy
17:04:40 <adamw> #chair lruzicka bcotton
17:04:40 <zodbot> Current chairs: adamw bcotton lruzicka
17:04:47 <adamw> impending boilerplate alert!
17:04:55 <adamw> Why are we here?
17:04:55 <adamw> #topic Introduction
17:04:57 <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.
17:05:01 <adamw> #info We'll be following the process outlined at:
17:05:05 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
17:05:08 <adamw> #info The bugs up for review today are available at:
17:05:10 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
17:05:13 <adamw> #info The criteria for release blocking bugs can be found at:
17:05:16 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
17:05:19 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria
17:05:23 <adamw> #link https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria
17:05:33 <adamw> #info for Beta, we have:
17:05:42 <adamw> #info 2 Proposed Blockers
17:05:42 <adamw> #info 8 Accepted Blockers
17:05:44 <adamw> #info 6 Proposed Freeze Exceptions
17:05:48 <adamw> #info 3 Accepted Freeze Exceptions
17:05:59 <adamw> #info for Final, we have:
17:06:00 <adamw> #info 7 Proposed Blockers
17:06:09 <adamw> #info 4 Accepted Blockers
17:06:09 <adamw> #info 1 Proposed Freeze Exceptions
17:06:18 <adamw> #info coremodule will secretarialize, thanks!
17:06:30 <adamw> so, let's get started with:
17:06:34 <adamw> #topic Proposed Beta blockers
17:06:41 <adamw> #topic (2057193) f36 composes still have firefox 96, f34 f35 have firefox 97
17:06:45 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2057193
17:06:49 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/624
17:06:52 <adamw> #info Proposed Blocker, firefox, NEW, depends on other bugs
17:06:57 <adamw> #info Ticket vote: BetaBlocker (+2,0,-0) (+bcotton, +nielsenb)
17:06:59 <adamw> #info Ticket vote: BetaFreezeException (+3,0,-0) (+churchyard, +imsedgar, +nielsenb)
17:08:12 <adamw> so, per the last two comments on the bug, downgrading from 97 to 96 is known to cause major problems
17:08:17 <lruzicka> +1 BetaBlocker
17:08:32 <adamw> since an upgrade from f35 to f36 would cause that to happen by default, i think, i'd say +1 blocker to this
17:09:05 <adamw> oh, wait, hm
17:09:08 <adamw> i think it's clearly a final blocker
17:09:11 <adamw> not sure about beta
17:09:37 <adamw> i think we could plausibly argue it for Beta on "All known bugs that can cause corruption of user data must be fixed or documented at Common F36 bugs. "
17:10:04 <adamw> a firefox user profile is pretty significant 'user data', if mine was rendered unusable by an upgrade 35->36 i'd be narked off
17:11:11 <adamw> there's also a basic criterion "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments"
17:11:23 <adamw> which may be violated by the broken state, by the looks of Chris' mozilla report
17:11:32 <lruzicka> adamw, yes, that sounds good ... we should make upgrade as reliable as possible
17:11:33 <frantisekz> +1 BetaBlocker then if we find suitable criterion, otherwise BetaFE and FinalBlocker
17:12:01 <bcotton> yeah, and cmurf proposed it with the "hinders execution of test plans or dramatically reduces test coverage" criterion, and i think "destroys my default browser's profile" would drive away a lot of testers
17:12:15 <adamw> ok, so i think i'm +1 beta blocker and we can cite all three of those
17:12:17 <bcotton> so there are several plausible justifications for accepting this
17:12:55 <cmurf> yeah there's no reasonable way to disambiguate whether behaviors are bugs or due to this
17:13:43 <cmurf> at one point 1 in 3 websites were doing some weird shit and i kept thinking this is one f'd up build of firefox - i was super confused as you can see from the upstream bug report
17:13:59 <cmurf> blow away the profile, voila, fixed
17:15:06 <adamw> ok, other votes?
17:15:14 <cmurf> there's a test@ rfc i sent to make this a release criteria so we can just skip over this question - it's come up before when we even shipped a beta with a downgraded firefox
17:15:35 <cmurf> * this question in the future - it's
17:15:59 <geraldosimiao> +1 FE
17:15:59 <geraldosimiao> +1 Final Blocker
17:16:08 <cmurf> +1 beta blocker
17:17:38 <adamw> Ben Cotton (he/him): frantisekz are you +1?
17:17:49 <bcotton> aye
17:17:51 <adamw> i.e. do you think the plausible justifications are plausible enough? :D
17:17:56 <OnuralpSezer[m]> FF +1 BB I(If my vote accepted)
17:18:15 <OnuralpSezer[m]> s/I//
17:18:33 <adamw> all votes are accepted!
17:18:42 <adamw> vote early and vote often, folks
17:18:45 <pwhalen> +1 BB
17:21:41 <adamw> proposed #agreed 2057193 - AcceptedBlocker (Beta) - upgrade criterion footnote requires upgraded system to meet other release criteria, we consider this to violate Basic criterion footnote "The web browser must be able to download files, load extensions (if applicable), and log into FAS" and Beta criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F36 bugs." if Firefox is downgraded
17:21:41 <adamw> from 97 to 96 on upgrade to F36
17:21:49 <adamw> did that make it on one line, IRC folks?
17:22:31 <pwhalen> not quite
17:22:51 <adamw> grr
17:23:06 <frantisekz> "from 97 to 96 on upgrade to F36" on next line
17:23:30 <adamw> proposed #agreed 2057193 - AcceptedBlocker (Beta) - upgrade criterion footnote requires upgraded system to meet other release criteria, we consider this to violate Basic criterion footnote "The web browser must be able to download files, load extensions (if applicable), and log into FAS" and Beta criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F36 bugs" if Firefox downgraded on
17:23:30 <adamw> upgrade to F36
17:23:49 <cmurf> uhh i don't hate it
17:23:53 <adamw> better? if it missed by less than 9 characters we're good because of "proposed"
17:23:56 <cmurf> but thing is, the browser mostly works
17:24:04 <cmurf> it's about 1/3 of cases that don't
17:24:13 <adamw> cmurf: don't complicate things! it's easy this way. :D
17:24:19 <bcotton> ack
17:24:24 <cmurf> i think the stronger argument is the beta criterion catch all for inhibiting testing
17:24:39 <cmurf> but i'll General Ackbar this one because otherwise it's a trap
17:24:43 <adamw> i'd like to include all three but there isn't space
17:24:48 <adamw> we can reference all three on the bug or ticket
17:24:57 <adamw> i'll add a supplementary #info too
17:26:18 <lruzicka> ack
17:26:27 <geraldosimiao> ACK
17:26:41 <adamw> #agreed 2057193 - AcceptedBlocker (Beta) - upgrade criterion footnote requires upgraded system to meet other release criteria, we consider this to violate Basic criterion footnote "The web browser must be able to download files, load extensions (if applicable), and log into FAS" and Beta criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F36 bugs" if Firefox downgraded on upgrade to
17:26:41 <adamw> F36
17:26:44 <pwhalen> ack
17:28:02 <adamw> #info for 2057193 we also cite the Beta blocker catch-all wording, that "A bug is considered a Beta blocker bug if ... Bug hinders execution of required Beta test plans or dramatically reduces test coverage" - we believe this bug would have that effect, as it would prevent people who would otherwise upgrade to the Beta and help test from doing so
17:28:19 <adamw> ok, next bug!
17:28:20 <adamw> #topic (2057719) After upgrade gnome-control-center to 42~beta-1.fc37  unable to configure VPN connection
17:28:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2057719
17:28:32 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/630
17:28:33 <adamw> #info Proposed Blocker, gnome-control-center, NEW
17:28:43 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+bcotton)
17:28:45 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+bcotton)
17:28:56 <adamw> btw, bcotton gets the gold star for ticket voting this week, everyone else gets a lump of coal
17:29:32 <bcotton> 🎉
17:29:32 <geraldosimiao> 😶
17:30:14 <cmurf> umm fc37?
17:30:45 <adamw> cmurf: comments suggest it affects 42~beta in f36
17:30:58 <adamw> which means it doesn't affect stable right now, but, we have an FE for 42~beta to be included and the update is pending stable
17:31:10 <adamw> so i could push it into f36 right now (and mclasen asked me to do so). so we should probably consider this
17:31:13 <cmurf> got it
17:31:21 <adamw> i feel like we discussed specific VPN requirements before?
17:31:28 <adamw> but i don't see any in the criteria. hmm. let me go digging
17:31:42 <cmurf> well actually the FE is for gnome 42 RC being in f36 beta
17:31:50 <bcotton> i think it was with the systemd-resolved change a release or two or three ago (what even is time?)
17:32:23 <adamw> cmurf: oh. yes. we should probably re-title that then.
17:32:39 <cmurf> pretty sure i titled it rc
17:32:55 <adamw> yes
17:33:02 <adamw> so we could change that. maybe it should be vaguer. :P
17:33:06 <adamw> i'll, uh, throw that on the agenda for later
17:33:29 <cmurf> ship GNOME 42.rc in Fedora 36 beta ?
17:33:55 <cmurf> i think what makes me do a double take is we just got 42.beta into stable
17:34:04 <adamw> cmurf: no we didn't
17:34:06 <adamw> that's the point
17:34:09 <adamw> 42~beta is not in stable yet
17:34:19 <cmurf> 🤦
17:34:37 <cmurf> ok, i guess i got it from u-t then
17:34:45 <adamw> anyhoo, yeah, there's a thread from august 2020 titled "Release criteria proposal: networking requirements"
17:35:21 <adamw> i sent a second draft on 2020-08-28
17:36:05 <adamw> after that there was some argy bargy about mDNS and kamil said the draft looked good, and then we forgot about it
17:36:20 <adamw> business as usual at fedora hq, then
17:37:16 * adamw resurrects the thread
17:37:22 <geraldosimiao> +1 FE
17:37:22 <geraldosimiao> +1 FinalBlocker
17:38:14 <adamw> fwiw, the wording i proposed was "Using the default network configuration tools for the console and for
17:38:14 <adamw> release-blocking desktops, it must be possible to establish a working
17:38:14 <adamw> connection to common OpenVPN, openconnect-supported and vpnc-supported
17:38:14 <adamw> VNC servers with typical configurations." as a Basic criterion.
17:38:39 <lruzicka> I would support this criterion.
17:38:39 <adamw> we could punt this for a week to resurrect the criterion discussion, i guess?
17:38:44 <adamw> well, accept it as FE and punt on blocker
17:38:45 <lruzicka> let's do it
17:38:51 <lruzicka> ack
17:38:53 <adamw> cos i'm definitely +1 FE
17:39:35 <frantisekz> +1 FE
17:39:58 <bcotton> i'm not convince this should be a beta blocker, but i think accepting an FE and punting on blocker for criterion discussion is a good approach
17:40:42 <lruzicka> +1fe
17:40:44 <pwhalen> +1 FE
17:41:27 <geraldosimiao> ACK
17:42:14 <cmurf> i think punt is enough, we're not at final freeze yet
17:42:55 <adamw> proposed #agreed 2057719 - punt (delay decision) on blocker status, AcceptedFreezeException (Beta) - we do not have specific criteria for VPN connections, and trying to stretch existing criteria to fix this is difficult. we do have proposed specific criteria from 2020, so we will resurrect the discussion on those criteria and decide on blocker status when that's done. This is definitely serious enough to grant an FE, though
17:43:05 <lruzicka> ack
17:43:23 <bcotton> ack
17:44:46 <pwhalen> ack
17:45:38 <adamw> #agreed 2057719 - punt (delay decision) on blocker status, AcceptedFreezeException (Beta) - we do not have specific criteria for VPN connections, and trying to stretch existing criteria to fix this is difficult. we do have proposed specific criteria from 2020, so we will resurrect the discussion on those criteria and decide on blocker status when that's done. This is definitely serious enough to grant an FE, though
17:45:58 <adamw> OK, since we're in Beta freeze, next let's do:
17:46:02 <adamw> #topic Proposed Beta freeze exceptions
17:46:13 <adamw> #topic (2058502) libyui-mga-gtk won't currently install on fc36 or Rawhide
17:46:18 <Eighth_Doctor> 👋
17:46:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2058502
17:46:23 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/634
17:46:28 <adamw> #info Proposed Freeze Exceptions, libyui-mga-gtk, MODIFIED
17:46:34 <adamw> yes, Conan Kudo ? did you bring enough gum for the whole class?
17:46:50 <Eighth_Doctor> nope
17:46:59 <Eighth_Doctor> just hangry and wanting to get my blockers/FEs through :)
17:47:15 <adamw> okay, so three of the proposed FEs are fails-to-install issues
17:47:38 <adamw> which we typically grant FEs on the basis that they cause upgrades to require --allowerasing if you have the package installed, and we want to avoid that if possible
17:47:54 <adamw> so i'm gonna propose a blanket vote on those
17:48:20 <bcotton> +1 blanket BetaFE for FTI bugs
17:48:35 <Eighth_Doctor> +1 blanket BetaFE for FTI/FTBFS bugs
17:48:41 <adamw> proposal is we accept 2058502 , 2046220 and 2044286 as FE as they are fails-to-install bugs
17:48:43 <adamw> +1 from me
17:48:51 <geraldosimiao> ack
17:48:54 <lruzicka> +1
17:48:57 <adamw> i should probably write something for the automatic FE page or something here.
17:49:01 <cmurf> +1 blanket beta fe for fti/ftbfs bugs
17:49:34 <Eighth_Doctor> yeah, I think FTI/FTBFS bugs should get automatic FEs
17:49:50 <Eighth_Doctor> it's not like we can't identify them from the blocker tickets associated with them
17:49:50 <adamw> proposed #agreed 2058502 , 2046220 and 2044286 are all: AcceptedFreezeException (Beta) as they are fails-to-install bugs. We typically grant FEs for these to avoid upgrades of systems with these packages installed requiring the use of `--allowerasing`, as that can be dangerous and we want to avoid it where possible
17:50:04 <bcotton> ack
17:50:08 <Eighth_Doctor> ack
17:50:09 <geraldosimiao> ack
17:50:24 <adamw> #agreed 2058502 , 2046220 and 2044286 are all: AcceptedFreezeException (Beta) as they are fails-to-install bugs. We typically grant FEs for these to avoid upgrades of systems with these packages installed requiring the use of --allowerasing, as that can be dangerous and we want to avoid it where possible
17:50:33 <adamw> okey dokey
17:50:34 <adamw> #topic (2054921) dnf system-upgrade 35 to 36 fails with various pipewire wireplumber conflicts
17:50:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2054921
17:50:43 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/612
17:50:48 <adamw> #info Proposed Freeze Exceptions, pipewire, NEW
17:50:54 <adamw> #info Ticket vote: BetaFreezeException (+1,0,-0) (+bcotton)
17:51:08 <Eighth_Doctor> +1 BetaFE
17:51:15 <adamw> did we actually figure out any way to fix this yet? i'm not entirely sure it's possible
17:51:19 <Eighth_Doctor> though I'd consider that blockery honestly
17:51:50 <adamw> well, i guess we still didn't figure out exactly what's going on.
17:51:53 <Eighth_Doctor> this is the first time I've ever seen something like this actually
17:52:03 <adamw> it's already rejected as a blocker.
17:52:03 <geraldosimiao> last night I did such an upgrade F35kde - F36 and pipewire did well
17:52:05 <Eighth_Doctor> oh, I see what's happening
17:52:11 <lruzicka> +1 BetaFE
17:52:31 <Eighth_Doctor> it's because someone explicitly swapped from wireplumber back to pipewire-media-session
17:52:39 <Eighth_Doctor> and dnf wants to swap them back on upgrade
17:52:46 <Eighth_Doctor> because that's what comps says we should do
17:52:49 <lruzicka> Eighth_Doctor, this is what I believe, too
17:52:51 <adamw> Conan Kudo: no, not necessarily. there was also a time during f35 cycle where you got pipewire-media-session on upgrade.
17:52:59 <geraldosimiao> only problems here was plocate and libyui-mga-gtk
17:53:00 <Eighth_Doctor> so the swappable one-and-only-one setup blocks it until the user resolves the problem
17:53:08 <adamw> but the question is why dnf wants to pull in wireplumber now.
17:53:42 <Eighth_Doctor> it should always pull wireplumber since f35
17:53:52 <lruzicka> adamw, I think it wanted to pull it for F35 already
17:54:01 <Eighth_Doctor> if it pulled pipewire-media-session ever, something messed up
17:54:16 <lruzicka> but some people experienced troubles at some point so they reverted media-session
17:54:45 <adamw> Conan Kudo: it did. we know it did. it was a blocker bug for f35.
17:55:04 <cmurf> that bug should just be closed IMO, and i'm the one who filed it
17:55:05 <geraldosimiao> lruzicka: true
17:55:26 <adamw> but the point is, if you have a system with pipewire-media-session installed right now, that satisfies deps and what we want to happen on upgrade is you keep it. we don't want the system to try and switch to wireplumber.
17:55:43 <cmurf> the root I had been using was not the root I thought it was, I thought it was an f35 ga clean install, but it was an f34 clean install upgraded to f36 after beta freeze and before beta GA
17:56:09 <geraldosimiao> adamw: fair enough
17:56:23 <cmurf> i'm 99% certain adamw has it exactly right, there was a period of ambiguity with wireplumber during that time frame and i just got sucked into the vortex
17:56:32 <Eighth_Doctor> well, the way to fix that is to make dnf warn instead of error when something is not satisfiable from comps
17:56:46 <Eighth_Doctor> like it does when no package is found
17:56:54 <lruzicka> cmurf, adamw: this is also a problem, because there might be people who would upgrade from 34 so they will experience this with this release
17:56:57 <cmurf> virtually certain that only testers would get hit by this
17:57:04 <adamw> lruzicka: no, they won't
17:57:10 <adamw> there is no pipewire-media-session in f34
17:57:19 <adamw> if you upgrade from clean f34 you'll get switched to wireplumber, which is what we want
17:57:44 <lruzicka> adamw, hah ... then no big deal, we should advice people to leave media-session and switch over
17:57:56 <cmurf> yes and somehow i got both and it's not worth trying to figure out why that happened for that 2-3 week period between f35 beta freeze and GA
17:58:42 <adamw> lruzicka: the case we care about now is people who specifically switched to pipewire-media-session because wireplumber is broken for them. the best outcome for them is if the upgrade keeps them on pipewire-media-session, rather than failing or forcing a switch to wireplumber.
17:58:53 <adamw> however, it may be tricky to actually achieve that...
17:59:07 <lruzicka> adamw, but do we know it IS STILL broken for them?
17:59:08 <cmurf> gotcha, that's a valid concern
17:59:11 <Eighth_Doctor> you can --exclude=wireplumber and that'll work
17:59:44 <cmurf> but rather than those kinds of work arounds being used regularly in the wild, we need to escalate bug fixes for those users
17:59:45 <adamw> lruzicka: we don't, but on principle we should probably let them choose to try switching back. i guess.
17:59:46 <Eighth_Doctor> because then dnf falls through to the "no package" case for comps
18:00:15 <adamw> hmm, i wonder what would happen if we made it 'default' in comps. right now the type isn't specified which i think means it gets assumed to be 'mandatory'.
18:00:40 <Eighth_Doctor> well, it's assumed to be default, I think
18:00:48 <Eighth_Doctor> hence, well... default?
18:01:10 <lruzicka> wireplumber should be the default
18:01:12 <Eighth_Doctor> but I think we explicitly set mandatory
18:01:21 <adamw> Conan Kudo: nope. it's unspecified.
18:01:30 <Eighth_Doctor> mmmm
18:01:31 <adamw> <packagereq>wireplumber</packagereq>
18:01:36 <adamw> (in the multimedia group)
18:01:59 <adamw> looking at libcomps, it actually has a specific case for this, it calls it COMPS_PACKAGE_UNKNOWN . dunno what things down the stack do with that.
18:02:28 <adamw> aaanyhoo
18:02:33 <adamw> let's try and get back on track
18:02:43 <adamw> assuming there is something that can be done to make this case Better(tm), do we think it merits an FE?
18:03:05 * Eighth_Doctor shrugs
18:03:05 <adamw> i'm gonna say 'potentially yes', so +1 but would review any update that claims to address this bug carefully
18:03:20 <Eighth_Doctor> I suppose so... +1 BetaFE
18:03:28 <Eighth_Doctor> but I suspect there's nothing we can really do here
18:03:29 <lruzicka> yes, if we can fix it for those who need that, let's do it, I say
18:03:35 <lruzicka> +1 BetaFE
18:03:43 <Eighth_Doctor> this is basically comps weirdness
18:04:05 <geraldosimiao> +1 BetaFE
18:04:12 <adamw> well, comps and dnf. i guess it's possibly the case that we could change how dnf handles this case without breaking the world
18:07:10 <adamw> proposed #agreed 2054921 - AcceptedFreezeException (Beta) - this seems like a tricky case to handle, but if there is in fact some way we can make it better, we think it's worth a freeze exception so that it reaches people upgrading before the Beta release
18:07:22 <lruzicka> ack
18:07:29 <Eighth_Doctor> ack
18:07:31 <geraldosimiao> ack
18:07:39 <bcotton> ack
18:07:52 <copperi[m]> ack
18:08:49 <adamw> #agreed 2054921 - AcceptedFreezeException (Beta) - this seems like a tricky case to handle, but if there is in fact some way we can make it better, we think it's worth a freeze exception so that it reaches people upgrading before the Beta release
18:09:07 <adamw> #topic (2057184) cgroupify: Error moving pid into new cgroup (11)
18:09:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2057184
18:09:15 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/623
18:09:18 <adamw> #info Proposed Freeze Exceptions, uresourced, NEW
18:10:21 <bcotton> so i was a 0 because i have no idea what the effect is here. it seems like it's just a spurious log message, which is a pretty meh reason to grant a freeze exception
18:11:50 <Eighth_Doctor> I'm fine with +1 BetaFE here
18:12:27 <adamw> yeah, i can't quite parse the consequences of this from the upstream report
18:12:34 <adamw> but, i mean, my system didn't explode yet, so.
18:12:44 <adamw> kinda -1 on this unless someone can explain it's more serious than a log message.
18:13:05 <Eighth_Doctor> it means that cgroupify failed to move processes into a cgroup
18:13:26 <Eighth_Doctor> which means that the resource control enforced by things like systemd-oomd would be broken
18:14:12 <Eighth_Doctor> iirc, cgroupify is used to handle this for terminal processes, chrome tabs, etc. which normally don't get put into a single cgroup
18:14:12 <adamw> did it actually fail to do that, though?
18:14:13 <adamw> or did it do it, then try to do it again by mistake?
18:14:32 <adamw> or did it not fail, but think it failed?
18:14:39 <adamw> (sort of looks a bit like the latter to me)
18:15:41 <Eighth_Doctor> it looks like 1
18:15:49 <Eighth_Doctor> where it failed to put it into the scope
18:15:56 <adamw> no, i think it's 3.
18:16:46 <adamw> the fix changes what `move_to_subgroup` returns. it does not change what it *does*.
18:16:53 <Eighth_Doctor> hmm, I see
18:16:57 <adamw> and the consequence of what it returns is...an error gets logged if what it returns is not 0.
18:18:23 <adamw> so, yeah, if I'm understanding that right, i'm -1 on principle. wouldn't likely hurt to take this, but that's what we always think. :D
18:18:59 <Eighth_Doctor> lol
18:19:51 <bcotton> okay, i'm convinced to get off the fence and also go -1
18:21:04 <adamw> we can always revote if i'm wrong
18:22:13 <Eighth_Doctor> sure
18:22:24 <adamw> any other votes?
18:23:36 <adamw> okay, well, don't all rush at once!
18:24:20 <adamw> proposed #agreed 2057184 - RejectedFreezeException (Beta) - as we understand it, this is only an incorrect log message, the group move actually worked fine. on that basis it's not serious enough to be worth a freeze exception and can be addressed with a 0-day update.
18:24:50 <bcotton> ack
18:24:53 <lruzicka> ack
18:25:16 <Eighth_Doctor> ack
18:25:19 <cmurf> +1 beta FE
18:25:21 <cmurf> ack
18:25:31 <Eighth_Doctor> it'll go in after beta freeze is lifted anyway
18:25:59 <cmurf> it does mean cgroupify does not put firefox tabs into their own cgroup
18:26:58 <cmurf> but yeah, it's not terrible that it doesn't work correctly on the media - probably a low chance of oomd triggering there anyway i guess
18:27:27 <cmurf> and the update isn't cut yet upstream anyway, and i found another bug that's still being looked into
18:27:56 <adamw> cmurf: see above. my understanding is that it doesn't stop anything happening.
18:28:08 <adamw> it just causes an error message to be logged saying it didn't work, but it actually did work.
18:28:08 <cmurf> it does though
18:28:14 <cmurf> it does not actually work
18:28:17 <adamw> that's not what the fix looks like
18:28:47 <cmurf> shrug all i know is the tabbed processes are not put in their own cgroup
18:29:06 <geraldosimiao> adamw: ack
18:29:52 <adamw> well, hmm
18:30:00 <adamw> i guess as well as logging the failure we break out of a loop
18:30:24 <adamw> so if other things were gonna happen later in that loop, they don't. so, hmm. it could have practical effects
18:30:39 <adamw> so, um, i think i'm changing my vote to "iunno"
18:30:53 <cmurf> it's suboptimal to ship it in the beta this way but not "bad"
18:30:58 <cmurf> it'll get fixed when freeze is lifted
18:31:27 <cmurf> i wouldn't worry too much about it, it was really a "nice to have" per the pre-freeze exception language
18:31:53 <adamw> well, "freeze exception" is what we changed the name to because we didn't like "nice to have". :P
18:32:04 <cmurf> i know
18:32:04 <adamw> ok, new proposal
18:32:20 <adamw> punt on it and ask ben how much he thinks it ought to be in beta
18:32:26 <cmurf> lol
18:32:31 <cmurf> i'll circle back with benzea
18:32:46 <cmurf> punt to next week is plenty soon enough
18:33:53 <adamw> proposed #agreed 2057184 - punt (delay decision) - we're not entirely sure how serious of a problem this is, and hence whether it's worth a freeze exception. We'll ask the maintainer for his opinion in the bug report and discuss this again next week or in the ticket
18:34:05 <lruzicka> ack
18:34:31 <Eighth_Doctor> ack
18:34:41 <bcotton> ack
18:35:01 <copperi[m]> ack
18:35:03 <adamw> #agreed 2057184 - punt (delay decision) - we're not entirely sure how serious of a problem this is, and hence whether it's worth a freeze exception. We'll ask the maintainer for his opinion in the bug report and discuss this again next week or in the ticket
18:35:23 <adamw> okay, let's dive into...
18:35:27 <cmurf> ok just talked to ben berg, it's not a big deal to reject this
18:35:28 <adamw> #topic Proposed Final blockers
18:35:33 <adamw> cmurf: TOO LATE
18:35:41 <adamw> i wish to get off this goddamn bug before nuclear war destroys us all
18:35:48 <Eighth_Doctor> haha
18:35:48 <adamw> #topic (2055908) bluetooth, cannot remove a bluetooth device
18:35:54 <Eighth_Doctor> yikes
18:35:55 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2055908
18:36:00 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/617
18:36:04 <adamw> #info Proposed Blocker, gnome-control-center, NEW
18:36:08 <adamw> #info Ticket vote: FinalBlocker (+4,0,-0) (+adamwill, +lruzicka, +catanzaro, +nielsenb)
18:36:21 <adamw> oh, look, i missed a ticket vote. bad me.
18:36:27 <adamw> so, we have +4 here, anyone wanna vote -1?
18:37:06 <bcotton> +1 finalbocker
18:37:30 <Eighth_Doctor> +1 FinalBlocker
18:37:59 <copperi[m]> +1 fb
18:38:32 <adamw> it'd be good to have more people test, of course, there could be some hw-specific element here
18:38:38 <adamw> my bluetooth is completely screwed with all 5.17 kernels so far
18:38:59 <adamw> oh, from the upstream report looks like it's a known issue
18:41:03 <adamw> and
18:41:15 <geraldosimiao> +1 FB
18:41:35 <adamw> looks like the 42~beta update should actually fix this
18:41:40 <adamw> anyhoo
18:42:01 <Eighth_Doctor> which already has an approved FE
18:42:04 <adamw> proposed #agreed 2055908 - AcceptedBlocker (Final) - accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"
18:42:11 <lruzicka> ack
18:42:15 <Eighth_Doctor> ack
18:42:31 <copperi[m]> ack
18:42:38 <geraldosimiao> ack
18:42:45 <adamw> cmurf: can you test if it works with the packages from the 42~beta update? specifically gnome-bluetooth-42~beta.2-1.fc36
18:43:27 <bcotton> ack
18:43:33 <cmurf> this is fixed
18:44:12 <adamw> #agreed 2055908 - AcceptedBlocker (Final) - accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"
18:44:35 <adamw> #topic (2058920) [abrt] gnome-control-center: cc_object_storage_create_dbus_proxy_finish(): gnome-control-center killed by SIGABRT
18:44:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2058920
18:44:42 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/632
18:44:46 <adamw> #info Proposed Blocker, gnome-control-center, NEW
18:47:28 <adamw> this will definitely need an upstream report i think
18:47:30 <cmurf> so yeah, i'm getting some abrt notifications of a crash in gnome-control-center bluetooth and i don't know why or how to reproduce it
18:47:47 <cmurf> ok i'll do that now and we can punt until next week
18:48:33 <adamw> i don't see this one on my system
18:48:41 <adamw> be good if anyone else can check
18:49:25 <geraldosimiao> Bluetooth seems to be recurrent source of bugs. Just a thought. 🤷‍♂️
18:50:34 <lruzicka> I might need to go, children need to go to bed.
18:50:42 <adamw> thanks lruzicka
18:50:56 <adamw> geraldosimiao: as i said i have kernel issues with bluetooth in 5.17, which may play into that, hard to say
18:51:24 <adamw> proposed #agreed 2058920 - punt (delay decision) - we don't have enough info on the causes, consequences or prevalence of this crash to make a decision yet. Chris will report it upstream and see if that gets us anywhere
18:52:19 <geraldosimiao> ack
18:53:00 <bcotton> ack
18:53:01 <Eighth_Doctor> ack
18:53:13 <cmurf> ack
18:53:20 <cmurf> upstream bug report in the rhbz now
18:53:25 <copperi[m]> ack
18:53:46 <cmurf> I'm not even sure this is bluetooth related because even though abrt claims it is, the backtrace has nothing about bluetooth in it
18:54:01 <cmurf> could just be some transient crash of g-c-c
18:55:26 <adamw> #agreed 2058920 - punt (delay decision) - we don't have enough info on the causes, consequences or prevalence of this crash to make a decision yet. Chris will report it upstream and see if that gets us anywhere
18:55:31 <adamw> #topic (2056927) Require authselect for use in scriptlets
18:55:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2056927
18:55:41 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/622
18:55:44 <adamw> #info Proposed Blocker, nss-mdns, NEW
18:55:47 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+nielsenb)
18:57:18 <bcotton> +1 finalblocker
18:57:25 * bcotton has to disappear. will return in ~30 minutes if we're still going
18:57:36 <Eighth_Doctor> +1 FinalBlocker
18:57:51 <Eighth_Doctor> there's also a related issue where authselect itself fails to install properly because of a missing secriptlet dependency
18:57:57 <Eighth_Doctor> https://src.fedoraproject.org/rpms/authselect/pull-request/17
18:59:01 <adamw> ehhh, i dunno if we really meant to cover ipp everywhere here, i think we were more about locally connected printers
18:59:14 <geraldosimiao> +1 FinalBlocker
18:59:16 <adamw> but it doesn't seem worth fighting too hard about
19:01:03 * Eighth_Doctor shrugs
19:02:31 <adamw> proposed #agreed 2056927 - AcceptedBlocker (Final) - this is accepted as a violation of "Printing must work in release-blocking desktops on at least one printer using...The generic IPP driver"
19:05:07 <adamw> echo? echo? is this thing on?
19:05:15 <coremodule> ack
19:06:05 <Eighth_Doctor> ack
19:08:06 <copperi[m]> ack
19:08:16 <adamw> #agreed 2056927 - AcceptedBlocker (Final) - this is accepted as a violation of "Printing must work in release-blocking desktops on at least one printer using...The generic IPP driver"
19:09:24 <adamw> #topic (2057563) The About button sends Discover into loop and the application stops responding.
19:09:30 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2057563
19:09:33 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/627
19:09:38 <adamw> #info Proposed Blocker, plasma-discover, NEW
19:09:41 <adamw> #info Ticket vote: FinalBlocker (+2,0,-0) (+lruzicka, +nielsenb)
19:09:49 <adamw> well, this is clearly silly, but...would it pass the last blocker test?
19:10:11 <adamw> be honest, who really clicks on About buttons? :D
19:10:12 <Eighth_Doctor> apparently someone did :o
19:10:28 <geraldosimiao> 😆
19:10:58 <adamw> well yeah, but it was lruzicka
19:11:03 <adamw> what normal person clicks on an About button
19:11:26 <copperi[m]> I don't know if I am normal, but occasionally yes
19:11:38 <geraldosimiao> +1 FinalBlocker
19:13:16 <Southern_Gentlem> adamw to me that the same as all desktop apps should work
19:13:29 <adamw> well, the criterion is "Basic functionality"
19:13:36 <adamw> is an about button basic functionality? that's the vote, i guess.
19:13:45 <Southern_Gentlem> yep
19:14:01 <Eighth_Doctor> I would think so
19:14:03 <Eighth_Doctor> +1 FinalBlocker
19:14:17 <Southern_Gentlem> +1 FB
19:14:41 <copperi[m]> +1 fb
19:16:00 <adamw> alrighty
19:17:16 <adamw> proposed #agreed 2057563 - AcceptedBlocker (Final) - this is accepted as a violation of the default application functionality criterion, which requires that the KDE package manager (that's Discover) "must start successfully and withstand a basic functionality test"
19:18:35 <Eighth_Doctor> ack
19:18:42 <copperi[m]> ack
19:19:10 <Southern_Gentlem> ack
19:19:51 <geraldosimiao> ack
19:19:53 <Southern_Gentlem> so this review has been going on for 2+ hours
19:20:32 <adamw> #agreed 2057563 - AcceptedBlocker (Final) - this is accepted as a violation of the default application functionality criterion, which requires that the KDE package manager (that's Discover) "must start successfully and withstand a basic functionality test"
19:20:41 <adamw> yeah, if more people had done ticket votes it'd be faster
19:20:43 <adamw> but also there were just a lot of proposals
19:20:48 <adamw> the cap is 3 hours, but we should be done by then
19:20:57 <adamw> three more to go
19:21:02 <adamw> #topic (2053790) Fedora look and feel is not fully applied on new installs
19:21:05 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2053790
19:21:09 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/606
19:21:14 <adamw> #info Proposed Blocker, plasma-workspace, MODIFIED
19:21:17 <adamw> #info Ticket vote: FinalBlocker (+0,0,-1) (-nielsenb)
19:21:22 <Eighth_Doctor> I finally fixed this on Sunday
19:21:42 <adamw> so as this stands i'm kinda -1 on it, the justification was that things could actually be so badly themed as to be hard to see, but i don't see any screenshots supporting that
19:21:56 <adamw> just screenshots of things not being as expected, but they were perfectly 'okay' for usage purposes
19:22:20 <Southern_Gentlem> -1 for now
19:22:22 <Eighth_Doctor> well, there's other bugs around appearance stuff, which I need to deal with upstream
19:22:35 <Eighth_Doctor> like the fact that none of the theme setting buttons work at all
19:23:06 <Eighth_Doctor> but it's important to me and the KDE SIG that our default look and feel is used consistently, esp. with OpenQA testing and other things
19:23:15 <Southern_Gentlem> well the +FB from above should take care of this as well
19:23:49 <Eighth_Doctor> In retrospect, I should have filed a BetaFE too
19:24:00 <Eighth_Doctor> but I didn't because I didn't know what the problem was yet
19:24:10 <adamw> oh, yeah, i'm +1 Beta FE on this if it isn't already
19:24:12 <Eighth_Doctor> but... I fixed it and I'd like to have this in for Beta
19:24:24 <Southern_Gentlem> +1 BFE
19:24:40 <Eighth_Doctor> +1 BetaFE (though not sure I can do that...)
19:25:14 <adamw> at this point you can have your dog vote if it'll get the meeting done faster
19:25:32 <adamw> of course the one time i could do with my cat jumping on the keyboard, he isn't here
19:25:44 <coremodule> +1 Beta FE
19:25:54 <copperi[m]> +1 bfe
19:26:19 <coremodule> -1 final blocker
19:26:38 <adamw> proposed #agreed 2053790 - RejectedBlocker (Final) AcceptedFreezeException (Beta) - this doesn't really seem to violate any criteria as it stands (the elements are perfectly usable, they just don't look as intended), but we do grant it a Beta freeze exception as obviously we want things to look as intended for Beta if possible
19:26:52 <coremodule> ack
19:26:58 <Southern_Gentlem> ack
19:27:01 <Eighth_Doctor> ack
19:27:08 <copperi[m]> ack
19:27:12 <adamw> #agreed 2053790 - RejectedBlocker (Final) AcceptedFreezeException (Beta) - this doesn't really seem to violate any criteria as it stands (the elements are perfectly usable, they just don't look as intended), but we do grant it a Beta freeze exception as obviously we want things to look as intended for Beta if possible
19:27:23 <adamw> #topic (2010595) Cannot install firmware if secureboot is enabled
19:27:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2010595
19:27:32 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/635
19:27:36 <adamw> #info Proposed Blocker, shim, NEW
19:27:41 <Eighth_Doctor> that's a bit of a yikes
19:28:05 <Southern_Gentlem> again
19:28:34 <Eighth_Doctor> ugh
19:28:36 <Eighth_Doctor> +1 Beta FE, +1 FinalBlocker
19:30:04 <Southern_Gentlem> +1 BFE +1 FB
19:30:06 <adamw> ehhh. i'm having trouble seeing this as a blocker, honestly
19:30:15 <adamw> or an FE. it doesn't need to be on media.
19:30:23 <adamw> it's an important bug, but that's not the same thing as a release blocker or FE.
19:30:27 <Eighth_Doctor> not being able to update firmware in the default setup is pretty bad
19:30:50 <adamw> i mean, kinda? but otoh, you can't update system firmware from the OS at all on a lot of other systems, and we still let you install fedora on those, so?
19:31:00 <Eighth_Doctor> there's also the marketing/political angle here, where Ubuntu is able to do it and we can't
19:31:05 <Southern_Gentlem> and it been going on for a couple of releases
19:31:06 <adamw> again, not a release blocker.
19:31:15 <Eighth_Doctor> which is, frankly, pretty maddening
19:31:17 * bcotton returns
19:31:25 <adamw> which means we shipped two releases with it and the world didn't end, so, another argument that it isn't release blocking :D
19:31:28 <Eighth_Doctor> perhaps we should make firmware management part of the release criteria then
19:31:41 <Eighth_Doctor> because it's a pretty critical aspect of Fedora's security story
19:31:48 <adamw> it's an option, sure
19:32:04 <Eighth_Doctor> the problematic part is testing that, since people don't always have updates pending
19:32:12 <Eighth_Doctor> and dummy firmware updates aren't really a thing :/
19:32:41 <adamw> i mean, it sounds like the problem is known and fixed upstream already
19:32:52 <adamw> and the issue here is just "someone needs to corner pjones and make him send out an update"
19:33:15 <adamw> or javier, i guess.
19:33:42 <geraldosimiao> +1 Beta FE
19:33:42 <geraldosimiao> +1 FinalBlocker
19:33:58 <bcotton> so i don't love this, but I think I'm in the -1 camp
19:34:32 <adamw> i'm gonna ask someone who's +1 to come up with a justification for that based on the criteria
19:34:41 <adamw> because we can't really accept things without one
19:35:13 <geraldosimiao> <Southern_Gentlem> "so this review has been going on..." <- 🥲
19:35:27 <adamw> this is the second-to-last bug on the list
19:35:50 <Eighth_Doctor> IMO, it inhibits the updating software criterion: https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Installing.2C_removing_and_updating_software
19:36:00 <Eighth_Doctor> since GNOME Software and Plasma Discover fall under that
19:36:08 <Eighth_Doctor> and their ability to apply updates is inhibited by this
19:36:26 <cmurf> all updates are inhibited or just firmware updates?
19:36:28 <adamw> that very clearly specifies "software", though. not "firmware"
19:36:39 <adamw> if this bug prevents a software update working if a firmware update is available, that might be an argument
19:36:42 <adamw> but otherwise, i don't see it
19:36:47 <Eighth_Doctor> well, Software stops you from doing both
19:37:00 <Eighth_Doctor> if you try to trigger an update, it'll do it, fail, and loop back
19:37:19 <adamw> are you sure about that? i don't see it stated in the bug report.
19:37:36 <adamw> the firmware update process and software update process are separate. i would expect the software update portion would go ahead even if the firmware update fails.
19:37:47 <Eighth_Doctor> that's not how GNOME Software works
19:37:50 <adamw> (i'm pretty sure i've actually seen that happen on my system before)
19:37:58 <Eighth_Doctor> it picks one, does it, and then will let you do the other
19:38:02 <cmurf> if they are so compartmentalized, that would be the blocking bug, not the inability to update the firmware
19:38:08 <Eighth_Doctor> unless you manually pick an update process
19:38:13 <adamw> Conan Kudo: no, it really is. for a firmware update it sets a flag to tell the firmware to handle an update. gnome software per se does not do it.
19:38:23 <cmurf> ^not so compartmentalized
19:38:48 <adamw> if the firmware doesn't manage to update itself, i don't think that would prevent fedora itself booting into the special upgrade mode and running the software update.
19:39:11 <cmurf> but if so, that's the bug we could block on
19:39:28 <adamw> if so, yes. but i'd rather see that confirmed
19:39:36 <adamw> afaik nobody has claimed it's the case in the bug
19:39:41 <cmurf> agreed
19:39:46 <cmurf> right so needinfo and punt
19:39:58 <adamw> i love ignoring things!
19:40:04 <cmurf> or -1 final blocker
19:40:11 <adamw> maybe by next week we'll all just be traces of radiation and this will seem less important
19:40:12 <Eighth_Doctor> this whole thing is kind of bullshit... having packages that only one person can update is garbage
19:40:17 <geraldosimiao> if that's that controversial: +1 punt
19:40:24 <adamw> Conan Kudo: well, javier did the last couple of updates
19:40:35 <Eighth_Doctor> because Peter is basically never around
19:40:38 <adamw> he wasn't CCed on the bug, though. I CCed him now, which might help.
19:40:44 <Eighth_Doctor> so I reiterate: having only one person is bad
19:40:49 <Eighth_Doctor> we have that for both kernels and bootloaders
19:40:58 <geraldosimiao> adamw: 🤯
19:40:59 <Eighth_Doctor> and nobody else can do anything about it
19:41:08 <cmurf> could also cc rharwood
19:41:19 <adamw> there are meant to be two kernel maintainers, but they keep leaving :P
19:41:27 <adamw> for boot chain, we do have javier now.
19:41:47 <Eighth_Doctor> he's supposed to be moving off the boot stuff :(
19:41:56 <adamw> and other people do have the privileges, they're just reluctant to touch the packages unless it's absolutely necessary as they're not experts and it's complicated.
19:42:01 <adamw> whee
19:42:30 <adamw> okay, anyway, so, we punting?
19:43:06 <Eighth_Doctor> fine
19:43:07 <Eighth_Doctor> let's punt
19:43:10 * Eighth_Doctor grumbles
19:43:23 <copperi[m]> +1 punt
19:43:50 <adamw> proposed #agreed 2010595 - punt (delay decision) - there was some support in principle for this being a blocker, but also some opposition, and it doesn't obviously violate the existing criteria. we will ask how software updates are affected if a firmware update is queued but fails (if the software update also does not happen in this case, that could be a blocker issue). someone may also choose to propose specific criteria for firmware
19:43:50 <adamw> updates.
19:44:20 <coremodule> adamw, can you shorten it by 8 characters for IRC?
19:44:20 <Eighth_Doctor> ack
19:44:23 <cmurf> ack
19:44:25 <geraldosimiao> ack
19:44:26 <copperi[m]> ack
19:44:30 <adamw> if it's 8 characters it's fine
19:44:34 <adamw> "proposed " is 9 :P
19:44:44 <coremodule> wonderful!
19:44:45 <coremodule> ack
19:44:57 <bcotton> acl
19:45:01 <bcotton> ack, too
19:45:08 <adamw> #agreed 2010595 - punt (delay decision) - there was some support in principle for this being a blocker, but also some opposition, and it doesn't obviously violate the existing criteria. we will ask how software updates are affected if a firmware update is queued but fails (if the software update also does not happen in this case, that could be a blocker issue). someone may also choose to propose specific criteria for firmware updates
19:45:15 <adamw> #topic (2054594) crash happens when try to set up a google or microsoft online account
19:45:18 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2054594
19:45:24 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/609
19:45:26 <adamw> #info Proposed Blocker, xdg-desktop-portal, NEW
19:45:30 <adamw> #info Ticket vote: FinalBlocker (+0,0,-2) (-nielsenb, -catanzaro)
19:45:34 <adamw> okay, last bug, folks
19:46:36 <adamw> yeah, i think i'm -1 on this for now unless we pin it down to something more concrete that will be commonly encountered
19:47:06 <bcotton> -1 ditto
19:47:27 <coremodule> agreed, -1 Final Blocker
19:47:32 <cmurf> i haven't experienced this
19:47:52 <cmurf> if it were reproducible i'd be +1 final blocker, either fix it or remove the option
19:48:03 <cmurf> and i recently had to use it for some other bug
19:48:50 <adamw> proposed #agreed 2054594 - RejectedBlocker (Final) - we agreed this would be a blocker issue if it were clearly reproducible, but so far other testers have not been able to reproduce it. We can reconsider this decision if we are able to pin the issue down more precisely and it still seems concerning
19:48:56 <bcotton> ack
19:49:05 <geraldosimiao> ack
19:49:05 <cmurf> ack
19:49:17 <copperi[m]> ack
19:49:41 <coremodule> ack
19:50:00 <adamw> #agreed 2054594 - RejectedBlocker (Final) - we agreed this would be a blocker issue if it were clearly reproducible, but so far other testers have not been able to reproduce it. We can reconsider this decision if we are able to pin the issue down more precisely and it still seems concerning
19:50:02 <adamw> okey dokey
19:50:15 <adamw> uhhhh, i said earlier i was gonna add something to the agenda later didn't i
19:50:20 <adamw> and now i've forgotten what that was
19:50:43 <adamw> also, does anyone know why I came in here and where I left my teeth?
19:51:09 <adamw> oh yes I remember
19:51:28 <copperi[m]> Dog ate them ?
19:51:38 <geraldosimiao> lol
19:51:59 <adamw> proposal: retitle the accepted FE https://bugzilla.redhat.com/show_bug.cgi?id=2049147  from "ship GNOME 42.rc in Fedora 36 beta" to "ship GNOME 42.beta or 42.rc in Fedora 36 beta"
19:52:18 <adamw> i figured it'd be correct to have a vote on this somewhere instead of just ninja'ing it
19:52:47 <adamw> i am +1 to the proposal, we should include the latest gnome bits we safely can, even if that's beta not rc.
19:52:58 <adamw> otherwise we're stuck with alpha, which nobody wants.
19:52:59 <bcotton> +1
19:53:03 <copperi[m]> +1
19:53:27 <cmurf> ok insofar as it gets beta into stable asap +1
19:53:29 <Eighth_Doctor> +1
19:53:42 <adamw> #agreed we will retitle the accepted FE https://bugzilla.redhat.com/show_bug.cgi?id=2049147  from "ship GNOME 42.rc in Fedora 36 beta" to "ship GNOME 42.beta or 42.rc in Fedora 36 beta" to make it clearer that we want to include 42.beta in F36 Beta if rc is not ready in time, beta still better than alpha
19:53:48 <cmurf> ack
19:53:53 <Eighth_Doctor> ack
19:53:59 <copperi[m]> ack
19:53:59 <geraldosimiao> ack
19:54:02 <adamw> #topic Open floor
19:54:13 <adamw> ok, sorry for the long meeting and thanks for sticking it out, folks
19:54:13 <cmurf> and now back to the continuing coverage of the end of the world as we know it...
19:54:22 <adamw> please do vote in the tickets in future, it makes these meetings shorter!
19:54:23 * Eighth_Doctor sighs
19:54:36 <adamw> cmurf: on the plus side, great excuse to bust out some classic 80s REM
19:54:44 <cmurf> haha
19:54:48 <cmurf> that is so corny
19:55:12 <cmurf> i feel fine?
19:55:23 <cmurf> now you can add the i feel fine dog meme to the mix
19:55:29 <Eighth_Doctor> haha
19:55:51 <geraldosimiao> goodbye people, see you all next time 👋
19:55:56 <adamw> any other business before i go finally get a shower?
19:56:02 <adamw> geraldosimiao: fingers crossed!
19:56:29 <geraldosimiao> 😉
19:56:35 * bcotton hands adamw a bar of soap
19:57:03 <adamw> pffft, i use only the finest body shop body wash i'll have you know
19:57:10 <cmurf> oh just got rub yourself with some sand and swim in the ocean
19:57:15 <adamw> (because bar soap tends to clog up our drains)
19:57:39 <cmurf> body shop soap hahaha, extra pumice
19:57:48 <adamw> cmurf: it's 7 degrees celsius right now. plan rejected
19:58:09 <copperi[m]> so warm ...
19:58:20 <adamw> still not great for ocean swimming
19:58:37 <cmurf> so it'd be brief...
19:59:43 <Eighth_Doctor> there's still ice on my sidewalks
20:00:20 <Eighth_Doctor> (2 degrees centigrade)
20:01:20 <adamw> alrighty, thanks again folks
20:01:29 <adamw> #endmeeting