16:02:08 <adamw> #startmeeting F35-blocker-review
16:02:08 <zodbot> Meeting started Mon Oct  4 16:02:08 2021 UTC.
16:02:08 <zodbot> This meeting is logged and archived in a public location.
16:02:08 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:02:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:08 <zodbot> The meeting name has been set to 'f35-blocker-review'
16:02:09 <adamw> #meetingname F35-blocker-review
16:02:09 <zodbot> The meeting name has been set to 'f35-blocker-review'
16:02:09 <adamw> #topic Roll Call
16:02:22 <adamw> ahoyhoy folks, who's around for meeting fun?
16:03:04 <geraldosimiao> .hello geraldosimiao
16:03:05 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:03:41 * coremodule is here, willing to act as secretary, but I have a doctor's appointment in an hour, so I'll have to leave early and return to the secretarialization afterward.
16:03:48 <adamw> that's fine
16:04:05 <adamw> hope everything is ok
16:04:52 <coremodule> thanks. yeah, just an eye appointment, nothing fancy.
16:04:58 <coremodule> thankfully
16:06:28 <adamw> welp, just me and the guy who's leaving in an hour, apparently
16:06:35 <adamw> oh, and geraldo :D
16:06:48 <coremodule> lol
16:07:28 <geraldosimiao> yeah, don't forget me lol
16:07:42 <adamw> Ben Cotton (he/him/his): mclasen Southern_Gentlem ping
16:07:48 <adamw> pwhalen is not officially here yet :D
16:08:09 * mclasen lurks
16:08:15 <pwhalen> .hello2
16:08:16 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
16:10:04 <adamw> alrighty, well, that's a few to be going on with
16:10:05 <adamw> #chair pwhalen geraldosimiao
16:10:05 <zodbot> Current chairs: adamw geraldosimiao pwhalen
16:10:05 <adamw> boilerplate alert
16:10:05 <adamw> #topic Introduction
16:10:05 <adamw> Why are we here?
16:10:05 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:10:06 <adamw> #info We'll be following the process outlined at:
16:10:06 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:10:07 <adamw> #info The bugs up for review today are available at:
16:10:07 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:10:11 <adamw> #info The criteria for release blocking bugs can be found at:
16:10:31 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:10:32 <adamw> #link https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria
16:10:32 <adamw> #link https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria
16:10:37 <adamw> #info for Final, we have:
16:10:43 <adamw> #info 7 Proposed Blockers
16:10:50 <adamw> #info 5 Accepted Blockers
16:10:51 <adamw> #info 4 Proposed Freeze Exceptions
16:10:54 <adamw> #info 2 Accepted Freeze Exceptions
16:10:59 <adamw> #info coremodule will secretarialize
16:11:07 <adamw> let's get started with:
16:11:11 <adamw> #topic Proposed Final blockers
16:11:16 <adamw> #topic (2010259) [abrt] dnf: _revert_transaction(): history.py:233:_revert_transaction:KeyError: 'Reason Change'
16:11:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2010259
16:11:27 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/493
16:11:27 <adamw> #info Proposed Blocker, dnf, NEW
16:11:31 <adamw> #info Ticket vote: FinalBlocker (+0,0,-1) (-bcotton)
16:11:36 <adamw> #info Ticket vote: FinalFreezeException (+1,0,-0) (+bcotton)
16:12:18 <geraldosimiao> I'll go with Ben on that FinalBlocker -1
16:12:18 <geraldosimiao> FinalFE +1
16:13:20 <coremodule> I guess we should "discuss whether it's OK to have history operations broken in certain cases, and whether we're sure this won't affect install/update/remove operations as well"
16:13:51 <adamw> so, on a quick look at the code, we crash here before we actually do anything to the filesystem/db
16:14:10 <adamw> and the code seems fairly specialized to rollback/revert operations
16:14:25 <adamw> we're basically in this block:
16:14:26 <adamw> https://github.com/rpm-software-management/dnf/blob/master/dnf/cli/commands/history.py#L192-L249
16:14:47 <adamw> i think the point at which it'd actually start Doin' Stuff is line 249, and we don't get there
16:15:59 <adamw> so on that basis i'm probably -1. i'm also actually -1 FE because i don't think we should be rushing in changes like this during freeze, it seems safer giving it longer to mature
16:16:20 <adamw> and there's no huge benefit to having the fix in the frozen repos/install media vs. having it in 0-day updates
16:16:45 <geraldosimiao> adamw: thats a good point indeed
16:17:10 <pwhalen> -1/-1, agree with adamw
16:18:21 <coremodule> -1 blocker, -1 fe
16:19:21 <geraldosimiao> FinalBlocker -1
16:19:21 <geraldosimiao> FinalFE -1
16:21:30 <adamw> ok
16:23:36 <adamw> proposed #agreed 2010259 - RejectedBlocker (Final), RejectedFreezeException (Final) - the crash here appears to be non-destructive (it happens before we touch the filesystem or the RPM database, or change the dnf database) and limited to revert/rollback transactions. So we don't think it violates the release criteria or otherwise qualifies as a blocker. We also think it does not need a freeze exception, as there is no great benefit to
16:23:36 <adamw> getting it in the release media, and any change would benefit from the extra time in testing to ensure safety.
16:25:14 <geraldosimiao> ack
16:25:21 <frantisekz> .hello2
16:25:22 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:25:24 <coremodule> adamw, I don't know if you're on matrix or irc, but it overran on irc
16:25:51 <adamw> darn
16:25:51 <adamw> let me subedit myself
16:25:51 * adamw gets out the red pencil
16:26:46 <adamw> proposed #agreed 2010259 - RejectedBlocker (Final), RejectedFreezeException (Final) - the crash here appears to be non-destructive and limited to revert/rollback transactions. So we don't think it violates the release criteria or otherwise qualifies as a blocker. We also think it does not need a freeze exception - there is no great benefit to getting it in the release media, and any change would benefit from the extra time in testing
16:26:46 <adamw> to ensure safety.
16:26:51 <adamw> how's that
16:26:59 <coremodule> "to ensure safety" overran
16:27:06 <geraldosimiao> ack
16:27:31 <frantisekz> ack
16:27:33 <adamw> okay, strike "to ensure safety" :D
16:27:40 <coremodule> wfm ack
16:28:05 <geraldosimiao> I'm on matrix side, no errors here
16:29:23 <adamw> #agreed 2010259 - RejectedBlocker (Final), RejectedFreezeException (Final) - the crash here appears to be non-destructive and limited to revert/rollback transactions. So we don't think it violates the release criteria or otherwise qualifies as a blocker. We also think it does not need a freeze exception - there is no great benefit to getting it in the release media, and any change would benefit from the extra time in testing.
16:29:49 <adamw> geraldosimiao: yeah, matrix can cope with a lot more than irc can :) but the bot runs on irc, so if a meeting control message overflows on irc, meetbot will 'lose' the part that overflowed
16:30:11 <geraldosimiao> ok, understood :)
16:30:15 <adamw> #topic (2009451) Meeting link imported are truncated; results in invalid link
16:30:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2009451
16:30:23 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/487
16:30:27 <adamw> #info Proposed Blocker, gnome-calendar, NEW
16:30:34 <adamw> #info Ticket vote: FinalBlocker (+0,1,-3) (bcotton, -catanzaro, -imsedgar, -frantisekz)
16:30:41 <adamw> #info Ticket vote: FinalFreezeException (+4,0,-0) (+catanzaro, +imsedgar, +frantisekz, +bcotton)
16:31:13 <adamw> so i took an executive decision to include a few bugs that have the bare minimum for a decision in the tracker, but seem kinda arguable, to see if there are any differing opinions
16:31:28 <adamw> i honestly think sumantro made a reasonable case for this on the merits, but catanzaro being -1 is obviously a big consideration
16:32:47 <frantisekz> imo, apart from not being a huge problem in my eyes, this is something that could be easily fixed in updates, nobody is going to be joining to the meetings from live media
16:33:29 <adamw> that is a fair point, though it's actually considered more for FEs than blockers, officially
16:33:43 <adamw> blockers are blockers even if they can be fixed in updates, technically. though we bend the point occasionally. :D
16:34:23 <frantisekz> yeah, fair point :D
16:36:27 <geraldosimiao> well, if we assume that calendar is a primary aplication and assume one of the basic functionality of gnome calender is to resolve meeting links...
16:36:57 <geraldosimiao> isn't that a blocker?
16:37:13 <adamw> geraldosimiao: yeah, that's the argument sumantro made. mcatanzaro basically pointed out that there's an even *worse* bug we haven't blocked on for the last two years, which is kind of a fair point as well, i guess.
16:37:24 <adamw> let me see exactly what the criterion says again
16:38:44 <geraldosimiao> adamw: right, I see.
16:38:51 <adamw> hmm, we're just under the old "All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test" here, I think
16:39:05 <adamw> the whole thing about 'primary applications' doesn't apply since this is Workstation, that stuff is for non-Workstation
16:39:44 <geraldosimiao> adamw: so, for me, basic func of calendar is to show the days and appointments correctly as I have saved.
16:40:19 <geraldosimiao> an no resolving meeting links
16:41:19 <coremodule> I've gotta go, I've voted already in several of the blockers coming up. +
16:41:43 <geraldosimiao> yeah, this here is way more basic than broken links: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/444
16:41:54 <Eighth_Doctor> .hello ngompa
16:41:55 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:42:02 <geraldosimiao> I'm with catanzaro
16:42:17 <adamw> coremodule: thanks
16:42:24 <geraldosimiao> FinalBlocker -1
16:42:24 <geraldosimiao> FinalFE +1
16:42:40 <geraldosimiao> Hi Neal :)
16:42:57 <geraldosimiao> Thanks, and bye coremodule
16:43:28 <Southern_Gentlem> -1FB,+1FE
16:44:19 <adamw> ok
16:44:23 <adamw> so we seem to have a solid consensus there
16:44:24 <pwhalen> -1FB,+1FE
16:44:37 <adamw> an even more solid consensus!
16:44:50 <pwhalen> heh
16:46:42 <adamw> proposed #agreed 2009451 - RejectedBlocker (Final) AcceptedFreezeException (Final) - on balance, there's a consensus that this isn't quite serious enough to constitute "core functionality" for GNOME Calendar. however, it is definitely an annoying problem and would be good to have fixed for fresh installs, so it is accepted as a freeze exception issue
16:46:55 <geraldosimiao> ack
16:47:14 <frantisekz> ack
16:47:31 <pwhalen> ack
16:47:53 <Southern_Gentlem> ack
16:48:52 <adamw> #agreed 2009451 - RejectedBlocker (Final) AcceptedFreezeException (Final) - on balance, there's a consensus that this isn't quite serious enough to constitute "core functionality" for GNOME Calendar. however, it is definitely an annoying problem and would be good to have fixed for fresh installs, so it is accepted as a freeze exception issue
16:48:58 <adamw> #topic (2010353) updates-testing repo can't be disabled
16:49:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2010353
16:49:05 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/494
16:49:15 <adamw> #info Proposed Blocker, gnome-software, NEW
16:49:15 <adamw> #info Ticket vote: FinalBlocker (+2,0,-0) (+kparal, +sumantrom)
16:50:01 <adamw> this sounds kinda minor from the description but is actually quite bad in practice
16:50:03 <adamw> if you turn updates-testing on from Software, you can't turn it back off
16:50:03 <frantisekz> we need more testers using u-t, let's move on...
16:50:06 <frantisekz> :D :P
16:50:08 <adamw> (i think this was introduced by the 'fix' for the 'distro packages shown as untrusted' bug from beta, btw)
16:50:13 <adamw> frantisekz: heheh
16:50:14 <pwhalen> FinalBlocker +1
16:51:24 <adamw> yeah, i think on the whole i'm finalblocker +1...this is pretty awkward
16:51:37 <frantisekz> on one hand, this is ugly, on the other hand, user fiddling with something that has "testing" in it should know how to deal with disabling it manually, there are worse things going on sometimes in u-t land
16:52:06 <bcotton> FinalBlocker +1
16:52:10 <bcotton> (oh hi, i'm here now)
16:52:14 <frantisekz> \o
16:52:54 <adamw> hi ben
16:52:54 <adamw> votes from latecomers will be refused and mocked
16:53:05 <StephenGallagher> FinalBlocker +1
16:53:07 <StephenGallagher> (Commence mocking)
16:53:10 <frantisekz> hmm, FinalBlocker +1
16:53:22 <bcotton> well you mock my votes even when i'm on time, so i'm okay with this :p
16:53:26 <adamw> Stephen Gallagher: heya, your wisdom on what repos should be 'official' and 'required' would probably be helpful here too :D
16:54:36 <geraldosimiao> oh, sorry, I was reading the discussion on the ticket and I'm a little confused now... lol
16:54:38 <StephenGallagher> Catch me up? I just got here.
16:55:08 <geraldosimiao> does the dnf comands work fine?
16:55:23 <Eighth_Doctor> yes
16:55:24 <adamw> proposed #agreed 2010353 - AcceptedBlocker (Final) - while it sounds a bit trivial, being able to enable updates-testing but not disable it again both looks bad and can potentially cause problems, so we agree that this is a significant violation of "All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and
16:55:25 <adamw> withstand a basic functionality test."
16:55:37 <adamw> Stephen Gallagher: check the bug report, most recent comments from me and milan
16:55:38 <StephenGallagher> ack
16:55:57 <frantisekz> adamw, can we have one-liner :) ? or we don't need that anymore?
16:56:00 <bcotton> wordy, but ack
16:56:12 <frantisekz> (ack otherwise)
16:56:14 <StephenGallagher> I'm inclined to say that enable/disable is DEFINITELY core functionality.
16:56:18 <adamw> geraldosimiao: yes, but we have a pretty clear expectation that all of this stuff should be doable via the default GUI and users should not be expected to have to use console if they don't want to
16:56:25 <pwhalen> ack
16:56:28 <adamw> frantisekz: it overflowed? grr
16:56:31 <geraldosimiao> ok ACK, graphical must work fine too.
16:56:34 <StephenGallagher> But that we should only hold the "enabled-by-default" (and possibly the special repos like H264) to our standards.
16:56:42 <frantisekz> yep, "withstand a basic functionality test" is on another line
16:57:37 <bcotton> ack
16:57:43 <geraldosimiao> ack
16:57:43 <StephenGallagher> Hmm, that would need different phrasing, since u-t is enabled by default in Beta
16:57:45 <StephenGallagher> But you get the idea.
16:57:50 <StephenGallagher> ack
16:57:58 <adamw> proposed #agreed 2010353 - AcceptedBlocker (Final) - being able to enable updates-testing but not disable it again both looks bad and can potentially cause problems, so we agree that this violates "All applications that can be launched...after a default installation of Fedora Workstation on the x86_64 architecture must...withstand a basic functionality test."
16:58:05 <frantisekz> perfect, ack
16:58:17 <Southern_Gentlem> ack
16:59:05 <StephenGallagher> That... is an interesting question.
16:59:06 <adamw> Stephen Gallagher: the fix here is gonna be a distinction between "repos that are official for the purposes of trusting installed packages" and "repos that you shouldn't be allowed to disable", that's the categorization you might be able to help with :)
16:59:06 <adamw> #agreed 2010353 - AcceptedBlocker (Final) - being able to enable updates-testing but not disable it again both looks bad and can potentially cause problems, so we agree that this violates "All applications that can be launched...after a default installation of Fedora Workstation on the x86_64 architecture must...withstand a basic functionality test."
16:59:06 <adamw> #topic (2008537) 5.14.x defaults to acpi on aarch64
16:59:09 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2008537
16:59:14 <adamw> Stephen Gallagher: isn't it just
16:59:17 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/492
16:59:23 <adamw> #info Proposed Blocker, kernel, NEW
16:59:28 <adamw> #info Ticket vote: FinalBlocker (+0,0,-2) (-bcotton, -coremodule)
16:59:31 <adamw> #info Ticket vote: FinalFreezeException (+2,0,-0) (+bcotton, +coremodule)
17:00:12 <Eighth_Doctor> +1 FinalBlocker
17:00:22 <Eighth_Doctor> +1 FinalFreezeException
17:00:27 <frantisekz> hmm, do our criteria cover this? is some supported board broken? I mean, I am not against it being a blocker
17:00:38 <Southern_Gentlem> aarch64 a blocking  arch?
17:00:45 <frantisekz> but it does work
17:00:46 <pwhalen> +1 blocker. We really need to pull in the fix, users will default to acpi on install then change to device-tree on update
17:00:55 <adamw> seems a bit academic if jforbes reverted it already, but yeah, it'd be good to have a specific "supported board X is broken this way" to justify blocker status
17:00:56 <pwhalen> +1 FE
17:01:15 <Eighth_Doctor> most of our boards would be busted
17:01:21 <Southern_Gentlem> -1fb, +1fe
17:01:25 <frantisekz> we can say +1FE and have it pulled anyway as it's fixed as per jforbes
17:01:28 <Eighth_Doctor> ACPI is a horrid default for AArch64 because it's just not a thing ARM devices do naturally
17:02:10 <adamw> if pwhalen says "it breaks board X" i'm gonna vote +1 :D
17:02:11 <pwhalen> it does fallback to device-tree but systems that use both will change defaults when updated.
17:02:12 <bcotton> define "busted". i'm not opposed, but the bz did not make that clear at all
17:02:39 <adamw> pwhalen: what's the practical consequence of changing defaults?
17:03:22 <pwhalen> It doesnt really break anything, but causes issues for users. We had this happen before
17:04:19 <Southern_Gentlem> the fix is in the works so why block this
17:04:23 <pwhalen> or, I am not aware of it breaking anything
17:05:44 <Southern_Gentlem> so is this the hill, worth blocking the release for no, not in my opinion
17:05:48 <pwhalen> This would be changing our defaults on installation, then changing it back on update
17:06:03 <adamw> Southern_Gentlem: if it's on the blocker list we are definitely not releasing till we pull in an updated kernel. if it's only on the FE list, theoretically, if the kernel update isn't submitted or karma'ed in time we could release without it.
17:06:53 <adamw> i think i've gotta vote 0 FinalBlocker, +1 FinalFreezeException as it stands, but definitely gonna make sure we get the fix in :P
17:06:53 <Southern_Gentlem> like their will not be 5-10 new kernels before release
17:07:20 <adamw> Southern_Gentlem: final freeze is tomorrow, so possibly not.
17:07:36 <frantisekz> +1 FE, +/-0 FinalBlocker
17:08:00 <Southern_Gentlem> and the FE will allow it correct
17:09:05 <adamw> sure, but just noting we're getting to the crunch end of the schedule, it's not safe to assume there's tons of time for non-blocker fixes to land :)
17:10:13 <geraldosimiao> as said by Justin: 5.14.10 will release on Oct 6th, and should be pushed to updates-testing by the 7th, though that is after freeze.
17:10:16 <adamw> proposed #agreed 2008537 - punt (delay decision) on FinalBlocker, AcceptedFinalFreezeException - we don't have a clear vote on whether this is serious enough to constitute a release blocker bug, but we definitely agree it's at least bad enough to grant a freeze exception, and expect the fix will land soon enough as to render the blocker question academic
17:10:28 <bcotton> ack
17:10:32 <frantisekz> ack
17:10:32 <Southern_Gentlem> ack
17:10:33 <geraldosimiao> ack
17:11:06 <pwhalen> ack
17:11:21 <adamw> #agreed 2008537 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - we don't have a clear vote on whether this is serious enough to constitute a release blocker bug, but we definitely agree it's at least bad enough to grant a freeze exception, and expect the fix will land soon enough as to render the blocker question academic
17:11:23 <pwhalen> We really need to fix this before final is released.
17:11:29 <adamw> stealth patch to my more usual format :D
17:11:49 <adamw> pwhalen: yeah, i'll make sure it gets in. if the update goes to testing on the 7th it'll be no problem.
17:12:03 <pwhalen> Ok.
17:15:48 <geraldosimiao> Its too specific and not common use of a VM (IMHO), so I vote -1 FB on that
17:16:17 <bcotton> i don't recall that i've ever done it (except via dynamic resizing, and even then rarely)
17:16:53 <geraldosimiao> adamw: but in that case the bug doesnt happens
17:17:23 <pwhalen> IRC seems to be left behind on this discussion
17:17:31 <geraldosimiao> Only manual resolution changes trigger it.
17:18:09 <geraldosimiao> as pointed by Kammil
17:18:51 <pwhalen> IRC topic didnt change to this bug, assuming its the spice-vdagent being discussed
17:19:45 <adamw> darn bot...yes
17:20:19 <adamw> let me try it again...
17:20:20 <adamw> #topic (2006746) Mouse cursor position offset changes randomly after changing resolution in a VM
17:21:19 <nirik> try now
17:21:30 <nirik> oh, you are changing it, not zodbot.
17:21:52 <adamw_> ahoy from irc-land
17:22:16 <nirik> #topic (2006746) Mouse cursor position offset changes randomly after changing resolution in a VM
17:22:48 <adamw> hmm, so i don't have powers?
17:22:56 <nirik> I can give you them
17:23:11 <adamw> i guess none of the topic changes worked, then. but they probably are ok in the meetbot logs.
17:23:40 <adamw> anyhow. votes!
17:24:05 <pwhalen> I only looked when it was obvious none of the discussion from matrix was coming through
17:24:13 <adamw> i...think i'm probably -1 blocker on this on current info. i'd be +1 FE if the fix needs to be in the VM guest, so that our release live images can be fixed.
17:24:39 <adamw> pwhalen: since i joined on irc side messages seem to be coming over the bridge fine to me...
17:25:14 <cmurf[m]> -1 blocker
17:25:21 <bcotton> what adam said makes sense
17:25:27 <cmurf[m]> i don't like it but, just wiggle it around and you'll find it
17:25:27 <bcotton> -1 blocker, +1 fe
17:25:37 <cmurf[m]> +1 fe though, yea
17:25:44 <geraldosimiao> -1 FB   +1FE
17:25:45 <Southern_Gentlem> -1fb,+1fE
17:25:56 <pwhalen> adamw: there was a gap, but yes, looks better now
17:26:56 <pwhalen> -1 blocker, +1 fe
17:27:11 <frantisekz> -1 Blocker, +1 FE
17:28:09 <adamw> proposed #agreed 2006746 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as a blocker on the basis that changing resolutions in a VM such that the bug happens is not commonly done (we may reconsider based on plausible arguments to the contrary). accepted as a freeze exception issue if the fix needs to be in the guest, so that release lives may be fixed
17:28:22 <bcotton> ack
17:28:35 <pwhalen> ack
17:28:48 <geraldosimiao> ack
17:29:04 <adamw> #agreed 2006746 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as a blocker on the basis that changing resolutions in a VM such that the bug happens is not commonly done (we may reconsider based on plausible arguments to the contrary). accepted as a freeze exception issue if the fix needs to be in the guest, so that release lives may be fixed
17:29:16 <adamw> #topic (2009304) Mouse cursor offset in VMs with Wayland (but not X11), possibly due to mouse integration
17:29:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2009304
17:29:22 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/486
17:29:25 <adamw> #info Proposed Blocker, spice-vdagent, NEW
17:29:29 <adamw> #info Ticket vote: FinalBlocker (+3,0,-0) (+kparal, +bcotton, +coremodule)
17:29:40 <adamw> this one seems kinda worse since it seems like it just always happens
17:29:54 <adamw> i've seen this in the past on KDE guests but not on GNOME, with F35 it seems to affect GNOME guests too
17:30:12 <adamw> it is super annoying in all kinds of ways, especially trying to select text or image areas
17:30:45 <geraldosimiao> thats I agree with Kamil and the others, its the real annoing bug that interferes using a VM gui.
17:30:50 <geraldosimiao> +1 FB
17:30:51 <geraldosimiao> for me
17:31:25 <adamw> yeah, i think i'm +1. lots of people test in VMs, this is gonna look super bad to them
17:31:28 <Southern_Gentlem> so this appears to be a wayland issue so i would expect we would see it in gnome and kde  +1FB
17:31:50 <geraldosimiao> I'm allways changing to x11 here to avoid this
17:31:51 <pwhalen> +1 FB
17:32:32 <Southern_Gentlem> geraldosimiao, in the VM or the host
17:34:22 <frantisekz> +1 FB
17:35:59 <adamw> proposed #agreed 2009304 - AcceptedBlocker (Final) - in contrast to 2006746, this bug seems to happen on all boots of an F35 Workstation or KDE VM, and it causes substantial functionality issues, so we accept it as a sufficiently serious problem to constitute a violation of several graphical desktop usage requirements when running in a VM
17:36:11 <bcotton> ack
17:36:13 <geraldosimiao> Southern_Gentlem: the VM
17:37:16 <geraldosimiao> adamw: ack
17:37:19 <cmurf[m]> ack
17:37:57 <cmurf[m]> i haven't hit that one yet, i think i'd have been quite aggravated
17:38:06 <pwhalen> ack
17:38:26 <adamw> cmurf: have you been using F35 VMs?
17:38:35 <adamw> it'd be useful/interesting to know if there are cases where it isn't happening...
17:39:44 <frantisekz> ack
17:40:02 <adamw> #agreed 2009304 - AcceptedBlocker (Final) - in contrast to 2006746, this bug seems to happen on all boots of an F35 Workstation or KDE VM, and it causes substantial functionality issues, so we accept it as a sufficiently serious problem to constitute a violation of several graphical desktop usage requirements when running in a VM
17:41:57 <adamw> #topic (2006393) [DNS over TLS] following connection to a wifi AP, internet is not available for ~30s
17:42:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2006393
17:42:04 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/472
17:42:07 <adamw> #info Proposed Blocker, systemd, NEW
17:42:10 <adamw> #info Ticket vote: FinalBlocker (+4,0,-0) (+imsedgar, +chrismurphy, +bcotton, +coremodule)
17:43:24 <Southern_Gentlem> +1FB
17:43:26 <pwhalen> FinalBlocker +1
17:44:26 <frantisekz> FinalBlocker +1
17:44:49 <adamw> yeah, this again seems kinda trivial but is really all kinds of annoying for a common use case
17:44:57 <adamw> so +1
17:45:09 <geraldosimiao> good point from catanzaro on the issue +1 FB
17:48:31 <adamw> hmm, still. attempting to write a justification i find myself lacking a criterion. :D
17:48:42 <adamw> it'd be nice if we had more explicit criteria around networking.
17:48:56 <adamw> does anyone want to attempt a justification? i don't think cmurf's really works, though it's a heroic effort.
17:51:19 <bcotton> breaks basic functionality of web browser?
17:51:20 <geraldosimiao> that would be a good justification? (imsedgar) "30 seconds delay may trigger some timeouts on services that depend on network services from remote services."
17:52:38 <bcotton> "is so obviously a requirement that we never bothered to write it down"?
17:53:45 <adamw> we have tended to consider functioning network as implicit in various other criteria
17:53:51 <adamw> like the web browser requirements and the software update ones
17:54:16 <adamw> but for this case, that seems a bit awkward...
17:57:43 <adamw> so...i'd say we can try just taking it on that basis, even if it's awkward
17:57:54 <adamw> or we can come up with a rough new requirement on the fly...
17:58:18 <bcotton> i mean, ultimately who is going to complain if we contort this requirement to fix a bug that everyone seems to think is worth blocking for?
17:59:11 <bcotton> (i'm not saying we should be willy-nilly about our decisions, they'd take my clipboard away for that. but i think this is a case worth applying the "the process is here to serve the community; the community is not here to serve the process" axiom)
17:59:16 <adamw> Ben Cotton (he/him/his): me! i'm complaining
17:59:46 <adamw> the problem is one of those 'gradual build up' ones
18:00:01 <adamw> we can always just say of this bug or that that it's fine to just take it as a blocker because we think it 'obviously' should be one
18:00:20 <bcotton> yeah, i understand the concern. the slope can get very slippery sometimes
18:00:27 <adamw> but the cumulative effect of doing that is that we render the criteria a dead letter and go back to just making arbitrary decisions that have no consistency or predictability
18:00:46 <adamw> which was the situation we wrote the criteria to get away from, because nobody liked it and it meant the process wasn't taken seriously
18:00:47 <StephenGallagher> adamw: We can try to get FESCo to just declare it.
18:00:58 <adamw> Stephen Gallagher: ooo, i didn't think of that!
18:01:00 <adamw> we could.
18:01:22 <adamw> i actually kind of like that, because this seems like a hard area to draft criteria in, and i don't really feel like doing it on the fly is a good idea
18:01:52 <StephenGallagher> I'll take it to FESCo for the rubber stamp at today's meeting.
18:02:01 <StephenGallagher> In ~2hours
18:02:12 <bcotton> ~1 hours
18:02:24 <StephenGallagher> Right ~1 hours
18:02:31 <StephenGallagher> This day is flying by
18:02:54 <adamw> and we can maybe try to draft some explicit networking criterions in a more considered timeframe for f36
18:03:18 <bcotton> "it has to be networking, not netbrokening"
18:04:15 <adamw> proposed #agreed 2006393 - punt (delay decision) - there is a strong consensus that this ought to be a release blocker, but nobody has made a really plausible justification for it based on the release criteria. therefore, we punt on the decision but refer it to FESCo for consideration as a FESCo-declared blocker. we will also start a discussion about explicit (wireless) networking criteria for F36.
18:04:33 <frantisekz> ack
18:06:11 <StephenGallagher> ack
18:06:26 <geraldosimiao> ack
18:06:52 <adamw> #agreed 2006393 - punt (delay decision) - there is a strong consensus that this ought to be a release blocker, but nobody has made a really plausible justification for it based on the release criteria. therefore, we punt on the decision but refer it to FESCo for consideration as a FESCo-declared blocker. we will also start a discussion about explicit (wireless) networking criteria for F36.
18:07:04 <adamw> ok, that's all the proposed blockers
18:07:06 <adamw> moving onto:
18:07:11 <adamw> #topic Proposed Final freeze exceptions
18:07:25 <adamw> #topic (2009451) Meeting link imported are truncated; results in invalid link
18:07:35 <adamw> oh, wait, did we do this?
18:07:38 <adamw> yeah, we did.
18:07:46 <adamw> #undo
18:07:46 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f257b8ffbe0>
18:08:02 <geraldosimiao> this was moved from FB to FE
18:08:41 <adamw> we already voted on both earlier
18:09:17 <adamw> 2009063 is already accepted by ticket vote...
18:09:39 <adamw> oh, and the next two issues both have +3 ticket vote now too.
18:09:44 <adamw> so, we don't actually need to do anything!
18:09:59 <adamw> #info all proposed FEs are decided or decidable by ticket vote already, moving on
18:10:12 <adamw> #topic Accepted Final blockers
18:10:31 <adamw> #info as a reminder, we are checking status, not re-voting here (unless we decide a re-vote is merited)
18:10:40 <adamw> #topic (1997315) abrt-dbus segmentation faulted in abrt_p2_service_dbus when shutting down, rebooting, or logging out of Plasma
18:10:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1997315
18:10:46 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/431
18:10:50 <adamw> #info Accepted Blocker, abrt, ASSIGNED
18:12:18 <adamw> #info assignee said (last week) "Soon-ish -- I hope to have the fix ready early next week!", so we are awaiting a fix this week
18:12:24 <adamw> anything else on this?
18:12:59 <geraldosimiao> tested today and theres no fix yet
18:13:37 <adamw> yeah, you have to wait for the assignee to actually say there's an update, usually :D
18:13:49 <adamw> #topic (2006028) Non-root user cannot join an Active Directory domain through Cockpit
18:13:56 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2006028
18:13:57 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/465
18:14:00 <adamw> #info Accepted Blocker, cockpit, ON_QA
18:14:32 <geraldosimiao> adamw: 👀😆👍️
18:14:36 <adamw> Stephen Gallagher: did you get a chance to check the update?
18:15:58 <adamw> #info fix for this is in updates-testing, waiting karma or time to go stable, we don't have explicit confirmation of the fix in the update but it does look like stephen confirmed the same fix on the bug report
18:18:00 <frantisekz> karma-ed the cockpit update, it worked fine for me
18:18:21 <adamw> ok, it should go stable then as i also karmed it...
18:18:28 <adamw> #topic (1991075) time is transiently incorrect when Automatic Time Zone is enabled
18:18:32 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1991075
18:18:35 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/389
18:18:38 <adamw> #info Accepted Blocker, geoclue2, NEW
18:19:14 <adamw> this doesn't seem to be going anywhere...
18:19:21 <adamw> mclasen: is there anything we can do to bump this along?
18:20:36 <mclasen> kalev said last week that he was going to take a look at it
18:20:48 * coremodule is back
18:21:04 <mclasen> let me ask him for an update
18:21:40 <adamw> thanks
18:21:55 <adamw> unfortunately it looks like the reproduction steps may not be as simple as doing what comment #0 says...
18:23:11 <adamw> i did look into the error message, but it kinda looks like that wasn't the cause.
18:27:02 <mclasen> kalev says he plans to look at it tomorrow
18:27:50 <adamw> ok, cool
18:28:49 <adamw> #info we don't have significant progress on this yet, but kalev will take a look at it tomorrow. it's worth noting that kamil and chris got somewhat different test results here - neither managed to see successful timezone updating on F35, but kamil says he couldn't get it to work on F34 either, whereas chris says it was working for him on F34.
18:29:17 <adamw> #topic (1989726) [abrt] gnome-shell: cogl_texture_get_gl_texture(): gnome-shell killed by SIGSEGV
18:29:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1989726
18:29:24 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/399
18:29:28 <adamw> #info Accepted Blocker, mesa, NEW
18:29:53 <frantisekz> this looks a bit scary out of all blockers
18:29:55 <adamw> doesn't look like we have any news here :|
18:30:12 <adamw> frantisekz: we may just have to waive it again, sadly
18:30:16 <adamw> it's really kinda out of our hands to a degree
18:30:27 <adamw> pwhalen: have you heard any more on this? don't think i have
18:32:48 * bcotton has not
18:33:45 <adamw> #info we are more or less at the mercy of Outside Forces on this one, and there doesn't seem to be much movement
18:33:59 <adamw> #action adamw to prod a few folks to see if there's any hope of this being fixed in time for release
18:34:16 <bcotton> this one feels like it's going to end up an F36 Beta blocker
18:34:37 <Southern_Gentlem> bcotton, i am betting final
18:35:34 <StephenGallagher> adamw: I haven't tested the Cockpit patch yet. I'll try to get on that tomorrow. Today is kicking my butt.
18:35:58 <frantisekz> is it open floor already?
18:36:02 <pwhalen> adamw: I haven't heard anything new :(
18:36:03 <adamw> Stephen Gallagher: np.
18:36:33 <frantisekz> (I am on irc, so not sure, my connection is not behaving well today)
18:36:48 <adamw> Ben Cotton (he/him/his): i think if we waive it past f35 final, we should probably propose taking jetson out of the blocking platforms list for f36 until such time as we can actually support it again
18:36:53 <adamw> frantisekz: not technically yet, nope
18:37:11 <adamw> frantisekz: it's coming soon, though
18:37:19 <frantisekz> okay, ty
18:37:58 <adamw> #topic (2001837) The switch for Fedora Third Party repositories does not switch them on.
18:38:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2001837
18:38:04 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/455
18:38:08 <adamw> #info Accepted Blocker, selinux-policy, ASSIGNED
18:38:42 <adamw> so i pinged zdenek on this last week, but didn't hear anything
18:38:46 <adamw> maybe i'll try direct mail this week
18:38:58 <adamw> it seems fairly understood at this point, not much we can do besides wait on zdenek...
18:41:02 <adamw> #info we are just waiting for the maintainer to fix this one, we pinged once but without response. will try again this week
18:41:11 <adamw> #topic Open floor
18:41:14 <adamw> OK, that's all the agenda
18:41:17 <adamw> any other business, folks?
18:41:30 <frantisekz> so
18:41:57 <frantisekz> today, an ugly thing hit f35: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e353a56911 ( https://bugzilla.redhat.com/show_bug.cgi?id=2010250 )
18:42:34 <geraldosimiao> none here
18:42:37 * bcotton has nothin'
18:42:39 <frantisekz> beware, on the other hand, I've talked about it with Peter, it might be good idea to push it as FE, I'll propose it as soon as build is done
18:43:00 <frantisekz> it'll be great if it could get as many testing as possible
18:43:59 <frantisekz> many/much
18:44:17 <adamw> well since we're in the blocker/fe review meeting, this seems like an excellent time to consider it as an FE :D
18:44:28 <cmurf[m]> let me know if i should file the fesco issue for bug 2006393
18:45:09 <frantisekz> yeah, I was planning to wait if pbrobinson manages to get fixed build pushed today, or propose it after we have fixed build
18:45:22 <adamw> cmurf: ben's taking care of it.
18:45:41 <frantisekz> from what I understand, there is some HW enablement, fixes, it's just a packaging that's an issue, it seems so far
18:46:02 <mclasen> I asked kherbst about the tegra / shell crash - he says a fix is in the works, but no idea about eta
18:46:04 <bcotton> frantisekz: might as well go ahead and propose it now
18:46:07 <adamw> oh, i see the bad update is only in u-t
18:46:09 <adamw> so we don't need an FE
18:46:19 <adamw> mclasen: thanks
18:47:02 <frantisekz> I can propose it now, if you want? I am not sure, there may be a stable push right after the freeze tomorrow ?
18:47:58 <frantisekz> to clarify, that didn't hit stable, it won't, the FE would be the same bug, different title to get the latest linux-firmware to GA
18:48:46 <adamw> frantisekz: ah, i see. hmm. i guess we can do a ticket vote on that then as it's not so clear as 'upgrades are broken'
18:49:05 <frantisekz> mhm, okey dokey
18:49:22 <cmurf[m]> ok i did it already
18:49:23 <cmurf[m]> https://pagure.io/fesco/issue/2671
18:50:57 <adamw> alrighty
18:51:00 <adamw> i think we're all done?
18:51:27 <coremodule> semi-related, f35 beta Heroes of Fedora will be published on the blog tomorrow
18:51:43 <frantisekz> coremodule, did you check the data?
18:51:50 <coremodule> frantisekz, yeah, it looked fine
18:52:00 <frantisekz> I am not sure the script is working properly after bz paging changes, but it may be
18:52:24 <coremodule> kparal said he expected it would only display the first 20 contributors, but that worked out for the article
18:52:26 <adamw> coremodule: awesome, thanks for being on top of that
18:52:39 <frantisekz> okay then
18:52:40 <coremodule> you got it!
19:01:16 <frantisekz> anyhow, need to run, bye and thanks for the meeting
20:00:34 <coremodule> #endmeeting
20:01:20 <coremodule> hey adamw^^
20:03:09 <adamw> whoops
20:03:10 <adamw> #endmeeting