16:00:12 <adamw> #startmeeting F32-blocker-review
16:00:12 <zodbot> Meeting started Mon Apr  6 16:00:12 2020 UTC.
16:00:12 <zodbot> This meeting is logged and archived in a public location.
16:00:12 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:12 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:00:12 <adamw> #meetingname F32-blocker-review
16:00:12 <adamw> #topic Roll Call
16:00:12 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:00:14 <adamw> ahoyhoy folks
16:00:17 <adamw> who's around for blocker fun
16:00:55 <bcotton> .hello2
16:00:56 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:24 <frantisekz> .hello2
16:02:25 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:46 <coremodule> .hello2
16:02:48 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:02:55 <Southern_Gentlem> .hello jbwillia
16:02:56 <zodbot> Southern_Gentlem: jbwillia 'Ben Williams' <vaioof@gmail.com>
16:02:57 <coremodule> ready and willing to secretarialize
16:03:08 <Lailah> hello all!
16:03:12 <sgallagh> .hello2
16:03:13 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:03:17 <Lailah> .fas lailah
16:03:18 <zodbot> Lailah: lailah 'Sylvia Sánchez' <BHKohane@gmail.com>
16:03:43 <cmurf> .hello chrismurphy
16:03:44 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:05:26 <pwhalen> .hello2 pwhalen
16:05:27 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
16:05:35 <jforbes> .hello2
16:05:36 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:06:18 <pwhalen> Good afternoon folks, hope everyone is doing well :)
16:06:20 <lruzicka> .hello2
16:06:21 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:06:29 <adamw> how's everyone doing this FINE/REASONABLE/AWFUL (DELETE FOR YOUR GEOGRAPHIC REGION AS APPROPRIATE) morning?
16:06:32 <lruzicka> I am sorry for being late.
16:06:42 <adamw> .fire lruzicka apology accepted
16:06:42 <zodbot> adamw fires lruzicka apology accepted
16:06:48 <lruzicka> adamw, fine except it is evening here :D
16:06:59 <frantisekz> adamw, pretty much fine :)
16:07:09 <sgallagh> This is fine.
16:07:15 <adamw> .fire lruzicka nobody likes a smartass
16:07:15 <zodbot> adamw fires lruzicka nobody likes a smartass
16:07:17 <frantisekz> sitting outside in the garden with glass of beer, so :)
16:07:33 <sgallagh> adamw: It *is* better than being a dumbass, at least!
16:07:36 <adamw> =)
16:07:43 <bcotton> frantisekz: i hope you brought enough for the whole class
16:07:46 <cmurf> is this one of those 'apology accepted captain needa' apologies?
16:07:52 * lruzicka thinks: smartass, dumbass ... they both stink
16:08:03 <sgallagh> moving along...
16:08:11 <frantisekz> bcotton , sure, I have plenty to survive post apocalyptic world :)
16:08:28 <Lailah> adamw:  it's a fine German late afternoon here.
16:09:07 * kparal is here
16:09:14 <adamw> sgallagh: nah, let's stay right here, i'm having fun :P
16:09:27 <adamw> #chair sgallagh jforbes
16:09:27 <zodbot> Current chairs: adamw jforbes sgallagh
16:09:45 <adamw> IMPENDING BOILERPLATE ALERT
16:09:48 <adamw> #topic Introduction
16:09:48 <adamw> Why are we here?
16:09:48 <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:09:48 <adamw> #info We'll be following the process outlined at:
16:09:50 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:50 <adamw> #info The bugs up for review today are available at:
16:09:52 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:56 <adamw> #info The criteria for release blocking bugs can be found at:
16:09:58 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:10:00 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria
16:10:02 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria
16:10:17 <adamw> #info for Final, we have:
16:10:17 <adamw> #info 4 Proposed Blockers
16:10:18 <adamw> #info 4 Accepted Blockers
16:10:21 <adamw> #info 2 Proposed Freeze Exceptions
16:10:39 <adamw> #info coremodule will secretarialize, thanks
16:10:54 <adamw> ok, so without further ado...
16:10:59 <adamw> #topic Proposed Final blockers
16:11:07 <adamw> #topic (1816621) Second suspend does not work
16:11:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1816621
16:11:08 <adamw> #info Proposed Blocker, kernel, ON_QA
16:12:05 <frantisekz> hmm, shall I needinfo David (reporter)?
16:12:10 <jforbes> This should be pushed
16:12:10 <frantisekz> fix seems to be in stable already
16:12:13 <Lailah> It seems that there is already a patch
16:12:39 <sgallagh> We still have to decide whether to block on it if the patch is incomplete or wrong
16:12:41 <jforbes> Yeah, only reason bug isn't closed is because F30 doesn't get enough karma
16:13:10 <adamw> we should needinfo david and mark, yeah
16:13:17 <adamw> they are lenovo people so they should get back to us
16:13:45 <Lailah> I don't feel fine with accepting a blocker that already has a patch...
16:13:54 <Lailah> Or seemingly has a patch
16:14:01 <frantisekz> why not?
16:14:07 <lruzicka> F32 with latest updates suspends twice fine here
16:14:13 <frantisekz> it doesn't matter if there is patch
16:14:15 <adamw> Lailah: those are my favourite kinds of blockers!
16:14:17 <bcotton> Lailah: in general, i'd still approve a bug as a blocker because the patch may not fix it
16:14:19 <adamw> it means they'll go away quickly ;)
16:14:24 <frantisekz> :)
16:14:31 <bcotton> but specifically, i'm not sure what criteria this would violate
16:14:38 <adamw> #c1 says "on some ThinkPad laptops"
16:14:43 <frantisekz> lruzicka: It's hw specific
16:14:44 <Lailah> bcotton: okay, that's a good point
16:14:53 <adamw> and #c2 says "The x1 carbon 7th and 8th gen are both affected by this and both are very popular laptop models. Not having suspend/resume working on these really is not acceptable."
16:15:02 <lruzicka> frantisekz, adamw: ok, I think +1 blocker in all cases
16:15:08 <adamw> (i'd agree with the first half of that for sure, these are popular models)
16:15:10 <bcotton> ctrl+f suspend gets zero hits and I have a vague recollection that we've generally avoided suspend as a blocker because omg it's hard
16:15:17 <sgallagh> FWIW, those are also standard offerings for Red Hat employees
16:15:51 <frantisekz> +1 Blocker, affects non-small amount of laptops?
16:16:00 <lruzicka> My laptop is T580, T430 and T460 so I cannot talk for carbons :/
16:16:01 <sgallagh> frantisekz: On what criterion?
16:16:02 <jforbes> +! blocker here
16:16:06 <adamw> bcotton: i think that's been mostly true, but we may have been a bit less absolutist of late, at least for major laptop models. it's pretty impractical to use a laptop without suspend these days
16:16:08 <sgallagh> I'd say +1 FE for this
16:16:12 <lruzicka> sgallagh, panel?
16:16:21 <sgallagh> lruzicka: Is that a joke?
16:16:28 <adamw> otoh, suspend *is* something we can mostly fix with an update, we really don't 'support' suspending live environments
16:16:38 <Lailah> My laptop is a T440s. It suspends just fine.
16:16:40 * mboddu is here
16:16:42 <adamw> Lailah: twice? :)
16:16:58 <Lailah> adamw:  Twice what?
16:17:08 <adamw> Lailah: does it suspend fine twice (that's the bug here)
16:17:08 <Lailah> Oh, yeah.
16:17:13 <pwhalen> +1 FE
16:17:16 <adamw> though i think yours is maybe a bit older than the affected generations
16:17:20 <Southern_Gentlem> +1FE
16:17:22 <lruzicka> sgallagh, no, I did not mean it as a joke. You can only access suspend via the panel and if that does not work? panel should work all the time
16:17:38 <adamw> i'm a weak +1 blocker or punt to make it go away, i guess
16:18:30 <sgallagh> Alright, I guess I can go +1 blocker also
16:18:30 <frantisekz> sgallagh: I can't dig out proper criterion, maybe adamw can help me here?
16:18:34 <Lailah> I'm in favour of punt
16:18:36 <bcotton> +0.5 blocker from me. it doesn't violate any criteria that i can tell, but it does seem like Something We Should Block On
16:18:48 <bcotton> but i'd also accept punting :-)
16:18:55 <adamw> bcotton: we'd probably have to reconsider the whole suspend thing
16:18:59 <adamw> otoh, that gives us a good punting excuse!
16:19:09 <cmurf> +1FE
16:19:23 <jforbes> Well, I expect the patch is good, and it won't matter either way
16:19:31 * lruzicka thinks that the suspend criterion should be part of logout, restart and poweroff
16:20:08 <adamw> lruzicka: if we were going to decide to start 'formally' blocking on suspend, yeah, that's the logical place for it
16:20:19 <adamw> if you want to propose something it'd make for an interesting discussion :)
16:20:21 <bcotton> i propose we punt to next week to see if it just goes away on its own. people who have tested it all say it works
16:20:24 <frantisekz> lruzicka, yeah, but... it's difficult, cause this is firmware bug, we'd always need to discuss how many devices are affected
16:20:29 <adamw> a proposal like that should be cc'ed to kernel and probably devel too btw
16:20:34 <jforbes> Changing suspend criteria would need to be much more specific though. I am much more comfortable saying we support suspend on a lenovo, or a Dell, than whatevercheaplaptopyoufound
16:20:43 <adamw> bcotton: you can't propose that, i already did ;)
16:21:01 <bcotton> adamw: i second (suspend) your proposal then :p
16:21:59 <adamw> proposed #agreed 1816621 - punt (delay decision) on blocker, AcceptedFreezeException - there is some support for blocking on suspend issues on widely-used laptop models, but we do not currently have this in the criteria, so we will delay blocker decision to allow proposals. Accepted as an FE issue as a very visible bug on widely-used hardware
16:22:06 <Southern_Gentlem> ack
16:22:14 <kparal> ack
16:22:27 <cmurf> ack
16:22:40 <bcotton> ack
16:22:55 <lruzicka> ack
16:23:03 <pwhalen> ack
16:23:15 <jforbes> ack
16:23:30 <frantisekz> ack
16:23:30 <Southern_Gentlem> reporter should also check for a bios update on their equipment
16:23:37 <lruzicka> adamw, shall I draft the criterion somehow?
16:23:48 <adamw> lruzicka: sure, i think it's worth discussing
16:24:04 <adamw> Southern_Gentlem: reporters are employed by Lenovo, they know about the firmware :P
16:24:09 <lruzicka> adamw, aye, will do :D
16:24:25 <adamw> #agreed 1816621 - punt (delay decision) on blocker, AcceptedFreezeException (Final) - there is some support for blocking on suspend issues on widely-used laptop models, but we do not currently have this in the criteria, so we will delay blocker decision to allow proposals. Accepted as an FE issue as a very visible bug on widely-used hardware
16:24:36 <lruzicka> adamw, also, we should make sure we will not pass that blocker onto those Lenovo laptops
16:24:49 <adamw> ?
16:25:16 <adamw> #topic (1814015) System freeze.locksup when using wayland on P53
16:25:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1814015
16:25:16 <adamw> #info Proposed Blocker, mutter, NEW
16:25:45 <frantisekz> hmm, this affects just one laptop afaik
16:25:50 <coremodule> yes
16:25:54 <coremodule> what frantisekz said
16:26:09 <Lailah> "let the system sit"  What a wonderful description, I need to use it more often.
16:26:24 <frantisekz> i'd say +1 FE, I am expecting fix to be sort of wayland blacklist on that device? Or nouveau modeset = 0 seems to make it work
16:26:35 <coremodule> we've tried a p50, p52 laptops with other graphics cards that work fine
16:27:04 <coremodule> its this particular combo of nvidia quadro t1000 and nouveau
16:27:18 <Lailah> Then it's probably an issue with Nvidia.
16:27:35 <coremodule> and using the nvidia driver, it no longer freezes
16:27:36 <bcotton> -1 blocker, +1 FE based on the narrow set of affected hardware
16:27:39 <cmurf> -1 blocker +1 FE
16:27:52 <pwhalen> -1 blocker +1 FE
16:27:52 <Lailah> -1 Blocker +1FE
16:28:20 <Southern_Gentlem> +1fe
16:28:27 <jforbes> +1 FE. It may end up switched to kernel
16:28:57 <lruzicka> +1 FE
16:29:23 <Southern_Gentlem> +1 commonbug
16:30:40 <adamw> proposed #agreed 1814015 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this seems to affect only one laptop model and there is a known workaround, so it is not considered broad enough in impact to be a release blocker, but is accepted as an FE as a significant and highly visible bug on a relatively popular piece of hardware
16:30:48 <cmurf> ack
16:30:50 <frantisekz> ack
16:30:51 <coremodule> ack
16:30:51 <Lailah> ack
16:30:54 <Southern_Gentlem> ack
16:30:56 <kparal> ack
16:31:02 <lruzicka> ack
16:31:21 <jforbes> ack
16:31:57 <pwhalen> ack
16:32:07 <adamw> #agreed 1814015 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this seems to affect only one laptop model and there is a known workaround, so it is not considered broad enough in impact to be a release blocker, but is accepted as an FE as a significant and highly visible bug on a relatively popular piece of hardware
16:32:15 <adamw> #topic (1817708) The desktop session will not start.
16:32:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1817708
16:32:15 <adamw> #info Proposed Blocker, plasma-desktop, NEW
16:33:31 <cmurf> I'm tentatively +1 blocker
16:33:49 <cmurf> lruzicka is this reproducible on more than the test system you used?
16:34:06 <Southern_Gentlem> give me a link to a new compose and i will test real quick
16:34:17 <bcotton> lruzicka: do i understand that this works on "real (both physical and virtual)" machines and only appears on openQA?
16:34:24 <adamw> i would like to know how commonly this happens on real hardware
16:34:29 <cmurf> yeah
16:34:36 <lruzicka> At first, I could reproduce it on any VM, but lately it only appears in OpenQA for me.
16:34:37 <cmurf> but also clean installs aren't affected?
16:34:40 <adamw> happening to openqa vms is inconvenient but probably not blockery on its onw
16:34:51 <Lailah> I saw a similar complaint days ago on Fedora Telegram  adamw
16:35:06 <adamw> this might be a Call For Testing case
16:35:18 <cmurf> good idea
16:35:20 <lruzicka> I am aware of that ... it can be related to a VM setting we have in OpenQA
16:35:21 <Lailah> Yes, I think so
16:35:35 <cmurf> +1 call for testing and punt
16:35:42 <bcotton> i mean, we do have a "this thing makes it hard for us to do testing" criterion, but if you're satisfied, then cool
16:36:19 <pwhalen> +1 call for testing and punt, vote in bug if needed
16:36:29 <lruzicka> bcotton, we can test manually, but I have been working on login automation test and one of the steps is switching users, which I cannot do in OpenQA right now.
16:36:47 <lruzicka> bcotton, speking of KDE
16:38:10 <Lailah> +1 too for a call for testing and punt
16:38:26 <bcotton> +1 CfT, punt
16:38:31 <frantisekz> +1 cft/punt
16:38:40 <lruzicka> Just want to know .... a call for testing is organizing a test day? or is something different?
16:38:54 <lruzicka> I agree with it, +1cft and punt
16:39:03 <adamw> proposed #agreed 1817708 - punt (delay decision) - this could be a serious problem, but so far it only seems to reliably affect an openQA environment. We will send out a call for testing to see if many people hit this bug in 'real world' environments
16:39:07 <cmurf> ack
16:39:11 <Lailah> ack
16:39:11 <frantisekz> ack
16:39:13 <lruzicka> ack
16:39:19 <pwhalen> ack
16:39:21 <adamw> lruzicka: it's when we send out an email specifically asking people to test a certain thing (reproduce a bug, check a fix, etc)
16:39:28 <Southern_Gentlem> i am installing a f32 beta and will update and test lets skip this for 10 min
16:39:29 <cmurf> we=adamw
16:39:30 <adamw> i'll send this one to test@ and kde@
16:39:34 <lruzicka> adamw, ok, gott it
16:39:35 <kparal> ack
16:39:47 <adamw> Southern_Gentlem: it's best to have input from multiple people on something like this anyway
16:39:48 <Southern_Gentlem> ack
16:40:01 <adamw> #agreed 1817708 - punt (delay decision) - this could be a serious problem, but so far it only seems to reliably affect an openQA environment. We will send out a call for testing to see if many people hit this bug in 'real world' environments
16:40:08 <adamw> #action adamw to send out call for testing for 1817708
16:40:10 <Lailah> cmurf:  It sounds better than saying  "I send out..."
16:40:54 <adamw> i mean, it's just an email. when i win the lottery someone else can do it. :P
16:41:12 <cmurf> Lailah it's just my way of teasing adam
16:41:21 <Lailah> I know  :-D
16:41:34 <adamw> #topic (1819749) KDE login screen cannot handle expired passwords.
16:41:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1819749
16:41:34 <adamw> #info Proposed Blocker, sddm, NEW
16:42:15 <Lailah> I don't understand much what exactly is an expired password...
16:42:29 <adamw> Lailah: you can set a user account's password to have a limited lifespan
16:42:39 <adamw> when that lifespan expires the system requires the password to be changed
16:42:54 <adamw> things like login prompts are supposed to cope with this situation (it's a standard interface they're meant to implement)
16:42:55 <lruzicka> I proposed this one for mere discussion.
16:43:27 <kparal> since this is not a regression but it was never implemented, I feel that we can't consider it a blocker
16:43:34 <jforbes> Is this a regression? Does F31 deal with this gracefully?
16:43:36 <Southern_Gentlem> a lot of corps and Universities have policy for password expiration in like 90 days
16:43:41 <kparal> we don't specifically require this to be working in criteria
16:43:45 <lruzicka> Gnome is able to create a user without password (expired), which forces GDM to create a new password upon first login. KDE cannot do it.
16:44:02 <adamw> this seems a bit too corner case-y to block on, to me
16:44:05 <Lailah> Nope. I still don't understand the problem adamw
16:44:06 <Lailah> Sorry
16:44:12 <lruzicka> Southern_Gentlem, yes, that is why we should discuss it
16:44:28 <bcotton> yeah, agreed it's a corner case
16:44:42 <frantisekz> -1 Blocker
16:44:43 <kparal> it's a good bug to be commonbug'd
16:44:48 <adamw> lruzicka: is this only broken in the "no password" case?
16:44:50 <bcotton> and it's an unimplemented upstream feature that's been sitting around for 3.5 years
16:44:52 <jforbes> I understand the issue, but unless it is a regression, I can't see how it would be blocker worthy
16:45:00 <pwhalen> -1 Blocker
16:45:03 <lruzicka> adamw, this is broken with any expired password
16:45:07 <jforbes> -1 blocker
16:45:15 <Southern_Gentlem> lruzicka, block no, discuss yes
16:45:19 <lruzicka> adamw, you cannot create a no password user with KDE tools
16:45:22 <adamw> okay.
16:45:28 <bcotton> -1 blocker
16:46:18 <Southern_Gentlem> -1blocker
16:46:22 <cmurf> -1 blocker
16:46:38 <adamw> proposed #agreed 1819749 - RejectedBlocker (Final) - this is not a clear criteria violation. at best it's a conditional violation of the 'log in/out' criterion, it is not a regression but an unimplemented feature upstream, so we don't think it is significant enough to constitute a blocker
16:46:45 <Lailah> I'm 0 here (neutral) because I'm not sure to understand the problem.
16:46:46 <kparal> ack
16:46:50 <Lailah> ack
16:46:53 <Southern_Gentlem> ack
16:46:54 <bcotton> ack
16:46:57 <lruzicka> ack
16:47:00 <pwhalen> ack
16:47:04 <jforbes> ack
16:47:11 <cmurf> I think the criterion is about behavior following a clean install, which for KDE the password is set by the installer, and can't be set to be expired
16:47:21 <lruzicka> Lailah, the problem is that if you use sddm and your password expires, you will not log into the system.
16:47:34 * Southern_Gentlem i will test it here shortly
16:47:37 <adamw> #agreed 1819749 - RejectedBlocker (Final) - this is not a clear criteria violation. at best it's a conditional violation of the 'log in/out' criterion, it is not a regression but an unimplemented feature upstream, so we don't think it is significant enough to constitute a blocker
16:47:41 <lruzicka> cmurf, but this problem can arise later while using the system
16:47:50 <adamw> #info that's all the proposed blockers
16:47:56 <adamw> #topic Proposed Final freeze exception issues
16:47:58 <cmurf> i agree it's a bug and a problem, i just don't think the criterion covers it
16:48:03 <lruzicka> cmurf, I think that Linux still should be considered multiuser :D
16:48:03 <adamw> #topic (1819296) [abrt] geoclue2: g_type_check_instance(): geoclue killed by SIGSEGV
16:48:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1819296
16:48:03 <adamw> #info Proposed Freeze Exceptions, geoclue2, NEW
16:48:54 <cmurf> oh this
16:49:08 <cmurf> so this is a gray area that I need help clarifying
16:49:37 <Lailah> Uhm...  I don't see it a blocker-worthy bug.
16:49:43 <adamw> Lailah: we're on proposed FEs now
16:49:49 <Lailah> Sorry, yes
16:49:52 <Lailah> Still.
16:49:55 <adamw> though cmurf said he's sort of proposing it as both i guess
16:50:06 <kparal> confused me as well
16:50:09 <adamw> i'd say it's definitely too rare to take as blocker
16:50:21 * kparal nods
16:50:26 <adamw> it seems sufficiently mysterious i wouldn't want to vote FE as is, i'd rather see a patch / better understanding of the bug first
16:50:33 <adamw> seems just as likely to make sense to fix it with an update
16:50:40 <cmurf> it's a crash, I get a notification, it could happen following a clean install, I just haven't seen that particular event because it's transient
16:50:50 <bcotton> cmurf: you only see it after a sleep so far?
16:50:54 <kparal> I'm +0 on FE
16:51:20 <lruzicka> I don't know what geoclue is for.
16:51:29 <frantisekz> punt?
16:51:44 <bcotton> #info Geoclue is a D-Bus service that provides location information. The goal of the Geoclue project is to make creating location-aware applications as simple as possible.
16:51:45 <cmurf> bcotton: coredumpctl shows 7 crashes in ~20 days, but i don't have logs proving that it only happens after wake from sleep, except the last three crashes
16:51:45 <Southern_Gentlem> -fe
16:52:19 <Southern_Gentlem> most people i know disable location on installs
16:52:30 <Lailah> Yeah, I do that too.
16:52:32 <cmurf> but it's enabled by default in g-i-s
16:52:43 <cmurf> I don't think we know what people do
16:53:19 <adamw> the 'crash notification' criterion is really meant to catch very very widespread cases
16:53:32 <adamw> like "there is going to be a crash notification right on first boot / install for 50% or more of people"
16:53:46 <cmurf> sure
16:53:50 <bcotton> +0.5 FE i guess. as far as we know (big caveat), it only happens after sleep, which doesn't make a lot of sense for lives IMO. but if it can be fixed, might as well include it, i guess
16:54:13 <cmurf> i guess punt because we haven't heard from upstream
16:54:16 <adamw> i'm not saying -1 to FE, just that i don't want to take it on what we have right now, it'd be easier to make a call with more concrete info in hand
16:54:30 <adamw> right, i'm -1 blocker / punt on FE
16:54:35 <cmurf> i only just stumbled into this pre-existing bug over the weekend and found the upstream bug and linked them
16:54:35 <jforbes> punt seems reasonable
16:54:39 <Lailah> Yes, agree.
16:54:49 <Lailah> -1 Blocker Punt on FE
16:54:52 <pwhalen> -1 blocker / punt
16:55:23 <lruzicka> punt cannot make any harm, +1 on it
16:56:50 <adamw> proposed #agreed 1819296 - punt (delay decision) - this one isn't definitely serious enough to take as an FE (or blocker) on current information, we would like more info on the details of the bug and fix before making a decision
16:57:06 <adamw> (not formally RejectedBlocker because it's not formally proposed as one()
16:57:25 <cmurf> ack
16:57:27 <Lailah> ack
16:57:56 <bcotton> ack
16:57:56 <jforbes> ack
16:58:00 <pwhalen> ack
16:59:00 <Southern_Gentlem> ack
16:59:36 <lruzicka> ack
16:59:58 <adamw> #agreed 1819296 - punt (delay decision) - this one isn't definitely serious enough to take as an FE (or blocker) on current information, we would like more info on the details of the bug and fix before making a decision
17:00:20 <adamw> #topic (1819749) KDE login screen cannot handle expired passwords.
17:00:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1819749
17:00:20 <adamw> #info Proposed Freeze Exceptions, sddm, NEW
17:00:24 <adamw> oops, we should've voted on FE for this earlier
17:00:33 <adamw> i'm kinda -1 FE on this since it's not likely to be a trivial patch
17:00:35 <Lailah> Again?
17:00:36 <bcotton> but it wasn't FE time :-)
17:00:39 <adamw> and it has limited value for live environments
17:00:42 <adamw> Lailah: as an FE this time!
17:00:46 <cmurf> agreed
17:00:48 <Lailah> Ah.
17:00:49 <bcotton> -1 FE for the reasons adamw said
17:01:15 <kparal> it's unlikely the patch will be implemented in time, I don't think we need to vote on this now
17:01:39 <Lailah> -1 FE
17:01:44 <pwhalen> -1 FE
17:02:05 <jforbes> -1 FE
17:02:25 <Southern_Gentlem> -fe
17:02:25 <lruzicka> -1 FE
17:02:30 <cmurf> but i also think kparal makes a good point
17:03:16 <lruzicka> cmurf, if kparal ended with the 8th word, I'd think it would be more exact.
17:03:30 <cmurf> it's Fedora, we can change our mind next week if there's a tested fix :D
17:03:49 <Southern_Gentlem> now if this a sddm issue or a pam issue
17:04:10 <Southern_Gentlem> i see an update for pam in my beta install
17:04:28 <adamw> Southern_Gentlem: it's an SDDM issue
17:04:45 <lruzicka> Southern_Gentlem, I think it does not check for expired password, because you only get "Login failed"
17:05:09 <adamw> proposed #agreed 1819749 - RejectedFreezeException (Final) - fixing this seems to require implementing a missing feature in SDDM, which would be a very significant change and too disruptive to risk during a freeze
17:05:15 <cmurf> ack
17:05:17 <lruzicka> ack
17:05:21 <Southern_Gentlem> ack
17:05:40 <jforbes> ack
17:05:46 <bcotton> ack
17:05:51 <Lailah> ack
17:06:06 <frantisekz> ack
17:06:12 <pwhalen> ack
17:06:29 <adamw> #agreed 1819749 - RejectedFreezeException (Final) - fixing this seems to require implementing a missing feature in SDDM, which would be a very significant change and too disruptive to risk during a freeze
17:06:59 <adamw> #info that's all proposed FEs, moving onto accepted blockers
17:07:04 <adamw> #topic Accepted Final Blocker review
17:07:07 <adamw> #topic (1768206) DNF prompts for GPG key import for "repo_gpgcheck=1"-repositories despite "rpm --import"-ing the keys first
17:07:07 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1768206
17:07:07 <adamw> #info Accepted Blocker, dnf, NEW
17:07:14 <adamw> so, this one i'm getting a bit worried about at this point
17:07:18 <cmurf> yep
17:07:23 <cmurf> was gonna say the same thing
17:07:24 <adamw> bcotton, sgallagh, nirik, do we have Plans?
17:07:54 <Lailah> Oh, this one...
17:07:55 <nirik> I have no plan... perhaps we should ask dmach?
17:08:16 <bcotton> i can bring it up on wednesday's dnf team meeting
17:08:22 <adamw> bcotton: that sounds like a plan
17:08:38 <cmurf> what's involved in c21's (d) option?
17:08:47 <adamw> mirrormanager changes i guess?
17:09:02 <cmurf> :P
17:09:08 <cmurf> how difficult is that?
17:09:23 <cmurf> or rather, how likely given the time frame?
17:09:56 <cmurf> btw is only freeze pushed back one week? or is GA pushed back too?
17:10:19 <frantisekz> only freeze is pushed afaik
17:10:23 <adamw> only freeze
17:10:26 <frantisekz> by 3 days?
17:10:30 <adamw> dunno, i'm not a mirrormanager expert
17:10:43 <adamw> #info we are worried at the apparent lack of an agreed plan here
17:11:02 <adamw> #action bcotton to bring 1768206 up during the DNF meeting on Wednesday
17:11:47 <cmurf> frantisekz looks like 2 days
17:11:55 <cmurf> thursday instead of tuesday
17:13:20 <bcotton> cmurf, frantisekz that is correct
17:13:27 <bcotton> i'll #info that when we get to open floor
17:13:27 <adamw> ok, any more on this?
17:13:37 <cmurf> i think we need (d) looked at and even have reverting the h264 change on the table as fallbacks
17:14:14 <cmurf> i'll just say that in the bug
17:14:17 <adamw> yeah, thanks
17:14:27 <bcotton> cmurf: who would be resposible for d? releng?
17:14:31 <adamw> i don't *think* d) would be a crazy amount of work or anything, just might need organizing...
17:14:42 <adamw> bcotton: CPE! :P
17:14:42 <cmurf> i think both (d) and revert fall on releng, ultimately
17:15:09 <adamw> not sure which official bucket mirrormanager falls in, but it's definitely in my 'bug nirik about it' unofficial bucket
17:15:22 * nirik looks back
17:15:29 <Lailah> LOL
17:15:30 <nirik> d?
17:15:33 <bcotton> that's a very big bucket, though
17:15:50 <bcotton> nirik: switch to mirrormanager for the cisco repo metadata, which would allow us to change repo_gpgcheck to 0
17:15:51 <cmurf> nirick https://bugzilla.redhat.com/show_bug.cgi?id=1768206#c21
17:15:55 <cmurf> oops
17:15:55 <adamw> nirik: i believe d) is "go through mirrormanager for the h264 repo"
17:15:56 <cmurf> nirik
17:16:05 <nirik> wow... can everyone say it? :)
17:16:16 <adamw> it's the zaireeka of irc meetings!
17:16:21 <adamw> (ten points to anyone who gets that reference)
17:16:35 <nirik> I would ask adrianr about that... I think it might not be too hard, but it's kinda silly since there's... one mirror thats a cdn
17:16:37 <adamw> bcotton: especially since that bucket got most of the former 'puiterwijk' bucket, yep :P
17:16:49 <nirik> I will inquire.
17:16:55 <adamw> nirik: let's face it, we're *fedora*, when has "kinda silly" ever stopped us before:D
17:17:07 <bcotton> i'm pretty sure "kinda silly" is a requirement
17:18:14 <adamw> i'll add it to the release criteria
17:18:19 <adamw> "must meet minimum silliness requirement"
17:18:26 <bcotton> nirik++  please keep me informed as to what you find out so i can have that info handy when i talk to the dnf team
17:18:41 <adamw> #action nirik to investigate viability / silliness of https://bugzilla.redhat.com/show_bug.cgi?id=1768206#c21 option d)
17:19:24 <nirik> I will cut the middle man and ask him to reply on the bug. ;)
17:20:28 <Lailah> adamw:  I can see future bug reports like  "Not silly enough"  "Silliness level does not meet the minimum required"
17:21:09 <adamw> i've seen the future, and it is glorious!
17:21:17 <Lailah> nirik:  Will you use an axe or a hunter knife to cut that middle man?
17:21:18 <adamw> ENEEDMORESILLINESS
17:21:25 <adamw> okey dokey
17:21:26 <adamw> next one
17:21:33 <adamw> #topic (1816547) Firefox not using langpacks for localization
17:21:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1816547
17:21:34 <adamw> #info Accepted Blocker, firefox, NEW
17:21:38 <adamw> so this one is just sort of sitting around
17:21:51 <nirik> Lailah: I do own a battle axe. ;)
17:21:54 <adamw> i will poke martin directly
17:22:19 <cmurf> ack
17:22:36 <Lailah> nirik:  you're sharpening it already, aren't you?
17:23:26 <Lailah> adamw:  That's a bad one.  It can be frustrating if the browser doesn't localise properly.
17:25:27 <adamw> it's already an accepted blocker
17:25:38 <adamw> at this point we're reviewing them to check on progress of getting them fixed
17:25:50 <adamw> which, here, appears to be 'not much'. but martin may just not have noticed, so i'll poke him
17:25:52 <Lailah> Okay
17:25:58 <adamw> #action adamw to poke mstransky directly to get this one moving
17:26:04 <adamw> #topic (1813515) [abrt] gnome-shell: cogl_matrix_stack_pop(): gnome-shell killed by SIGSEGV
17:26:04 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1813515
17:26:04 <adamw> #info Accepted Blocker, gnome-shell, ON_QA
17:26:42 <Lailah> adamw:  I can lend you a long stick to properly poke people.
17:26:47 <bcotton> (adamw if you don't get a satisfactory response from mstransky, let me know and i will do my annoying program manager routine)
17:26:53 <Lailah> Just in case you need it with mstransky
17:27:27 <bcotton> yay, something not in NEW state
17:27:30 <adamw> Lailah: i have a wide array of pokin' sticks
17:27:52 <Lailah> Oh, good good
17:28:55 * Lailah imagines adamw going to a display at his place, and carefully selecting poking sticks for the task ahead.
17:29:40 <bcotton> this one seems like a good candidate to be set to VERIFIED?
17:29:45 <adamw> Lailah: this is *precisely* what happens
17:29:52 <adamw> bcotton: well, CLOSED, in fact
17:29:54 <bcotton> or CLOSED or whatever
17:29:56 <adamw> the update is already stable
17:30:07 <adamw> we just wanted confirmation it seems to fix the bug
17:30:14 <adamw> at this point i'd say we can go ahead and close it. and in fact i will!
17:30:18 <bcotton> hooray!
17:30:25 <Lailah> Yay!!!
17:30:33 <adamw> #info feedback indicates the mega-update did indeed fix this bug, so we will close it.
17:31:17 <adamw> #topic (1815463) Cannot create another user account through KDE System Settings if 'Real Name' field is not filled in
17:31:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1815463
17:31:17 <adamw> #info Accepted Blocker, plasma-user-manager, NEW
17:32:01 <bcotton> rdieter is active in #fedora-devel right now, i'll page him into this channel
17:32:06 <Lailah> Ah, that one is weird.
17:32:07 <adamw> bcotton: thanks
17:32:43 <rdieter> hi
17:32:49 <adamw> so, it's worth nothing we only figured out the 'real name' wrinkle after this was accepted
17:32:59 <adamw> we could *potentially* re-evaluate it on that basis, though i'd probably still be +1
17:33:00 <rdieter> imo, -1 blocker , it's cosmetic
17:33:01 <adamw> hi rdieter!
17:33:06 <adamw> cosmetic?
17:33:14 <rdieter> with easy workaround
17:33:27 <rdieter> ie, don't leave real name blank
17:33:37 <Lailah> rdieter: Hi
17:34:27 <adamw> "with an easy workaround" i'll buy, but not cosmetic. it's a real bug :P
17:34:31 <rdieter> as far as I know, it's not been reported upstream yet either, so likelihood of getting fixed quickly is small
17:34:43 <adamw> the problem i see with the workaround is that it is not obvious at all that the way to fix "creating a user isn't working" is "fill in the real name field"
17:34:53 <adamw> i don't see that anyone's going to intuitively work that out
17:35:09 <Lailah> I would try, out of desperation.
17:35:18 <adamw> people who habitually *do* fill out that field won't see the bug, of course, but people who don't will see the bug and we can't assume they'll figure out how to work around it
17:35:25 <rdieter> I'm not saying it's not a bug, it is, and def should be fixed.  I'm just saying not worth considering a blocker, imho
17:35:28 <Lailah> I always press every button available and fill in blank spaces, just in case  adamw
17:35:34 <adamw> Lailah: wise :)
17:35:51 <bcotton> i'd be okay with de-blockering this now that we know it's a narrow case and putting it on commonbugs
17:35:55 <rdieter> may be worth patching the code to make that field non-optional though
17:36:10 <adamw> rdieter: that i'd buy for a dollar
17:36:10 <rdieter> (not sure how easy/hard that would be)
17:36:25 <adamw> not sure we have enough folks still paying attention to re-vote this right now
17:36:36 <adamw> i don't want to take a three-person vote to overturn a previous decision...
17:36:48 <Lailah> I'm paying attention!
17:37:10 <lruzicka> I am paying attention and I think this is worth blocking.
17:37:15 <Lailah> adamw: Look  (O - O)
17:37:38 <Lailah> To me it's not worth blocking.
17:37:53 <adamw> #info this bug is now known to be somewhat narrower than when we accepted it as a blocker (it only happens if the 'real name' field is not filled in)
17:38:13 <adamw> #action rdieter to investigate possibility of patching 'real name' field to be mandatory as a workaround for this
17:39:05 <bcotton> should we notify the mailing list to revote based on the new information, or just wait to see if rex can magic it up
17:39:09 <adamw> so if we're taking votes on this, we have +1.5 (i'm counting myself as +0.5) and -3 right now
17:39:24 <adamw> which isn't really enough to overturn it
17:39:43 <adamw> i'd say leave it on the list for now and see what rex comes back with
17:39:51 <adamw> rex, can we ask you to look into it a bit more and update the bug?
17:39:51 <cmurf> agreed
17:39:53 <bcotton> wfm
17:39:56 <adamw> then we can revisit next week and see where we are
17:39:58 <lruzicka> yes
17:39:59 <Lailah> Yeah, agree with that
17:42:08 <adamw> #info there is some support to change this to rejectedblocker based on the 'real name' wrinkle, but not enough to change status at this point. we will revisit next week, hopefully with more info from rdieter
17:42:15 <adamw> #topic Open floor
17:42:18 <adamw> OK, that's all the bugs i have
17:43:06 * Lailah imagines adamw looking sadly at an empty bag that used to be full of bugs.
17:43:08 <bcotton> ooh, i have a thing
17:43:21 <adamw> Lailah: it's okay! bcotton has a thing!
17:43:23 * adamw opens the bag for things
17:43:30 <Lailah> Yay!
17:43:35 <bcotton> #info Fedora 32 Final freeze is delayed by 2 days (to 2020-04-09). other milestones are unaffected
17:43:35 <adamw> fire away, bcotton
17:43:43 <adamw> did i chair you? i don't think i did
17:43:45 <adamw> #chair bcotton
17:43:45 <zodbot> Current chairs: adamw bcotton jforbes sgallagh
17:43:50 <adamw> fire again!
17:44:03 <bcotton> #info Fedora 32 Final freeze is delayed by 2 days (to 2020-04-09). other milestones are unaffected
17:44:16 <bcotton> i think non-chairs can info, but what the heck, we can say it twice :-)
17:44:18 <bcotton> #link https://fedorapeople.org/groups/schedule/f-32/f-32-quality-tasks.html
17:44:22 <bcotton> EOF
17:44:54 <adamw> non-chairs can info? what is this anarchy?!
17:45:26 <adamw> thanks bcotton
17:45:43 <Southern_Gentlem> adamw, easy to double check when meeting logs are made
17:45:47 <Lailah> adamw:  No respect anymore, anyone can do anything nowadays. It's not the same like in the good old days of IRC
17:45:57 * adamw waves cane, yells at cloud
17:46:09 <Lailah> LMAO
17:46:17 <lruzicka> adamw, what are the two stones with carvings you are holding?
17:46:56 <adamw> eh? what? stones? carvings? where am I? why did I come out here? who are you?
17:47:25 <adamw> alrighty folks, sounds like we're about done here :)
17:47:26 * Lailah pats adamw on the shoulder
17:47:33 <Lailah> Yeah.
17:47:58 <Lailah> I'm also falling asleep.  In case you didn't notice.
17:48:17 <lruzicka> Lailah, we did not :) good night
17:48:20 <adamw> nooo, you're fine :P
17:48:27 <adamw> thanks for coming out as always, everyone!
17:48:42 <lruzicka> thank you, too, adamw
17:48:44 <Lailah> Thanks for chairing adamw
17:48:49 <kparal> thanks
17:48:55 <Lailah> And everyone else too, thanks
17:48:58 <lruzicka> have a nice day and see you around
17:49:10 <Lailah> Bye. Have a nice day, night, whatever
17:49:21 <bcotton> thanks everyone!
17:49:24 <adamw> have a nice REGIONALLY APPROPRIATE DAYPERIOD
17:49:36 <adamw> #endmeeting