16:02:41 <coremodule> #startmeeting F33-blocker-review
16:02:41 <zodbot> Meeting started Mon Aug  3 16:02:41 2020 UTC.
16:02:41 <zodbot> This meeting is logged and archived in a public location.
16:02:41 <zodbot> The chair is coremodule. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:41 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:02:41 <coremodule> #meetingname F33-blocker-review
16:02:41 <coremodule> #topic Roll Call
16:02:41 <zodbot> The meeting name has been set to 'f33-blocker-review'
16:02:54 <coremodule> good morning/afternoon/evening!
16:03:04 * kparal is here
16:03:06 <coremodule> who's here?
16:03:44 * cmurf is in the ether
16:05:49 <coremodule> we'll wait a few more minutes for others...
16:08:57 <coremodule> welllllll.... let's see if we can power through this, there's only four
16:09:04 <coremodule> #chair kparal cmurf
16:09:04 <zodbot> Current chairs: cmurf coremodule kparal
16:09:15 <coremodule> #topic Introduction
16:09:16 <coremodule> Why are we here?
16:09:16 <coremodule> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:09:16 <coremodule> #info We'll be following the process outlined at:
16:09:16 <coremodule> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:17 <coremodule> #info The bugs up for review today are available at:
16:09:19 <coremodule> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:21 <coremodule> #info The criteria for release blocking bugs can be found at:
16:09:23 <coremodule> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:09:25 <coremodule> #link https://fedoraproject.org/wiki/Fedora_33_Beta_Release_Criteria
16:09:27 <coremodule> #link https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria
16:09:29 <coremodule> #topic proposed Beta Blockers
16:09:37 <coremodule> #topic (1830343) Network manager started stuck when I tries connecting to VPN (openconnect)  after upgrade gnome-shell to 3.37.1-1.fc33 version
16:09:38 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1830343
16:09:38 <coremodule> #info Proposed Blocker, gnome-shell, NEW
16:09:50 <kparal> who's the fourth one?
16:10:07 <kparal> ah, four bugs
16:10:14 <kparal> not four people :)
16:10:23 <coremodule> yes, haha :)
16:10:43 <kparal> we are pretty low on staff, I wonder if we should continue or reschedule?
16:11:04 <kparal> do we even have cmurf? in the ether doesn't sound like being here :-)
16:12:02 <cmurf> yes
16:12:17 <kparal> the minimum number of participants is I believe 3, so if we have cmurf, we can technically vote. But perhaps we should vote on just stuff that we can all easily agree on :)
16:12:20 <cmurf> sorry distracted by a small coffee incident
16:12:21 <coremodule> let's continue. there's only four bugs, and it only takes three to make quorum.
16:13:47 <cmurf> i think we're in the same boat here yes?
16:14:28 <coremodule> cmurf, as far as what?
16:14:31 <cmurf> this bug
16:14:37 <cmurf> we're still trying to get a reproducer
16:14:40 <cmurf> it isn't good
16:14:53 <kparal> punt from me
16:15:02 <cmurf> no explicit criterion but maybe it's doable to say VPN stuff is basic functionality these days
16:15:31 <coremodule> yeah, i can see the reasoning for blocker status.
16:15:32 <cmurf> yeah punt
16:15:35 <coremodule> I'm okay with punt
16:15:38 <kparal> well we have a criterion for main panel not working properly, and this is a part of it
16:15:39 <cmurf> if we can get a reproducer i'm +1 block
16:15:51 <kparal> and also it's part of gnome-control-center, which is under default app functionality
16:15:55 <kparal> but still punt from me
16:16:00 <cmurf> yep
16:17:20 <coremodule> proposed #agreed 1830343 - While we believe this could be a potential blocker violating the "basic functionality" criterion, the lack of testing and reproducability has us skeptical for now. We'll punt for now for further testing.
16:17:37 <coremodule> patch
16:17:47 <coremodule> proposed #agreed 1830343 - While we believe this could be a potential blocker violating the "basic functionality" criterion, the lack of testing and reproducability has us skeptical for now. We'll punt for further testing.
16:18:04 <kparal> ack
16:18:43 <coremodule> #agreed 1830343 - punt - While we believe this could be a potential blocker violating the "basic functionality" criterion, the lack of testing and reproducability has us skeptical for now. We'll punt for further testing.
16:19:01 <kparal> you could have waited for cmurf...
16:19:02 <coremodule> ^ack that one kparal . I messed it up twice, do'h :)
16:19:12 <cmurf> ack
16:19:14 <cmurf> haha
16:19:16 <coremodule> dangit, I did not mean to do that
16:19:18 <cmurf> i'm distracted
16:19:20 <coremodule> #undo
16:19:20 <zodbot> Removing item from minutes: AGREED by coremodule at 16:18:43 : 1830343 - punt - While we believe this could be a potential blocker violating the "basic functionality" criterion, the lack of testing and reproducability has us skeptical for now. We'll punt for further testing.
16:19:29 <coremodule> proposed #agreed 1830343 - While we believe this could be a potential blocker violating the "basic functionality" criterion, the lack of testing and reproducability has us skeptical for now. We'll punt for further testing.
16:19:32 <coremodule> nope
16:19:32 <kparal> that's fine, we acked it :)
16:19:34 <coremodule> dont ack that
16:19:44 <coremodule> #agreed 1830343 - punt - While we believe this could be a potential blocker violating the "basic functionality" criterion, the lack of testing and reproducability has us skeptical for now. We'll punt for further testing.
16:19:48 <coremodule> son of a...
16:19:54 <cmurf> rofl
16:19:57 <kparal> :D
16:20:13 <coremodule> okay! moving on. the one that was "ack"ed was wrong, and the one in my clipboard didn't have the "proposed" ahead of it
16:20:16 <coremodule> alright!
16:20:21 <coremodule> #topic (1860616) abrt-server errors when processing zstd compressed core dumps produced by systemd-246~rc1-1.fc33
16:20:22 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1860616
16:20:22 <coremodule> #info Proposed Blocker, libreport, NEW
16:20:43 <kparal> I'll suggest this should be a Beta blocker
16:21:11 <kparal> if you don't agree, Final blocker is a no-brainer I think
16:21:29 <coremodule> is this a regression?
16:21:44 <coremodule> or intentional?
16:21:44 <bcotton> +1 beta blocker
16:21:57 <cmurf> it's intentional
16:22:08 <cmurf> but maybe there wasn't communication with abrt folks that this was going to change
16:22:17 <kparal> well the systemd change is intentional
16:22:20 <cmurf> looks like they have a fix
16:22:22 <kparal> the abrt behavior is a regression
16:24:06 <cmurf> yeah it can't handle anything except lzma and lz4
16:24:30 <cmurf> so the PR gets it using a different library so it can handle these other compression types including zstd
16:24:37 <cmurf> so yeah +1 blocker
16:26:54 <coremodule> proposed #agreed 1860616 - AcceptedBlocker (Beta) - Violates "Bug hinders execution of required Beta test plans or dramatically reduces test coverage". The impact of this bug could leave users with no ability to automatically report bugs, which would reduce the amount of testing coverage. As such, we find it warrants blocker status.
16:27:23 <kparal> ack
16:27:33 <cmurf> ack
16:27:39 <kparal> coremodule: you should also vote
16:28:06 <coremodule> we have three, kparal, bcotton, cmurf, so that's good enough :)
16:28:25 <kparal> oh bcotton I didn't see you, welcome! :)
16:28:58 <kparal> coremodule: it's still helpful if you vote, esp. since we're low on attendance
16:29:00 <kparal> just saying
16:29:19 <coremodule> ack
16:29:20 <coremodule> #agreed 1860616 - AcceptedBlocker (Beta) - Violates "Bug hinders execution of required Beta test plans or dramatically reduces test coverage". The impact of this bug could leave users with no ability to automatically report bugs, which would reduce the amount of testing coverage. As such, we find it warrants blocker status.
16:29:31 <coremodule> #topic (1861700) login stuck when changing users repeatedly (log out, log in a different one)
16:29:31 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1861700
16:29:31 <coremodule> #info Proposed Blocker, sddm, NEW
16:29:43 <bcotton> kparal: i snuck in late. someone didn't include me in the ping and i assumed we were skipping this week :-)
16:29:57 <kparal> .fire someone
16:29:57 <zodbot> adamw fires someone
16:30:06 <coremodule> oh sheesh
16:30:30 <coremodule> I *did* send mail to the test-announce list, but I never received a copy of my own message, so maybe it didn't go out?
16:30:37 <kparal> it did
16:30:56 <cmurf> i saw it
16:31:08 <cmurf> re: this bug...
16:31:22 <kparal> in this bug, we're in a hillarious situation where our switch user criterion is now much better than our standard log in criterion, when taken literally
16:31:25 <cmurf> on the one hand we have a criterion that says we block on user switching bugs
16:31:45 <cmurf> on the other hand we're not exactly sure why it happens, what to blame, therefore what to block on fixing
16:32:05 <kparal> well it works in gnome, so it's a problem somewhere in KDE
16:32:16 <cmurf> i'm not sure the requirement is that we isolate the exact nature of the bug
16:32:33 <kparal> no it isn't
16:33:05 <bcotton> yeah, this feels like a "call it a blocker and then except it later if we can't get it fixed" kind of bug
16:33:18 <kparal> perhaps there's a more fitting criterion somewhere than comment 5, adamw would know for sure :)
16:33:36 <kparal> bcotton: right
16:33:41 <cmurf> +1 beta blocker
16:33:52 <coremodule> don't we have criteria specific to user switching?
16:33:59 <kparal> coremodule: this is not switching
16:34:03 <kparal> just log in log out log in
16:34:10 <kparal> that's the fun part
16:34:13 <cmurf> oh
16:34:15 <cmurf> right
16:34:24 <kparal> and the existing criterion can be understand just to talk about the first user logging in
16:34:25 <cmurf> so it's even more basic
16:34:26 <bcotton> kparal: is this new? i feel like i've seen something similar in previous releases, but i was never bothered enough to debug it
16:34:31 <cmurf> ahhh
16:34:39 <cmurf> now i'm back on the fence
16:34:51 <kparal> bcotton: I don't know, I wanted to report user switching bugs, and found out that just standard log in is broken as well
16:35:09 <cmurf> what happens if you delay between 1 - 2 - 1
16:35:14 <cmurf> like, 2 minutes between each
16:35:17 <bcotton> kparal: does this happen if you log in/log out with a single user (i'm going to guess no, but it's worth asking)
16:35:19 <kparal> cmurf: I don't care :)
16:35:24 <kparal> I can surely debug that
16:35:30 <kparal> but I don't care for the purpose of voting
16:35:44 <kparal> bcotton: with a single user it works fine
16:36:04 <cmurf> but you can't log back into user 1
16:36:13 <cmurf> ever? you have to reboot?
16:36:24 <kparal> this is way too typical use case, "let me check email and I'll give you the laptop back"
16:36:33 <cmurf> yeah that would be step 8
16:36:45 <kparal> cmurf: well, you see just a black screen, so unless you're power user, you can only hard reset
16:36:52 <cmurf> ask described it seems like basic functionality to me, of course you should be able to log in without rebooting or hanging
16:37:00 <cmurf> that seems bad
16:37:18 <bcotton> if it's the same thing i saw, you can log in from a tty and `kill -9` the offending processes, but that's not very friendly
16:37:28 <coremodule> maybe this is the catalyst to kick-off some talks regarding multi-user blocker criteria?
16:37:53 <kparal> shrug. we can use the existing one, or if you don't want to, we can rephrase the existing one (or add new ones)
16:37:53 <cmurf> I'd say +1 beta blocker and also kick off multi user blocker criteria to make it more clear
16:38:00 <kparal> but either way, I think this should be a blocker
16:38:06 <coremodule> because as it stands, it's bad, but we also don't have the best criteria to cover this
16:38:12 <coremodule> I mean, not specifically anyway
16:38:15 <kparal> we can also punt a week to have more people to discuss this
16:38:46 <kparal> coremodule: I choose the understand the existing criterion as "every login attempt must work"
16:38:57 <cmurf> i'd say it's more of a basic functionality criterion at the moment because the cited criterion is narrow
16:39:11 <kparal> cmurf: but that's only defined for apps
16:39:53 <cmurf> right
16:40:02 <cmurf> so we need a new or modified criterion
16:40:11 <coremodule> I don't think the listed criterion is applicable to this case... It *is* possible to login to a working desktop on first boot...
16:40:28 <kparal> coremodule: it's not just on first boot
16:40:33 <kparal> you're not reading it right
16:40:59 <kparal> and if you follow the steps, you end up in a state where it *isn't* possible to log in with that user
16:41:07 <cmurf> it's true
16:41:19 <coremodule> "...must boot to a log in screen..." <--- implies that the system just "boot"ed
16:41:31 <kparal> you create user1 in anaconda, then create user2 in system. reboot. log in user 1, log out, log in user 2, log out, and now the criterion is violated
16:41:37 <cmurf> but it's oddy worded as i think about it, if user 2 was created *other* than by first boot utility, and this same behavior happened, it would not be a blocker? :D
16:41:47 <cmurf> i think you're right
16:41:48 <kparal> coremodule: I don't think that is implied by that
16:41:52 <coremodule> When you log out of an account, it's not called a "boot"
16:42:27 <coremodule> then the criterion is dubious and needs to be specified. Any way we cut this, I think we have a criteria issue
16:42:40 <cmurf> yes
16:43:04 <kparal> coremodule: when you log out, it's still the same screen you booted into during the initial boot, so...
16:43:15 <kparal> yes, rewording is needed, or a new one, possibly both
16:43:16 <cmurf> it's a bad bug and we're basically looking for a rationale to take it as a blocker, but this is a bit square peg in round hole to use this particular criterion
16:43:20 <cmurf> criterion refinement needed
16:43:53 <coremodule> I am +1 punt for time to refine/redefine the criteria
16:43:58 <cmurf> +1 punt
16:44:05 <kparal> any volunteers for proposing the wording change, or is it me? :)
16:44:13 <coremodule> I am also +1 blocker.... if we can find something that it violates lol
16:44:19 <coremodule> I'll do it kparal if you don't want to
16:44:25 <kparal> coremodule++
16:44:25 <zodbot> kparal: Karma for coremodule changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:44:33 <cmurf> haha
16:44:35 <bcotton> coremodule++
16:44:35 <zodbot> bcotton: Karma for coremodule changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:44:38 <coremodule> yay
16:44:40 <coremodule> yay!
16:44:46 <cmurf> coremodule++
16:44:46 <zodbot> cmurf: Karma for coremodule changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:44:50 <coremodule> YAY!
16:44:51 <kparal> awesome, I love somebody else doing all the work, thanks ;)
16:44:51 <cmurf> kparal++
16:44:51 <zodbot> cmurf: Karma for kparal changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:45:01 <cmurf> bcotton++
16:45:01 <zodbot> cmurf: Karma for bcotton changed to 26 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:45:06 <cmurf> might as well hand out all the cookies
16:45:15 <kparal> so, punt
16:45:18 <bcotton> 🎼It's raining cookies! Hallelujia it's raining cookies🎶
16:45:24 <bcotton> i can +1 punting
16:46:40 <coremodule> proposed #agreed 1861700 - punt – We acknowledge that this is a bad bug and perhaps intellectually violates the criteria, however we don’t believe we have a specific criterion to use against this bug at the moment. We will punt for now and send out mail to discuss implementing a new criterion or redefining an existing one.
16:47:12 <bcotton> ack
16:47:46 <kparal> the fudge power is not with us today...
16:47:47 <kparal> ack
16:48:16 <cmurf> ack
16:48:19 <coremodule> #agreed 1861700 - punt – We acknowledge that this is a bad bug and perhaps intellectually violates the criteria, however we don’t believe we have a specific criterion to use against this bug at the moment. We will punt for now and send out mail to discuss implementing a new criterion or redefining an existing one.
16:49:01 <coremodule> moving on to final blockers
16:49:08 <coremodule> #topic proposed Final Blockers
16:49:17 <cmurf> it's a dup
16:49:23 <coremodule> #topic (1860616) abrt-server errors when processing zstd compressed core dumps produced by systemd-246~rc1-1.fc33
16:49:23 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1860616
16:49:23 <coremodule> #info Proposed Blocker, libreport, NEW
16:49:27 <coremodule> ahhh
16:49:31 <cmurf> yeah we took it for beta
16:49:41 <cmurf> we are done
16:49:43 <cmurf> finis
16:49:49 <kparal> :fireworks:
16:49:50 <cmurf> outta here
16:50:02 <coremodule> #undo
16:50:02 <zodbot> Removing item from minutes: INFO by coremodule at 16:49:23 : Proposed Blocker, libreport, NEW
16:50:06 <coremodule> #undo
16:50:06 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fb1a15904d0>
16:50:10 <kparal> 🎉
16:50:11 <coremodule> #undo
16:50:11 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fb1ae245250>
16:50:14 <coremodule> #undo
16:50:14 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fb1a42b4650>
16:50:22 <coremodule> #undo
16:50:27 <cmurf> is that icecream or a sushi handroll?
16:50:42 <coremodule> #undo
16:50:55 <coremodule> zodbot why u do this
16:51:00 <kparal> party popper it says
16:51:05 <cmurf> could be temaki sushi
16:51:08 <coremodule> #topic Open Floor
16:51:21 <coremodule> any thing else? I'll send out that mail today and hopefully get a conversation started
16:51:30 <cmurf> don't forget to cc: kde list
16:51:45 <coremodule> cmurf, roger, would have forgotten had you not suggested
16:52:05 <kparal> I don't have anything else. There are still numerous user switch bugs in KDE that could be blockers, but KDE sneakily removed the option to switch users, so I can't report them.
16:52:14 <kparal> they did that on purpose because of me, I'm sure
16:52:16 <cmurf> and desktop list also, might as well
16:52:34 <cmurf> kparal: they did this to reduce your influence :P
16:52:48 <kparal> they didn't think about logging in and out, though
16:52:53 <cmurf> demagnetize the bug magnet!
16:52:54 <kparal> they need to remove that as well
16:52:54 <coremodule> #action coremodule to send out mail to the lists regarding 1861700 and the lack of multi-user criteria
16:53:06 <coremodule> kparal, did you find out if that was a bug or intentional?
16:53:14 <coremodule> I saw it in the comments and forgot to ask
16:53:48 <kparal> coremodule: the user switch bug? there are multiple versions mentioned in here: https://bugzilla.redhat.com/show_bug.cgi?id=1817708
16:53:49 <cmurf> another way to test it would be to enable....lets see
16:53:53 <kparal> they are regular bugs
16:54:14 <kparal> but don't apply to F33 atm
16:54:19 <coremodule> kparal, I mean was the user-switching feature intentionally removed from KDE or is it missing due to some bug?
16:54:25 <kparal> I wonder if they plan to re-enable user switching once they're GA :D
16:54:26 <coremodule> oh gotcha
16:54:36 <kparal> coremodule: aha, I don't know that
16:54:47 <cmurf> where's the kill alluser processes option for systemd?
16:54:52 <kparal> but I mentioned that in the bug we discussed, so rdieter so it for sure
16:55:00 <coremodule> cool
16:55:02 <kparal> *saw it
16:55:17 <cmurf> found it
16:55:19 <cmurf> /etc/systemd/logind.conf
16:55:26 <cmurf> #KillUserProcesses=no
16:55:30 <cmurf> change that to yes
16:55:37 <cmurf> reboot
16:55:39 <kparal> I can debug that with it, yeah
16:55:40 <cmurf> see if that solves this problem
16:56:31 <cmurf> if it does it means it's a user process not being killed off, but that's still the domain of the DE to kill it off so the user can log back in
16:56:58 <cmurf> is the user 2 login/logout required to hit this bug?
16:57:18 <kparal> yes
16:57:23 <cmurf> huh
16:57:25 <cmurf> that's curious
16:57:38 <kparal> it also might be related to the crash that's in the log
16:57:48 <kparal> kglobalaccel5
16:57:50 <cmurf> oh yeah that's suspicious, didn't see that
16:57:54 <kparal> but abrt is broken so I can't report it!
16:58:03 <kparal> well I could but didn't have time to do it manually
16:58:04 <cmurf> abrt is broken but so is the retrace server
16:58:08 <kparal> learn gdb once again...
16:58:16 <kparal> awesome
16:58:50 <cmurf> haha yeah
16:59:03 <cmurf> coredumpctl gdb
16:59:33 <coremodule> alright, im gonna end this thing
16:59:39 <coremodule> 10
16:59:39 <kparal> 👍
16:59:40 <coremodule> 9
16:59:41 <coremodule> 8
16:59:42 <coremodule> 7
16:59:42 <coremodule> 6
16:59:42 <coremodule> 5
16:59:43 <coremodule> 4
16:59:44 <coremodule> 3
16:59:46 <coremodule> 2
16:59:48 <coremodule> 2 1/2
16:59:51 <coremodule> 1
16:59:52 <kparal> 💣
16:59:52 <coremodule> 0
16:59:56 <coremodule> #endmeeting