16:00:46 <coremodule> #startmeeting F35-blocker-review
16:00:46 <zodbot> Meeting started Mon Sep 13 16:00:46 2021 UTC.
16:00:46 <zodbot> This meeting is logged and archived in a public location.
16:00:46 <zodbot> The chair is coremodule. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:46 <zodbot> The meeting name has been set to 'f35-blocker-review'
16:00:47 <coremodule> #meetingname F35-blocker-review
16:00:47 <coremodule> #topic Roll Call
16:00:47 <zodbot> The meeting name has been set to 'f35-blocker-review'
16:00:56 <coremodule> good morning all, who is around for a blocker review?
16:01:02 <bcotton> .hello2
16:01:03 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:01:05 <bittin> .hello2
16:01:06 <zodbot> bittin: bittin 'Luna jernberg' <droidbittin@gmail.com>
16:03:09 <lruzicka2> .hello lruzicka
16:03:10 <zodbot> lruzicka2: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:04:05 <geraldosimiao> .hello geraldosimiao
16:04:06 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:04:40 <pwhalen> .hello2
16:04:41 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
16:05:01 <coremodule> #chair bcotton pwhalen lruzicka2
16:05:01 <zodbot> Current chairs: bcotton coremodule lruzicka2 pwhalen
16:05:22 <coremodule> #topic Introduction
16:05:22 <coremodule> Why are we here?
16:05:22 <coremodule> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:05:22 <coremodule> #info We'll be following the process outlined at:
16:05:22 <coremodule> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:05:24 <coremodule> #info The bugs up for review today are available at:
16:05:26 <coremodule> #link http://qa.fedoraproject.org/blockerbugs/current
16:05:28 <coremodule> #info The criteria for release blocking bugs can be found at:
16:05:30 <coremodule> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:05:32 <coremodule> #link https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria
16:05:34 <coremodule> #link https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria
16:05:36 <coremodule> #info 0 Proposed Blockers
16:05:38 <coremodule> #info 6 Accepted Blockers
16:05:40 <coremodule> #info 0 Accepted 0-day Blockers
16:05:42 <coremodule> #info 0 Accepted Previous Release Blockers
16:05:44 <coremodule> #info 6 Proposed Freeze Exceptions
16:05:46 <coremodule> #info 7 Accepted Freeze Exceptions
16:05:58 <coremodule> #topic Proposed Freeze Exceptions
16:06:19 <coremodule> #topic (2003308) Making Design Suite available for Fedora 35 Beta
16:06:19 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2003308
16:06:19 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/446
16:06:19 <coremodule> #info Proposed Freeze Exceptions, distribution, NEW
16:06:20 <coremodule> #info Ticket vote: BetaFreezeException (+6,0,-0) (+kevin, +zbyszek, +kparal, +lruzicka, +geraldosimiao, +sumantrom)
16:06:41 <coremodule> I think this has already been accepted in bug and in app, I don't know why it's still here...
16:07:16 <brunowolff> I wanted to note that bug 2003701 shouldn't be a blocker despite its security designation, because it applies to unsquashfs, not mksquashfs.
16:07:35 <coremodule> several of these have already been marked accepted. Is anyone able to trigger a blocker bugs app refresh?
16:07:58 <coremodule> brunowolff, Could you bring that up when we get to that bug?
16:08:34 <bcotton> coremodule: looks like it refreshed at the top of the hour?
16:08:53 <coremodule> it didn't pull in several of these that were marked accepted before then...
16:09:13 <bcotton> computers are the worst
16:09:17 <brunowolff> It probably isn't on the list as I just made it this morning after noting an upstream commit. I didn't want people alarmed by the new update for squashfs-tools.
16:09:27 <coremodule> lruzicka2, do you know if frantisekz is around to refresh the blocker bug app?
16:10:07 <kparal> frantisekz is on PTO the whole week
16:10:19 <lruzicka2> yeah
16:10:43 <coremodule> okay! We'll work around it!
16:10:49 <bittin> adamw, is also gone today
16:10:49 <kparal> I'll can look into the syncing issue tomorrow, perhaps the latest pull failed or something
16:11:04 <bittin> kparal +1
16:11:36 <coremodule> #info Blocker bugs app is not properly syncing, so we'll work around it and only look at FE's that weren't just accepted
16:11:37 <coremodule> #topic (1962238) python-django-auth-ldap fails to build with Python 3.10: AssertionError: 5 != 1
16:11:37 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1962238
16:11:37 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/451
16:11:37 <coremodule> #info Proposed Freeze Exceptions, python-django-auth-ldap, MODIFIED
16:11:42 <coremodule> alright, let's start here
16:12:16 <coremodule> +1 FE looks like it's already fixed
16:12:57 <coremodule> ah, something I did forget to ask, being as I'm the one hosting, who wants to act as secretary for the meeting today?
16:12:57 <lruzicka2> +1 FE, too
16:13:00 <bittin> coremodule, seems to have been fixed earlier today +1 FE
16:13:10 <pwhalen> +1 FE
16:13:49 <geraldosimiao> +1 FE
16:14:31 <bcotton> 0 FE. Not generally a fan of pulling in FTBFS fixes that don't affect ISOs but I won't object since the consensus is that this is a good thing
16:16:30 <coremodule> duly noted
16:16:31 <coremodule> proposed #agreed 1962238 - The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that cannot be fixed with an update.
16:17:02 <bcotton> ack
16:17:09 <geraldosimiao> ack
16:17:21 <bittin> ack
16:17:35 <coremodule> #agreed 1962238 - The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that cannot be fixed with an update.
16:17:38 <pwhalen> ack
16:18:03 <coremodule> #topic (1965963) watchman: FTBFS in Fedora rawhide
16:18:03 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1965963
16:18:03 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/452
16:18:03 <coremodule> #info Proposed Freeze Exceptions, watchman, MODIFIED, depends on other bugs
16:18:30 <lruzicka2> coremodule, being a secretary means adding the flags to the bugs?
16:18:55 <coremodule> lruzicka2, yes, and updating the blocker bugs pagure pages to reflect the meeting vote
16:19:17 <coremodule> I'm +1 FE here again, based off the last one, but taking bcotton's objection into consideration
16:19:21 <lruzicka2> coremodule, ok, I'll do it.
16:19:28 <coremodule> thank you lruzicka2
16:19:35 <coremodule> #info lruzicka2 will secretarialize
16:19:37 <coremodule> lruzicka2++
16:19:55 <bittin> +1 FE
16:20:30 <lruzicka2> +1 FE
16:20:48 <pwhalen> +1 FE
16:20:56 <bcotton> just to keep you on your toes, i'm +1 fe here since churchyard says it's an FTI
16:21:04 <sumantro> +1 FE
16:21:23 <coremodule> :D, it's a consensus then
16:21:28 <coremodule> proposed #agreed 1965963 - The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that cannot be fixed with an update.
16:21:47 <bcotton> ack
16:21:49 <bittin> ack
16:21:56 <sumantro> ack
16:21:58 <pwhalen> ack
16:22:00 <geraldosimiao> ack
16:22:22 <coremodule> #agreed 1965963 - The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that cannot be fixed with an update.
16:23:59 <coremodule> let's look at the accepted Beta blockers and FEs and plan to move to the Final proposed blockers only after the fact (time permitting)
16:24:10 <coremodule> #topic Accepted Beta Blockers
16:24:22 <coremodule> #topic (1999180) sdhci_setup_cfg: Hardware does not specify base clock frequency
16:24:22 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1999180
16:24:22 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/439
16:24:22 <coremodule> #info Accepted Blocker, bcm283x-firmware, ASSIGNED
16:24:31 <coremodule> pwhalen, any news here?
16:25:13 <pwhalen> Patch is in the works upstream
16:25:26 <coremodule> #info patch is in the works upstream
16:25:56 <coremodule> #info if patch doesn't arrive in time, there is some agreement to waive this bug for beta under the "hard to fix" label
16:26:21 <coremodule> #topic (1999321) DNS often stops resolving properly after FreeIPA server upgrade to Fedora 35 or 36
16:26:21 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1999321
16:26:21 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/419
16:26:21 <coremodule> #info Accepted Blocker, freeipa, NEW
16:27:39 <coremodule> lruzicka2, wondering if you had a chance to look at this bug?
16:27:48 <coremodule> specifically comment 36
16:28:13 <lruzicka2> coremodule, let me check, but I do not understand FreeIPA too much
16:28:34 <coremodule> cool, thanks
16:29:38 <coremodule> #info is fweimer looking into this?
16:29:41 <lruzicka2> coremodule, I have an installation of OpenQA on my laptop and desktop, but I have not run the IPA tests. I guess I can try tomorrow to set it up if needs be.
16:30:19 <lruzicka2> It will probably require to pull some images, but should be doable, actually
16:30:41 <coremodule> if you get a chance, that would be helpful in this context I think. It seems like if it is only occurring on OpenQA, we could pass on this bug as it wouldn't affect users
16:31:15 <coremodule> #info lruzicka2 will attempt to test this on his local OpenQA setup
16:31:32 <coremodule> #topic (1996998) Cannot reboot/poweroff on login screen
16:31:32 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1996998
16:31:32 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/436
16:31:33 <coremodule> #info Accepted Blocker, gdm, NEW
16:31:36 <lruzicka2> coremodule, the question was if it fails on Fedora Infrastructure - I will be running it in the OpenQA, too
16:31:46 <coremodule> ahh, okay
16:32:34 <coremodule> looks like there's been little progess here
16:32:49 <coremodule> #info is Jens Petersen working on this bug?
16:33:27 <bittin> coremodule, he is in the cc list atleast (not sure if that says anything however)
16:33:48 <coremodule> ill assume that he is
16:34:25 <coremodule> #topic (1989726) [abrt] gnome-shell: cogl_texture_get_gl_texture(): gnome-shell killed by SIGSEGV
16:34:25 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1989726
16:34:25 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/399
16:34:25 <coremodule> #info Accepted Blocker, mesa, NEW
16:35:27 <coremodule> pwhalen, have you heard anything from jadahl about this bug?
16:37:04 <pwhalen> coremodule: nothing beyond what's on the bug
16:38:42 <coremodule> alright
16:39:13 <coremodule> #info no news... is good news?
16:39:16 <coremodule> #topic (2002609) Fedora34 cannot be upgraded to 35 using Software and PackageKit
16:39:16 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2002609
16:39:16 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/440
16:39:16 <coremodule> #info Accepted Blocker, PackageKit, ON_QA
16:39:28 <bcotton> nack
16:39:31 <bcotton> :-)
16:40:58 <bittin> -1 as long as it works via dnf, but its a good thing to have fixed for the final release
16:41:19 <bittin> but maybe for beta testing an errata or such could be written
16:41:36 <lruzicka2> this issue is fixed already, so this will go away
16:41:43 <coremodule> oh goody
16:41:45 <sumantro> -1, this is fixed
16:41:45 <bcotton> bittin: it's already an accepted blocker
16:41:47 <bittin> ah nice :)
16:41:59 <coremodule> #info there is already a fix for this
16:42:11 <coremodule> #topic (1997310) gnome-initial-setup slow to start up, missing Online Accounts page when SELinux in enforcing mode
16:42:11 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1997310
16:42:11 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/403
16:42:11 <coremodule> #info Accepted Blocker, selinux-policy, ASSIGNED
16:42:15 <lruzicka2> There was an agreement to create a downstream patch that would enable that, check tha bug
16:42:35 <lruzicka2> coremodule, you are too quick for me
16:42:42 <coremodule> sorry lruzicka2
16:42:58 <bittin> lruzicka2, thats nice :)
16:43:09 <coremodule> #info coremodule is too fast for lruzicka2 in meeting-speed context
16:43:26 <lruzicka2> coremodule, yeah, before I can type the info, the bug changes :D
16:43:38 <coremodule> ill slow down. Should we undo and go back?
16:44:14 <lruzicka2> coremodule, no need, I said what I wanted to :D
16:44:27 <coremodule> okay, hah, I will slow down before changing bugs
16:44:48 <lruzicka2> superb!
16:45:54 <coremodule> this bug looks like there is no fix yet
16:46:07 <geraldosimiao> lruzicka2: it is already on today's iso? will test it
16:47:27 <lruzicka2> geraldosimiao, I do not think so, I need to install the advisory today in the morning
16:47:43 <lruzicka2> when I tested, it only had two karma
16:47:52 <lruzicka2> from me and alciregi
16:47:54 <geraldosimiao> oh, ok then.
16:49:28 <lruzicka2> geraldosimiao, it still has just two karma so any testing is welcome
16:49:30 <lruzicka2> https://bodhi.fedoraproject.org/updates/FEDORA-2021-ed95149b77
16:49:57 <geraldosimiao> lruzicka2: can you paste here the link, for me? I can test it today
16:50:07 <lruzicka2> which link, geraldosimiao ?
16:50:09 <geraldosimiao> lruzicka2: ohhh fast
16:50:18 <geraldosimiao> thanks ;)
16:50:41 <geraldosimiao> lruzicka2: that one you already paste lol
16:50:43 <lruzicka2> no problem
16:50:44 <geraldosimiao> me too, I'm too slow
16:50:48 <geraldosimiao> on this meetings
16:51:10 <lruzicka2> :)
16:51:15 <bittin> so anything for gnome-initial-setup slow to start up, missing Online Accounts page when SELinux in enforcing mode ?
16:51:17 <bittin> https://bugzilla.redhat.com/show_bug.cgi?id=1997310
16:51:46 <lruzicka2> bittin, No idea here, the stuff is still happening.
16:51:55 <lruzicka2> on latest composes
16:52:12 <coremodule> #info this bug still occurs on the latest compose
16:53:47 <coremodule> I can't remember, do we usually go over accepted Freeze Exceptions or not?
16:54:24 <bcotton> i don't think we usually do
16:54:25 <lruzicka2> If you cut my head off, I would not remember :)
16:54:49 <coremodule> okay
16:55:04 <coremodule> #topic Proposed Final Blockers
16:55:36 <coremodule> sorry for the out of order here, I thought the review would take longer
16:55:44 <coremodule> #topic (2003285) gsd-usb-protection-manager crash in get_current_screen_saver_status
16:55:44 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2003285
16:55:44 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/445
16:55:44 <coremodule> #info Proposed Blocker, glib2, NEW
16:55:44 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-0) (+kparal)
16:56:18 <bittin> got one of these crashes in Rawhide earlier today
16:57:05 <coremodule> bittin, that's good info. Has anyone else tested a recent workstation compose?
16:57:26 <geraldosimiao> thats not a duplicate?
16:57:32 <sumantro> coremodule, got that one, +1'ed the vote
16:58:01 <coremodule> okay, I'm also +1 blocker
16:58:19 <bcotton> so does g-i-s not work at all? because that would seem more like a beta blocker than a final
16:58:29 <bittin> +1
16:59:07 <geraldosimiao> bcotton: yes, it seems G-I-S is broken somehow
16:59:20 <lruzicka2> +1, I am seeing this too
17:00:05 <bittin> and we are at time
17:00:25 <lruzicka2> bittin, we are not, Blocker review takes longer than an hour :D
17:00:33 <bcotton> bittin: no, we have 2 more hours
17:00:43 <lruzicka2> bittin, I have seen much more than one hour actually :D
17:01:00 <coremodule> how about this criterion?
17:01:00 <coremodule> https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_image_boot_behavior
17:01:07 <bittin> lruzicka2, bcotton ah i see, i have to drop however *poff*
17:01:57 <bcotton> coremodule: i think that applies more to the pre-install than the post
17:02:04 <bcotton> at least how i read it
17:02:06 <lruzicka2> coremodule, I do not think this bug violates it -> you end up in the g-i-s eventually and after a reboot, the issue goes away
17:02:24 <coremodule> ah, gotcha. you're right bcotton
17:03:06 <coremodule> more like this: https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior
17:03:32 <coremodule> lruzicka2, does gis eventually start then and allow for user creation/wifi/etc?
17:04:24 <lruzicka2> coremodule, yes ... we might put some weight on the word "clearly"
17:04:50 <lruzicka2> coremodule, because the Oops something went wrong can make one nervous before the gis appears
17:05:23 <lruzicka2> coremodule, maybe if the SElinux issue goes away which makes it appear late, the issue will not be so bad
17:05:27 <bcotton> the most obvious applicable criterion is https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#First_boot_experience
17:05:43 <bcotton> but i don't think it's a stretch to apply the basic release criterion that coremodule linked
17:05:46 <lruzicka2> bcotton, yeah, true
17:05:52 <coremodule> obviously :)
17:06:14 <lruzicka2> bcotton, coremodule: As this is proposed as a final blocker, we should apply final criterion ...
17:06:21 <lruzicka2> for better understading
17:06:38 <coremodule> lruzicka2, but not if it violates a basic criterion, then we fall back to a beta blocker
17:06:48 <coremodule> instead of final blocker. But I guess that's what we're voting on
17:06:53 <bcotton> lruzicka2: we should apply whatever criterion fits
17:07:04 <bcotton> i'm definitely +1 Final Blocker
17:07:12 <bcotton> i think I'm +1 Beta blocker, but I won't insist on it
17:07:34 <lruzicka2> coremodule, bcotton: well, I do not think this is severe to a Beta release, so let's use the final criterion, otherwise we should Beta block, I think
17:07:38 <lruzicka2> +1 FB
17:08:03 <pwhalen> +1 FB, I believe we waived this for F34 Beta
17:08:19 <lruzicka2> pwhalen, F35?
17:08:22 <coremodule> bcotton, bias aside, I think I like the "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system." better, just because with the other criterion, it sounds like GIS *does* start successfully, implying that each page of it works correctly. It's just overshadowed by the error message
17:08:41 <geraldosimiao> +1 FB too (but I think all this bugs slowing and showing oops message at install will cause allot of noise at the community)
17:08:48 <lruzicka2> but GIS starts successfully and all pages do too
17:09:02 <pwhalen> lruzicka2: I think we had the same issue in F34 Beta, the oops screen appeared but GIS started and was usable
17:09:17 <bcotton> coremodule: that's the best kind of correct :-)
17:09:19 <lruzicka2> pwhalen, oh, did not remember
17:09:29 <coremodule> bcotton, biased correct?
17:09:59 <bcotton> technically correct
17:10:07 <copperi[m]> +1 FB
17:10:36 <lruzicka2> ok, I am not going to question this specific criterion, go ahead coremodule
17:11:34 <coremodule> we need a final criterion that this is going to block on, the one I suggested is a basic
17:11:43 <coremodule> oh i see now
17:11:48 <coremodule> bcotton ftw
17:12:03 <coremodule> that *was* a final criterion
17:12:34 <coremodule> I still don't think it makes sense in this context
17:12:39 <bcotton> you can argue that it does start successfully under that criterion, but that's not a meaningful distinction to the user
17:13:09 <coremodule> okay, I can get behind that
17:14:20 <coremodule> proposed #agreed 2003285 - The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:
17:14:20 <coremodule> "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test."
17:14:20 <coremodule> Note that while it seems like GIS does in fact start successfully, the error message that is presented occludes this fact so isn’t a meaningful distinction to the user.
17:14:34 <coremodule> ah let me try again
17:14:48 <coremodule> proposed #agreed 2003285 - The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test." Note that while it seems like GIS does in fact start
17:14:48 <coremodule> successfully, the error message that is presented occludes this fact so isn’t a meaningful distinction to the user.
17:14:50 <coremodule> gah
17:14:52 <coremodule> one more time
17:15:54 <coremodule> proposed #agreed 2003285 -  AcceptedBlocker, violates the following criterion: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test." While GIS does start successfully, the error message that is presented occludes this fact so isn’t a meaningfu
17:15:54 <coremodule> l distinction to the user.
17:15:58 <coremodule> dangit
17:16:00 <lruzicka2> tough
17:16:39 <coremodule> proposed #agreed 2003285 -  AcceptedBlocker, violates the following criterion: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test." While GIS does start, the error that is presented occludes this fact so isn’t a meaningful distinction.
17:16:41 <lruzicka2> proposed #agreed 2003285 -  AcceptedBlocker, violates the: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test." While GIS does start successfully, the error message that is presented occludes this fact so isn’t meaningful to the user.
17:16:53 <lruzicka2> sorry
17:17:30 <coremodule> thats okay, let's get some acks
17:17:38 <lruzicka2> ack
17:17:54 <copperi[m]> ack
17:18:09 <geraldosimiao> ack
17:18:44 <coremodule> #agreed 2003285 -  AcceptedBlocker, violates the following criterion: "If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test." While GIS does start, the error that is presented occludes this fact so isn’t a meaningful distinction.
17:19:10 <coremodule> #topic (2003253) Keyboard layout specified in anaconda is not respected
17:19:10 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=2003253
17:19:10 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/444
17:19:10 <coremodule> #info Proposed Blocker, gnome-initial-setup, NEW
17:19:10 <coremodule> #info Ticket vote: FinalBlocker (+1,0,-0) (+kparal)
17:20:32 <coremodule> seems pretty reasonable to accept this as a blocker
17:20:36 <coremodule> +1 Final Blocker
17:20:44 <geraldosimiao> ohhh, I only have qwerty keyboard to test... didnt see that
17:21:13 <geraldosimiao> FB +1 to me too
17:21:33 <lruzicka2> Interesting I have not seen it with Czech layout
17:21:37 <coremodule> I think the potential oversight mentioned in comment 1 could be argued either way
17:23:20 <geraldosimiao> perhaps it's a problem only with dvorak keyboard?
17:24:22 <lruzicka2> maybe it is ... I think we should test more. I'd say punt.
17:25:01 <coremodule> we have time for this, I'm good with punting
17:25:07 <pwhalen> +1 punt
17:25:12 <lruzicka2> +1 punt
17:25:38 <geraldosimiao> ok, +1 punt too
17:26:01 <coremodule> proposed #agreed 2003253 -  The decision to delay the classification of this as a blocker bug was made as we are unsure exactly which layouts this affects and want more time to test.
17:26:07 <bcotton> yeah, let's punt
17:26:10 <lruzicka2> ack
17:26:13 <bcotton> i'm leaning blocker, ubt i'd like to have more info
17:26:13 <bcotton> ack
17:26:19 <pwhalen> ack
17:26:22 <coremodule> #agreed 2003253 -  The decision to delay the classification of this as a blocker bug was made as we are unsure exactly which layouts this affects and want more time to test.
17:26:23 <copperi[m]> ack
17:26:33 <lruzicka2> bcotton, we still have time for Final blockers :D
17:26:36 <coremodule> #topic (1950669) [abrt] gnome-settings-daemon: get_current_screen_saver_status(): gsd-usb-protection killed by SIGSEGV
17:26:36 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1950669
17:26:36 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/412
17:26:36 <coremodule> #info Proposed Blocker, gnome-settings-daemon, NEW
17:26:59 <bcotton> lruzicka2: especially if we never get the beta out :p
17:28:21 <lruzicka2> bcotton, well, let's hope for the best :D
17:28:36 <coremodule> I think I'm punt for more info here, as it looks like we are still waiting to see if this causes the "sadface" at boot
17:29:07 <bcotton> this seems a lot  like 2003285, doesn't it?
17:29:31 <coremodule> yes, i do believe so
17:30:16 <geraldosimiao> bcotton: yeah, thats why I said 2003285 seems to be duplicate
17:30:23 <coremodule> from my reading, it seems like they might correlated, but not causated (i made that one up)
17:32:01 <lruzicka2> so? should we punt then?
17:32:11 <geraldosimiao> coremodule: 👀
17:32:52 <coremodule> I'm good with punting until we are sure this is a dupe, if 2003285 is fixed, then this will be too, right?
17:33:14 <bcotton> yeah, let's punt
17:33:44 <lruzicka2> right ho
17:34:05 <coremodule> proposed #agreed 1950669 -  The decision to delay the classification of this as a blocker bug was made as we are unsure if this is a duplicate of 2003285 at the moment.
17:34:14 <geraldosimiao> ack
17:34:20 <lruzicka2> ack
17:35:42 <copperi[m]> ack
17:35:45 <coremodule> #agreed 1950669 -  The decision to delay the classification of this as a blocker bug was made as we are unsure if this is a duplicate of 2003285 at the moment.
17:35:58 <coremodule> #topic (1991075) time is transiently incorrect when Automatic Time Zone is enabled
17:35:58 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1991075
17:35:58 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/389
17:35:58 <coremodule> #info Proposed Blocker, gnome-settings-daemon, NEW
17:35:59 <coremodule> #info Ticket vote: FinalBlocker (+4,0,-0) (+bcotton, +chrismurphy, +tablepc, +kparal)
17:36:09 <coremodule> looks like this has already been accepted.
17:36:32 <coremodule> #info marking accepted in pagure
17:36:46 <bcotton> iirc, there has been some discussion about whether or not we shoudl accept this in the last few meetings
17:36:46 <coremodule> #topic (1995439) cannot run F34 or F33 toolboxes in F35 or C9S: Error: invalid entry point PID of container
17:36:47 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1995439
17:36:47 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/447
17:36:47 <coremodule> #info Proposed Blocker, toolbox, NEW
17:36:55 <coremodule> #undo
17:36:55 <zodbot> Removing item from minutes: INFO by coremodule at 17:36:47 : Proposed Blocker, toolbox, NEW
17:36:59 <coremodule> #undo
17:36:59 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f6317a932e8>
17:37:04 <coremodule> #undo
17:37:04 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f6317c1ccc0>
17:37:06 <coremodule> #undo
17:37:06 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f6312b26278>
17:37:08 <coremodule> #undo
17:37:08 <zodbot> Removing item from minutes: INFO by coremodule at 17:36:32 : marking accepted in pagure
17:37:37 <coremodule> ah, good to know
17:38:03 <bcotton> i'd go look at the minutes, but meetbot is brokenish
17:38:11 <lruzicka2> coremodule, this is an accepted FE, we should be voting on the blocker status
17:38:22 <lruzicka2> if I am reading the BZ correctly
17:38:48 <coremodule> #topic (1991075) time is transiently incorrect when Automatic Time Zone is enabled
17:38:48 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1991075
17:38:48 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/389
17:38:48 <coremodule> #info Proposed Blocker, gnome-settings-daemon, NEW
17:38:49 <coremodule> #info Ticket vote: FinalBlocker (+4,0,-0) (+bcotton, +chrismurphy, +tablepc, +kparal)
17:39:05 <coremodule> I think we
17:39:18 <coremodule> I think the votes were for FinalBlocker status
17:39:26 <lruzicka2> +1 FB
17:39:33 <geraldosimiao> +1 FB
17:39:34 <coremodule> I can see where adamw redacted the vote
17:40:05 <bcotton> so i remain +1 blocker. i know we've been looking for more info, but i'm not sure what info we're looking ofr
17:40:11 <bcotton> https://bugzilla.redhat.com/show_bug.cgi?id=1991075#c5 is adam's most informative summary
17:41:08 <coremodule> well, I think that's quite a few +1 blocker votes, we'll mark it as an "AcceptedBlocker" and adamw can redact it again should we come to a disagreenment
17:41:16 <lruzicka2> ok
17:41:24 <bcotton> wfm
17:41:32 <coremodule> #info marking AcceptedFinalBlocker in pagure based off the votes there
17:41:40 <bcotton> fwiw cmurf and kamil both say it's a real problem
17:41:56 <coremodule> #topic (1995439) cannot run F34 or F33 toolboxes in F35 or C9S: Error: invalid entry point PID of container
17:41:56 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1995439
17:41:56 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/447
17:41:56 <coremodule> #info Proposed Blocker, toolbox, NEW
17:42:51 <lruzicka2> coremodule, I need the reasoning for the blocker acceptance, dont I?
17:43:33 <coremodule> lruzicka2, no, since that one was already +4 votes in pagure, we'll just leave it as so and then you can mark the bug as an "AcceptedBlocker" in the whiteboard and call it good.
17:43:40 <lruzicka2> ok
17:44:25 <lruzicka2> coremodule, someone is doing my job :D
17:44:29 <coremodule> I don't know which criteria this bug is supposed to have broken...
17:44:31 <coremodule> lol
17:44:33 <bcotton> so this one is bad but i'm not sure it blocks any existing criteria
17:44:46 <coremodule> its nice when the asynchronous process works like it was designed to
17:45:02 <coremodule> bcotton, agreed, unless someone can enlighten us?
17:47:48 <bcotton> it also seems like it could be fixed in an update. i'm not sure there's much use of rpm-ostree variants in a live boot scenario, which seems like the mostly likely way this would be cannot-be-fixed-in-an-update
17:48:29 <bcotton> +1 beta FE for sure
17:48:39 <bcotton> even though hopefully we'll be out of beta freeze before a fix lands anyway
17:49:09 <bcotton> i could also say +1 final FE just in case
17:49:12 <coremodule> if it can be fixed with an update, do we even need to give it FE status?
17:49:27 <bcotton> not sold on the blocker status, although i really hope it would be fixed before release
17:49:41 <bcotton> i guess we don't need to
17:50:02 <bcotton> again, unless there are people using ostree variants as lives for some reason
17:50:09 <coremodule> I'm just playing adamw's advocate here
17:51:02 <coremodule> alright, so votes, who has got a vote?
17:51:26 <geraldosimiao> +1 Final FE
17:51:26 <lruzicka2> +1 beta FE, punt the reset
17:51:32 <lruzicka2> rest
17:51:39 <pwhalen> +1 beta FE
17:52:48 <lruzicka2> that's 3 BFE
17:52:57 <bcotton> +1 beta FE, punt the rest (i am not lruzicka2)
17:54:13 <coremodule> proposed #agreed 1995439 -  The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that could impact user experience. We will punt on the other classifications for now.
17:54:37 <geraldosimiao> ack
17:54:45 <bcotton> ack
17:54:52 <pwhalen> ack
17:54:57 <lruzicka2> ack
17:55:01 <coremodule> #agreed 1995439 -  The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that could impact user experience. We will punt on the other classifications for now.
17:55:17 <coremodule> #topic Proposed Final Freeze Exceptions
17:55:20 <coremodule> one last thing
17:55:22 <coremodule> #topic (1980460) Obsolete packages that used to require Python 3.9 but are gone in Fedora 35
17:55:22 <coremodule> #link https://bugzilla.redhat.com/show_bug.cgi?id=1980460
17:55:22 <coremodule> #link https://pagure.io/fedora-qa/blocker-review/issue/422
17:55:22 <coremodule> #info Proposed Freeze Exceptions, fedora-obsolete-packages, MODIFIED
17:55:46 <coremodule> +1 FE
17:57:23 <bcotton> +1 FE
17:57:32 <lruzicka2> +1 FE
17:57:43 <copperi[m]> +1 FE
17:57:52 <geraldosimiao> +1 FE
17:58:26 <coremodule> proposed #agreed 1980460 -  The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that cannot be fixed with an update.
17:58:32 <lruzicka2> ack
17:59:56 <bcotton> ack
18:00:01 <copperi[m]> ack
18:00:07 <geraldosimiao> ack
18:00:22 <coremodule> #agreed 1980460 -  The decision to classify this bug as an "AcceptedFreezeException (Beta)" was made as it is a noticeable issue that cannot be fixed with an update.
18:00:32 <coremodule> #topic Open Floor
18:00:36 <coremodule> Alright, that's about that!
18:00:43 <coremodule> Thanks for coming everyone.
18:00:51 <lruzicka2> I apologize, kids want to go to bed, I need to go.
18:01:01 <coremodule> thanks for your help lruzicka2
18:01:02 <lruzicka2> Thanks for coming, everyone.
18:01:14 <coremodule> we'll close this meeting out if no one has anything else...
18:01:26 <pwhalen> thanks coremodule et al.
18:01:37 <coremodule> 5...
18:01:39 <coremodule> 4...
18:01:40 <coremodule> 3...
18:01:41 <coremodule> 2...
18:01:42 <coremodule> 1...
18:01:46 <coremodule> #endmeeting