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