16:00:04 <bcotton_> #startmeeting F33-blocker-review
16:00:04 <zodbot> Meeting started Mon Sep 21 16:00:04 2020 UTC.
16:00:04 <zodbot> This meeting is logged and archived in a public location.
16:00:04 <zodbot> The chair is bcotton_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:04 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:00:05 <bcotton_> #meetingname F33-blocker-review
16:00:05 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:00:07 <bcotton_> #topic Roll Call
16:00:23 <bcotton> so nice, i'm joining twice!
16:00:24 <bcotton> .hello2
16:00:25 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:00:36 <coremodule> .hello2
16:00:37 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:00:49 * coremodule here as acting secretary.
16:00:54 <bcotton_> #chair bcotton coremodule
16:00:54 <zodbot> Current chairs: bcotton bcotton_ coremodule
16:01:00 <adamw> .hello adamwill
16:01:01 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
16:01:07 <adamw> i'm here for like 15 mins
16:01:14 <bcotton_> #info coremodule is the Secretary of Secretarying
16:01:21 <bcotton_> welcome adamw
16:01:31 <bcotton_> #chair adamw
16:01:31 <zodbot> Current chairs: adamw bcotton bcotton_ coremodule
16:01:33 <bcotton_> have a seat :-)
16:02:25 <coremodule> huzzah!
16:02:41 <cmurf> .hello chrismurphy
16:02:42 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:03:17 <kparal> .hello2
16:03:18 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
16:04:53 <bcotton_> okay, let's plate some boilers
16:05:16 <bcotton_> #topic Introduction
16:05:17 <bcotton_> Why are we here?
16:05:19 <bcotton_> #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:05:20 <bcotton_> #info We'll be following the process outlined at:
16:05:23 <bcotton_> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:24 * pwhalen is here
16:05:25 <bcotton_> #info The bugs up for review today are available at:
16:05:27 <bcotton_> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:28 <bcotton_> #info The criteria for release blocking bugs can be found at:
16:05:33 <Southern_Gentlem> .hello2 jbwillia
16:05:34 <zodbot> Southern_Gentlem: Sorry, but you don't exist
16:05:40 <Southern_Gentlem> .hello jbwillia
16:05:41 <bcotton_> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:05:41 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
16:05:42 <bcotton_> #link https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria
16:05:44 <bcotton_> #link https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria
16:06:06 <bcotton_> welcome pwhalen and Southern_Gentlem
16:06:25 <bcotton_> #info 3 Proposed Blockers
16:06:26 <bcotton_> #info 4 Accepted Blockers
16:06:28 <bcotton_> #info 0 Accepted 0-day Blockers
16:06:33 <bcotton_> #info 0 Accepted Previous Release Blockers
16:06:35 <bcotton_> #info 9 Proposed Freeze Exceptions
16:06:36 <bcotton_> #info 9 Accepted Freeze Exceptions
16:06:43 <bcotton_> #topic (1879127) a metalink repository can't be added using UI
16:06:45 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1879127
16:06:46 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/94
16:06:48 <bcotton_> #info Proposed Blocker, anaconda, VERIFIED
16:07:01 <adamw> this is kinda academic
16:07:08 <adamw> it was already an FE and the fix is verified and queued for stable
16:07:22 <bcotton_> yeah, but if it re-breaks somehow
16:07:34 <adamw> ehhhhhh
16:07:38 <kparal> there's a large consensus for FinalBlocker in the ticket, I think we can just bless that resolution
16:07:43 <adamw> i'
16:07:44 <kparal> for Beta, I think we don't have a criterion
16:07:46 <adamw> i'm fine with that
16:07:49 <kparal> but Adam can correct me
16:08:01 <kparal> see https://pagure.io/fedora-qa/blocker-review/issue/94#comment-686566
16:08:06 <bcotton_> #info In ticket: BetaBlocker (+0, 0, -1), FinalBlocker (+5, 0, -0), Accepted BetaFE (+3, 0, -0)
16:08:14 <adamw> it depends on whether you wanna stretch that http 'repository' criterion, i guess
16:08:24 <adamw> but i'm fine with just -1 betablocker +1 finalblocker
16:08:24 <cmurf> i didn't even know there was metalink anywhere in the Fedora ecosystem
16:08:30 <adamw> cmurf: it's the default
16:08:32 <cmurf> haha
16:08:34 <cmurf> LOL
16:08:42 <kparal> adamw: you didn't sound like it was stretchable ;-)
16:08:46 <kparal> in the list
16:08:47 <cmurf> ok then apparently I don't know what metalink is
16:08:56 <adamw> cmurf: check your /etc/yum.repos.d/fedora.repo
16:09:07 <adamw> unless you modified it, should say metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
16:09:09 <cmurf> it must just work
16:09:14 <adamw> shocking right
16:09:37 <cmurf> well if it works that well
16:09:42 <cmurf> it should keep on working! :D
16:09:48 <bcotton_> proposed #agreed 1879127 - RejectedBlocker (Beta) AcceptedBlocker (Final) - Violates "The installer must be able to use all supported local and remote package and installer sources."
16:09:58 <kparal> ack
16:10:03 <Southern_Gentlem> ack
16:10:05 <adamw> ack
16:10:17 <bcotton_> #agreed 1879127 - RejectedBlocker (Beta) AcceptedBlocker (Final) - Violates "The installer must be able to use all supported local and remote package and installer sources."
16:10:30 <bcotton_> proposed #agreed "metalink" should be pronounced "metal ink" ;-)
16:10:43 <Southern_Gentlem> nack
16:10:48 <bcotton_> #topic (1863041) systemd-resolved.service not work with DNS server placed behind VPN (openconnect)
16:10:50 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1863041
16:10:51 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/24
16:10:53 <bcotton_> #info Proposed Blocker, NetworkManager, NEW
16:11:13 <bcotton_> #info This was previously accepted as a betablocker, but the scope has narrowed since
16:11:41 <bcotton_> #info In the ticket: BetaBlocker (+0, 1, -4), Accepted BetaFE (+0, 0, -0)
16:12:06 <bcotton_> lol
16:12:14 <adamw> i'm finding it pretty hard to get a grasp on this one tbh
16:12:19 <adamw> dunno about anyone else
16:12:31 <zbyszek> It's not clear if there's even a bug.
16:12:49 <bcotton_> it kinda seems like the "bug" is "it's working as designed"
16:13:32 <cmurf> -1 betablocker
16:13:36 <Southern_Gentlem> -1
16:13:39 <bcotton_> but it seems like it's a relatively specific configuration that's needed
16:14:03 <adamw> yeah, if we have to vote i lean -1 because it seems that if there is a case that has problems it's a relatively specific VPN config
16:14:21 <cmurf> or alternatively improve summary and argument to be more persuasive
16:14:21 <zbyszek> It boils down to whether a VPN that doesn't declare any domains should take all domains by default.
16:14:22 <adamw> no-one seems to be saying "there is this very serious and obvious bug here"
16:14:55 <bcotton_> proposed #agreed 1863041 - RejectedBlocker (Beta) - The problem case seems to be tied to a relatively specific VPN config and it's not clear that there's a broadly-applicable bug
16:14:57 <cmurf> networking is complicated
16:14:59 <zbyszek> One *can* argue that if they didn't specify any domains, they clearly meant all domains, but it's a bit iffy.
16:15:01 <cmurf> ack
16:15:06 <bcotton_> everything is a $^#Q# DNS problem
16:15:13 <kparal> ack
16:15:17 <coremodule> ack
16:15:21 <Southern_Gentlem> ack
16:15:38 <bcotton_> #agreed 1863041 - RejectedBlocker (Beta) - The problem case seems to be tied to a relatively specific VPN config and it's not clear that there's a broadly-applicable bug
16:15:42 <adamw> bcotton: naming!
16:15:57 <adamw> sorry, that wasn't a patch
16:16:02 <adamw> just a note that naming is always the problem. =)
16:16:16 <bcotton_> good, because i've already released the agreed :p
16:16:19 <bcotton_> #topic (1880499) rpm-ostree rebase fails when using aarch64 disk images
16:16:21 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880499
16:16:22 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/104
16:16:22 <adamw> i gotta run folks, thanks for looking after things bcotton
16:16:24 <bcotton_> #info Proposed Blocker, ostree, NEW
16:16:35 <bcotton_> gl, adamw
16:16:42 <kparal> adamw: take care
16:16:44 <bcotton_> #info In the ticket: BetaBlocker (+3, 0, -0)
16:17:08 <kparal> well, you should read the ticket :)
16:17:16 <kparal> (all of you!) :D
16:18:06 <bcotton_> #info We should treat this as a proposed PreviousRelease blocker
16:18:26 <lruzicka> .hello2
16:18:26 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:18:30 <lruzicka> Sorry, for being late.
16:18:32 <bcotton_> welcome lruzicka
16:18:52 <bcotton_> so i understand the "F33 is the first Edition release so previous releases shouldn't block" but...
16:18:56 <pwhalen> I am +1, I tested the fix on F32 and it worked.
16:19:24 <zbyszek> pwhalen: +1 to BetaBLocker of PreviousReleaseBlocker?
16:19:29 <zbyszek> *or*
16:19:30 <bcotton_> i think that's a little too rules-lawyer and not enough we should expect the first edition to be upgradeable from the most recent release
16:19:41 <cmurf> i guess if there's a tested fix for F32, just push to F32
16:20:02 <cmurf> there isn't a reason to hold up beta for a tested fix for previous release version, is there?
16:20:19 <Southern_Gentlem> the fix is there why is this a betablocker for f33
16:20:21 <kparal> bcotton_: we really don't have any precedent for this scenario
16:20:35 <pwhalen> zbyszek: +1 PreviousReleaseBlocker
16:20:50 <bcotton_> yeah. i said over the weekend that this is the sort of thing that program managers have nightmares about :-)
16:20:52 <pwhalen> When I filed the bug, I didn't know it could be fixed in f32.
16:20:54 <zbyszek> +1 PreviousReleaseBlocker too
16:20:54 <kparal> but it something becomes release-blocking, it seems weird to me to apply rules retroactively
16:21:18 <bcotton_> i suppose since it's beta we can be a little more forgiving
16:21:21 <kparal> so my current feeling is towards PreviousReleaseBlocker -1
16:21:30 <bcotton_> we could release and then commonbugs it until the fix lands in 32
16:21:36 <Southern_Gentlem> i can see where this could be a final blocker but not beta
16:21:58 <kparal> also, I'm not really sure if we blocked Beta (instead of Final) with a PreviousReleaseBlocker before?
16:22:03 <kparal> adamw would know, sigh
16:22:08 <bcotton_> kparal and Southern_Gentlem are being very convincing. i'm leaning previousrelease -1 too
16:22:09 <Southern_Gentlem> push the f32 fix and this goes away
16:22:23 <bcotton_> kparal: yeah, i'm not sure either
16:22:45 <cmurf> yeah that's reasonably convincing, it could be previousreleaseblocker for f33 final
16:22:46 <bcotton_> okay, i'll say previousreleaseblocker -1
16:22:54 <bcotton_> well
16:22:57 <cmurf> but it can be fixed anytime in f32
16:23:01 <Southern_Gentlem> -1 pb
16:23:05 <lruzicka> I agree
16:23:17 <zbyszek> OK, is it on its way to being pushed to F32?
16:23:23 <kparal> we can remove the BetaBlocker nomination, add the FinalBlocker nomination, and wait after Beta to discuss it
16:23:27 <kparal> it might go away in the meantime ;)
16:23:33 <kparal> errr
16:23:42 <kparal> not FinalBlocker, but PreviousReleaseBlocker
16:23:44 <pwhalen> zbyszek: we need an official build still, what I tested was a scratch build
16:23:58 <lruzicka> kparal, now it makes sense :D
16:24:19 <Southern_Gentlem> next question is aarach64 release blocking
16:24:29 <pwhalen> kparal: I am ok with that, there is a work around. We can document it
16:24:31 <bcotton_> proposed #agreed 1880499 - RejectedBlocker (Beta) - The fix is needed for F32 so this is either a PreviousReleaseBlocker or not a blocker at all
16:24:40 <pwhalen> Southern_Gentlem: yes
16:24:44 <Southern_Gentlem> ack
16:24:47 <bcotton_> we can at least agree it's not a betablocker :-)
16:24:48 <lruzicka> ack
16:24:50 <pwhalen> ack
16:24:52 <kparal> ack
16:24:54 <cmurf> I think IoT Edition on both x64 and aarch64 is release blocking
16:24:56 <cmurf> ack
16:25:01 <bcotton_> #agreed 1880499 - RejectedBlocker (Beta) - The fix is needed for F32 so this is either a PreviousReleaseBlocker or not a blocker at all
16:25:12 <kparal> coremodule: when updating the bug, please add Blocks: PreviousReleaseBlocker and CommonBugs, thanks
16:25:25 <bcotton_> okay, so now the question is what do we do about the previousreleaseblocker?
16:25:36 <cmurf> punt :)
16:25:38 <kparal> ah, this was two part discussion, ok :)
16:25:44 <Southern_Gentlem> push the fix
16:26:01 <Southern_Gentlem> so for now punt
16:26:11 <bcotton_> pwhalen: are you okay with commonbugs-ing it until the f32 fix lands?
16:26:23 <kparal> well technically we can block Beta on a previous release (instead of blocking Final). I'm just not sure if we ever did it
16:26:57 <kparal> either way I'm rather -1 on previousreleaseblocker anyway, because F32 wasn't release blocking
16:27:07 <kparal> at least not IoT
16:27:21 <pwhalen> bcotton_: yes.
16:27:30 <bcotton_> okay
16:28:42 <cmurf> yeah if it turns out this is harder to fix for some reason, then it means reprovision which is sort of an expected and straightforward thing to do anyway with rpm-ostree installs as i understand it
16:28:44 <bcotton_> proposed #agreed 1880499 - Defer decision (punt) on PreviousReleaseBlocker - We will add this to CommonBugs for F33 until the F32 update is available and make a decision on blocker status after that
16:28:49 <cmurf> ack
16:28:58 <lruzicka> ack
16:28:58 <kparal> ack
16:29:25 <pwhalen> ack
16:29:55 <bcotton_> #agreed 1880499 - Defer decision (punt) on PreviousReleaseBlocker - We will add this to CommonBugs for F33 until the F32 update is available and make a decision on blocker status after that
16:30:17 <bcotton_> okay, let's look at the FEs
16:30:28 <bcotton_> #topic (1880096) Include Plasma 5.19.5 in F33 Beta
16:30:29 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880096
16:30:31 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/99
16:30:32 <bcotton_> #info Proposed Freeze Exceptions, distribution, MODIFIED
16:30:46 <bcotton_> #info In ticket: BetaFE (+3, 0, -1)
16:31:34 <kparal> we have a divisive topic here :)
16:32:04 * bcotton_ cracks knuckles
16:32:28 <bcotton_> it's a point release, so in theory, it shouldn't be too bad
16:32:33 <cmurf> we've had two no go's so i'd say -1 beta FE for this unless it's for sure well tested and isn't going to risk more blockers
16:32:35 <kparal> If I were cynical, I'd say that the KDE update will introduce the same number of bugs it will fix, just distribute them somewhere else, so it doesn't really matter... :)
16:32:37 <cmurf> it's Monday already
16:32:54 <bcotton_> but i also don't see that there's anything that would be critical to live images
16:33:03 <lruzicka> on the other hand, we have let Gnome megaupdate inside
16:33:20 <kparal> lruzicka: adamw covered that a bit in his argument in the ticket
16:33:28 <Southern_Gentlem> lruzicka, since the slips?
16:33:34 <cmurf> that was discussed a week ago and had lots of heads up though
16:33:34 <kparal> but I basically said the same thing
16:33:35 <zbyszek> I voted -1 but I don't participate in the blocker process too much, so feel free to ignore my vote.
16:34:15 <bcotton_> i'm still going back and forth
16:34:15 <cmurf> i'd say, same deal
16:34:25 <cmurf> +1 FE *if* we slip again this week
16:34:28 <lruzicka> If we disapprove, what will happen then, will it be able to dive into Final?
16:34:59 <kparal> zbyszek: your vote is appreciated even if you don't participate often :)
16:35:02 <bcotton_> lruzicka: yeah, it'll be a 0-day update so the final compose will have it (or a subsequent version)
16:35:13 <cmurf> well if it gets enough karma, then it goes in for final when freeze is lifted upon beta GA
16:35:25 <kparal> I'd say take it in if we expect a slip this week
16:35:27 <kparal> otherwise don't
16:35:35 <cmurf> +1 kparal
16:35:39 <bcotton_> the other thing about the gnome megaupdate vs this is that the gnome megaupdate has a bigger team behind it, i think
16:35:46 <Southern_Gentlem> +1 kparal
16:35:46 <zbyszek> kparal: yeah, that makes sense
16:36:04 <lruzicka> bcotton_, you should have seen the powerful kde commnunity in test lists :D
16:36:39 <bcotton_> so how do we record a conditional FE procedurally?
16:36:40 <lruzicka> but I am ok with +1 if we slip mode
16:37:05 <bcotton_> just vote and not ask RelEng to allow it unless we slip?
16:37:06 <kparal> bcotton_: well, we can leave this discussion as the last one, it might be clearer then
16:37:06 <Southern_Gentlem> so for today -1 so bring it back up next week
16:37:12 <kparal> but still it's just guesswork
16:37:26 <bcotton_> Southern_Gentlem: the problem is that if we wait until next week, we're in the same position
16:37:48 <Southern_Gentlem> bcotton_, at least it will have a week more to be tested
16:38:16 <cmurf> -! FE for now, if on wednesday it's clear we're gonna slip, then +1 FE so it goes in a nightly or RC before the weekend
16:38:27 <kparal> another approach is to approve it with a note, and ask anyone who's going to submit stable push requests (frantisekz) to not include this one unless it's clear we're slipping
16:38:35 <cmurf> i don't know how that was written for the gnome megaupdate but it's the same thing
16:39:05 * bcotton_ looks at last week's minutes
16:39:23 <bcotton_> okay yeah, so it was just a straight vote on FE status with a note about "only if we slip"
16:39:36 <kparal> we can also leave it in the "punt" state until wednesday
16:39:47 <kparal> just print our decision into the ticket
16:39:54 <kparal> all of that works fine I think
16:40:46 <bcotton_> is there anyone who thinks we should take a non-conditional vote?
16:41:08 <bcotton_> i.e. a yes/no decision on FE status now, independent of slippage
16:41:31 <lruzicka> speak now or hold your peace forever
16:41:46 <Southern_Gentlem> +1 Punt
16:42:33 <bcotton_> otherwise, let's do this: are you +1/-1 FE conditional on slipping or punt to an async decision on Thursday after the go/no-go
16:42:44 <bcotton_> +1 FE from me
16:42:49 <lruzicka> +1 FE from me
16:43:00 <zbyszek> +1 FE conditional
16:43:04 <kparal> +1 FE if we slip
16:43:06 <cmurf> +1 FE only if we slip
16:43:17 <Southern_Gentlem> +1 FE Conditional
16:44:02 <bcotton_> proposed #agreed 1880096 - AcceptedFreezeException (Beta) -  this is accepted as a major useful change that affects live images, but we will only pull it in if we slip this week and it tests out well in the meantime
16:44:11 <Southern_Gentlem> ack
16:44:12 <cmurf> ack
16:44:17 <zbyszek> ack
16:45:21 <lruzicka> ack
16:45:23 <kparal> ack
16:45:34 <bcotton_> #agreed 1880096 - AcceptedFreezeException (Beta) -  this is accepted as a major useful change that affects live images, but we will only pull it in if we slip this week and it tests out well in the meantime
16:45:50 <bcotton_> #topic (1880772) fedmsg in F33 has lower version than in F32, breaks upgrade to F33
16:45:52 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880772
16:45:54 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/111
16:45:55 <bcotton_> #info Proposed Freeze Exceptions, fedmsg, MODIFIED
16:46:38 <bcotton_> kparal can't reproduce it https://bugzilla.redhat.com/show_bug.cgi?id=1880772#c3
16:46:47 <kparal> so, zbyszek has filed a few bugs yesterday, but he has been doing "dnf update" and reporting failures, instead of "dnf distrosync/system-upgrade"
16:46:55 <kparal> I assume this might be another instance of that
16:46:56 <bcotton_> and i'm not sure there are use cases for using fedmsg on a live
16:47:21 <zbyszek> yes, all my bugs are from the same test session.
16:47:23 <kparal> bcotton_: it's not on Live, this is just an FE to improve the upgrade process
16:47:50 <bcotton_> right, i'm just saying being on a live makes a strong case for FE-ness
16:47:53 <kparal> so since it worked for me, I think this is fine and it's not really a bug, at least according to how we currently do distro upgrades
16:47:57 <zbyszek> My motivation is that when we announce "beta", people try to upgrade immediately.
16:48:13 <cmurf> yeah
16:48:24 <bcotton_> zbyszek: a reasonable motivation :-)
16:48:34 <kparal> zbyszek: it should work immediately, just downgrade to a lower version
16:48:40 <kparal> I agree it's non-ideal
16:48:47 <bcotton_> i'm a weak -1 FE
16:48:50 <kparal> but there must be hundreds packages like this
16:48:52 <Southern_Gentlem> doing a quick test
16:48:56 <kparal> constantly changing
16:49:03 <kparal> because F32 receives updates every day
16:49:39 <zbyszek> So I think it's fine to reject at least the ones where no major version downgrade happens.
16:49:47 <kparal> so unless it breaks something or is important for some other reason, we can't push dozens packages through freeze every day so that the package versions are higher than in F32
16:50:17 <zbyszek> Ack.
16:50:20 <cmurf> i'm inclined to -1 FE unless there's a problem that needs solving
16:50:48 <zbyszek> Yeah, no major problem.
16:50:55 <cmurf> we need USS Beta to set sail or the u-t bottleneck just gets worse
16:50:57 <kparal> right, for example if an app didn't start because it wouldn't understand the newer configs, that would be a reason for an FE/blocker
16:51:38 <cmurf> barn door on easy FE's should be closed this week :)
16:52:30 <bcotton_> i'm not seeing anyone arguing strongly for a +1 so
16:53:07 <bcotton_> proposed #agreed 1880772 - RejectedFreezeException (Beta) - This can be fixed in a 0-day update and does not negatively impact the Live experience
16:53:20 <kparal> ack
16:53:21 <pwhalen> ack
16:53:33 <coremodule> ack
16:53:47 <cmurf> ack
16:53:51 <zbyszek> ack
16:53:56 <bcotton_> #agreed 1880772 - RejectedFreezeException (Beta) - This can be fixed in a 0-day update and does not negatively impact the Live experience
16:54:18 <bcotton_> #topic (1856098) Obsolete packages that used to require Python 3.8 but are gone in Fedora 33
16:54:19 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1856098
16:54:21 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/112
16:54:22 <bcotton_> #info Proposed Freeze Exceptions, fedora-obsolete-packages, ON_QA
16:54:40 <bcotton_> #info In ticket: BetaFE (+2, 0, -0)
16:54:46 <kparal> please see the ticket to read my thoughts
16:55:35 <bcotton_> BetaFE +1
16:56:14 <lruzicka> BetaFE +1
16:56:54 <Southern_Gentlem> bfe+1
16:57:39 <cmurf> i'm 0
16:58:03 * kparal voted BetaFE +1 in ticket
16:58:56 <bcotton_> proposed #agreed 1850698 - AcceptedFreezeException (Beta) - this is a low-risk update and it will help people with some upgrade issues if they try to upgrade on the release day
16:59:02 <cmurf> ack
16:59:11 <bcotton_> explanation shamelessly stolen from kparal's comment :-)
16:59:57 <kparal> bcotton_: 👮
17:00:17 <kparal> ack
17:00:40 <lruzicka> ack
17:00:44 <kparal> why there is no handcuffs emoji? so basic!
17:01:01 <Southern_Gentlem> on https://bugzilla.redhat.com/show_bug.cgi?id=1880772 doing a workf32 to f33 systemupgrade not seeing any issues
17:01:12 <Southern_Gentlem> ack
17:01:17 <bcotton_> \#agreed 1850698 - AcceptedFreezeException (Beta) - this is a low-risk update and it will help people with some upgrade issues if they try to upgrade on the release day
17:01:19 <bcotton_> GAH
17:01:21 <bcotton_> #agreed 1850698 - AcceptedFreezeException (Beta) - this is a low-risk update and it will help people with some upgrade issues if they try to upgrade on the release day
17:01:42 <bcotton_> #topic (1880628) FreeIPA server doesn't get along well with systemd-resolved (need to manually disable it)
17:01:43 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880628
17:01:45 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/105
17:01:47 <bcotton_> #info Proposed Freeze Exceptions, freeipa, NEW
17:01:53 <cmurf> uhoh
17:02:00 <bcotton_> #info In ticket: BetaFE (+2, 0, -0)
17:02:29 <cmurf> BetaFE +1
17:02:41 <Southern_Gentlem> +1 bfe
17:03:15 <bcotton_> i'm a little hestitant about +1ing something that doesn't have a fix in the works yet, but on the other hand that means if we're go on thursday, it's probably a moot point
17:03:21 <bcotton_> so BetaFE +1
17:03:28 <lruzicka> +1 bfe
17:03:56 <kparal> bcotton_: I lost that battle a long time ago :)
17:04:06 <pwhalen> +1 bfe
17:04:11 <Southern_Gentlem> there is always a freeipa blocker
17:04:40 <bcotton_> proposed #agreed 1880628 - AcceptedFreezeException (Beta) - This does not qualify as a Beta blocker, but it's worth including a fix if it's available for the Beta release
17:04:56 <lruzicka> ack
17:04:57 <bcotton_> Southern_Gentlem: and yet i still have to pay for my IPAs :-(
17:04:58 <pwhalen> ack
17:04:59 <Southern_Gentlem> ack
17:05:00 <zbyszek> ack
17:05:28 <lruzicka> bcotton_, it's because there's a bug in it always
17:05:39 <bcotton_> lruzicka: all the more reason I shouldn't have to pay!
17:05:45 <bcotton_> #agreed 1880628 - AcceptedFreezeException (Beta) - This does not qualify as a Beta blocker, but it's worth including a fix if it's available for the Beta release
17:05:54 <lruzicka> bcotton_, they cannot serve you a glass with insects in it
17:06:00 <bcotton_> #topic (1880778) file conflict between gst-transcoder and gstreamer1-plugins-bad-free
17:06:02 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880778
17:06:03 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/115
17:06:05 <bcotton_> #info Proposed Freeze Exceptions, gst-transcoder, NEW
17:06:19 <bcotton_> #info In ticket: BetaFE (+1, 0, -0)
17:06:46 <Southern_Gentlem> +1 bfe
17:06:59 <bcotton_> +1 FE
17:07:06 <lruzicka> +1 fe
17:07:06 <cmurf> oof
17:07:31 <pwhalen> +1 FE
17:07:40 <cmurf> so. painful. to give up. BFE +1
17:08:23 * cmurf is being silly, it's worse to not give it an FE
17:08:23 <bcotton_> proposed #agreed 1880778 - AcceptedFreezeException (Beta) - This conflict breaks upgrades, so we should include a fix if available
17:08:31 <cmurf> ack
17:08:42 <zbyszek> ack
17:08:47 <pwhalen> ack
17:08:56 <lruzicka> ack
17:09:00 <Southern_Gentlem> ack
17:09:40 <bcotton_> #agreed 1880778 - AcceptedFreezeException (Beta) - This conflict breaks upgrades, so we should include a fix if available
17:10:03 <bcotton_> #topic (1880776) file conflict between f32-backgrounds-mate and f33-backgrounds-mate
17:10:05 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880776
17:10:06 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/113
17:10:08 <bcotton_> #info Proposed Freeze Exceptions, mate-desktop, NEW
17:10:12 <Southern_Gentlem> (not seeing that breakage yet in my upgrade )
17:10:32 <Southern_Gentlem> +1 bfe
17:10:43 <cmurf> betafe +1
17:10:51 <lruzicka> +1 fe
17:11:07 <bcotton_> +1 fe
17:11:09 <kparal> looks like a legit bug
17:11:16 <kparal> +1 beta FE I guess
17:12:10 <bcotton_> proposed #agreed 1880776 - AcceptedFreezeException (Beta) - This conflict breaks upgrades, so we should include a fix if available
17:12:37 <kparal> this might have been a repo issue, but an FE won't hurt
17:12:39 <kparal> ack
17:12:51 <cmurf> ack
17:13:04 <lruzicka> ack
17:13:28 <cmurf> mate folks did ask for that, right?
17:13:47 <kparal> they didn't ask for a FE
17:13:54 <zbyszek> I asked for FE.
17:14:15 <bcotton_> #agreed 1880776 - AcceptedFreezeException (Beta) - This conflict breaks upgrades, so we should include a fix if available
17:14:33 <bcotton_> #topic (1880769) mock in F33 has lower version than in F32, breaks upgrade to F33
17:14:34 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880769
17:14:36 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/109
17:14:37 <bcotton_> #info Proposed Freeze Exceptions, mock, MODIFIED
17:15:07 <kparal> this is a similar issue to the fedmsg
17:15:20 <kparal> this will not break the upgrade
17:15:22 <cmurf> -1 Beta FE
17:15:34 <kparal> so unless it breaks mock for some reason, I think this should be -1 FE
17:15:46 <bcotton_> -1 FE
17:16:06 <Southern_Gentlem> -1 fe
17:16:51 <lruzicka> -1 fe
17:17:54 <pwhalen> -1 Beta FE
17:17:58 <zbyszek> So we're downgrading from mock 2.6 to 2.4... but I understand why everybody is against.
17:18:26 <kparal> we'd need to freeze F32 to prevent this
17:18:45 <kparal> today we'll grant FE and tomorrow there will be 2.6.1
17:18:49 <bcotton_> proposed #agreed 1880769 - RejectedFreezeException (Beta) - This can be fixed in a 0-day update and does not negatively impact the Live experience
17:19:40 <kparal> ack
17:19:44 <cmurf> ack
17:19:45 <zbyszek> ack
17:20:24 <Southern_Gentlem> mock 2.6 in koji
17:20:33 <kparal> zbyszek: the downgrade will not happen if we can ensure that mirrors are up-to-date on the release day. But unfortunately that's not often the case
17:20:57 <lruzicka> ack
17:21:03 <kparal> the early adopters always have a harder time :)
17:21:38 <bcotton_> #agreed 1880769 - RejectedFreezeException (Beta) - This can be fixed in a 0-day update and does not negatively impact the Live experience
17:22:27 <bcotton_> #topic (1880596) Include Python 3.9.0rc2 in Fedora 33 Beta
17:22:29 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880596
17:22:30 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/103
17:22:32 <bcotton_> #info Proposed Freeze Exceptions, python3.9, ON_QA
17:22:49 <bcotton_> #info In ticket: BetaFE (+1, 0, -3)
17:22:56 <cmurf> BetaFE -1
17:23:03 <bcotton_> i think i've gotta be -1 too. it's pretty risky
17:23:11 <Southern_Gentlem> -1 bfe
17:23:33 <Southern_Gentlem> something else to make a slip at this point in time
17:23:34 <pwhalen> BetaFE -1
17:25:24 <bcotton_> proposed #agreed 1880596 - RejectedFreezeException (Beta) - We're already behind schedule, so it does not seem worth the risk to bring in a change to a major package
17:25:35 <lruzicka> ack
17:25:37 <cmurf> ack
17:25:44 <pwhalen> ack
17:26:00 <Southern_Gentlem> ack
17:26:05 <bcotton_> adam is rolling in his grave at my wording :-)
17:26:38 <bcotton_> #agreed 1880596 - RejectedFreezeException (Beta) - We're already behind schedule, so it does not seem worth the risk to bring in a change to a major package
17:26:53 <bcotton_> #topic (1880777) file conflict between texlive-texlive-scripts and texlive-kpathsea
17:26:55 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880777
17:26:57 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/114
17:26:58 <bcotton_> #info Proposed Freeze Exceptions, texlive-base, ASSIGNED
17:27:10 * adamw back
17:27:23 <kparal> back from the grave ;)
17:27:45 <adamw> can't keep me down
17:27:49 <kparal> so I don't know how zbyszek managed to mix fc32 and fc33 packages in one transaction
17:28:17 <kparal> but I think there's no need for explicit conflicts between these two sets of packages, because you're never supposed to mix them
17:28:22 <zbyszek> kparal: I had other conflicts which were preventing part of the upgrade from happening.
17:28:29 <adamw> what it usually means is that something wants to keep the older texlive-kpathsea around
17:28:35 <adamw> dnf could make this clearer
17:28:53 <kparal> adamw: well zbyszek used "dnf update"
17:29:05 <kparal> so my gut feeling is that this is another instance where distrosync would resolve this issue
17:29:10 <adamw> or give us a different issue :P
17:29:11 <kparal> but of course we can't be sure
17:29:24 <kparal> but on F33 this seems to be working fine
17:29:24 <cmurf> I'm not sure
17:29:35 <kparal> I haven't done a full F32->F33 upgrade to verify this
17:29:39 <adamw> but yes, the real issue here was "whatever meant dnf tried to keep the old texlive-kpathsea around". that would be worth looking into if we had the details, but apparently we don't
17:29:52 <cmurf> inclined to BetaFE -1
17:29:52 <adamw> i agree that there's no need for an explicit conflict between f32 and f33 packages here
17:30:00 <adamw> yeah, betafe -1 for that part
17:30:14 <bcotton_> -1 fe here to go along with the crowd
17:30:16 <Southern_Gentlem> -1 bfe
17:30:22 <kparal> unless we can see a clear problem in the log, I'd also give this -1
17:30:23 <zbyszek> spot said he'll add a versioned requires, I think this is good enough.
17:30:28 <cmurf> i've done one F31->F33 with dnf, and two F32->F33 one with dnf one with Software
17:30:47 <cmurf> they both worked *shrug*
17:30:59 <cmurf> upgrade test day is today too
17:31:07 <lruzicka> all my attempted upgrades worked ok, too
17:31:23 <Southern_Gentlem> my work upgrade just worked
17:31:25 <lruzicka> dnf and software
17:31:47 <bcotton_> proposed #agreed 1880777 - RejectedFreezeException (Beta) - This is caused by a mix of F32 and F33 packages and does not appear to affect default package sets.
17:32:25 <cmurf> ack
17:32:29 <Southern_Gentlem> ack
17:32:29 <pwhalen> ack
17:33:08 <zbyszek> ack
17:33:20 <Southern_Gentlem> ack
17:33:24 <kparal> ack
17:33:25 <lruzicka> ack
17:33:26 <bcotton_> #agreed 1880777 - RejectedFreezeException (Beta) - This is caused by a mix of F32 and F33 packages and does not appear to affect default package sets.
17:33:35 <bcotton_> okay!
17:33:44 <bcotton_> that's all the beta proposals
17:33:56 <bcotton_> so let's go look at the accepted beta blockers
17:34:10 <bcotton_> #topic (1878317) Can't report a crash (even with local processing) due to "Could not resolve host: retrace.fedoraproject.org"
17:34:11 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1878317
17:34:13 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/86
17:34:14 <bcotton_> #info Accepted Blocker, abrt, NEW
17:34:34 <cmurf> oh dear
17:34:39 <kparal> has anyone talked to the abrt team?
17:34:52 <bcotton_> #info msuchy says retrace server should be back online "in days"
17:34:52 <kparal> they seem to be extremely non-responsive
17:34:56 <adamw> not for the last few days
17:35:06 <adamw> msuchy kinda responds to things, but like...one thing at a time
17:35:08 <bcotton_> yeah, they have not responded to any nudges i've sent
17:35:13 <kparal> :(
17:35:13 <adamw> it's hard to get any kind of idea that they have an overview of the problem
17:35:23 <lruzicka> "in days" is pretty vague
17:35:24 <cmurf> i put it on tomorrow's workstation wg agenda but i'm not sure what the wg can do
17:35:33 <kparal> why is abrt even hardcoded to require retrace server? is that a bug, or intentional?
17:35:43 <adamw> did anyone else try removing uReport from the libreport configs and see how it behaves for them then?
17:35:57 <adamw> kparal: that's what i was explaining in my most recent comments
17:36:15 <adamw> all the report configs have uReport as the first event, and it seems like it's treated as fatal, if it fails the report doesn't proceed
17:36:20 <kparal> adamw: I did not want to hack it this way, because I might simply receive some invalid results that were caused by me doing things that were not supposed to happen
17:36:24 <adamw> uReport requires the retrace server, there is no 'local fallback' for it
17:36:47 <adamw> i mean, my hope was just taking uReport out would make it work and we could just literally do that as a packaging change
17:36:55 <adamw> but for me i still couldn't successfully report a crash after :/
17:37:08 <adamw> it just seems like this is...really broken
17:37:08 <cmurf> this particular bug is up for final blocker but beta FE?
17:37:24 <kparal> cmurf: it's accepted beta blocker
17:37:26 <adamw> it's an accepted beta blocker
17:37:33 <cmurf> oh now i see that, i missed it
17:37:50 <kparal> I also don't understand how abrt team can propose several bodhi updates where it's still completely broken
17:37:55 <adamw> and we've had bugs and issues filed for months and i don't have confidence the team is really on top of it
17:37:57 <adamw> yeah
17:38:01 <bcotton_> are we at the "bcotton starts emailing people's managers" stage of life?
17:38:16 <Southern_Gentlem> yep
17:38:25 <cmurf> I think so
17:38:33 <kparal> if they said "we can't do that for F33 (Beta), because" at least we'd know something
17:38:48 <kparal> is abrt getting killed? something else? we don't know
17:39:07 <kparal> we can drop it from Workstation in the worst case
17:39:08 <cmurf> https://pagure.io/fedora-workstation/issue/156
17:39:12 <cmurf> two months ago
17:39:16 <cmurf> ABRT is broken
17:39:18 <zbyszek> hopefully not, abrt is pretty useful to catch bugs.
17:39:27 <adamw> right, losing it would be a big loss
17:39:36 <kparal> but at the moment, it's just an extra icon on the desktop
17:39:41 <bcotton_> #action bcotton to email aries to escalate abrt bugs
17:39:42 <adamw> especially for a beta release, we kinda *want* people to run the beta and find crashes and report them
17:39:52 <Southern_Gentlem> but if it cant report what good is it
17:39:59 <kparal> I agree it would be a huge loss
17:40:07 <kparal> so we need to get some real replies
17:40:09 <adamw> but equally it seems weird to just sit around for weeks waiting for this to "get fixed" with no kind of apparent roadmap or timeline or anything
17:40:34 <bcotton_> i suppose on thursday we can decide to waive it and say "well it doesn't make our lives that much harder, really"
17:40:41 <adamw> so on that topic
17:40:48 <adamw> you're keen to do an rc and make that a possibility
17:40:53 <bcotton_> i am :-)
17:40:55 <adamw> but if we're gonna do that, should we leave abrt/libreport bits out of the rc?
17:41:05 <lruzicka> Is that ekulik somebody related to abrt, do you know?
17:41:07 <cmurf> yeah this is the conversation
17:41:11 <adamw> or leave them in in the hopes the retrace server coming up will magically solve everything?
17:41:24 <adamw> lruzicka: name rings a bell
17:41:28 <cmurf> if it's waive it off then it's not really beta blocking material
17:41:34 <Southern_Gentlem> what are the chances retrace will be back
17:41:51 <bcotton_> if we leave it in, it can get fixed by retrace being back or subsequent updates
17:41:55 <adamw> lruzicka: yeah, he is
17:41:59 <adamw> https://github.com/ernestask
17:42:04 <lruzicka> because the last comment in that issue says things work for him/her, but I it has not worked me a single time since branch
17:42:07 <bcotton_> if we pull it, then it won't get installed later when it works
17:42:08 <cmurf> i thought retrace was supposed to be back this week
17:42:10 <cmurf> or last week
17:42:34 <lruzicka> sorry for my typos
17:42:44 <bcotton_> so i'd lean toward including it with the understanding that it's not currently useful
17:42:47 <kparal> btw, the current abrt update in bodhi should probably be pushed stable, at least some issues seem fixed in there
17:42:49 <adamw> three weeks ago nirik said msuchy would "look at finishing the deployment"
17:42:50 <cmurf> but it's not just a matter of restoring it, i think it's a new configuration (?) so I don't know if we can count on it
17:42:54 <adamw> i pinged him four days ago
17:42:55 <adamw> nothing
17:43:02 <adamw> https://pagure.io/fedora-infrastructure/issue/9060 is the retrace server ticket
17:43:23 <bcotton_> i asked him in #fedora-meeting this morning and he said it would be on the order of days
17:43:28 <bcotton_> err #fedora-admin
17:43:34 <lruzicka> is he at work? might be ill or pto
17:43:50 <bcotton_> well, he said he hopes it would be in days
17:44:36 * nirik notes there was that thing about it getting renamed... so that seems to point to it not going away.
17:45:25 <adamw> i mean, there's commits and builds happening and stuff
17:45:30 <adamw> it's not like it's *dead*
17:45:46 <adamw> we just don't seem to be getting any clear overview of what the roadmap is or anything
17:46:28 <nirik> https://abrt.github.io/2020/09/09/abrt-new-name/
17:47:06 <bcotton_> does anyone want to disagree with me about leaving broken abrt in the RC?
17:47:38 <adamw> no, that seems a reasonable call
17:47:54 <bcotton_> "dear diary, today i was reasonable"
17:48:04 <kparal> as a last resort, yes
17:48:10 <kparal> oh, in RC
17:48:14 <Southern_Gentlem> bcotton_, its appears that is what is needed
17:48:14 <kparal> yeah, I guess
17:48:24 <zbyszek> Leaving it as is seems better than delaying beta.
17:48:44 <kparal> so let's make sure the latest abrt update is pushed stable
17:48:54 <adamw> okay, can do that
17:48:57 <adamw> it may need karma
17:49:20 <bcotton_> #action adamw to include latest abrt update in the next batch of F33 stable push requests
17:49:49 <kparal> adamw: it should have enough
17:49:52 <bcotton_> are we ready to move on?
17:49:55 <adamw> yeah
17:50:11 <bcotton_> #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one)
17:50:12 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700
17:50:14 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/16
17:50:15 <bcotton_> #info Accepted Blocker, dbus-broker, ON_QA
17:50:19 <bcotton_> speaking of bugs i'm going to argue in favor of waiving :-)
17:50:55 <kparal> I guess both the abrt and this one can be marked as "hard to fix bugs"?
17:51:03 <kparal> which would make them a blocker for Final
17:51:26 <bcotton_> yeah, although i'm not hopeful for this one being fixed for final either :/
17:51:28 <kparal> in both cases the issue seems to be with the development team resources
17:51:47 <adamw> kparal: you found that the systemd kill user processes hammer doesn't help here, right?
17:51:54 <adamw> odd that it doesn't, but...
17:51:54 <kparal> bcotton_: in that case we'll either need to re-evaluate our criteria or KDE blocker status
17:52:08 <kparal> adamw: it changes the behavior, doesn't help
17:52:35 <cmurf> so something is lingering?
17:52:41 <cmurf> i think that's explicit isn't it?
17:52:43 <adamw> and systemd can't or won't kill it, i guess?
17:53:03 <cmurf> suggests linger was requested when it was launched
17:53:37 <cmurf> or it's exempt from being killed
17:53:56 <kparal> I didn't really have time to debug this too much, but others seemed to provide the necessary logs and output
17:53:57 <cmurf> the only thing i'm aware of that's exempt from systemd killing it off is plymouth
17:54:04 <cmurf> what happens if plymouth is removed
17:54:15 <kparal> and I'm not sure I understand the process lingering etc enough to provide more useful info here
17:55:01 <bcotton_> do we even know what component is actually to blame at this point? my understanding is that it may not actually be dbus either
17:55:12 <adamw> no we're pretty sure it's not dbus at this point, i think
17:55:19 <adamw> we should probably assign it back to something kde-y
17:55:24 <kparal> yep
17:55:29 <adamw> people tried using dbus-daemon and it still behaved the same
17:55:49 <bcotton_> yeah, which makes me worried that we won't have any Red Hat developers to throw at it :-(
17:56:56 <bcotton_> at least when it's something in RHEL, i'm 2-3 hours away from escalating it to Mike McGrath's doorstep :-)
17:57:23 <zbyszek> bcotton_: then the solution is simple. Make KDE-wayland the default RHEL9 desktop ;)
17:57:30 <bcotton_> :-)
17:57:32 <adamw> so i guess the plan here is, cut an RC, consider waiving this at go/no-go?
17:57:46 <bcotton_> adamw: yeah, i think that's the best we can do at this poitn
17:58:08 <adamw> and maybe start a discussion about whether it's feasible to keep blocking on KDE if a bug like this can't get fixed
17:58:18 <zbyszek> I'll try to look into the bug too.
17:58:25 <bcotton_> zbyszek++
17:58:28 <cmurf> adamw: agreed
17:58:29 <adamw> thanks zbyszek
17:58:34 <bcotton_> adamw: i'll let you kick that hornet's nest ;-)
17:58:41 <adamw> one thing i do wonder is
17:59:01 <adamw> does this bug happen in a more realistic scenario where you don't just keep logging in and out repeatedly but like say at least 10-15 mins apart?
17:59:13 <bcotton_> but speaking as a KDE Spin user, I have to agree that it's something we should at least talk about
17:59:22 <adamw> because i don't think in a real world situation people just log in and out and in and out and in and out like that
18:00:23 <kparal> I think I tried waiting for a bit
18:00:30 * kparal looking in the bug
18:00:30 <bcotton_> i've seen something like this in the past but i don't know if it's the same or just similar
18:00:39 <kparal> it also has some dupes
18:00:43 <cmurf> curious what loginctl says about what session+scope+slices still remain after logout
18:00:59 <bcotton_> and now the machine i'd use to test it is kaput. i can try it on my f32 machine
18:01:53 <cmurf> dual boot is getting a bit less clunky and space inefficient when on btrfs :)
18:02:35 <cmurf> i'm not sure we ever get a release criterion for dual boot, but if we can more easily do side by side installs on baremetal, makes it less of a disincentive to do such testing
18:02:46 <kparal> I'd argue that I log out and log in immediately quite often
18:02:53 <kparal> every time something breaks in my desktop
18:03:06 <kparal> also when changing users between my wife and I
18:03:21 <kparal> when I assigned myself to a new group
18:03:35 <kparal> when new gnome extensions updates are available (doesn't apply here)
18:03:36 <kparal> etc
18:03:52 <cmurf> so it's strictly log out user A, log in user B - not a user switching issue?
18:04:03 <kparal> cmurf: KDE disabled user switching
18:04:10 <kparal> so yes, just log in log out
18:04:32 * kparal going partially afk, baby is crying
18:04:35 <adamw> kparal: fair argument, i guess
18:04:39 <adamw> anyway, we have a plan...
18:04:42 <adamw> next bug?
18:04:54 <bcotton_> sounds good
18:04:56 <bcotton_> #topic (1860616) abrt-server errors when processing zstd compressed core dumps produced by systemd-246~rc1-1.fc33
18:04:58 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1860616
18:05:00 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/15
18:05:01 <bcotton_> #info Accepted Blocker, libreport, VERIFIED
18:05:21 <cmurf> surely this is fixed by now
18:05:27 <bcotton_> so this one is verified but also causes another problem
18:05:36 <cmurf> ok
18:06:03 <cmurf> doh!
18:06:15 <adamw> yeah, so not much to say here, just we may as well push the update
18:06:26 <bcotton_> #info FEDORA-2020-444a3363f0 fixes this bug and causes bug 1878317
18:06:32 <cmurf> so that 'another problem' is the bug i filed about local processing
18:06:50 <cmurf> oh boy
18:06:59 <bcotton_> yeah, i think this falls under the "let's push what we have and see if we can fix it later" plan :/
18:07:34 <cmurf> that does seem realistic
18:07:37 <bcotton_> anything else to add?
18:08:00 <adamw> i'm not sure this "causes" 1878317, more it just "reveals" it by letting us reach that stage
18:08:01 <adamw> but hey
18:08:19 <zbyszek> "makes possible" ?
18:08:22 <zbyszek> "enables" ?
18:08:23 <cmurf> so what's the process, ask for an RC despite the blockers?
18:08:23 <bcotton_> now you're getting philosophical
18:08:39 <bcotton_> cmurf: yep. we can choose to waive blockers, but we can't do that without an RC
18:08:47 <bcotton_> or we can, but there's no point
18:08:50 <cmurf> got it
18:08:52 <bcotton_> #topic (1873029) bugs can't be reported: "No matching actions found for this event"
18:08:53 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1873029
18:08:55 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/45
18:08:56 <bcotton_> #info Accepted Blocker, libreport, VERIFIED
18:09:01 <adamw> this is same as the previous
18:09:28 <bcotton_> #info FEDORA-2020-444a3363f0 fixes this bug and *reveals* bug 1878317
18:09:55 <bcotton_> and that covers the accepted beta blockers
18:10:36 <bcotton_> anybody up for looking at the proposed final blockers or are we all blockered out for one day?
18:11:55 <cmurf> they look more straightforward
18:12:09 <cmurf> i'm ok either way
18:12:26 <adamw> we can do 'em i guess
18:12:38 <bcotton_> that's the spirit!
18:13:21 <bcotton_> so the first one we already accepted
18:13:33 <bcotton_> #topic (1880833) Massive memory leak on AMD cards
18:13:35 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880833
18:13:36 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/116
18:13:38 <bcotton_> #info Proposed Blocker, mesa, NEW
18:13:51 <bcotton_> #info In ticket: FinalBlocker (+1, 0, -0)
18:13:53 <zbyszek> I think we need more info here.
18:14:04 <zbyszek> It's not clear how specific this at this point.
18:14:22 <zbyszek> this=thisis=this is
18:14:36 <cmurf> punt need more info
18:14:56 <adamw> massive, huh?!
18:14:58 <bcotton_> yeah, this seems puntable
18:15:22 <cmurf> it'd be helpful to get some info from mesa people on how to debug/narrow it down
18:15:55 <adamw> yeah, +1 punt
18:16:01 <kparal> +1 punt
18:16:01 <lruzicka> +1 punt
18:16:19 <kparal> it might be specific to integrated AMD GPUs
18:16:27 <kparal> which would still be quite bad
18:16:29 <cmurf> could be kernel regression
18:16:30 <kparal> but we don't know
18:16:41 <kparal> that as well
18:16:42 <cmurf> that's easier to test than mesa regression
18:16:55 <kparal> cmurf: can you ask Daniel to test that please?
18:17:08 <cmurf> yas
18:17:08 <bcotton_> proposed #agreed 1880833 - Defer decision (punt) - The scope of affected hardware is unclear at this point, so we don't have enough information to make a decision yet
18:17:13 <kparal> thanks
18:17:36 <kparal> ack
18:17:46 <lruzicka> ack
18:18:11 <adamw> ack
18:18:59 <bcotton_> #agreed 1880833 - Defer decision (punt) - The scope of affected hardware is unclear at this point, so we don't have enough information to make a decision yet
18:19:17 <bcotton_> #topic (1876162) anaconda storage configuration is extremely slow with an existing btrfs filesystem containing hundreds of snapshots
18:19:18 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1876162
18:19:20 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/64
18:19:21 <bcotton_> #info Proposed Blocker, python-blivet, ON_QA
18:19:24 <adamw> cmurf's baby
18:19:42 <cmurf> punt until it's tested or close it since we have a tentative fix pulled in for beta?
18:19:53 <bcotton_> #info This is an accepted Beta FE
18:20:01 <cmurf> tested ^more widely
18:20:12 <bcotton_> i'm fine with voting on it now
18:20:22 <bcotton_> that way if it pops back up, it's already a blocker
18:21:05 <adamw> cmurf: did you manage to do any more 'real world-y' testing on it?
18:21:39 <bcotton_> #info Last time, on Fedora Blocker Review: The decision to delay the classification of this as a blocker bug was made as we would like more evaluation from anaconda team and also testing with a real-world case (not identical snapshots) to figure out what's really plausible in an f33 timeframe before voting on this.
18:21:50 <cmurf> no
18:22:03 <cmurf> the real world aspects relate to the mount/umount loops, not udev
18:22:10 <bcotton_> so re-punt for the same reason?
18:22:18 <adamw> i guess
18:22:21 <zbyszek> +1 to punt
18:22:22 <cmurf> the udev stuff i don't totally understand what problems could come up, to try and poke it
18:22:32 <adamw> the update is submitted for stable soooo i guess we're pulling it into the rc and strapping on our hope pants
18:22:37 <cmurf> i think adding and removing devices might trigger issues, if there are any
18:22:55 <Southern_Gentlem> +1 punt
18:22:58 <bcotton_> proposed #agreed 1876162 - Delay decision (punt) - We would like more evaluation from anaconda team and also testing with a real-world case (not identical snapshots) to figure out what's really plausible in an f33 timeframe before voting on this
18:22:59 <cmurf> yeah the devil we know vs the devil we don't
18:23:14 <bcotton_> if we have to wear pants, we might as well wear hope pants
18:23:32 <cmurf> hope pants
18:23:40 <cmurf> is this Canadian slang?
18:23:53 <adamw> it's me slang
18:24:09 <adamw> i'm one of a kind
18:24:36 <cmurf> wishful thinking pants? haha
18:25:51 <adamw> oh, ack, btw
18:25:59 <cmurf> ack
18:26:07 <cmurf> ack pants
18:26:09 <bcotton_> that's good enough for me
18:26:16 <bcotton_> #agreed 1876162 - Delay decision (punt) - We would like more evaluation from anaconda team and also testing with a real-world case (not identical snapshots) to figure out what's really plausible in an f33 timeframe before voting on this
18:26:37 <bcotton_> #topic (1870476) Google Account doesn't work during initial setup
18:26:39 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1870476
18:26:41 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/38
18:26:42 <bcotton_> #info Proposed Blocker, selinux-policy, VERIFIED
18:27:05 <cmurf> clear +1 final blocker due to our new criterion
18:27:16 <cmurf> tailor made
18:27:42 <bcotton_> which one is that?
18:28:01 <cmurf> initial setup functionality
18:28:25 <adamw> yeah
18:28:26 <adamw> so +1
18:28:33 <bcotton_> this one: https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#First_boot_experience
18:28:36 <bcotton_> yeah +1
18:29:32 <lruzicka> +1
18:30:17 <kparal> +1 blocker
18:30:21 <bcotton_> proposed #agreed 1870476 - AcceptedBlocker (Final) - Violates First Boot Experience: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test.
18:30:26 <kparal> ack
18:30:37 <zbyszek> ack
18:30:41 <adamw> ack
18:30:43 <bcotton_> (will also include the trailing " )
18:30:45 <cmurf> ack
18:31:07 <bcotton_> #agreed 1870476 - AcceptedBlocker (Final) - Violates First Boot Experience: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test. "
18:31:22 <bcotton_> #topic (1880752) Documents preview doesn't work with Nautilus
18:31:24 <bcotton_> #link https://bugzilla.redhat.com/show_bug.cgi?id=1880752
18:31:25 <bcotton_> #link https://pagure.io/fedora-qa/blocker-review/issue/107
18:31:27 <bcotton_> #info Proposed Blocker, sushi, NEW
18:31:32 <cmurf> last one!
18:31:37 <bcotton_> #info In ticket: FinalBlocker (+3, 0, -1)
18:32:12 <cmurf> yep +1 for me too
18:32:16 <cmurf> (1) it's a regression
18:32:18 <bcotton_> kparal and lruzicka argue that this is not "basic" functionality. i'm potentially convinced by that
18:32:47 <lruzicka> yeah, this does not affect file manipulation in any way
18:32:54 <cmurf> (2) workstation wg have wanted more polish for what it basic
18:33:08 <adamw> i think kparal makes a reasonable point in the ticket
18:33:09 <cmurf> i.e. basic functionality isn't minimal funtionality
18:33:35 <cmurf> s/it/is/
18:33:36 <lruzicka> cmurf, I agree and I would not want anything less than a proper definition of what basic is
18:33:51 <adamw> it seems pretty hard to define
18:33:53 <cmurf> we can ask this question and punt
18:33:56 <lruzicka> cmurf, but even I, the usual blockery guy, think this is not basic.
18:34:01 <cmurf> and i'll ask WG folks tomorrow
18:34:09 <adamw> i mean
18:34:12 <cmurf> ordinarily i agree
18:34:18 <adamw> it doesn't need to be a blocker for them to *fix* it :)
18:34:32 <cmurf> true and there's plenty of lead time
18:34:54 <zbyszek> I'd lean -1 blocker.
18:34:54 <bcotton_> i'm open to punting until the Workstation WG gives us a clearer definition of what they consider "basic"
18:35:12 <lruzicka> fine, we can wait :D
18:35:25 <bcotton_> as it stands, i think i'd change to -1 based on my current understanding
18:36:20 <bcotton_> proposed #agreed 1880752 - Defer decision (punt) - We lack a common understanding of what "basic" functionality entails. Workstation WG would like to raise the bar, so we will wait to make a decision until they decide what "basic" means
18:37:06 <kparal> that's a good idea, relaying the "basic functionality" decision to a particular WG every time. Makes our life easier :-)
18:37:20 <kparal> ack
18:37:24 <zbyszek> ack
18:37:40 <lruzicka> cmurf, could you also define at the WG meeting what are the crucial application for Workstation and what is their expected behaviour? thanks
18:38:07 <lruzicka> cmurf, I would like to start working on some automation for application and I'd need inspiration.
18:38:09 <kparal> cmurf: yes, please define basic functionality for all Workstation apps :P
18:38:14 <cmurf> lruzicka: could you file a workstation ticket for that?
18:38:24 <bcotton_> and also KDE apps, just to be clear ;-)
18:38:26 <cmurf> and then i can schedule it for an upcoming meeting
18:38:29 <lruzicka> cmurf, sure, I will do it tomorrow morning.
18:38:34 <cmurf> thanks
18:38:52 <lruzicka> cmurf, ok in Bugzilla?
18:40:10 <bcotton_> any other acks/nacks/or snacks on my proposal?
18:40:48 <adamw> ack
18:40:54 <bcotton_> #agreed 1880752 - Defer decision (punt) - We lack a common understanding of what "basic" functionality entails. Workstation WG would like to raise the bar, so we will wait to make a decision until they decide what "basic" means
18:40:58 <bcotton_> okay, we did it!
18:41:12 <bcotton_> #topic Open floor
18:41:22 <bcotton_> anything we missed and/or need to discuss related to blockers?
18:42:04 <cmurf> whew!
18:42:11 <zbyszek> FWIW, I was surprised how smoothly the upgrade to F33 went. We are getting quite good at listing all packages in fedora-obsolete-packages that should be listed there.
18:42:30 <coremodule> bcotton, Please give me a few hours to get all this secretarialized, I have an appointment in 30 minutes so will need a bit longer than usual.
18:42:37 <bcotton_> coremodule: ack
18:42:39 <coremodule> but it will get done!
18:42:54 <bcotton_> we gave you a nice, long list of things to secretarialize this week
18:42:56 <lruzicka> I must go, thank you and have a good day.
18:43:09 <bcotton_> okay, sounds like it's time to #endmeeting
18:43:12 <kparal> zbyszek: even considering you were using the unsupported method ;-)
18:43:15 <bcotton_> thanks for your time everyone
18:43:28 <bcotton_> hopefully next week we'll only be talking about F33 Final :-D
18:43:37 <zbyszek> kparal: when the supported method yields no bugs, it's time to try something different!
18:43:51 <adamw> thanks a lot for running the meeting bcotton
18:43:53 <bcotton_> #endmeeting