16:00:40 <adamw> #startmeeting F32-blocker-review
16:00:40 <zodbot> Meeting started Mon Mar 23 16:00:40 2020 UTC.
16:00:40 <zodbot> This meeting is logged and archived in a public location.
16:00:40 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:40 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:00:41 <adamw> #meetingname F32-blocker-review
16:00:41 <adamw> #topic Roll Call
16:00:41 <zodbot> The meeting name has been set to 'f32-blocker-review'
16:00:52 <adamw> morning morning
16:00:58 <adamw> who's around for blocker review funtimes?
16:01:01 <frantisekz> .hello2
16:01:02 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:01:03 <coremodule> .hello2
16:01:08 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:01:12 * coremodule ready to secretarialize.
16:02:46 <kparal> .hello2
16:02:47 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
16:02:48 <adamw> thanks coremodule
16:03:18 <coremodule> you got it
16:03:30 <lruzicka> .hello2
16:03:31 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:04:39 <sgallagh> .hello2
16:04:40 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:04:52 <sgallagh> (I'm semi-here, but also juggling a thousand things in each hand)
16:06:10 * adamw sets them on fire
16:07:22 <sgallagh> I knew I could count on you
16:07:30 <adamw> i'm a helper
16:07:34 <adamw> alrighty, let's get going!
16:07:37 <adamw> incoming boilerplate alert
16:07:46 <adamw> oh wait, first i throw chairs
16:07:49 <adamw> THEN boilerplate
16:07:53 <adamw> #chair coremodule lruzicka
16:07:53 <zodbot> Current chairs: adamw coremodule lruzicka
16:07:59 <adamw> #topic Introduction
16:07:59 <adamw> Why are we here?
16:07:59 <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:07:59 <adamw> #info We'll be following the process outlined at:
16:07:59 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:01 <adamw> #info The bugs up for review today are available at:
16:08:03 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:05 <adamw> #info The criteria for release blocking bugs can be found at:
16:08:07 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:08:11 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria
16:08:13 <adamw> #link https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria
16:08:42 <adamw> #info for Final, we have:
16:08:43 <adamw> #info 8 Proposed Blockers
16:08:43 <adamw> #info 1 Accepted Blockers
16:09:08 <adamw> #info 2 Proposed Freeze Exceptions
16:09:08 <adamw> #info 1 Accepted Freeze Exceptions
16:10:09 <adamw> #info coremodule will secretarialize
16:10:14 <adamw> and with that, let's get started on...
16:10:17 <adamw> #topic Proposed Final blockers
16:10:26 <adamw> #topic adamw only has nine rolls of toilet paper left
16:10:29 <adamw> wait how'd that get in there
16:10:37 <adamw> automatic blocker, obvs
16:10:50 * tflink wants to see the bugzilla bug on that one
16:11:08 <adamw> #topic (1768206) DNF prompts for GPG key import for "repo_gpgcheck=1"-repositories despite "rpm --import"-ing the keys first
16:11:08 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1768206
16:11:08 <adamw> #info Proposed Blocker, dnf, NEW
16:11:42 <frantisekz> +1 Final Blocker
16:11:59 <coremodule> +1 blocker
16:12:08 <lruzicka> +1 locker
16:13:01 <sgallagh> +1 blocker
16:13:14 <adamw> seems a blocker per dusty's proposal, yep
16:13:15 <adamw> +1
16:13:24 * pwhalen is here
16:13:39 <adamw> proposed #agreed 1768206 - AcceptedBlocker (Final) - accepted as a clear violation of "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present" for the Cloud default install
16:13:48 <coremodule> ack
16:13:48 <pwhalen> +1/ack
16:13:50 <frantisekz> ack
16:13:57 <kparal> just a note, if they add -y to the dnf-makecache.service, it will fix the service, but not fix the bug
16:13:58 <lruzicka> ack
16:14:13 <kparal> just to make clear what we're voting on
16:14:32 <kparal> ack
16:14:52 <frantisekz> service is broken by default... so +1 blocker just because of that kparal
16:15:35 <adamw> kparal: well, it would address the blocker aspect...if we don't have any other affected services in a default package set
16:15:47 <adamw> but yes, not fix the ultimate bug
16:15:57 <kparal> sure, I'm just clarifying that +1 blocker here will not guarantee fixing the dnf bug
16:16:10 <kparal> if we vote like we're doing now
16:16:40 <kparal> good enough for me
16:17:25 <adamw> patch
16:17:49 <adamw> proposed #agreed 1768206 - AcceptedBlocker (Final) - accepted as a clear violation of "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present" for the Cloud default install. note blocker aspect can be resolved by adjusting the service, without fixing the underlying dnf issue
16:18:20 <coremodule> ack
16:18:21 <kparal> ack
16:18:25 <frantisekz> ack
16:18:26 <sgallagh> ack
16:18:48 <lruzicka> ack
16:19:06 <adamw> #agreed 1768206 - AcceptedBlocker (Final) - accepted as a clear violation of "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present" for the Cloud default install. note blocker aspect can be resolved by adjusting the service, without fixing the underlying dnf issue
16:19:06 <pwhalen> ack
16:19:15 <adamw> #topic (1803996) systemd-ask-password-console.service: Unit configuration has fatal error
16:19:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1803996
16:19:15 <adamw> #info Proposed Blocker, dracut, ON_QA
16:21:21 <adamw> dang, this still didn't go away?
16:21:28 * adamw wonders when was the last time we actually heard from cmurf...
16:21:54 <adamw> oh, he mailed the list yesterday
16:22:00 <adamw> so i guess he's around, just not following up on this
16:22:18 <adamw> i'd say we still don't know if it's a blocker, so we should probably actually needinfo him this week (and hope the dracut update gets pushed anyway)
16:22:26 <adamw> i'd been figuring he'd just follow up naturally but i guess not..
16:24:12 <adamw> proposed #agreed 1803996 - punt (delay decision) again - we still don't have follow up on this. this time we'll needinfo cmurf expressly to check it out further and also see if the update fixes it
16:25:01 <frantisekz> ack
16:25:07 <coremodule> ack
16:25:15 <pwhalen> ack
16:25:26 <kparal> ack
16:25:28 <lruzicka> ack
16:26:05 <adamw> #agreed 1803996 - punt (delay decision) again - we still don't have follow up on this. this time we'll needinfo cmurf expressly to check it out further and also see if the update fixes it
16:26:13 <adamw> #topic (1814370) gnome-clocks won't add a new world clock
16:26:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1814370
16:26:13 <adamw> #info Proposed Blocker, gnome-clocks, NEW
16:26:28 <adamw> so i tried briefly to reproduce this when i saw it, but can't reproduce on my desktop, it works fine
16:26:32 <adamw> didn't try on a clean install though
16:26:34 <adamw> anyone else tried?
16:26:43 <coremodule> I have one machine here that does it, and one that doesn't...
16:26:55 <adamw> is it a graphical glitch as mcatanzaro suggested
16:26:55 <adamw> ?
16:27:08 <coremodule> possibly, but one where the glitch is that nothing shows up...
16:27:43 <coremodule> seeing as you can't reproduce it, mcatanzaro can't reproduce it, and I'm 1/2 for reproducing it, I'm inclined to vote -1 blocker
16:28:06 <kparal> works for me on my desktop and in a VM
16:28:17 <coremodule> although i do think that if it is an actual bug and can be reproduced, it is a valid blocker, as not having a working mechanism to add a clock in the clocks app is... detrimental
16:28:44 <coremodule> and seemingly violates the criteria
16:28:47 <coremodule> but i digress
16:28:55 <coremodule> im -1 for now, will keep an eye on it
16:29:29 <frantisekz> yeah, works for me too
16:29:33 <frantisekz> -1 for now?
16:29:47 <adamw> yeah, i'd be +1 if it affected all cases but -1 on current evidence
16:30:06 <adamw> if it turns out to affect a lot of systems and/or affect more things than just this, would be willing to reconsider
16:30:13 <coremodule> two thumbs up
16:30:32 <lruzicka> yeah, -1 works on my machine
16:30:46 <pwhalen> -1 here too
16:30:51 <adamw> proposed #agreed 1814370 - RejectedBlocker (Final) - so far we only have one system that hits this out of 5 or 6 that have tried, so it doesn't seem widespread enough to justify blocker status. we are open to reconsider if more information emerges
16:30:58 <kparal> ack
16:31:00 <frantisekz> ack
16:31:00 <coremodule> ack
16:31:01 <lruzicka> ack
16:31:03 <pwhalen> ack
16:31:05 <adamw> if folks who tried and couldn't reproduce can say that in the bug it would be useful
16:31:22 <lruzicka> ok, will do
16:32:04 <adamw> #agreed 1814370 - RejectedBlocker (Final) - so far we only have one system that hits this out of 5 or 6 that have tried, so it doesn't seem widespread enough to justify blocker status. we are open to reconsider if more information emerges
16:32:14 <adamw> #topic (1815487) X11 session is broken ('Something has gone wrong') in VMs
16:32:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1815487
16:32:14 <adamw> #info Proposed Blocker, gnome-session, NEW
16:32:28 <frantisekz> hmm
16:32:44 <frantisekz> do we have explicitly x11 as blocking?
16:32:57 <frantisekz> because... I think it might be a good time to stop doing so...
16:33:05 <kparal> we never got around to specify that in criteria. But X11 are used on many systems by default
16:33:12 <frantisekz> huh?
16:33:33 <kparal> sure, all that fail the 3d rendering check. I wonder what you get in virtualbox
16:33:43 <kparal> or nouveau
16:33:52 <frantisekz> no
16:33:54 <kparal> or nvidia binary driver?
16:34:02 <frantisekz> failing 3d rendering check doesn't mean x11
16:34:13 <frantisekz> nvidia binary driver is not something we need to care too much
16:34:27 <kparal> I'm saying it affects a decent portion of our user base
16:34:27 <frantisekz> nouveau should use wayland
16:34:37 <lruzicka> no, let's not make X11 non-blocking, please
16:34:40 <kparal> also wayland has quirks so many people still prefer X11 (myself included)
16:34:43 <frantisekz> all blacklisted stuff for wayland should be listed here /usr/lib/udev/rules.d/61-gdm.rules
16:34:49 <frantisekz> it's not that much
16:35:12 <kparal> I'm fine with proposing a criterion that both Wayland and X11 must block, if people want to have it explicitly said
16:35:32 <frantisekz> and I hope that criterion wouldn't be accepted
16:35:41 <frantisekz> the other thing to do is to remove xorg option from gdm
16:35:56 <kparal> once that is done, it wouldn't block, yes
16:36:02 <frantisekz> which I'd dicuss with workstation guys tomorrow
16:36:07 <kparal> but it's there aftera default install
16:36:20 <kparal> I wouldn't expect anything less from you :)
16:36:29 <frantisekz> ;)
16:36:49 <lruzicka> frantisekz, there are still things that need to use x11, I think you should not discuss anything in this matter.
16:36:50 <adamw> x11 has always been effectively implicitly blocking on the basis of the hardware that still falls back to it for various erasons
16:36:54 <adamw> but x11 *in a VM* is harder to make a case for
16:37:00 <frantisekz> also... since it's broken only in vm, I feel even more like it shouldn't block
16:37:25 <frantisekz> yeah
16:37:26 <kparal> does anybody have virtualbox installed?
16:37:44 <kparal> I'd be very interested to know what does it boot with
16:37:46 <coremodule> not me...
16:37:56 <frantisekz> should boot with wayland
16:38:03 <frantisekz> didn't try though
16:38:14 <frantisekz> just read stuff that's blacklisted for wayland
16:38:39 * King_InuYasha waves
16:38:43 <King_InuYasha> .hello ngompa
16:38:44 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:38:46 <lruzicka> do not use virtualbox
16:39:42 <kparal> lruzicka: ? that's how majority of windows users get in contact with fedora, e.g. on universities
16:39:51 <frantisekz> lruzicka ... there will always be something that would need X11 (reply to previous message)
16:39:52 <lruzicka> kparal, I have now tried to use xorg in my VM (kvm) and it works for WS Beta
16:39:55 <kparal> we officially recommend them to try fedora in virtualbox
16:40:05 <lruzicka> kparal, I meant, I do not use it
16:40:10 <kparal> ok
16:40:22 <lruzicka> kparal, that was an answer to your question
16:40:39 <frantisekz> https://www.virtualbox.org/ticket/13471
16:40:41 <adamw> we really ought to stick virtualbox in the matrices or something
16:40:42 <lruzicka> frantisekz, and therefore it should work :)
16:40:44 <frantisekz> vbox should support wayland
16:40:53 <adamw> (as optional)
16:40:57 <frantisekz> no, stuff that needs it need to change or go away lruzicka
16:41:35 <lruzicka> frantisekz, I don't agree with you
16:41:48 <frantisekz> according to upstream ticket, vbox support should be there both for 3d and 2d
16:41:55 <frantisekz> lruzicka: I see :)
16:42:52 <kparal> well, I believe we should block on X11 even in VMs, as long as it is offered in the default install
16:43:16 <kparal> but sure, finding a common case where it matters is a big plus
16:43:27 <kparal> I can try virtualbox later, if needed
16:43:45 <frantisekz> so... let's count the votes then, we can discuss x11 blocking status elsewhere, however, I am -1 Blocker for this (vm) case
16:44:23 <kparal> the tricky part is that we never got to defining a criterion, when wayland was introduced
16:44:38 <kparal> so we're in the undefined teritory
16:45:05 <kparal> so from me +1 based on history, but I can be convinced if most people think I'm wrong here
16:45:49 <kparal> I'd like to point out though, that this really prevented me from debugging a different proposed blocker. I had to find a second bare metal machine
16:46:04 <kparal> this is a non-trivial roadblock for QA activities
16:46:29 <lruzicka> +1, i think Xorg should work as a fallback solution wherever wayland does not work or cannot be used.
16:46:49 <adamw> personally i actually kinda consider it intentional we don't talk explicitly about x11 or wayland in the criteria
16:47:00 <adamw> it's part of that whole 'concentrate on what it does not how' philosophy
16:47:16 <adamw> what we require is basically that you can get a working graphical session in the configurations we care about
16:47:33 <adamw> whether that's achieved via wayland or x11 is an implementation detail the criteria shouldn't be explicit about
16:47:41 <adamw> anyhoo. i agree with -1 for this on current info
16:48:16 <adamw> i just can't think of a terribly plausible case where it's actually necessary to use x11 in a vm
16:48:51 <kparal> I can think of some bug you want to work around
16:49:03 <kparal> there are still plenty of them, e.g. window positioning with firefox, etc
16:49:19 <kparal> sure they're getting fixed, but new ones appear regularly
16:49:33 <kparal> but I don't have a strong case, no
16:50:02 <frantisekz> yeah, that's how it goes with releases, bugs appear and get fixed
16:51:32 <adamw> any other votes?
16:51:38 <adamw> or are we still considering? :)
16:52:39 * kparal tests virtualbox in windows
16:54:44 <adamw> we're at +2/-2 atm
16:56:00 <pwhalen> I'm on the fence, leaning towards blocker
16:56:06 <lruzicka> what does coremodule think?
16:56:09 <coremodule> lol
16:56:16 <coremodule> if I vote, we're still in the same boat
16:56:19 <coremodule> I'm more toward -1
16:56:26 * kparal booting in a VM now
16:56:37 <coremodule> but can see kparal's point about using x11 in a vm for testing
16:56:43 <coremodule> but really only for that...
16:57:05 <frantisekz> kalev? don't you want to throw some +1 or -1 ? :D
16:57:23 <kparal> vbox is surprisingly slow compared to libvirt
16:57:26 <lruzicka> coremodule, I would like to write an app to detect coordinates of mouse clicks - this does not work on wayland and I need x11 in VM, too
16:57:43 <coremodule> hmmm
16:57:49 <frantisekz> lruzicka - I wouldn't do it for X11
16:57:53 <frantisekz> that will go away some day
16:58:05 <frantisekz> it should be doable on wayland I think
16:58:41 <lruzicka> frantisekz, there is a chance that until then it will be doable in wayland, I asked pschindler and he thinks it is not doable now
16:58:43 <kparal> it's running on wayland. It's also unusably slow
16:58:50 <kparal> f32 in virtualbox
16:59:06 <lruzicka> frantisekz, and they test via scripting
17:00:20 <kparal> wow that is an amazingly bad experience
17:01:04 <kparal> x11 also works in virtualbox, so the bug is somehow related to libvirt
17:01:19 <kparal> still unusably slow, though, no difference
17:01:31 <lruzicka> kparal, I cannot see the bug on F31 host in libvirt
17:01:46 <lruzicka> kparal, so it can be related to F32:F32 combination only
17:01:50 <kparal> might be
17:02:07 <kparal> lruzicka: have you tried a fresh new vm, to get default values everywhere?
17:02:23 <lruzicka> yes, I installed it yesterday
17:02:26 <kparal> ok
17:02:36 <kparal> I think we need to punt or we have to give up, then
17:02:49 <adamw> yeah
17:02:52 <adamw> doesn't seem like we'll break the tie
17:03:09 <lruzicka> I would like to hear some KDE guys' reasoning, too
17:03:26 <kparal> since virtualbox case didn't prove to be the worry I had, I guess I give up
17:03:30 <adamw> hum. wait. this isn't GNOME-only?
17:03:32 <frantisekz> how does this relate to KDE?
17:03:37 <adamw> if it affects KDE i might change my vote
17:03:44 <adamw> since KDE is release-blocking and still X11 by default, right?
17:03:50 <kparal> I still think we should block on both x11 and wayland, but since it doesn't affect bare metal, it's a sufficient corner case to let go
17:03:51 <frantisekz> anyhow
17:03:59 <frantisekz> I've installed KDE on F32 host
17:04:01 <frantisekz> it worked fine
17:04:06 <frantisekz> uses X11 by default
17:04:14 <lruzicka> I have not tested KDE, but I believe the Gnome guys will have opinion similar to frantisekz
17:04:14 <kparal> I don't think this affects KDE, it worked fine for me
17:04:37 <lruzicka> which means: let x11 go away
17:04:52 <kparal> so I change my vote to +0, with reservations
17:05:06 <kparal> kids, don't use virtualbox. It's tragic
17:05:14 <adamw> heh
17:05:21 <lruzicka> and thus the overall quality dropped another bit
17:05:24 <adamw> srsly though it's actually bad if we don't work well on virtualbox
17:05:28 <frantisekz> kparal, it should be better with 3d driver installed
17:05:36 <adamw> would be worth investigating that
17:05:50 <kparal> frantisekz: well I'm judging out of the box experience, the one that a newcomer will have
17:06:24 <frantisekz> I think there is some ongoing effort to have vbox 3d driver installed by default
17:06:35 <kparal> yeah I heard about that
17:06:43 <kparal> but I think this almost looks I/O related, not sure
17:06:56 <kparal> everything's on ssd, of course, on my system. No help
17:07:00 <frantisekz> hmm, interesting
17:07:15 <frantisekz> also, don't you need to install some virtualbox-kvm package to get accelerated virt?
17:07:17 <adamw> so uh
17:07:28 <adamw> we're at +1.5 - 2.5? I think?
17:07:29 <kparal> frantisekz: I'm testing on windows
17:07:32 <adamw> still a bit unclear
17:07:33 <frantisekz> huh
17:07:49 <frantisekz> adamw, round the numbers
17:07:50 <frantisekz> :D
17:07:51 <kparal> adamw: you count my zero as +0.5 and -0.5? :-)
17:08:09 <lruzicka> no, he counts kalev and coremodule affinity :)
17:08:11 <adamw> so, i'm counting pwhalen as +0.5 and coremodule as -0.5 :)
17:08:19 <lruzicka> yeah, pwhalen :D
17:08:38 <kparal> ah, but that would be a fun way to count my zero :)
17:09:05 <adamw> so should we reject or punt?
17:09:09 <adamw> if we punt, not sure what we're punting for
17:09:18 <adamw> i'd be inclined to reject as we really need a clear +3 to accept
17:09:52 <lruzicka> adamw, yeah, it is really only me who wants to block on this, so it is quite clear
17:10:03 <coremodule> lol
17:10:05 <lruzicka> adamw, I am going to have my cry later.
17:10:15 * kparal plays sad trombone
17:10:17 <adamw> lruzicka: add it to your 'i told you so' pile
17:10:25 <lruzicka> adamw, yeah :D totally
17:11:24 <adamw> proposed #agreed 1815487 - RejectedBlocker (Final) - as so far this is believed to affect virtual environments only, it is rejected on the basis that there is no situation in which the criteria require GNOME-on-X11 to work on our supported virtualization stack (Wayland is the default and should always work)
17:11:43 <coremodule> ack
17:11:45 <frantisekz> ack
17:11:47 <lruzicka> ack
17:12:00 <pwhalen> ack
17:12:01 <kparal> ack
17:12:16 <adamw> #agreed 1815487 - RejectedBlocker (Final) - as so far this is believed to affect virtual environments only, it is rejected on the basis that there is no situation in which the criteria require GNOME-on-X11 to work on our supported virtualization stack (Wayland is the default and should always work)
17:12:16 <lruzicka> but I want that frantisekz does not suggest anything to the gnome guys !!!
17:12:29 <frantisekz> lruzicka I can suggest what I want.... :D
17:12:31 <adamw> #topic (1809717) Update gnome-shell to version 3.35.92-1 brings a lot of problems
17:12:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1809717
17:12:31 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:12:43 <adamw> so this has a bit of a complex nomination history
17:12:43 <kparal> he can't suggest them anything new, though. They definitely think about it regularly
17:13:15 <lruzicka> don't we have 3.36 already?
17:13:25 <adamw> mikhail filed and proposed as Beta blocker
17:13:27 <adamw> then closed it
17:13:41 <adamw> then re-opened it after Beta was signed off, saying one issue remains. he didn't change the proposals
17:13:44 <frantisekz> so, the problem is with 4k on x11?
17:13:58 <adamw> then Andreas proposed it as final blocker, apparently by mistake
17:14:01 <adamw> but i figured we
17:14:18 <adamw> i figured we'll keep the nomination and treat it as mikhail proposing it for Final instead of Beta
17:14:38 <kparal> I don't see what gpu he has
17:14:47 <adamw> so, yeah, afaict, Mikhail says only 1/4 of his 4k display is shown in an X11 session.
17:15:11 <frantisekz> I can try 4k display tomorrow, if it's gonna help anything?
17:15:13 <adamw> the logs suggest radeon
17:15:32 <frantisekz> I can try both intel and radeon
17:15:43 <lruzicka> frantisekz, you have a 4k display?
17:15:46 <frantisekz> yeah
17:16:17 <kparal> if it affects most or all people, I'd be +1 final, I think 4k displays are now more common
17:16:28 <kparal> *most or all people with 4k displays
17:16:36 <frantisekz> but... isn't it x11 vs wayland again...? :D
17:16:48 <frantisekz> but I'd be okay with blocking on bare metal x11 problems
17:16:51 <frantisekz> for now
17:17:00 <kparal> on bare metal I'm definitely for blocking even on X11
17:17:17 <kparal> unless we have a criterion that says we don't
17:17:20 <adamw> yeah, looks like a vega 20 gen AMD from the logs
17:17:33 <frantisekz> I can try on Polaris and Intel Kaby Lake
17:17:47 <frantisekz> thinking about it
17:17:52 <adamw> if it affects KDE on popular graphics cards i'd be inclined to block
17:18:03 <frantisekz> I can try that out right away, but only GNOME
17:18:08 <adamw> who has a 4k display they can test with?
17:18:13 <adamw> sure
17:18:15 <kparal> frantisekz: please do
17:18:35 <adamw> i'd tend to suspect this is gonna be hardware-related, but it's only a guess
17:18:41 <kparal> me too
17:18:46 <adamw> i think we should punt this for testing and see where we wind up
17:18:48 <adamw> send out a testing request
17:18:58 <kparal> ack
17:19:16 <adamw> the system logs do have this
17:19:16 <adamw> Mar 03 21:34:13 localhost.localdomain kernel: amdgpu 0000:0b:00.0: Direct firmware load for amdgpu/vega20_ta.bin failed with error -2
17:19:16 <adamw> Mar 03 21:34:13 localhost.localdomain kernel: amdgpu 0000:0b:00.0: psp v11.0: Failed to load firmware "amdgpu/vega20_ta.bin"
17:19:20 <adamw> no idea how significant it is
17:19:47 <kparal> that looks quite significant
17:19:51 <pwhalen> +1 punt for more testing
17:21:06 <lruzicka> +1 punt, unfortunately I do not have a 4k monitor
17:21:11 <frantisekz> testing it
17:21:16 <frantisekz> give me like 10 minutes :D
17:21:26 <kparal> we can come back to this
17:21:51 <frantisekz> yep
17:21:58 <adamw> proposed #agreed 1809717 - punt (delay decision) - as we understand it, the remaining issue here is 4K display on X11 not working properly. This would be a significant issue if it affects a reasonable range of hardware. We will send out a call for people to test 4K-on-X11 on various graphics hardware and see how widespread the issue is
17:22:14 <adamw> i think whichever way frantisekz's result goes i'd want more than two data points to decide :)
17:22:19 <adamw> so i think the proposal is still valid
17:22:28 <adamw> i can test too, after the meeting
17:22:29 <frantisekz> okay, I'll reply to bugzilla
17:22:35 <adamw> on a few different cards i hope
17:22:39 <kparal> ack
17:22:39 <lruzicka> ack
17:22:45 <adamw> #action adamw to send out request for testing
17:22:51 <lruzicka> Can 4k run over DVI?
17:23:05 <adamw> hmm. not sure. definitely displayport and hdmi
17:23:21 <lruzicka> adamw, no such thing on my desktop :D
17:23:23 <adamw> you'd need two dual-link DVI cables apparently
17:23:31 <adamw> dunno if linux implemenets support for that either
17:23:40 <kparal> yes, single DVI is not enough
17:24:21 <lruzicka> adamw, so if I purchased the monitor, I'd need a new graphic card as well
17:25:16 * lruzicka shrugs his shoulders sadly.
17:25:23 <adamw> doh
17:25:31 <adamw> #agreed 1809717 - punt (delay decision) - as we understand it, the remaining issue here is 4K display on X11 not working properly. This would be a significant issue if it affects a reasonable range of hardware. We will send out a call for people to test 4K-on-X11 on various graphics hardware and see how widespread the issue is
17:25:42 <adamw> #topic (1815544) libreport crashes when trying to report a crash on X11 (BadAlloc)
17:25:43 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1815544
17:25:43 <adamw> #info Proposed Blocker, libreport, ON_QA
17:26:04 <frantisekz> +1 Final Blocker
17:26:19 <kparal> frantisekz: this is also just X11
17:26:28 <frantisekz> I know
17:26:34 <kparal> alright... :)
17:26:42 <frantisekz> also bare metal kparal :)
17:26:54 <adamw> so
17:26:57 <adamw> this is conditional on two things:
17:26:59 <adamw> 1) X11
17:27:01 <adamw> 2) long logs
17:27:04 <adamw> right?
17:27:23 <kparal> 1) yes, 2) probably
17:27:28 <adamw> anyone know offhand if we install crash reporter by default on kde?
17:27:36 <adamw> kparal: "Yeah, allocating a 62830x4530 buffer will do it."
17:28:11 <kparal> I guess you have to click on the "Show details" button to show the text window, so it might not crash if you don't
17:28:24 <adamw> 62830x4530 seems pretty big
17:28:39 * adamw boots a KDE live
17:28:57 <adamw> i'm inclined to +1 here, just a bit worried it'd fail the Sgallagh Final Blocker Test
17:28:59 <lruzicka> adamw, check the application test - this deals with all apps
17:29:19 * sgallagh looks up
17:29:24 <kparal> I'm +1 here, it looks easy to hit and happens to me every time I try it
17:29:28 <adamw> it does appear to be on the KDE live
17:29:29 <kparal> two different laptops
17:29:34 <adamw> which reduces the conditionality a bit
17:29:58 <adamw> kparal: if you're using the *same crash* to reproduce every time i can see that'd do it
17:30:16 <adamw> so, think i'm tentatively +1
17:30:28 <sgallagh> FWIW, I think this would pass the Final Blocker Test
17:30:59 <sgallagh> Because presumably it would mean that we could potentially not be able to report bugs on the GA Workstation Live
17:31:06 <kparal> adamw: I'm using the same steps, but different crash instances
17:31:07 <adamw> sgallagh: well, it's X11 only
17:31:20 <adamw> sgallagh: so less likely on Workstation (only if the boot falls back to X11)
17:31:22 <sgallagh> oh, I missed that part.
17:31:30 <adamw> but we do install abrt on KDE live too, and that's X11 by default
17:31:34 <pwhalen> +1 blocker
17:31:49 <adamw> kparal: right, but the same crasher bug is likely to always produce similar logs, i guess
17:31:58 <adamw> whereas an entirely different crash might produce different logs
17:32:00 <adamw> is what i'm saying
17:32:00 <kparal> sure, yes. I can try different apps
17:32:10 <kparal> but I still think it's +1
17:32:12 <adamw> would be useful info i guess
17:32:16 <adamw> yeah, doesn't change my vote at this point
17:32:28 <sgallagh> I still think it would pass the Final Blocker test, so +1 blocker from me
17:32:31 <adamw> ok
17:32:34 <adamw> that's enough i think
17:32:45 <lruzicka> +1 for me, too
17:33:57 <adamw> proposed #agreed 1815544 - AcceptedBlocker (Final) - this is accepted as a conditional violation of the app "basic functionality" criterion, when abrt gui runs on X11, since it is part of default KDE install and KDE uses X11 by default, and even some GNOME installs fall back on X11
17:34:01 <frantisekz> ack
17:34:21 <adamw> i should get a bonus for typing these summaries around my ever-helpful secretary cat
17:34:39 <adamw> (who is perched on my lap and the space bar, purring furiously)
17:35:12 <kparal> ack
17:35:47 <lruzicka> ack
17:36:00 <adamw> #agreed 1815544 - AcceptedBlocker (Final) - this is accepted as a conditional violation of the app "basic functionality" criterion, when abrt gui runs on X11, since it is part of default KDE install and KDE uses X11 by default, and even some GNOME installs fall back on X11
17:36:17 <kparal> adamw: let's see what happens now... 🐁🐁🐁🐁🐁🐁🐁🐁🐀🐀🐀🐀🐀🐀
17:36:43 <adamw> she's looking at it :P
17:36:54 <adamw> #topic (1815463) It's impossible to create another user account through KDE System Settings
17:36:54 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1815463
17:36:54 <adamw> #info Proposed Blocker, plasma-systemsettings, NEW
17:37:00 * lruzicka is seeing white mice ... should stop wining :)
17:37:43 <kparal> so... we're reduced desktop app criteria for KDE (and others)
17:37:53 <adamw> what did we reduce it to exactly?
17:37:54 <kparal> and system configuration is not listed among the apps
17:38:15 <kparal> adamw: https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Default_application_functionality
17:38:21 <adamw> if you can reach this through the panel you can make an argument that way
17:38:34 <adamw> (though that's a huge loophole for KDE as you can get to almost frickin' anything through the panel)
17:38:43 <kparal> yes, on the other hand, we always made little distinction between "main panel" and system settings
17:38:59 <kparal> and I didn't really consider this in the proposal
17:39:08 <adamw> yeah
17:39:09 <kparal> and you failed to tell me! :)
17:39:20 <adamw> sigh, criteria
17:39:27 <adamw> see i kinda want to block on this :P
17:39:34 <kparal> :D
17:39:35 <adamw> "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."
17:39:39 <adamw> is the panel criterion
17:39:42 <adamw> if we want to judo this under that
17:40:02 <adamw> back when we wrote that panels worked pretty differnetly :P
17:40:02 <sgallagh> What about the user-switching criterion?
17:40:05 <kparal> it would be nice it that criterion really included only the panel and the overview etc
17:40:12 <adamw> sgallagh: what user switching criterion?
17:40:14 <kparal> and we could add system settings to the list of blocked on apps
17:40:15 <sgallagh> You can't switch to another user if you can't create another user...
17:40:29 <adamw> sgallagh: you can create one during install, or with any other user management tool...
17:40:32 * sgallagh looks for it
17:40:35 <kparal> but I'm somewhat scared blocking on everything that's in KDE system settings...
17:40:38 <sgallagh> OK, yeah, I guess.
17:40:44 <lruzicka> sgallagh, you could create one via useradd
17:40:51 <sgallagh> I was trying to help
17:41:13 <sgallagh> kparal: I'm reasonably sure that someday we'll discover it's possible to adjust universal constants through there.
17:41:29 <lruzicka> however, I think that settings should be part of the "core"-that-must-not-be-named-core-applications
17:41:53 <kparal> so, I can add system settings to the list, if you think it's cleaner
17:41:56 <adamw> yeah
17:41:59 <adamw> i'm +1 for that
17:42:03 <kparal> well, it's definitely cleaner! if you think I should do that...
17:42:17 <kparal> alright. Should I submit a proposal to test list or do it right away?
17:42:18 <adamw> we could maybe try to define a mini-core?
17:42:26 <adamw> as in, 'things within system settings that have to work'?
17:42:32 <adamw> we probably don't want to block on all the garbage that's in there
17:42:36 <sgallagh> Maybe give ourselves some wiggle room and say "system settings common to blocking desktops"?
17:42:38 <adamw> that brings us back to where we were before almost...
17:42:52 <kparal> well it's still subject to "basic functionality", even in system settings. So we can fudge a lot
17:43:02 <adamw> yay for fudge
17:43:17 <adamw> i remember when i was young and naive and i thought the release criteria would reduce fudging
17:43:19 <adamw> oh those long-ago days
17:43:21 <kparal> and creating system users is basic functionality because adamw wants it, see?
17:43:21 <sgallagh> mmm... fudge /homer
17:43:30 <adamw> kparal: you get how this works!
17:44:19 <kparal> so let's accept it and I'll submit the diff to test list where you can ack it
17:44:40 <kparal> the diff to the criterion
17:44:43 <lruzicka> +1
17:45:06 <kparal> adamw: btw, doesn't KDE have several system settings apps?
17:45:11 <adamw> proposed #agreed 1815463 - AcceptedBlocker (Final) - this is accepted as a violation of the "Default application functionality" Final criterion. System Settings is not currently among the specified apps for KDE but we agreed in the meeting that this was an oversight and it will be added, thus this bug can be accepted
17:45:17 <adamw> kparal: it...sort of depends what you mean by 'app'
17:45:24 <kparal> sigh
17:45:44 <kparal> ack
17:45:46 <frantisekz> ack
17:45:48 <adamw> i think they have a thing a bit like gnome's, where they appear as a zillion menu entries but they're just running one executable with different args
17:45:49 <sgallagh> ack
17:45:56 <adamw> and you can just run the entire 'settings app' directly as one thing
17:46:07 <adamw> kparal: but you can go figure it out and propose a nice change, good luck :P
17:46:25 <kparal> so...
17:46:35 <kparal> I see System Settings and User Manager in their menu
17:46:45 <kparal> which one is this bug against?
17:46:47 <adamw> maybe this really is a separate app
17:46:51 * adamw goes back to his KDE live boot
17:47:05 <adamw> gahhhh and it's broken. why do our KDE lives do this i need to figure it out one day
17:47:20 <adamw> seems like if you let them put the display in a VM to sleep it never wakes up
17:47:31 <kparal> it looks to be the User Manager app embedded in System Settings view
17:47:37 <kparal> so it's the same app
17:47:44 <adamw> whew
17:47:51 <adamw> let's go with the proposal then
17:47:53 <King_InuYasha> KDE settings use a framework called KCM
17:47:53 <kparal> ok, in that case our plan works
17:47:59 <adamw> King_InuYasha: that's the one
17:48:01 <adamw> i was trying to remember it
17:48:11 <King_InuYasha> KDE Configuration Manager
17:48:11 <adamw> #agreed 1815463 - AcceptedBlocker (Final) - this is accepted as a violation of the "Default application functionality" Final criterion. System Settings is not currently among the specified apps for KDE but we agreed in the meeting that this was an oversight and it will be added, thus this bug can be accepted
17:48:34 <adamw> #topic (1797531) Confusing error when running container with parameter --rm
17:48:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1797531
17:48:35 <adamw> #info Proposed Blocker, podman, VERIFIED
17:49:29 <adamw> anyone want to play criteria bingo?
17:49:49 <coremodule> no
17:50:20 <coremodule> -1 blocker
17:50:23 <adamw> afaik we still don't have a criteria that says 'containers must work'. in any way at all
17:50:28 <adamw> criterion, sorry
17:50:34 <adamw> so, on that basis, i'm kinda -1.
17:50:59 <adamw> if we ought to be blocking on containers not working...someone needs to write a criterion!
17:51:21 <adamw> i guess i'd be +1 FE, though i expect the update would go stable before freeze anyway
17:51:24 <lruzicka> they claim a fix is easy, so +1 FE?
17:51:47 <adamw> update is submitted already
17:52:14 <sgallagh> -1 blocker +1 FE
17:52:20 <frantisekz> -1 Blocker, +1 FE
17:52:22 <lruzicka> agree with sgallagh
17:52:30 <lruzicka> -1 blocker, +1 fe
17:53:46 <adamw> proposed #agreed 1797531 - RejectedBlocker (Final) AcceptedFreezeException (Final) - there are (still) no criteria at all requiring podman/container functionality to work at all so we really cannot block on this. However, it's obviously important functionality these days that we would want to work at release, so accepted as an FE issue
17:53:57 <coremodule> ack
17:54:01 <lruzicka> ack
17:55:31 <adamw> one more ack?
17:55:42 <kparal> ack
17:55:54 <sgallagh> ack
17:56:21 <adamw> I SAID ONE
17:56:23 <adamw> .fire sgallagh
17:56:23 <zodbot> adamw fires sgallagh
17:56:27 <adamw> #agreed 1797531 - RejectedBlocker (Final) AcceptedFreezeException (Final) - there are (still) no criteria at all requiring podman/container functionality to work at all so we really cannot block on this. However, it's obviously important functionality these days that we would want to work at release, so accepted as an FE issue
17:56:44 <adamw> #topic Proposed Final freeze exceptions
17:56:50 <adamw> #info that's all the proposed blockers, moving onto proposed FEs
17:56:51 <adamw> #topic (1809096) Progressbar during offline upgrade phase gets reset after entering "Verifying phase"
17:56:51 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1809096
17:56:51 <adamw> #info Proposed Freeze Exceptions, dnf-plugins-extras, POST
17:57:14 <lruzicka> +1 FE, it is annoying
17:57:37 <adamw> um
17:57:44 <adamw> if the fix goes to F30/F31, what's the point of an FE?
17:58:10 <frantisekz> previous release fe? :D
17:59:24 <kparal> haha
17:59:46 <adamw> so, uh, -1 unless i miss something :)
18:00:29 <kparal> -1, lawyered by adamw
18:01:27 <lruzicka> I believe the fix should go into F32, too, otherwise we'll see that next release
18:02:02 <lruzicka> and if it is fixed before final, we will not have to think about it in the future
18:02:03 <adamw> sure
18:02:06 <adamw> but it doesn't need an FE for that
18:02:26 * kparal nods
18:02:28 <adamw> if the update is held up by the freeze but otherwise ready to go stable it will go stable with the 0-day push
18:02:32 <adamw> so there's really no justification for an FE
18:02:44 <lruzicka> as you wish, then
18:03:40 <adamw> proposed #agreed 1809096 - RejectedFreezeException (Final) - as this needs to be fixed in F30 and F31 for upgrades to F32, there is no justification for an F32 freeze exception, it would not achieve anything
18:04:01 <frantisekz> ack, farewell my FE :/ :)
18:05:57 <kparal> ack
18:06:34 <lruzicka> ack
18:07:02 <adamw> #agreed 1809096 - RejectedFreezeException (Final) - as this needs to be fixed in F30 and F31 for upgrades to F32, there is no justification for an F32 freeze exception, it would not achieve anything
18:07:12 <adamw> #topic (1812449) The cursor position isn't correct during pre-editing
18:07:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1812449
18:07:12 <adamw> #info Proposed Freeze Exceptions, mutter, NEW
18:07:19 <adamw> this explains a lot!
18:07:44 <kparal> I noticed incorrect cursor position in VMs when dragging window borders
18:07:55 <kparal> and it was quite inconvenient
18:08:20 <kparal> is this the same thing?
18:08:36 <kparal> doh, completely different. This is text cursor :)
18:08:38 <adamw> no
18:08:39 <adamw> yeah
18:08:46 <adamw> but i was testing japanese input and ran into it too
18:08:55 <adamw> +1 FE for sure
18:09:01 <frantisekz> +1 FE
18:09:10 <adamw> since there's a fix upstream i think we can just accept FE and not worry about promoting to blocker
18:09:22 <lruzicka> +1 FE, setansai omedeto gosai masu
18:09:25 <kparal> +1 FE. Doesn't it break Japanese usage completely?
18:09:34 <kparal> or is "pre-editing" used just sometimes?
18:10:11 <kparal> ok, adamw says we don't need to worry, I no longer worry
18:10:57 <lruzicka> kparal, oooh ooh oooh ooh ooh ooh ooh oo oo ooooohh, don't worry, be happy now
18:13:13 <adamw> kparal: you can work around it but it's pretty painful
18:14:53 <adamw> proposed #agreed 1812449 - AcceptedFreezeException (Final) - this is very inconvenient for the default Japanese input method and various other similar ones, and cannot be fixed for live environments with an update
18:14:56 <frantisekz> ack
18:17:28 <lruzicka> ack
18:20:15 <adamw> #agreed 1812449 - AcceptedFreezeException (Final) - this is very inconvenient for the default Japanese input method and various other similar ones, and cannot be fixed for live environments with an update
18:20:18 <adamw> (that's enough acking)
18:20:21 <adamw> OK, that is all we had!
18:20:24 <adamw> #topic Open floor
18:20:27 <adamw> any other business, folks?
18:21:02 <kparal> nothing here
18:21:29 <frantisekz> thanks for the meeting everybody, nothing more from me
18:21:34 <lruzicka> I do not have anything
18:21:56 * lruzicka thanks everybody
18:22:39 <adamw> ok, everyone can go back to obsessively refreshing the news from their back yard toilet paper fortresses
18:23:52 <kparal> :)
18:24:01 <kparal> thanks adamw for chairing
18:24:37 <kparal> I heard you can't catch the virus while being in a toilet paper fortress
18:24:58 <adamw> seems legit
18:25:15 <kparal> tinfoil wrap around the whole head also works
18:25:26 <lruzicka> kparal, you even can't catch a breath :D
18:25:41 <kparal> that's how you don't inhale the virus
18:26:59 <adamw> ok, thanks everyone!
18:27:05 <adamw> stay safe in there
18:27:07 <adamw> #endmeeting