16:02:22 <adamw> #startmeeting F31-blocker-review
16:02:22 <zodbot> Meeting started Mon Sep 16 16:02:22 2019 UTC.
16:02:22 <zodbot> This meeting is logged and archived in a public location.
16:02:22 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:22 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:02:23 <adamw> #meetingname F31-blocker-review
16:02:23 <adamw> #topic Roll Call
16:02:23 <zodbot> The meeting name has been set to 'f31-blocker-review'
16:02:29 <frantisekz> .hello2
16:02:30 <bcotton> .hello2
16:02:30 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:32 <adamw> morning folks, who's around for blocker review fun?
16:02:33 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:02:38 <coremodule> .hello2
16:02:40 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
16:02:41 <lruzicka> .hello2
16:02:43 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:03:00 <Southern_Gentlem> .hello2
16:03:01 <zodbot> Southern_Gentlem: Sorry, but you don't exist
16:03:04 <satellit_> present
16:03:33 <satellit_> .hello2
16:03:34 <zodbot> satellit_: Sorry, but you don't exist
16:03:44 <sgallagh> .hello2
16:03:45 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:04:39 <adamw> #chair sgallagh lruzicka
16:04:39 <zodbot> Current chairs: adamw lruzicka sgallagh
16:04:49 * coremodule is willing to act as secretary.
16:04:49 <adamw> awooga, impending boilerplate, awooga
16:04:55 <adamw> #topic Introduction
16:04:56 <adamw> Why are we here?
16:04:56 <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:04:56 <adamw> #info We'll be following the process outlined at:
16:04:56 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:04:57 <adamw> #info The bugs up for review today are available at:
16:04:59 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:01 <adamw> #info The criteria for release blocking bugs can be found at:
16:05:03 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:05:05 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Beta_Release_Criteria
16:05:07 <adamw> #link https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria
16:05:09 <adamw> #info coremodule will secretarialize
16:05:20 <adamw> #info for Final, we have:
16:05:25 <adamw> #info 7 Proposed Blockers
16:05:25 <adamw> #info 6 Accepted Blockers
16:05:28 <adamw> #info 1 Proposed Freeze Exceptions
16:05:39 * kparal is here as well, awooga
16:08:43 <adamw> awooga!
16:08:51 <adamw> #info let's get started with proposed blockers
16:08:58 <adamw> #topic (1751673) Second user gets locked out of his session every ~10 seconds
16:08:58 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1751673
16:08:58 <adamw> #info Proposed Blocker, gdm, NEW
16:10:24 <bcotton> +1 blocker
16:10:28 <coremodule> hmmm, I'm +1 blocker based off the criterion stated
16:10:34 <lruzicka> +1 blocker
16:10:47 <frantisekz> +1 B
16:11:38 <sgallagh> kparal: Just to confirm, is it actually *locking* user2 or is it just switching to the user1 lock screen?
16:11:49 <sgallagh> Does ctrl-alt-fN work to get back to user2?
16:12:21 <sgallagh> Never mind, just saw the latest comment
16:12:31 * pwhalen is here
16:12:36 <pwhalen> +1 blocker
16:13:19 <kparal> it's switching to a different tty
16:13:24 <kparal> the session is not actually locked
16:13:32 <adamw> i think at some point we specifically excepted user switching from the criteria because desktop team didn't want it in there, but someone from desktop team +1ed it in bug, so i can go +1
16:13:35 <kparal> which might or might not be even worse, pick your side :)
16:13:52 <sgallagh> I'm +1 as well
16:13:54 <adamw> if we're gonna accept user switch bugs, though, maybe we should write it into the 'login/logout/etc/shutdown/reboot' criterion...
16:14:15 <kparal> adamw: we've accepted some user switching bug in the past through the desktop panel functionality and there was no problem with it
16:14:19 <adamw> oh, k
16:14:29 <frantisekz> hmm, it's weird, because there is no "switch user" button in gnome
16:14:36 <kparal> adamw: and we haven't excepted it, we wanted to write a specific criterion for it and that didn't fly at that time
16:14:49 <adamw> kparal: i'll have to check the history again
16:14:59 <frantisekz> you need to lock the screen and then press "login as another user"
16:15:00 <kparal> frantisekz: yes, that got lost, but it's not something that prevents you from switching users, it's just more clicks
16:15:09 <adamw> yeah, it's just a ui change
16:15:21 <kparal> I think the missing button is a bug, we can ask
16:15:32 <adamw> proposed #agreed 1751673 - AcceptedBlocker (Final) - this is accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"
16:15:39 <kparal> there was a bug about it in the past and got fixed, perhaps it appeared again
16:15:42 <frantisekz> ack
16:15:51 <sgallagh> ack
16:15:54 <adamw> maybe check when it went missing too?
16:16:01 <bcotton> ack
16:16:06 <lruzicka> ack
16:16:06 <kparal> ack
16:16:10 <coremodule> ack
16:16:15 <adamw> #agreed 1751673 - AcceptedBlocker (Final) - this is accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"
16:16:23 <adamw> #topic (1750805) Apply button stays gray on Network configuration
16:16:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1750805
16:16:24 <adamw> #info Proposed Blocker, gnome-control-center, NEW
16:16:43 <bcotton> +1
16:16:45 <frantisekz> seems like +1 Blocker
16:17:01 <coremodule> +1 blocker
16:17:09 <kparal> yeah, seems blockery
16:17:40 <sgallagh> +1 blocker
16:17:41 <pwhalen> +1 Blocker
16:18:06 <lruzicka> +1 blocker
16:18:15 <adamw> +1
16:18:38 <adamw> proposed #agreed 1750805 - AcceptedBlocker (Final) - this is accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."
16:18:43 <coremodule> ack
16:18:46 <bcotton> ack
16:18:48 <lruzicka> ack
16:18:54 <frantisekz> ack
16:18:55 <pwhalen> ack
16:19:00 <adamw> #agreed 1750805 - AcceptedBlocker (Final) - this is accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use."
16:19:10 <adamw> #topic (1749868) GNOME Software doesn't prepare offline updates
16:19:10 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1749868
16:19:10 <adamw> #info Proposed Blocker, gnome-software, NEW
16:20:04 <frantisekz> hmm, -1, if I am not missing anything there
16:20:23 <kparal> the DNF change will get reverted
16:20:24 <frantisekz> is it just broken if some repo that doesn't have skip if unavail is unavailable?
16:20:26 <bcotton> #info fesco has asked dnf to revert the change that appears to be causing it
16:20:46 <frantisekz> even without reverting the dnf change, that shouldn't have been a blocker imo
16:20:48 <kparal> with that DNF change back, I think the criticality of this bug is much lower
16:20:50 <bcotton> frantisekz: that's my understanding
16:21:00 <Southern_Gentlem> -1
16:21:24 <kparal> frantisekz: I don't agree with you, but since the dnf change gets reverted, the discussion is moot I think
16:21:29 <lruzicka> the bug, as it is now, prevents people from upgrading
16:21:33 <frantisekz> kparal: yep
16:21:44 <adamw> -1 with the dnf revert
16:21:55 <coremodule> can we punt again to see if the revert actually fixes it?
16:21:58 <lruzicka> it should not be ... because it is not reverted yet
16:22:00 <frantisekz> (lruzicka: and that means it's working as it should by definition)
16:22:18 <coremodule> I'm asking if that's a viable option, or are we sure that it's being caused by new dnf
16:22:19 <kparal> coremodule: probably makes sense to wait until the dnf revert is done, yes
16:22:32 <adamw> i'd be fine -1ing it for now or punting, either way
16:23:02 <kparal> frantisekz: no, it's not working as it should, because the user is not informed in any meaningful way
16:23:12 <bcotton> +1 punt so it stays on our radar
16:23:14 <pwhalen> +1 punt
16:23:14 <coremodule> tbh I feel the same way, but just in case it turns out to be related to something else, it might be wise to punt for a week...
16:23:18 <lruzicka> I think this is a bug because it violates the criteria of upgrading and when it gets fixed, it is fixed and goes away
16:23:28 <bcotton> kparal: it's working as designed, which may or may not be as it should
16:23:36 <frantisekz> kparal: imo, bad error message doesn't mean it isn't working, I wouldn't block on that
16:23:48 <bcotton> lruzicka: but it doesn't happen with default repos
16:23:50 <Southern_Gentlem> punt +1
16:23:56 <kparal> it depends what you consider 'working'
16:24:04 <frantisekz> but... discussion about this doesn't make too much sense now, it's going to be fixed on dnf side
16:24:08 <kparal> inobvious error message is not 'working' for me
16:24:19 <kparal> frantisekz: that we can agree on
16:24:19 <sgallagh> We define working as "able to get updates"
16:24:24 <frantisekz> (also, upgrades with non-default repos are not supported either if I understand it correctly)
16:24:27 <sgallagh> If we can't get updates, that's pretty clear to me
16:24:39 <kparal> frantisekz: workstation repos are somewhat semi-official
16:24:40 <sgallagh> frantisekz: *that* is a fair argument, however
16:24:50 <sgallagh> Wait, it's the workstation repo that's doing this?
16:24:50 <lruzicka> frantisekz, but we are not any fortune tellers ... its not fixed now
16:24:52 <frantisekz> kparal: that's fixed already in workstation repos
16:24:53 <adamw> proposed #agreed 1749868 - punt (delay decision) - we believe the reversion of the DNF skip_if_unavailable default to True should mean this is no longer a big enough problem to be a blocker, we will confirm this once the reversion is done
16:25:04 <pwhalen> ack
16:25:05 <coremodule> ack
16:25:06 <sgallagh> nack
16:25:09 <kparal> frantisekz: hrm, you're right about that
16:25:10 <bcotton> ack
16:25:16 <frantisekz> sgallagh?
16:25:16 <kparal> ack
16:25:26 <sgallagh> Actually, I withdraw that
16:25:29 <sgallagh> Never mind
16:25:32 <frantisekz> ack
16:25:34 <adamw> sgallagh: i counted 4 votes for punt, none for anything else
16:25:40 <adamw> oh, maybe 1 for blocker
16:25:59 <adamw> #agreed 1749868 - punt (delay decision) - we believe the reversion of the DNF skip_if_unavailable default to True should mean this is no longer a big enough problem to be a blocker, we will confirm this once the reversion is done
16:26:02 <lruzicka> I reproduced on a clean system, no other repos than standard repos
16:26:04 <sgallagh> I was considering blocker, but if none of our repos are causing it, I'm fine with punt
16:26:13 <sgallagh> lruzicka: Wait, what?
16:26:26 <frantisekz> lruzicka: I'd guess networks issue, or some bigger problem if not that
16:26:33 <frantisekz> *network
16:26:37 <lruzicka> when I tested for this bug, I only had a clean F31 with third party repos enabled on my VM
16:26:49 <lruzicka> i did not have any PyCharm repos added or anything
16:26:51 <adamw> i think we have differing definitions of 'clean' :P
16:26:58 <frantisekz> lruzicka: third party repos...
16:27:01 <frantisekz> that's not clean :)
16:27:14 <lruzicka> third party repos is a standard choice of Gnome Software
16:27:15 <adamw> well, the workstation third party repos are a somewhat awkward case here
16:27:27 <adamw> but anyway
16:27:27 <frantisekz> lruzicka: no, it's not on by default
16:27:38 <lruzicka> these are no awkward repos
16:27:41 <adamw> i think the resolution holds regardless
16:27:44 <kparal> frantisekz is correct that we fixed workstation repos by adding skip_if_unavailable=True
16:27:53 <kparal> I forgot about that
16:28:03 <lruzicka> but it still is a bug until fixed
16:28:09 <lruzicka> and ergo a blocker
16:28:33 <adamw> is anyone changing their vote here?
16:28:37 <kparal> nope, punt
16:28:39 <lruzicka> +1
16:28:42 <frantisekz> nope, okay with punt
16:28:44 <bcotton> i'm still punt
16:28:44 <lruzicka> +1 blocker
16:29:01 <kparal> lruzicka: right now, you can only hit it with extra repos which are not workstation repos (those were fixed)
16:29:04 <frantisekz> lruzicka: what's the reason for blocking? on what criterion?
16:29:31 <frantisekz> those third party repos are fixed
16:29:35 <lruzicka> frantisekz, Gnome Software does not work with that
16:29:55 <kparal> define "that"
16:29:56 <frantisekz> if you add a third party repo... you are on your own
16:30:23 <frantisekz> there is no criterion for blocking on system with other repos added
16:30:31 <lruzicka> kparal, that = with that condition described in the bug
16:30:34 <frantisekz> you can propose some, if you think we should block on those systems
16:30:50 <lruzicka> I do really not understand your point.
16:30:54 <kparal> lruzicka: I proposed this because it could be hit with workstation repos, and those are somewhat gray area - semi-official. But you can no longer do that.
16:31:02 <sgallagh> frantisekz: He's talking about a built-in switch in GNOME Software that enables some other repos
16:31:18 <sgallagh> lruzicka: But the point is that those *specific* repos have already had a fix appl;ied
16:31:21 <sgallagh> Just not in time for Beta
16:31:27 <frantisekz> oh, kparal and myself have mentioned it's fixed, I didn't think he was talking about that
16:31:31 <kparal> well in gnome-software you have workstation extra repos and openh264, that's it
16:31:33 <lruzicka> something is or is not a blocker. But saying that it is not a blocker because it its going to get fixed anyway? what sort of criteria is that?
16:31:48 <adamw> we're not saying it's not a blocker, we're punting
16:32:04 <kparal> lruzicka: I don't think we're understanding each other
16:32:16 <lruzicka> we probably are not
16:32:23 <kparal> I'll explain it tomorrow :)
16:32:32 <kparal> punt for now, fine for you?
16:33:00 <lruzicka> I could live with punt.
16:33:24 <kparal> ok, already agreed, let's move on then
16:33:50 <adamw> #topic (1747408) Cannot upgrade to Fedora 31: package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
16:33:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1747408
16:33:50 <adamw> #info Proposed Blocker, libgit2, NEW
16:34:24 <frantisekz> (here I am... 100 % happy with modularity repos disabled and none of this ever hit me.... :) )
16:34:36 <adamw> so, per the criterion this is still -1, the criterion covers only default package sets
16:34:53 <frantisekz> yeah, -1, though, would be nice to have it fixed, FE maybe?
16:34:56 <adamw> though, i would be sad if we didn't do *something* about this, it's a dumb bug
16:35:27 <bcotton> if we don't give it blocker status, i'll nominate for Priortized Bugs so that mattdm gets to pester people about it :-)
16:35:50 <sgallagh> frantisekz: Disabling the modular repos will not work for too much longer. They're not optional.
16:35:57 <frantisekz> yeah, we don't have criteria for blocking on that, but Priortized Bug sounds like a good idea
16:35:59 <sgallagh> I'm frankly surprised they work at all for you today
16:36:04 <frantisekz> sgallagh, sigh :(
16:36:18 <bcotton> -1 blocker, +1 FE since it's sucky but doesn't involve default package sets
16:36:28 <sgallagh> Same, -1/+1
16:36:45 <lruzicka> currently, the libgit2 has a DEFAULT stream in F31. If I correctly understand, anytime an application asks for it, it will be installed from the modules. Am I correct, sgallagh ?
16:37:23 <lruzicka> so, although this is not standard, it can really bite a lot of people
16:37:24 <sgallagh> lruzicka: Correct. The default stream is 0.28
16:37:43 <sgallagh> What do you mean "not standard"?
16:38:05 <lruzicka> sgallagh, standard packages that is installed in the default set?
16:38:24 <sgallagh> Ok, it's not a default-installed package. That's correct.
16:38:38 <pwhalen> -1 Blocker/+1 FE
16:38:46 <sgallagh> But I know what the root problem is and I've been trying to get the DNF folks to prioritize it higher
16:39:00 <adamw> just for the record, the reason we have this 'default package sets' rule is that it's very difficult to draw a line for upgrade tests
16:39:20 <adamw> if you don't draw the line there you have to come up with some other horrible line about blocking on 'sufficiently widely-installed packages' or something like that, and it gets awful
16:40:05 <lruzicka> adamw, if we do not block on that, this must be documented in big letters
16:40:29 <frantisekz> there is written on what we block on
16:40:31 <bcotton> sgallagh: have a link? or want to join their team's 8am ET call tomorrow?
16:40:43 <frantisekz> we don't block on anything else as I understand that
16:40:56 <sgallagh> bcotton: I'll get back to you on the former. As to the latter, I'll be unavailable tomorrow
16:41:02 <bcotton> sgallagh: ack
16:41:24 <adamw> lruzicka: the criterion is "For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed."
16:41:54 <frantisekz> (theoretically, install vim on workstation and if you can't upgrade because of that, it's not blocking :) )
16:43:33 <lruzicka> I dont argue. I am saying its bad and should be documented well.
16:43:58 <kparal> add commonbugs for such cases
16:44:42 <lruzicka> Because becaues gnome-builder was involved in it
16:45:14 <adamw> yep, we'll definitely commonbugs this at worst
16:46:00 <adamw> proposed #agreed 1747408 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we reject this as a Final blocker for the same reason we rejected it for Beta: it does not affect any release-blocking default package set, so does not break the criteria. But it's definitely a bad bug and we'd like it resolved if at all possible, and documented if it is not resolved
16:46:26 <lruzicka> patch
16:46:37 <adamw> patch away!
16:46:51 <lruzicka> no, not needed
16:47:00 <frantisekz> ack
16:47:06 <lruzicka> adamw, I thought there was a typo
16:47:07 <bcotton> ack
16:47:10 <lruzicka> ack
16:48:06 <sgallagh> r
16:48:12 <sgallagh> oops, wrong window
16:48:48 <adamw> #agreed 1747408 - RejectedBlocker (Final) AcceptedFreezeException (Final) - we reject this as a Final blocker for the same reason we rejected it for Beta: it does not affect any release-blocking default package set, so does not break the criteria. But it's definitely a bad bug and we'd like it resolved if at all possible, and documented if it is not resolved
16:50:01 <adamw> #topic (1750036) Problem with time syncronization
16:50:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1750036
16:50:02 <adamw> #info Proposed Blocker, selinux-policy, ASSIGNED
16:51:34 <coremodule> I mean it "technically" starts properly, it just doesn't work like it should...
16:51:47 <kparal> or we can argue the desktop panel doesn't work as expected
16:52:02 <bcotton> i'd back kparal's argument
16:52:14 <sgallagh> I would as well
16:52:16 <frantisekz> yeah, I don't think we have a better suiting criterion
16:52:24 <bcotton> +1 blocker
16:52:27 <frantisekz> +1
16:52:29 <coremodule> Yes, me too, I was just showing that I think the criterion stated was a little obtuse.
16:52:29 <sgallagh> +1
16:52:33 <coremodule> +1
16:52:34 <adamw> i mean, i'd be willing to argue very strongly that we could count this as not "starting properly"
16:52:36 <lruzicka> +1
16:52:51 <kparal> adamw: does it matter which criterion we pick?
16:52:51 <adamw> just because systemctl is green doesn't mean the service actually *works*
16:52:54 <adamw> not a lot
16:52:56 <sgallagh> We could also probably count this against the domain criteria, as a lack of time-sync will break logins
16:53:04 <kparal> I don't personally care which one we use
16:53:09 <adamw> i'll use them all!
16:53:25 <kparal> adamw: just watch the character limitation :)
16:53:34 <coremodule> Sure, but what defines "start properly" in the criterion; systemctl reporting it "start"ed, or the service *actually* working like it should...
16:53:39 <coremodule> Semantics, I love them. :)
16:53:42 <Southern_Gentlem> +1
16:53:55 <kparal> coremodule: you might say the magic is in the word "properly" :)
16:54:26 <coremodule> Yeah, I could see that
16:54:35 <adamw> proposed #agreed 1750036 - AcceptedBlocker (Final) - this is accepted as a blocker with reference to multiple criteria: default panel functionality (as this affects time configuration), system services (as the service does not really start 'properly'), and domain-related criteria (as lack of time synchronization will often break domain authentication)
16:54:35 <kparal> a hanging process can also show up as green in systemd
16:54:42 <sgallagh> ack
16:54:46 <bcotton> ack
16:54:51 <kparal> ack
16:54:52 <lruzicka> ack
16:54:55 <coremodule> ack
16:55:00 <kparal> adamw: you nailed the char limit on first attempt
16:55:01 <adamw> #agreed 1750036 - AcceptedBlocker (Final) - this is accepted as a blocker with reference to multiple criteria: default panel functionality (as this affects time configuration), system services (as the service does not really start 'properly'), and domain-related criteria (as lack of time synchronization will often break domain authentication)
16:55:11 <adamw> kparal: i'm a legend
16:55:22 <kparal> #info adamw is a legend
16:55:29 <adamw> =)
16:55:29 <adamw> #topic (1750345) [abrt] gnome-initial-setup: webkitWebViewBaseMakeGLContextCurrent(): gnome-initial-setup killed by SIGSEGV
16:55:29 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1750345
16:55:29 <adamw> #info Proposed Blocker, webkit2gtk3, NEW
16:55:50 <frantisekz> +1 i guess
16:56:07 <kparal> this is about the crash, I'll file a next one for the rendering not working properly
16:56:32 <bcotton> +1
16:56:50 <frantisekz> however, I don't see it in installed system
16:56:55 <sgallagh> +1
16:56:55 <lruzicka> +1
16:57:11 <frantisekz> like kparal mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1750345#c15
16:58:02 <kparal> I think that's not that important, g-i-s is enough
16:58:10 <kparal> but I saw it on my first attempt
16:58:15 <kparal> no races, always crashes
16:58:19 <frantisekz> yeah, it's still +1 even if it happened only in gis
16:58:26 <adamw> +1 per comment #15
16:59:34 <adamw> proposed #agreed 1750345 - AcceptedBlocker (Final) - this is accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"
16:59:39 <frantisekz> ack
16:59:40 <adamw> (boy that criterion is getting a workout today)
16:59:46 <frantisekz> :D
16:59:48 <lruzicka> ack
16:59:53 <coremodule> lol ack
17:00:03 <kparal> ack
17:00:30 <adamw> #agreed 1750345 - AcceptedBlocker (Final) - this is accepted as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"
17:00:37 <adamw> #topic (1751852) Xfce is using upstream desktop background
17:00:37 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1751852
17:00:37 <adamw> #info Proposed Blocker, xfdesktop, ON_QA
17:00:43 <adamw> clear +1 under the criteria
17:00:45 <bcotton> +1
17:00:47 <lruzicka> +1
17:01:11 <coremodule> +1 blocker
17:01:13 <kparal> might be even an automatic blocker :)
17:01:19 <pwhalen> +1
17:01:31 <frantisekz> hmm, is this really a blocker? I am playing devil's advocate here, but isn't criterion that the wallpaper should be different than it was in previous release?
17:01:34 <frantisekz> anyway +1
17:01:45 <kparal> frantisekz: no, this final one is different
17:01:51 <kparal> *the
17:01:55 <frantisekz> okay, I knew I've missed something :)
17:02:10 <sgallagh> +1
17:02:35 <adamw> only the 'not different from previous release' bit is covered under automatic criteria
17:02:43 <kparal> frantisekz: https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Artwork
17:02:59 <kparal> adamw: oh it is? ok, never mind me
17:03:04 <adamw> the 'has to be the correct final artwork' bit is not, because i figured there's more room for corner cases tehre
17:03:10 <kparal> sure
17:03:14 <adamw> (what if one pixel is out of place or something)
17:03:38 <lruzicka> adamw, then the criteria applies of course
17:03:58 <kparal> adamw: I don't see it there: https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers
17:04:05 <adamw> proposed #agreed 1751852 - AcceptedBlocker (Final) - this is accepted as a violation of "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops..."
17:04:14 <bcotton> ack
17:04:15 <kparal> ack
17:04:18 <frantisekz> ack
17:04:20 <pwhalen> ack
17:04:24 <Southern_Gentlem> ack
17:04:34 <adamw> kparal: oh, right, it was a proposal still
17:04:36 <adamw> we didn't finalize it
17:04:41 <kparal> ok
17:04:41 <adamw> #agreed 1751852 - AcceptedBlocker (Final) - this is accepted as a violation of "The proposed final Fedora artwork must be included and used as the background on release-blocking desktops..."
17:05:05 <adamw> that's all the proposed blockers
17:05:18 <adamw> #topic Proposed Final freeze exception
17:05:27 <adamw> #topic (1751936) Google account shows just empty window
17:05:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1751936
17:05:28 <adamw> #info Proposed Freeze Exceptions, gnome-online-accounts, NEW
17:05:37 <adamw> so, this is the 'other bug'?
17:05:40 <frantisekz> isn't that the same issue as the blocker in gis?
17:05:42 <kparal> nice, Petr already reported this one
17:05:47 <kparal> it's the same one, but about rendering
17:05:54 <kparal> I think it should be proposed as a blocker as well
17:06:05 <adamw> yeah
17:06:07 <frantisekz> hmm, okay
17:06:23 <adamw> i'd probably be +1 blocker
17:06:24 <kparal> or we can have a single one about "working ok"
17:06:35 <adamw> if we're +1 on it crashing, don't see why we'd be -1 on it not crashing but not displaying anything
17:06:37 <kparal> as you wish. but for developers those are 2 different bugs
17:06:49 <frantisekz> it doesn't happen to me on bare metal
17:06:53 <frantisekz> it works just fine
17:06:54 <kparal> yes, +1
17:07:13 <kparal> frantisekz: perhaps the gnome megaupdate could fix something?
17:07:18 <pwhalen> +1
17:07:27 <frantisekz> I am testing with gnome-control-center-3.34.0.1-1.fc31.x86_64
17:07:34 <kparal> yes, that's the megaupdate
17:07:40 <lruzicka> +1
17:07:50 <frantisekz> and latest webkitgtk
17:07:50 <kparal> oh, but Petr used the same version
17:08:08 <kparal> I'll be happy to retest tomorrow. I certainly reproduced it a few days back
17:08:11 <bcotton> +1
17:08:32 <frantisekz> +1, but I think it's fixed already
17:08:38 <adamw> +1 in principle, we can work out the details of what's fixed where later
17:08:40 <adamw> oh
17:08:48 <adamw> can people clarify if they mean "+1 blocker" or "+1 FE"?
17:08:50 <adamw> I'm +1 blocker
17:08:53 <kparal> +1 blocker
17:08:54 <frantisekz> yeah, blocker
17:08:55 <pwhalen> +1 blocker
17:09:18 <lruzicka> +1 blocker
17:09:21 <bcotton> +1 blocker
17:09:50 <lruzicka> adamw, frantisekz:  "+1 in principle" ... yes, I like this formulation.
17:10:31 <adamw> proposed #agreed 1751936 - AcceptedBlocker (Final) - we accept this as a *blocker*, not just an FE, as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"
17:10:40 <frantisekz> ack
17:10:43 <lruzicka> ack
17:10:47 <coremodule> ack
17:10:52 <bcotton> ack
17:11:06 <pwhalen> ack
17:11:13 <kparal> ack
17:11:52 <adamw> #agreed 1751936 - AcceptedBlocker (Final) - we accept this as a *blocker*, not just an FE, as a violation of "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"
17:12:43 <adamw> #topic Accepted blockers
17:12:54 <adamw> #info most of these are in a fairly straightforward state and don't need particular followup
17:13:16 <adamw> but..
17:13:33 <adamw> #topic (1728240) Cannot start Fedora-KDE-Live (F31) in basic graphics mode on BIOS machine
17:13:33 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1728240
17:13:33 <adamw> #info Accepted Blocker, sddm, NEW
17:13:35 <adamw> this one worries me a bit
17:13:55 <adamw> all we have from a dev is 'hey can qa bisect this for us'
17:14:20 <frantisekz> adamw: I've seen some issues also with gdm last week
17:14:25 <frantisekz> in bios/nomodeset mode
17:14:32 <frantisekz> I'll dig more into this tomorrow
17:14:43 <frantisekz> (gdm worked but session wouldn't start)
17:15:30 <lruzicka> it's here on my testing machine, so we can probably take a look
17:16:09 <adamw> yeah, it seems like we might need to provide at least more specific details / logs to get any movement here
17:16:17 <adamw> and if we actually could bisect it down to a specific systemd change that'd be good too
17:16:23 <adamw> can i action you guys?
17:16:30 <frantisekz> yeah, bisecting on systemd would be fun...
17:16:38 <frantisekz> you can throw action item my way
17:17:22 <adamw> #action frantisekz and lruzicka to further investigate on this bug (sddm (and possibly gdm?) issues with basic graphics mode)
17:17:26 <frantisekz> would be nice if it happenned in vm though, automating bisecting/compiling/testing would be easier .. sigh
17:18:22 <adamw> ok then
17:18:25 <adamw> #topic Open floor
17:18:30 <adamw> any other f31-release-related business, folks?
17:19:15 <kparal> nothing here
17:19:29 <coremodule> nothing here either
17:19:42 <frantisekz> nothing from me
17:19:50 <frantisekz> thanks for the meeting
17:20:04 <adamw> you're welcome
17:20:09 <adamw> additional meetings can be arranged on request ;)
17:20:17 <frantisekz> and off for some beers :) , as usual
17:20:17 <frantisekz> :D
17:21:12 <kparal> frantisekz: sure, right once you resolve all your pending action items...
17:21:16 <frantisekz> -_-
17:21:29 <frantisekz> (I still have PTO kparal for today)
17:21:53 <kparal> frantisekz: ok, that warrants an exception for you. but just today
17:21:57 <lruzicka> thanks
17:21:59 <frantisekz> :) uff
17:22:12 <kparal> frantisekz: at midnight, your duties are up
17:22:36 <frantisekz> (frantisekz has disappeared)
17:23:50 <kparal> I'm a very lenient overlord
17:24:22 <adamw> frantisekz has turned into a pumpkin
17:25:00 <adamw> alrighty, thanks again everyone
17:25:02 <adamw> #endmeeting