16:01:06 <adamw> #startmeeting F37-blocker-review
16:01:06 <zodbot> Meeting started Mon Aug 22 16:01:06 2022 UTC.
16:01:06 <zodbot> This meeting is logged and archived in a public location.
16:01:06 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:01:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:06 <zodbot> The meeting name has been set to 'f37-blocker-review'
16:01:07 <adamw> #meetingname F37-blocker-review
16:01:07 <zodbot> The meeting name has been set to 'f37-blocker-review'
16:01:09 <adamw> #topic Roll Call
16:01:15 <adamw> how's everyone doing?
16:01:21 <coremodule> and so it begins...
16:01:28 * coremodule is here, doing well, how are you adamw?
16:01:33 * LunaJernberg[m] is here and okay
16:01:34 <bcotton> .hello2
16:01:35 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:01:50 * cmurf is ready to set some bugs free
16:01:52 * bcotton is hungry. I'm going to make lunch while folks check in
16:01:52 <cmurf> first step, identification
16:02:19 <geraldosimiao> .hello geraldosimiao
16:02:19 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:02:38 * AllanDay[m] is here
16:02:38 * cmurf goes to make tea
16:03:31 <LunaJernberg[m]> topic should be on Mondays 16:00 UTC :p
16:03:36 <adamw> oh, surviving
16:03:37 <LunaJernberg[m]> .hello2
16:03:38 <zodbot> LunaJernberg[m]: Sorry, but user 'LunaJernberg [m]' does not exist
16:04:00 <LunaJernberg[m]> .hello2 bittin
16:04:00 <zodbot> LunaJernberg[m]: Sorry, but user 'LunaJernberg [m]' does not exist
16:04:21 <bittin> .hello2
16:04:22 <zodbot> bittin: bittin 'Luna Jernberg' <droidbittin@gmail.com>
16:05:29 <SumantroMukherje> hey!
16:05:50 * SumantroMukherje is here
16:06:02 <lruzicka> .hello2
16:06:03 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
16:08:16 <lruzicka> is there a meeting? it looks quiet here
16:08:18 <adamw> thanks for coming, everyone
16:08:21 <cmurf> adamw: Good, good. Another round of herding winging ahead!
16:08:25 <LunaJernberg[m]> lruzicka: yeah
16:08:38 <adamw> sorry, i'm just trying to knock out a few blockers in the app to reduce the time this is gonna take
16:08:45 <adamw> let's do some boilerplate
16:08:47 <lruzicka> all right
16:08:50 <lruzicka> thanks
16:08:58 <adamw> #chair cmurf lruzicka
16:08:58 <zodbot> Current chairs: adamw cmurf lruzicka
16:09:03 <adamw> #topic Introduction
16:09:08 <adamw> Why are we here?
16:09:10 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:09:13 <adamw> #info We'll be following the process outlined at:
16:09:17 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:09:20 <adamw> #info The bugs up for review today are available at:
16:09:24 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:09:28 <adamw> #info The criteria for release blocking bugs can be found at:
16:09:31 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:09:34 <adamw> #link https://fedoraproject.org/wiki/Fedora_37_Beta_Release_Criteria
16:09:44 <adamw> #link https://fedoraproject.org/wiki/Fedora_37_Final_Release_Criteria
16:09:45 <adamw> as of right now, we have
16:10:02 <adamw> #info for Beta we have:
16:10:05 <adamw> #info 3 Proposed Blockers
16:10:10 <adamw> #info 1 Accepted Blockers
16:10:11 <adamw> #info 1 Proposed Freeze Exceptions
16:10:18 <adamw> #info for Final we have (numbers subject to change):
16:10:21 * sgallagh waves
16:10:26 <LunaJernberg[m]> and 1 Prio bug for Beta
16:10:29 <adamw> #info 10 Proposed Blockers
16:10:33 <adamw> #info 4 Accepted Blockers
16:10:44 <adamw> Luna Jernberg: yup, that's out of scope for this meeting though. it's just tracked in the same app because it's handy.
16:10:52 <LunaJernberg[m]> adamw: ah i see
16:10:57 <adamw> who wants to secretarialize?
16:11:04 <LunaJernberg[m]> and 1 Prio bug for Final
16:11:09 <adamw> Luna Jernberg: there's a separate prioritizied bugs meeting, you can join those if you're interested
16:11:23 <LunaJernberg[m]> adamw: ah yeah on Thursday afternoons my time :)
16:11:44 <LunaJernberg[m]> or if it was Wednesdays what is days
16:11:58 <bcotton> adamw: i can do my best coremodule impersonation
16:12:00 <coremodule> is that even a question?
16:12:02 <coremodule> oh
16:12:04 <coremodule> well then
16:12:12 <bcotton> ohai coremodule
16:12:21 <bcotton> i'll let you do your best coremodule impersonation if you want
16:12:30 <coremodule> oh if you insist
16:13:08 <lruzicka> coremodule, we do :D
16:13:27 <coremodule> alright, i'll do it
16:13:45 <bcotton> coremodule++
16:13:45 <zodbot> bcotton: Karma for coremodule changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:14:45 <adamw> #info coremodule will secretarialize
16:14:46 <adamw> alright, let's get rolling
16:15:55 <adamw> #topic (1907030) "dnf update" runs out of memory on swapless 0.5 GiB RAM machine
16:15:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1907030
16:16:03 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/841
16:16:05 <adamw> #info Proposed Blocker, dnf, NEW
16:16:11 <adamw> #info Ticket vote: BetaBlocker (+0,2,-3) (bcotton, kparal, -jmracek, -adamwill, -geraldosimiao)
16:16:15 <adamw> #info Ticket vote: FinalBlocker (+0,0,-1) (-jmracek)
16:16:33 <adamw> so a fun feature of this meeting is gonna be that all the Beta bugs technically have the votes to make a call right now, but i left them on the list for various reasons
16:17:03 <adamw> in this case, more wrinkles emerged after some folks had voted. see kparal's comment at https://pagure.io/fedora-qa/blocker-review/issue/841#comment-810582
16:17:13 <LunaJernberg[m]> -1 (what does it cost to hire more ram) and write system reqs that more ram is needed and don't think many have 512mb RAM in their on prem boxes
16:17:17 <adamw> and comment #9 and later on the bug
16:17:34 <adamw> Luna Jernberg: well, that's the thing - it seems there are issues with more than 512M of RAM too
16:17:43 <LunaJernberg[m]> o:
16:17:43 <adamw> and it's affecting CoreOS CI
16:18:19 <LunaJernberg[m]> ah did not read up on all details changes to +-0 then
16:19:01 <cmurf> Hmm this is sounding familiar
16:19:43 <cmurf> We should get a stack trace of the dnf PID
16:19:44 <adamw> cmurf: it's not the same thing as our weird workstation systemd-oomd thing, i don't think
16:19:51 <adamw> in this case it really is running out of memory
16:20:02 <LunaJernberg[m]> adamw: was what i was thinking too
16:20:16 <cmurf> Sorry /proc/$PID/status not stack
16:20:44 <cmurf> I think it's really using more memory
16:21:19 <cmurf> I've heard other stories but as yours expect those cases are already min resources
16:22:10 <adamw> yes, it really is, there are some measurements in the bug from dnf folks
16:22:41 <adamw> this one feels really borderline to me, honestly
16:23:01 <adamw> we don't do a good job of specifying our requirements, really, what we have just isn't appropriate for a container-y, CI-y work
16:23:02 <adamw> world*
16:23:14 <adamw> it's clearly focused on desktop/trad server usage
16:23:58 <lruzicka> I believe that we'd need some more discussions from people who are affected as @kparal suggests
16:24:23 <bcotton> yeah, i'd particularly like to hear from the ARM folks about this
16:24:25 <adamw> yeah, that would kinda be my inclination too
16:24:43 <adamw> we should reach out to mailing lists rather than waiting for folks to show up
16:24:56 <LunaJernberg[m]> +1
16:25:01 <adamw> pbrobinson is on the bug, so arm is "aware"
16:25:20 <lruzicka> coremodule, could you perhaps ask around CoreOS folks?
16:25:30 <bcotton> yeah, but he's on a lot of bugs, so a mailing list post (or showing up at a meeting) might get more attention
16:25:48 <coremodule> this is more SumantroMukherje area of expertise, I don't work on coreos
16:26:06 <adamw> the name is misleading!
16:26:25 <adamw> again, coreos is aware, as dusty is the one who pointed out the impact on coreos CI
16:26:26 <lruzicka> it sure is :) now, I'll just call him Module :D
16:26:53 * SumantroMukherje is reading logs.. but adamw said, dusty is aware
16:27:00 <lruzicka> I guess, we  might want to punt.
16:27:01 <SumantroMukherje> which seems right
16:27:30 <lruzicka> who else should know? if we post it to devel list, will it be enough?
16:28:43 <cmurf> i do not think we can call it a blocker bug, what's the criterion?
16:28:51 <adamw> i would say let's punt and send a mail cc'ed to a bunch of lists
16:29:02 <cmurf> our minimums are somewhere around 2G RAM?
16:29:07 * LunaJernberg[m] agrees with adamw
16:29:17 <adamw> cmurf: conditional violation of any criterion to do with packaging, the condition being "low RAM"
16:29:44 <LunaJernberg[m]> cmurf: i would say around 3-4GB
16:29:44 <adamw> cmurf: see above for my take on this. we do a very bad job of expressing requirements.
16:29:44 <cmurf> and in the lower memory cases, I think microdnf is indicated which is what someone else was using as a work around for this same problem I was listening in on the convo from last week
16:29:56 <adamw> i don't think we can just stand by 'some doc somewhere says 2GB for a desktop install' to wave this through
16:30:43 <adamw> to me it's a bad look if running our package manager on a minimal install takes more than 1GB of ram. that just seems like we're bad at software.
16:30:47 <adamw> anyhoo, we can have some discussion and come back to it, i guess
16:30:57 <cmurf> yeah i agree with all of that
16:31:09 <cmurf> i'm just not sure how to reliably draw the line
16:31:27 <cmurf> i think you'd have to say XYZ variants use dnf and thus have a 2G minimum RAM requirement
16:31:44 <cmurf> and for use cases with less RAM, we're using microdnf
16:31:50 <cmurf> which is available in variants ABC
16:31:55 <adamw> proposed #agreed 1907030 - punt (delay decision) - this is a difficult call as it really depends on a subjective evaluation of how much RAM we're comfortable with requiring for basic packaging operations on a minimal Fedora environment. we will solicit input from various teams and re-consider this at a later time
16:32:34 <lruzicka> ack
16:32:45 <cmurf> ack
16:32:45 <LunaJernberg[m]> ack
16:32:59 <SumantroMukherje> ack
16:33:01 <coremodule> ack
16:33:08 <adamw> #agreed 1907030 - punt (delay decision) - this is a difficult call as it really depends on a subjective evaluation of how much RAM we're comfortable with requiring for basic packaging operations on a minimal Fedora environment. we will solicit input from various teams and re-consider this at a later time
16:33:32 <adamw> #topic (2117859) FreeIPA client enrolment fails due to DNS issues with openssl-pkcs11-0.4.12-2.fc37 on server
16:33:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2117859
16:33:44 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/852
16:33:45 <adamw> #info Proposed Blocker, openssl-pkcs11, NEW
16:33:45 <adamw> #info Ticket vote: BetaBlocker (+3,0,-0) (+kparal, +lruzicka, +bcotton)
16:34:04 <adamw> so the complication here is, this only affects FreeIPA deployments with dnssec enabled (which is the default)
16:34:31 <lruzicka> clear +1
16:34:31 <adamw> and the Beta criteria have a get-out clause: "Before Final, it is acceptable if moderate workarounds are necessary to achieve the additional requirements above."
16:34:39 <adamw> (that being the FreeIPA requirements)
16:34:44 <LunaJernberg[m]> +1
16:34:51 <SumantroMukherje> +1
16:34:51 <adamw> it seems reasonable to say 'disable dnssec' is a moderate workaround
16:34:58 <bcotton> i'm not sure I agree
16:35:16 <adamw> for Final we require no workarounds, so this is a clear Final blocker
16:35:43 <lruzicka> well, there is some truth about it ... I could live with Final blocker :D
16:35:57 <adamw> Ben Cotton (he/him): you don't agree that it's a moderate workaround?
16:35:58 <adamw> (note, doing that is easy, it's a single argument to the server deploy command)
16:36:57 <TheExorcist[m]> Hi All o/
16:37:01 <adamw> for this to be beta blocker, either we have to decide that isn't a moderate workaround, or we could consider the case of upgrades of servers from previous releases. if upgrading a dnssec-enabled server breaks, that strengthens the case for the bug being a blocker. unfortunately i don't know right now if it does, because we have dnssec disabled for the upgrade tests already because of a different bug...
16:37:07 <bcotton> correct. i don't agree that it's a moderate workaround
16:37:08 <LunaJernberg[m]> TheExorcist[m]: hi
16:37:17 <adamw> i will now re-enable dnssec for an upgrade test and see what happens, but that'll take ~40 mins.
16:38:23 <bcotton> well, let me ask a clarifying question
16:38:26 <bcotton> is it about dnssec being enabled on the FreeIPA server or on an external DNS server?
16:38:36 <adamw> Ben Cotton (he/him): on the freeipa server
16:38:38 <bcotton> because I've been assuming the latter
16:38:52 <bcotton> okay!
16:39:17 <adamw> the workaround is just: pass `--no-dnssec-validation` when deploying the server
16:39:36 <jednorozec> that is a moderate workaround
16:39:37 <bcotton> so i'm still weakly +1. i'd prefer to accept it now and waive under the escape hatch you cited if it's the last remaining beta blocker
16:40:19 <jednorozec> -1 beta blocker
16:40:34 <lruzicka> -1 beta blocker, +1 final blocker
16:40:50 <jednorozec> +1 final blocker
16:41:06 <adamw> i would kinda like to punt for long enough to test the upgrade scenario, honestly
16:41:11 <adamw> wish i'd gotten around to it this week but, you know, it's been busy
16:41:24 <LunaJernberg[m]> adamw: maybe talk about it again next week?
16:41:46 <cmurf> 🔥
16:41:53 <bcotton> i'm okay with punting, but i don't think it changes my opinion :-)
16:43:23 <TheExorcist[m]> Seems, I missed some action today, I was not having the Calendar. OK, I will go through the script.
16:43:50 <adamw> so, uh.
16:43:53 <adamw> we're clearly +1 final blocker
16:45:02 <adamw> #info we'll circle back to 2117859 at the end of the meeting and see if the upgrade test is done by then
16:45:20 <adamw> #topic (2103835) failed to install server iso with virt-install due to the missing of isolinux  in the media
16:45:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2103835
16:45:30 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/833
16:45:31 <adamw> #info Proposed Blocker, osinfo-db, NEW
16:45:31 <adamw> #info Ticket vote: BetaBlocker (+3,0,-0) (+kparal, +lruzicka, +bcotton)
16:45:49 <TheExorcist[m]> does the sleep timer deactivation working now?
16:46:05 <adamw> so this one seems a bit complicated, because there was an update, i closed it, then it got reopened with a comment that suggests there's still an issue but it's maybe much more narrow than people thought when voting
16:46:06 <adamw> so that's why this is still on the list
16:46:16 <TheExorcist[m]> TheExorcist[m]: I mean to ask, if that is fixed?
16:46:30 <LunaJernberg[m]> +1 Betablocker
16:48:04 <adamw> Luna Jernberg: please stop voting in bug reports
16:48:17 <adamw> Luna Jernberg: you vote here, or in the pagure tickets
16:48:17 <LunaJernberg[m]> adamw: okay
16:48:21 <LunaJernberg[m]> okay i see sorry
16:48:21 <adamw> you never vote in bug tickets, and during a meeting you don't have to vote in pagure
16:48:22 <adamw> npnp
16:48:44 <LunaJernberg[m]> alright
16:50:10 <bcotton> so i guess i have two questions at this point: 1. is it still an osinfo-db bug or is it a libvirt issue? 2. is the new failure mode too narrow to violate release criteria?
16:50:35 <cmurf> those are my questions
16:50:48 <cmurf> i'm leaning toward +1 as it's described but needinfo is a good course of action at this point
16:51:23 <adamw> yeah, i think we might need to get more details...
16:52:26 <TheExorcist[m]> https://bugzilla.redhat.com/show_bug.cgi?id=2118152
16:52:27 <cmurf> every bootloader is special casing and compromising many things so i'm kinda unsurprised we switch bootloaders and there's a kaboom
16:52:55 <adamw> The Exorcist: this isn't a general discussion meeting, it's a meeting with a purpose, we discuss one bug at a time
16:53:09 <TheExorcist[m]> OK
16:53:17 <adamw> that bug is accepted as a final blocker, it is not yet fixed, that's why it's still open
16:54:53 * cmurf realizes he doesn't know if virt-install uses ISOs with a virtual optical drive or hard drive
16:55:25 <Southern_Gentlem> cmurf as the optical
16:55:39 <cmurf> ok i'll read the bug and ask questions there
16:56:40 <adamw> i'm live debugging rn...:D
16:58:02 <TheExorcist[m]> > * <@cmurf:fedora.im> realizes he doesn't know if virt-install uses ISOs with a virtual optical drive or hard drive
16:58:03 <TheExorcist[m]> Installer is recognizing VM and using virt memory Drivers for virt-hdds. So I guess if dirvers are really available, it should be using Virt Optical drives.
16:58:03 <adamw> so, it looks to me like the initial issue is not fixed for f37
16:58:04 <adamw> it's fixed for rawhide
16:58:24 <adamw> on that basis, I'm +1
16:58:51 <cmurf> +1 beta blocker
16:58:55 <SumantroMukherje> +1 Beta Blocker
16:58:59 <cmurf> surely it violates a basic criterion
16:59:05 <lruzicka> +1 bb
16:59:32 <adamw> cmurf: well, it's not entirely a slam dunk as the criteria focus on interactive virt use
16:59:47 <cmurf> also i'm reminding myself that https://fedoraproject.org/wiki/Changes/BIOSBootISOWithGrub2 means that we're not using syslinux for either optical or (hard)drive booting, i.e. USB sticks are treated as hard drives
17:00:19 <TheExorcist[m]> If it is not, then it is considered as real bug, but I still not very informative enough to say if it is bb or fb.
17:00:31 <adamw> kparal's reasoning at https://pagure.io/fedora-qa/blocker-review/issue/833#comment-810819 seems fairly sound for taking this
17:00:59 <adamw> also the impacts on test coverage (we've found at least two test tools affected by it)
17:01:32 <cmurf> agreed
17:01:51 <adamw> proposed #agreed 2103835 - AcceptedBlocker (Beta) - accepted as a violation of the virtualization criteria per kparal's comment on the ticket. We also note its impact on important test systems (anaconda CI and fedora-release-autotest)
17:02:30 <LunaJernberg[m]> ack
17:02:34 <cmurf> ack
17:02:58 <bcotton> ack
17:03:08 <adamw> #agreed 2103835 - AcceptedBlocker (Beta) - accepted as a violation of the virtualization criteria per kparal's comment on the ticket. We also note its impact on important test systems (anaconda CI and fedora-release-autotest)
17:03:20 <adamw> going on to:
17:03:27 <adamw> #topic Proposed Beta freeze exceptions
17:03:30 <adamw> #topic (2117256) Obsolete packages that used to require Python 3.10 but are gone in Fedora 37
17:03:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2117256
17:03:45 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/847
17:03:46 <adamw> #info Proposed Freeze Exceptions, fedora-obsolete-packages, ASSIGNED
17:03:48 <adamw> #info Ticket vote: BetaFreezeException (+4,0,-0) (+bcotton, +kparal, +kalev, +lruzicka)
17:03:55 <adamw> oh, wait, i can't count
17:04:01 <adamw> #info this already has sufficient votes, marking accepted
17:04:23 <adamw> #topic Proposed Final blockers
17:05:14 <cmurf> oh yay beta freeze is tomorrow
17:05:21 <adamw> good news, we're down to 5 of these
17:05:24 * cmurf feels like he's been put through a time machine
17:05:31 <adamw> #topic (2119762) Evince does not use utf-8 in search strings
17:05:35 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2119762
17:05:44 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/858
17:05:46 <adamw> #info Proposed Blocker, evince, NEW
17:05:47 <adamw> #info Ticket vote: FinalBlocker (+0,0,-2) (-catanzaro, -kparal)
17:06:15 <adamw> looks like this is NOTABUG
17:06:17 <adamw> or at least, not an evince bug
17:06:20 <LunaJernberg[m]> Finalblocker -1
17:06:34 <bcotton> -1 finalblocker, +1 notabug :-)
17:06:36 <adamw> #info recent investigation upstream indicates this is a bug in the PDF, not in evince, so we will close the bug and not consider it
17:06:38 <cmurf> lol
17:06:58 <lruzicka> yeah, away with it
17:07:16 <adamw> #topic (2111025) Making a screencast does not work
17:07:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2111025
17:07:30 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/839
17:07:31 <adamw> #info Proposed Blocker, gnome-shell, NEW
17:07:34 <adamw> #info Ticket vote: FinalBlocker (+1,1,-0) (+lruzicka, kparal)
17:07:46 <cmurf> umm +1 betaFE, and I'm not sure about final blocker
17:07:52 <lruzicka> +1, that is terrible.
17:08:08 <Southern_Gentlem> +1 BB
17:08:25 <lruzicka> If on wayland I cannot use wayland stuff to produce a screencast video ... that's bad
17:08:30 <LunaJernberg[m]> +1 Beta Blocker and hopefully get it fixed for Final
17:08:32 <cmurf> it should get fixed regardless of whather we block on it or not
17:08:35 <LunaJernberg[m]> and hope its better in GNOME 43
17:08:45 <LunaJernberg[m]> cmurf: +1
17:08:47 <lruzicka> we are discussing final blockers already
17:09:14 <cmurf> Michael Catanzaro should screencasting work for F37 final?
17:09:23 <cmurf> 👆️
17:09:30 <MichaelCatanzaro> yes
17:09:32 <cmurf> OK +1 final blocker
17:09:42 <bcotton> +1 final blocker
17:09:47 <adamw> yeah, i'm +1 on this
17:09:56 <Southern_Gentlem> ok _1fb
17:09:59 <Southern_Gentlem> +
17:10:04 <TheExorcist[m]> +1
17:10:09 <adamw> i don't care if we say it's part of an 'application' or the 'panel' but it ought to work
17:10:12 <LunaJernberg[m]> +1
17:10:17 <adamw> so, let me do some judo
17:10:45 <geraldosimiao> +1
17:11:06 <TheExorcist[m]> One more here: "Open in Disks" button/link is also not working in root "/" directory's properties window.
17:11:21 <adamw> proposed #agreed 2111025 - AcceptedBlocker (Final) - 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", on the basis it shows an icon in the panel when you trigger a recording
17:11:27 <adamw> do i get my black belt
17:11:28 <LunaJernberg[m]> ack
17:11:33 <bcotton> ack
17:11:44 <cmurf> ack
17:11:46 <geraldosimiao> ACK
17:11:51 <LunaJernberg[m]> TheExorcist[m]: save it for after the meeting or report it as a bug if you have not already
17:11:52 <adamw> The Exorcist: again, we're considering the bugs on the list, one at a time, here. if you want to propose a different bug, it needs to be filed and proposed, then it'll show up on the list
17:12:08 <bcotton> .moar adamw black belt
17:12:08 <zodbot> here black belt, have some more adamw
17:12:17 <adamw> #agreed 2111025 - AcceptedBlocker (Final) - 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", on the basis it shows an icon in the panel when you trigger a recording
17:12:30 <bcotton> d'oh
17:12:47 <LunaJernberg[m]> .moar black belt adamw
17:12:47 <zodbot> here belt adamw, have some more black
17:13:11 <bcotton> .fire zodbot
17:13:11 <zodbot> adamw fires zodbot
17:13:16 <cmurf> well we tried to be funny
17:13:25 <adamw> .fire everyone for failed humor
17:13:26 <zodbot> adamw fires everyone for failed humor
17:13:34 <bcotton> cmurf: that's going to be on my tombstone
17:13:43 <adamw> #topic (2115202) update 2.06-45 breaks windows boot manager
17:13:47 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2115202
17:13:48 <cmurf> there's a Yoda quote for this
17:13:49 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/846
17:13:59 <adamw> #info Proposed Blocker, grub2, ASSIGNED
17:14:00 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+lruzicka)
17:14:12 <TheExorcist[m]> adamw: OK, Do I have to propose it as a blocker, first to discuss a bug as a blocker, in meeting? I will follow this for sure. Thank you.
17:14:24 <cmurf> as it stands, +1 final blocker
17:14:29 <cmurf> the release criterion is still in place
17:14:34 <TheExorcist[m]> > <@adamwill:fedora.im> The Exorcist: again, we're considering the bugs on the list, one at a time, here. if you want to propose a different bug, it needs to be filed and proposed, then it'll show up on the list
17:14:34 <TheExorcist[m]> * OK, Do I have to propose it as a blocker first, to discuss a bug as a blocker, in meeting? I will follow this for sure. Thank you.
17:14:58 <cmurf> it seems fixed for the vast majority but one user reports it's still not working
17:14:58 <bcotton> +1 final blocker
17:15:24 <LunaJernberg[m]> +-0
17:15:40 <jednorozec> huh I have f36 and win dualboot and this was not a issue for me
17:15:42 <LunaJernberg[m]> TheExorcist[m]: yeah
17:15:42 <adamw> +1 yeah, since we still have the criterion
17:15:47 <geraldosimiao> +1 fb too
17:16:00 <lruzicka> +1 final blocker
17:16:07 <adamw> The Exorcist: yeah, the bug needs to be filed and marked as blocker FinalBlocker (or BetaBlocker if it's a beta candidate)
17:16:07 <Southern_Gentlem> +1 fb
17:16:14 <cmurf> The Exorcist yes, use the propose option in the blockerbug tracker app https://qa.fedoraproject.org/blockerbugs/propose_bug
17:16:22 <jednorozec> + Final blocker
17:16:28 <adamw> using the app does it for you, yes
17:16:30 <cmurf> don't forget to include a reference to a release criterion
17:16:57 <adamw> proposed #agreed 2115202 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora."
17:17:13 <bcotton> ack
17:18:05 <cmurf> ack
17:18:31 <lruzicka> ack
17:18:54 <adamw> #agreed 2115202 - AcceptedBlocker (Final) - accepted as a violation of "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora."
17:19:16 <adamw> #topic (2119757) F37 images don't boot in BIOS mode on Thinkpad T480s
17:19:17 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2119757
17:19:20 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/857
17:19:27 <adamw> #info Proposed Blocker, lorax, NEW
17:20:06 <cmurf> ahh here we go
17:21:25 <cmurf> ok i'm -1 on this for now
17:21:42 <cmurf> based on comment 2
17:22:01 <adamw> yeah, I'm -1 on this so long as it's single-system and that system supports UEFI, because use UEFI
17:22:09 <cmurf> but also we might want a release criterion clarification on UEFI support and carve out CSM-BIOS
17:22:16 <adamw> if we get reports on more systems including ones that don't support UEFI, i'd get more concerned
17:22:21 <LunaJernberg[m]> -1 use UEFI if kparal does not need to use BIOS for some specific reason
17:23:17 <lruzicka> this is not about kparal's only, but there is a chance that all T480s users will have issues
17:23:25 <cmurf> i'll post a question to the BIOS SIG list, do they intend to support CSM-BIOS cases as equivalent to native BIOS (only) cases
17:24:18 <cmurf> there are some rare cases of UEFI bugs that get masked by CSM-BIOS but, I'm pretty sure it's not reasonable to block on rare cases
17:25:14 <adamw> lruzicka: well, i mean, single model.
17:25:38 <adamw> lruzicka: 'just use UEFI instead' applies to all t480s users. :D
17:25:53 <bcotton> i'm not sure i love "you shouldn't want to boot in BIOS mode" as an answer here. but without a better understanding of the scope, it's hard for me to vote
17:26:21 <adamw> i mean
17:26:23 <adamw> it's 2022
17:26:29 <adamw> i would have had more qualms about it in 2015
17:26:53 <adamw> do we *really* need to block our releases on "but I REALLY WANT my boot chain to work like it's 1981" any more
17:27:04 <cmurf> that's what Debian is for (TM)
17:27:08 <lruzicka> I prefer to use BIOS if I can just to make my partitioning easier :D
17:27:32 <jednorozec> but as adamw noted its 2022
17:28:00 <adamw> i'd say the criteria are comfortably satisfied since the image boots on the system.
17:28:03 <adamw> we never promised it'd boot every possible way you can try booting it, that i can see.
17:28:09 <lruzicka> of course, but I feel that this is not our decision to make but Fesco's
17:28:18 <bcotton> that's part of the scope question. if it's just on one model that supports UEFI, that's one thing. if it is broader in impact (particularly if BIOS-only devices are affected), then that's another thing
17:28:24 <adamw> lruzicka: why is it fesco's decision?
17:28:43 <adamw> Ben Cotton (he/him): we have no information that they are, s ofar
17:28:50 <adamw> we can't really vote on an assumption that one might be
17:28:59 <bcotton> sure, and i'm not
17:28:59 <adamw> the bug says "I also tested other computers I have at home, and all of them booted F37 without issues in BIOS mode - Thinkpad T500, Fujitsu Lifebook E780, Gigabyte GA-Z87-D3HP (Intel Z87) desktop motherboard."
17:29:01 <lruzicka> because if we want to fully support BIOS on which devices, or in general is not a QA's thing to decide, I think
17:29:26 <bcotton> with what we know, i'm -1
17:29:35 <bcotton> i just worry a little bit about what we might be missing
17:29:35 <adamw> lruzicka: the criteria say "Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures." that's what we're evaluating against.
17:29:57 <adamw> there's also a footnote "System-specific bugs don't necessarily constitute an infringement of this criterion - for instance, if the image fails to boot because of a bug in some specific system's firmware, that is unlikely to constitute a violation unless the system is an extremely popular one. See Blocker_Bug_FAQ for more discussion of this."
17:29:57 <cmurf> i think it's up to BIOS SIG, they might say "for X models we support CSM-BIOS because the UEFI is messed up"
17:30:35 <adamw> i am perfectly happy making a call based on the release criteria, that's what we're here to do
17:31:00 <adamw> i think you'd have to bend over in all sorts of ways to read the criteria as being violated by this, so i'm -1.
17:31:23 <adamw> if BIOS SIG wants to try and fix this, they're welcome to, but that doesn't mean we have to block on it.
17:31:28 <cmurf> yeah it's a system specific bug, fair enough
17:34:43 <adamw> so, i'm -1
17:34:44 <adamw> ben's -1
17:34:44 <adamw> cmurf, you voted -1 super early, does that hold?
17:34:55 <cmurf> yes
17:34:56 * LunaJernberg[m] is still -1
17:34:56 <adamw> any other votes?
17:35:12 <adamw> ah sorry luna, missed your vote on a quick scan
17:35:13 <lruzicka> no, I withdraw
17:35:15 <adamw> so we're at -4
17:35:32 <jednorozec> -1
17:35:58 <TheExorcist[m]> I'm at 0 ;)
17:37:38 <adamw> proposed #agreed 2119757 - RejectedBlocker (Final) - it's clear images boot in both BIOS and UEFI mode on most systems, and this system is not blocked because you can simply boot in UEFI mode. With only this one UEFI-capable system definitely affected, this clearly is not severe enough to violate the criteria
17:37:40 <adamw> was that short enough for IRC?
17:37:52 <jednorozec> yes
17:37:56 <cmurf> last word criteria
17:38:01 <cmurf> no punctuation
17:38:01 <adamw> that's right
17:38:01 <cmurf> ack
17:38:13 <jednorozec> ack
17:38:30 <LunaJernberg[m]> ack
17:38:46 <bcotton> ack
17:38:54 <adamw> #agreed 2119757 - RejectedBlocker (Final) - it's clear images boot in both BIOS and UEFI mode on most systems, and this system is not blocked because you can simply boot in UEFI mode. With only this one UEFI-capable system definitely affected, this clearly is not severe enough to violate the criteria
17:39:28 <adamw> next on the list was 2103835 which we already accepted as Beta blocker, so we'll skip that
17:39:41 <LunaJernberg[m]> so on to the 7 Accepted Blockers then
17:39:58 <adamw> there's a newly proposed blocker, just a sec
17:40:08 <adamw> also we need to circle back to another
17:40:20 <adamw> #topic Proposed Beta blockers (redux)
17:40:21 <adamw> #topic (2117710) Open in Disks link is not working in root directory properties window.
17:40:21 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2117710
17:40:21 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/859
17:40:47 <adamw> #info Proposed Blocker, nautilus, NEW
17:41:09 <adamw> this is the one The Exorcist proposed during the meeting. clear -1 beta for me, as we don't have any beta criteria that would cover this. For Final, I think I'd also be -1 as this is a pretty obscure button and it's not really that...useful. you could just, you know, run Disks.
17:41:28 <adamw> (i had no idea this button existed till i read the bug report. :>)
17:41:28 <LunaJernberg[m]> Finalblocker +1
17:41:51 <adamw> it's a bug, but i don't see us not shipping F37 if this is the last bug leftr.
17:42:03 <bcotton> definitely -1 beta
17:42:18 <jednorozec> -1 beta, -1 final
17:42:23 <cmurf> -1 beta blocker, +1 beta FE, -1 final blocker
17:42:32 <bcotton> -1 beta blocker, that is. +1 beta FE
17:42:53 <bcotton> i can see a case for calling it a final blocker, but i'd like Workstation WG to explicitly say "yes, we think this is a blocker" before agreeing to that
17:43:06 <LunaJernberg[m]> bcotton: *agrees*
17:43:20 <cmurf> what's a better criterion here?
17:43:42 <geraldosimiao> -1 beta blocker
17:43:42 <geraldosimiao> +1 fe
17:43:48 <cmurf> All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use.
17:44:03 <adamw> cmurf: the default app functionality one
17:44:37 <adamw> "For all release-blocking desktop / arch combinations, the following applications must start successfully and withstand a basic functionality test"
17:44:39 <adamw> i.e., the relevant test here is 'basic functionality'
17:45:22 <cmurf> if Disks doesn't launch at all, blocker
17:45:31 <cmurf> if a "link" from Files to Disks doesn't work, well...yeah it's a bug but is it basic functionality? maybe not
17:45:45 <adamw> yeah, that's my argument. for me it fails the 'basic' test.
17:46:05 <lruzicka> I tried this now and it crashed my system completely.
17:46:46 <cmurf> if a crash is happening even a minority of the time, I'll quickly become +1 final blocker
17:47:03 <cmurf> i just tried it, no crash - just nothing happened at all
17:47:11 <adamw> lruzicka: huh, that's crazy. for me just clicking the button did nothing
17:47:23 <adamw> a crash would definitely be more concerning...
17:47:25 <TheExorcist[m]> for me, it is just 'not working'
17:47:52 <TheExorcist[m]> no crash happened.
17:48:28 <cmurf> GNOME test day still happening?
17:48:55 <lruzicka> cmurf, I am not going to try again until the meeting is over :D
17:49:10 <TheExorcist[m]> Hi sgallagh o/
17:49:11 <cmurf> maybe ask in the test day channel for folks to see if it crashes their system 😄
17:49:28 <LunaJernberg[m]> cmurf: ended 2 days ago, but there will be a GNOME RC test day in September
17:49:41 <adamw> so i'm still -1 for now but if we can even sometimes reproduce a crash i may change that
17:49:47 <cmurf> yep
17:49:51 <LunaJernberg[m]> * a GNOME 43 RC test, * in September before the release
17:50:33 <adamw> so we're clearly -1 beta blocker +1 beta fe, but there are only a few votes for final
17:50:44 <adamw> i'm -1 final blocker, other votes?
17:51:12 <TheExorcist[m]> adamw is it expected in new gnome, not to have 'Open in Terminal' context menu?
17:51:22 <bcotton> o
17:51:42 <adamw> The Exorcist: i think that's to do with nautilus extensions and GTK4
17:51:54 <bcotton> blerp! i'd like to have the Workstation WG weigh in, but if you push me to vote right now, i'm -1 final blocker
17:52:01 <LunaJernberg[m]> TheExorcist[m]: better ask that in #workstation:fedoraproject.org or in #gnome on GNOMEs matrix/IRC
17:52:15 <TheExorcist[m]> LunaJernberg[m]: OK
17:52:18 <LunaJernberg[m]> +1 Final blocker if it crashes peoples computers/nautlius if not -1
17:52:32 <LunaJernberg[m]> #gnome:gnome.org
17:53:21 <lruzicka> I will test it tomorrow and if really crashes, I'll let you know.
17:53:39 <adamw> Michael Catanzaro: ping, got a vote here?
17:53:42 <LunaJernberg[m]> sounds good
17:54:03 <adamw> Michael Catanzaro: we're on https://bugzilla.redhat.com/show_bug.cgi?id=2117710
17:54:16 <lruzicka> -1 for the time's being
17:54:34 <MichaelCatanzaro> -1 from me
17:55:06 <MichaelCatanzaro> It's a shame, but it's not highly-visible, I don't think this qualifies as basic functionality. I didn't know this button existed and most nautilus users will not notice.
17:55:35 <adamw> thanks
17:56:04 <TheExorcist[m]> LunaJernberg[m]: It should be +1 for final blocker. It either should work, or the button to be removed.
17:56:27 * bcotton is satisfied. -1 for real now
17:56:34 <adamw> proposed #agreed 2117710 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) RejectedBlocker (Final) - there are no relevant criteria for Beta. For Final, we agreed this does not meet the "basic functionality' bar. But it's accepted as a Beta FE as it's a visible bug in a core component that can be used on live images so a safe fix would be reasonable
17:56:40 <LunaJernberg[m]> ack
17:57:06 <adamw> The Exorcist: the release criteria don't say "every possible operation in every application must work", they say "basic functionality".
17:57:27 <adamw> cmurf: was that ok on IRC? last word 'reasonable'
17:57:44 <jednorozec> last work is reasonable
17:57:54 <adamw> yay
17:58:10 <cmurf> ack
17:58:12 <LunaJernberg[m]> ack
17:58:23 <jednorozec> ack
17:58:31 <bcotton> ack
17:58:59 <adamw> #agreed 2117710 - RejectedBlocker (Beta) AcceptedFreezeException (Beta) RejectedBlocker (Final) - there are no relevant criteria for Beta. For Final, we agreed this does not meet the "basic functionality' bar. But it's accepted as a Beta FE as it's a visible bug in a core component that can be used on live images so a safe fix would be reasonable
17:59:10 <lruzicka> ack
17:59:23 <adamw> OK, let's circle back to
17:59:24 <adamw> #topic (2117859) FreeIPA client enrolment fails due to DNS issues with openssl-pkcs11-0.4.12-2.fc37 on server
17:59:27 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2117859
17:59:30 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/852
17:59:33 <adamw> #info Proposed Blocker, openssl-pkcs11, NEW
17:59:44 <adamw> #info Ticket vote: BetaBlocker (+4,0,-0) (+kparal, +lruzicka, +bcotton, +bittin)
18:00:13 <adamw> so my upgrade test with dnssec enabled failed. unfortunately i forgot to tail logs on the server so i'm not 100% sure it's the same bug; it could be something else. i'm re-running with log tailing on server end enabled (i hope)
18:00:29 <adamw> still, with that info i think a +1 would be reasonable. i can keep investigating and we can always revote later
18:00:42 <adamw> i'm ok with +1 or punt
18:00:46 <LunaJernberg[m]> +1 and discuss it next week
18:00:47 <LunaJernberg[m]> when adamw is done testing
18:01:33 <adamw> oh wait. hold on. i'm an idiot
18:01:44 <adamw> i forgot f37 isn't actually affected by this bug atm as we blocked the problematic update
18:01:46 <adamw> only rawhide is affected right now
18:01:49 <adamw> but the change is still sort of queued for f37
18:02:09 <adamw> (and the thing the update was meant to fix is still utterly broken, it just doesn't break openqa's tests)
18:02:15 <adamw> uh. um. hmm.
18:02:43 <adamw> can we just punt this and i'll try to be less confused about it next week? 😅
18:02:56 <LunaJernberg[m]> sounds good
18:03:03 <lruzicka> +1 for punt
18:03:13 <cmurf> Adam you get unlimited no question punts.
18:03:30 <adamw> haha
18:03:31 <adamw> we'll never release again!
18:03:31 <LunaJernberg[m]> :P
18:03:38 <bcotton> if we never release, we're not technically late
18:04:15 <LunaJernberg[m]> :D ;)
18:04:34 <adamw> Ben Cotton (he/him): welp, i'm off to the beach
18:05:25 <adamw> proposed #agreed 2117859 - punt (delay decision) - we agreed to delay the decision here so adamw can do some more research and get the story of what exactly is affected and what needs doing sorted out.
18:05:32 <LunaJernberg[m]> ack
18:05:45 <bcotton> acl
18:05:47 <bcotton> ack, too
18:05:48 <lruzicka> ack
18:06:09 <jednorozec> ack
18:06:40 <adamw> #agreed 2117859 - punt (delay decision) - we agreed to delay the decision here so adamw can do some more research and get the story of what exactly is affected and what needs doing sorted out.
18:06:47 <adamw> alrightty
18:06:48 <adamw> #topic Accepted Beta blocker review
18:06:57 <adamw> there's just one of these...
18:06:59 <adamw> #topic (2110801) Logout from KDE session on Rawhide goes to console, not SDDM
18:07:02 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2110801
18:07:05 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/837
18:07:12 <adamw> #info Accepted Blocker, sddm, POST
18:07:20 <adamw> note we are not voting again, we're checking on progress of fixing the bug
18:07:25 <TheExorcist[m]> +1 beta blocker
18:07:41 <TheExorcist[m]> adamw: OK
18:07:51 <adamw> ben points out this may get resolved by switching sddm back to X11, we'll see
18:08:09 <LunaJernberg[m]> a PR was merged 1 hour ago to test things
18:08:12 <LunaJernberg[m]> https://src.fedoraproject.org/rpms/sddm/pull-request/5
18:08:45 <adamw> #info Ben Cotton (he/him) points out this may be resolved by switching SDDM back to X11, which will happen in the next compose
18:08:58 <adamw> #action adamw to check whether this bug goes away once SDDM is on X11 again
18:09:11 <adamw> ...aaaand i think we're done
18:09:13 <adamw> #topic Open floor
18:09:16 <adamw> anything else, folks?
18:09:43 <LunaJernberg[m]> not checking the accepted blockers for Final ?
18:09:48 <LunaJernberg[m]> other then that i don't have anything
18:09:51 <adamw> Luna Jernberg: not necessary at this point
18:09:54 <adamw> and it'd make the meeting go on forever
18:09:56 <LunaJernberg[m]> adamw: ah alright
18:09:56 <bcotton> i think we've meetinged enough for one day
18:10:02 <bcotton> beta freeze starts tomorrow!
18:10:18 <adamw> woohoo! i'll drink to that
18:10:29 <lruzicka> I think I will have a Final blocker for gnome-calendar
18:10:34 <jednorozec> if I dont forget to turn it on ;)
18:10:54 <lruzicka> https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/858
18:11:29 <LunaJernberg[m]> lruzicka: +1 FB
18:11:56 <adamw> lruzicka: wasn't something a lot like that in the set of late app blockers for f36?
18:11:57 <adamw> it sounds super familiar
18:12:08 <lruzicka> LunaJernberg[m], it seems so but I'd like a confirmation of someone else that they also see this.
18:12:15 <lruzicka> adamw, yeah, sort of
18:13:10 <bcotton> yeah, but at least we found it early this time :-)
18:14:06 <lruzicka> bcotton, I want to go over all the Gnome apps before Beta is out.
18:14:14 <adamw> well, i was thinking, is it the same bug rediscovered...
18:15:26 <lruzicka> adamw, I cannot remember if it got fixed or not.
18:18:09 <adamw> aha
18:18:30 <adamw> it's very similar to https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/241 , but for calendar not contacts
18:18:45 <adamw> there was also https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/775 but that's a bit different (kinda opposite)
18:19:15 <adamw> anyway, yeah, i'd probably be +1 on that - file an rh bug and propose it, we can vote in the app
18:19:19 <adamw> anything else folks?
18:19:50 <cmurf> I've got nothing
18:19:56 <lruzicka> I will do ... it is quite similar, just that it even does not help to restart application and I am still seeing those events.
18:20:02 <lruzicka> not from me
18:20:14 <LunaJernberg[m]> nope
18:20:47 <lruzicka> new stuff!!! - the events got deleted when I restarted the computer after the crash :D
18:21:01 <LunaJernberg[m]> :o
18:21:17 <adamw> alrighty, thanks for coming everyone
18:21:21 <adamw> keep debugging lruzicka :D
18:21:28 <adamw> thanks for testing those gnome apps early this cycle
18:21:35 <adamw> see you next time!
18:21:37 <adamw> #endmeeting