16:01:10 <adamw> #startmeeting F38-blocker-review 16:01:10 <zodbot> Meeting started Mon Apr 3 16:01:10 2023 UTC. 16:01:10 <zodbot> This meeting is logged and archived in a public location. 16:01:10 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:01:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:10 <zodbot> The meeting name has been set to 'f38-blocker-review' 16:01:13 <adamw> #meetingname F38-blocker-review 16:01:13 <zodbot> The meeting name has been set to 'f38-blocker-review' 16:01:16 <adamw> #topic Roll Call 16:01:22 <adamw> ahoy folks 16:01:32 <frantisekz> .hello2 16:01:38 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com> 16:01:38 <Eighth_Doctor> .hello ngompa 16:01:43 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com> 16:01:44 <lruzicka> .hello2 16:01:50 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com> 16:01:50 <marcdeop[m]> .hello2 16:01:53 <coremodule> .hello2 16:01:56 <bcotton> .hello2 16:01:56 <zodbot> marcdeop[m]: Sorry, but user 'marcdeop [m]' does not exist 16:02:01 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com> 16:02:05 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com> 16:02:10 <geraldosimiao> .hello geraldosimiao 16:02:11 <TheExorcist[m]> .hello2 16:02:17 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com> 16:02:21 <zodbot> TheExorcist[m]: Sorry, but user 'TheExorcist [m]' does not exist 16:02:39 <TheExorcist[m]> .hello naraiank 16:02:45 <zodbot> TheExorcist[m]: naraiank 'None' <knaraian@mail.com> 16:02:46 <lruzicka> TheExorcist[m], marcdeop[m] hello2 only works with FAS 16:03:16 <adamw> how's everyone doing 16:03:25 <Eighth_Doctor> ehh 16:03:27 <davdunc[m> .hello2 16:03:27 <zodbot> davdunc[m: Error: Missing "]". You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands. 16:03:32 <davdunc[m> .hello2 davdunc 16:03:32 <zodbot> davdunc[m: Error: Missing "]". You may want to quote your arguments with double quotes in order to prevent extra brackets from being evaluated as nested commands. 16:03:42 <davdunc[m> * .hello davdunc 16:03:44 <Eighth_Doctor> davdunc: .hello2 doesn't take args 16:04:11 * kparal is here 16:04:15 <davdunc[m> looks like I am off by a bracket on my nick again. 16:04:31 <TheExorcist[m]> good, but was out of town for last few months, just returned a week ago. Thanks for askingadamw 16:04:40 <adamw> stop trying to hack our bot, davdunc, jeez :D 16:04:55 <davdunc[m> .hello davdunc 16:05:00 <zodbot> davdunc[m: davdunc 'David Duncan' <davdunc@amazon.com> 16:05:05 <davdunc[m> adamw: one more time! 16:06:17 <adamw> alllrighty 16:06:26 <coremodule> I'll act as secretary. 16:06:32 <adamw> #chair bcotton lruzicka 16:06:32 <zodbot> Current chairs: adamw bcotton lruzicka 16:06:39 <adamw> impending boilerplate alert 16:06:45 <adamw> #topic Introduction 16:06:47 <adamw> Why are we here? 16:06:51 <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:06:53 <adamw> #info We'll be following the process outlined at: 16:06:55 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting 16:06:58 <adamw> #info The bugs up for review today are available at: 16:07:01 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current 16:07:03 <adamw> #info The criteria for release blocking bugs can be found at: 16:07:06 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria 16:07:09 <adamw> #link https://fedoraproject.org/wiki/Fedora_38_Beta_Release_Criteria 16:07:11 <adamw> #link https://fedoraproject.org/wiki/Fedora_38_Final_Release_Criteria 16:07:25 <adamw> #info for Final, we have: 16:07:29 <adamw> #info 2 Proposed Blockers 16:07:32 <adamw> #info 3 Accepted Blockers 16:07:34 <adamw> #info 3 Proposed Freeze Exceptions 16:07:41 <adamw> #info 6 Accepted Freeze Exceptions 16:07:47 <adamw> #info coremodule will secretarialize 16:07:51 <adamw> let's get started with... 16:07:54 <adamw> #topic Proposed Final blockers 16:07:59 <adamw> #topic (2180849) Gnome desktop notifications shown at the wrong times 16:08:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2180849 16:08:05 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1134 16:08:06 <adamw> #info Proposed Blocker, gnome-shell, NEW 16:08:10 <adamw> #info Ticket vote: FinalBlocker (+0,0,-1) (-frantisekz) 16:08:40 <frantisekz> heh... not many votes there :D 16:08:42 <adamw> so i guess we could make a case for judoing this under final criterion "Release-blocking desktops must notify the user of available updates, but must not do so when running as a live image", on the basis you might not always get the notification due to this bug... 16:09:25 <adamw> feels a bit borderline to me. 16:09:39 <kparal> the first problem here for me is that it behaves completely differently on my system 16:10:16 <adamw> yeah, i saw your comment 16:10:21 <adamw> still, it doesn't behave right 16:10:30 <kparal> it's easy to test, so try it 16:10:32 <bcotton> yeah, i can't reproduce this either 16:10:41 <kparal> that's true 16:10:55 <SumantroMukherje> I can't reproduce either 16:11:01 <adamw> i'm thinking something gets confused when notifications occur together or very close to each other 16:11:14 <kparal> I don't think this is a blocker, though. It's not that common that notifications are spammed at the very same instant. 16:11:22 <adamw> i wonder if gnome shell actually has the capability to display two notifications at once at all 16:11:26 <kparal> And the general functionality is working ok 16:11:36 <adamw> kparal: it is more likely if you have notifications from some kinda chat system enabled, to be fair 16:11:46 <kparal> it's possible that this is just a race 16:12:06 <adamw> on the whole i guess i'd lean -1 atm 16:12:15 <kparal> -1 here as well 16:12:45 <SumantroMukherje> -1 here 16:12:50 <lruzicka> -1 I have not even seen it when using my system normally. 16:13:21 <geraldosimiao> -1 too 16:13:41 <TheExorcist[m]> adamw: I guess there are threads are being created for notifications, generally should not.. 16:13:45 <adamw> proposed #agreed 2180849 - RejectedBlocker (Final) - it was agreed this is just too much of a corner case to constitute a violation of the panel or update notification criteria, so it's rejected 16:13:57 <lruzicka> ack 16:13:59 <bcotton> ack 16:14:01 <TheExorcist[m]> -1 16:14:06 <TheExorcist[m]> ack 16:14:21 <geraldosimiao> ack 16:14:28 <SumantroMukherje> ACK 16:14:46 <kparal> ack 16:15:26 <adamw> #agreed 2180849 - RejectedBlocker (Final) - it was agreed this is just too much of a corner case to constitute a violation of the panel or update notification criteria, so it's rejected 16:15:33 <adamw> #topic (2183034) packages with file capabilities fail to install in podman on F38 host 16:15:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2183034 16:15:38 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1132 16:15:40 <adamw> #info Proposed Blocker, podman, NEW 16:15:43 <adamw> #info Ticket vote: FinalBlocker (+1,0,-3) (+sumantrom, -nielsenb, -geraldosimiao, -frantisekz) 16:16:14 <kparal> there are recent findings in the bugzilla 16:16:16 <kparal> in short, this seems to affect those who have certain podman configuration 16:16:36 <kparal> since I haven't changed anything myself, I guess it means if you used podman in the past, you might be affected 16:16:47 <kparal> clean installs are likely not affected 16:16:55 <kparal> clean F38 installs 16:17:34 <kparal> I have this feeling that containers are important but there seems to be no criteria for them 🙂 16:17:34 <adamw> if clean installs aren't affected i'm probably -1 16:18:26 <kparal> adamw: well, we still have an upgrade criterion 16:18:26 <TheExorcist[m]> has podman also got new version? if so, did anybody tested F38 with old version of podman? and is working as expected on old podman on F38? 16:18:26 <davdunc[m> kparal: +1 on that feeling. 16:19:01 <adamw> kparal: yeah, it might be nice to check f36 and f37 upgraded to f38 i guess 16:19:06 <kparal> as I understand it, it's not caused by podman 16:19:17 <kparal> but by lower stacks 16:19:41 <Eighth_Doctor> this is increasingly in our hot path too :( 16:19:42 <Eighth_Doctor> because of toolbx and other things 16:19:56 <kparal> that's also not blocking at the moment, it seems 16:20:08 * Eighth_Doctor grumbles 16:20:33 <kparal> I tried a very simple upgrade f37->f38 and it worked ok. But I think it might be because I didn't use toolbox/podman with the original kernel version in f37, but with the latest one 16:20:51 <adamw> i guess we want to try install f36, use toolbox, upgrade to f38 16:21:07 <kparal> yes, something like that 16:21:17 <adamw> still, i'd kinda argue we're a bit late to be suddenly making this release blocking 16:21:21 <kparal> but before I spend lot of time on it, it would be good to know whether it's considered blocking at all 16:21:27 <adamw> yes, we have a sort of agreement in principle that it might be a good idea 'in the future' 16:21:35 <adamw> but blocking f38 on it right now seems a bit premature 16:23:27 <bcotton> my gut says it should be but maybe we develop an appropriate set of criteria for F39 and just grant an FE for 38 in the hopes that it gets fixed :-) 16:23:28 <kparal> workstation wg clearly wanted to block on toolbox more: https://pagure.io/fedora-qa/issue/716 16:23:32 <Eighth_Doctor> I'm fine with it being FE this cycle and having blocker criteria next cycle 16:23:39 <bcotton> yeah, we're essentially a week away from generating an RC, which is ...not much time to develop, refine, and accept a criterion 16:23:50 <kparal> I agree 16:24:01 <Eighth_Doctor> fwiw, we'll probably want this for the Fedora KDE side too 16:24:15 <Eighth_Doctor> I don't want to preload toolbox without release criteria 16:24:45 <adamw> as i noted in that ticket, it may not even exactly need a criterion if 'the toolbox container' itself is considered a release-blocking deliverable. but as of now, it isn't. 16:25:10 <adamw> (it's not even really built by fedora releng). 16:25:10 <geraldosimiao> ok, so we propose it as a FE for now? 16:25:26 <geraldosimiao> I'm ok with that 16:25:29 <adamw> i'm +1 FE 16:25:37 <frantisekz> yeah, +1 FE for sure 16:25:55 <Eighth_Doctor> +1 FE 16:25:57 <geraldosimiao> +1 FE 16:26:03 <bcotton> +1 FE 16:26:07 <lruzicka> +1fe 16:26:54 <kparal> +1 fe 16:27:36 <adamw> proposed #agreed 2183034 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as we really do not have the framework in place to treat toolbox as release blocking for now (see tickets). it's accepted as an FE, though, as it would definitely be good to have it working at release for the increasingly popular immutable editions 16:27:55 <bcotton> ack 16:27:57 <frantisekz> ack 16:28:06 <geraldosimiao> ack 16:28:17 <Eighth_Doctor> ack 16:28:27 <kparal> ack 16:29:11 <lruzicka> ack 16:29:55 <adamw> #agreed 2183034 - RejectedBlocker (Final) AcceptedFreezeException (Final) - this is rejected as we really do not have the framework in place to treat toolbox as release blocking for now (see tickets). it's accepted as an FE, though, as it would definitely be good to have it working at release for the increasingly popular immutable editions 16:30:10 <adamw> OK, that's the proposed blockers, let's move on to: 16:30:16 <adamw> #topic Proposed Final freeze exceptions 16:30:21 <adamw> #topic (2183038) Rebuild to pull in cryptographic fixes for RPM (bug 2170878) 16:30:24 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2183038 16:30:26 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1135 16:30:29 <adamw> #info Proposed Freeze Exceptions, fedora-toolbox, ON_QA 16:30:51 <adamw> note this is for a container. i don't know if the freeze actually applies to containers, but hey, no harm granting an FE if it's justified. I'm +1 for this one 16:31:09 <lruzicka> +1 16:31:10 <frantisekz> +1 16:31:35 <Eighth_Doctor> +1 16:31:51 <bcotton> +! 16:32:03 <Eighth_Doctor> (sidebar, we should probably figure out a process for containers) 16:32:07 <kparal> +1 16:32:43 <TheExorcist[m]> +1 16:33:40 <geraldosimiao> +1 16:33:45 <adamw> proposed #agreed 2170878 - AcceptedFreezeException (Final) - obviously it'd be good to have the known cryptographic issues fixed in the toolbox image too 16:33:55 <frantisekz> ack 16:33:57 <lruzicka> ack 16:35:03 <geraldosimiao> ack 16:35:06 <adamw> #agreed 2170878 - AcceptedFreezeException (Final) - obviously it'd be good to have the known cryptographic issues fixed in the toolbox image too 16:35:13 <adamw> #topic (2184091) LLVM 16 pull Into Fedora 38 (FreezeException) 16:35:15 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2184091 16:35:18 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1136 16:35:21 <adamw> #info Proposed Freeze Exceptions, llvm, NEW 16:35:35 <bcotton> ack 16:35:44 <adamw> why couldn't this be done before freeze? 16:35:56 <Eighth_Doctor> ack 16:35:56 <adamw> changes are supposed to be done well before we're worrying about final freeze 16:36:09 <frantisekz> it's already too late for it now to be pulled into the updates/fedora repos 16:36:26 <frantisekz> it is ready, llvm team is finishing fixes for two remaining broken packages 16:36:53 <adamw> i'm not honestly thrilled about landing mesa built against a new llvm this late 16:36:56 <adamw> that sounds like a recipe for trouble 16:37:11 <Eighth_Doctor> adamw: because apparently LLVM doesn't practice good hygiene and can't stabilize the ABI until the very last second 16:37:32 <frantisekz> yeah, I am kinda okay with it at this point, it can always be rebuilt against llvm15 if there were some issues 16:37:33 <Eighth_Doctor> this is known and unfortunately we knew from the FESCo side this would happen 16:37:48 <adamw> and does fesco want to land it? 16:38:41 <Eighth_Doctor> we accepted it already, so yeah 16:38:50 <Eighth_Doctor> we knew it was coming late, so sadly yeah 16:38:55 <adamw> well, no, but, that's not how Changes work 16:38:58 <adamw> there's a schedule 16:39:01 <bcotton> not all "late"s are equal though 16:39:03 <adamw> if they're not 'code complete' at beta they're not meant to land 16:39:09 <Eighth_Doctor> we accepted it with the general "upstream needs to be better" finger-wag 16:39:26 <adamw> i'm confused at what was 'accepted' 16:39:31 <adamw> you mean the lateness was accepted? 16:39:41 <Eighth_Doctor> but I don't know if they care, since there's really only one vendor's roadmap that matters, and it ain't us 16:39:51 <bcotton> #link https://pagure.io/fesco/issue/2958#comment-843760 16:40:33 <Eighth_Doctor> yes 16:40:41 <bcotton> from the link above, " This will happen prior to GA freeze." which is still technically true, but... 16:40:41 <adamw> that comment says "This will happen prior to GA freeze." 16:40:44 <adamw> yeah. 16:40:49 <adamw> yet now we're being asked to approve an FE 16:40:54 <Eighth_Doctor> we accepted it being this late 16:40:57 <adamw> i am honestly pretty tempted to say no. this is clearly not how changes are meant to work. 16:41:03 <Eighth_Doctor> we weren't happy about it, but we accepted it 16:41:30 <lruzicka> Which means we do not have the chance to say no? 16:41:58 <Eighth_Doctor> you can say no if you like, but from the fesco side, we're grudgingly okay with it 16:41:58 <TheExorcist[m]> adamw: +1 16:42:00 <adamw> i'm not really buying that comment as accepting landing this after final freeze. 16:42:15 <adamw> but yeah, i think i argued myself into -1 on this 16:42:31 <adamw> if the only justification for an FE is "it's an accepted change" that's not sufficient, because changes *are already meant to be done* by now 16:42:48 <adamw> if this fixed some terrible problem people are having with llvm 15 that might be different, but... 16:43:03 <lruzicka> what are the benefits for Fedora if it lands? 16:43:09 <frantisekz> one question here from me 16:43:14 <bcotton> also, the llvm16 build was finished on 30 March and there's still no update in bodhi, which is a little concerning about the attention being paid to it 16:43:26 <frantisekz> lruzicka: they're listed here: https://fedoraproject.org/wiki/Changes/LLVM-16 16:43:33 <Eighth_Doctor> lruzicka: significant performance boosts for Mesa-powered graphics 16:43:35 <Eighth_Doctor> is the main user-visible benefit 16:44:06 <lruzicka> thanks, Eighth_Doctor 16:44:07 <frantisekz> yeah, the bodhi update is being held because of breakage in two packages, can ask tuliom which of the packages are affected 16:44:11 <adamw> that says "New features and bug fixes provided by the latest version of LLVM." 16:44:12 <adamw> that's...vague. 16:44:16 <lruzicka> frantisekz, New features and bug fixes provided by the latest version of LLVM sound quite vague to me. 16:44:36 <frantisekz> the question here for me is, if it's declined, can it land in f38 at all? 16:44:54 <frantisekz> I think it shouldn't be able to according to package update guidelines 16:45:09 <Eighth_Doctor> also the change does list final freeze as its deadline :/ 16:45:11 <bcotton> that sounds like a good argument against granting an FE at this point. it seems unnecessarily risky 16:45:35 <adamw> frantisekz: by policy, no, it shouldn't then be updated after release. in practice, we don't tend to stop people doing that. 16:46:30 <Eighth_Doctor> if they can't fix it, those packages will be pointed to llvm15 (per the change) 16:46:35 <Eighth_Doctor> but I think one thing we should insist from the FESCo side is that they probably need to start landing this stuff even with ABI breaking RCs 16:46:47 <Eighth_Doctor> it's going to suck for them more, which might be sufficient motivation to get them to make upstream care to stabilize RCs 16:47:43 <bcotton> -1 FE 16:48:21 <Eighth_Doctor> +1 FE (with heavy finger wagging) 16:48:25 <frantisekz> +1 FE 16:48:38 <lruzicka> -1 FE 16:48:43 <Eighth_Doctor> the consequence of not shipping this is that we're potentially going to have problems with mesa updates down the road 16:48:57 <Eighth_Doctor> as mesa is a fairly aggressive consumer of llvm things 16:49:01 <adamw> what is the basis for voting +1, according to https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Freeze_exception_bug_principles ? 16:49:18 <adamw> Conan Kudo: why would we want to take major mesa updates into a stable release? 16:49:46 <jforbes> hardware support 16:49:51 <Eighth_Doctor> yep 16:49:54 <Eighth_Doctor> that 16:50:36 <bcotton> i think the other thing from the FESCo side is that they should be very wary of accepting changes with a final freeze deadline because we lose out on having it in the beta 16:50:36 <Eighth_Doctor> kernel, linux-firmware, mesa, and a few other packages make up hardware enablement 16:50:36 <kparal> F37 just received mesa 23 in updates-testing, fyi 16:50:54 <kparal> so major mesa bumps are definitely happening in stable releases 16:51:08 <adamw> if there's a solid justification to update mesa after f38 release and doing so requires an llvm update, we can update it then 16:51:26 <Eighth_Doctor> Ben Cotton (he/him): you're right, and I think this is probably going to result in us basically requiring LLVM RCs to land even if they are ABI breaking 16:51:26 <adamw> this still doesn't justify updating it now during final freeze when we do not actually need it for anything, for me 16:51:54 <Eighth_Doctor> because having to make this call now is way shittier than having it done earlier 16:52:21 <lruzicka> what are ABI breaking RCs? 16:52:37 <frantisekz> upstream "practice" I'd say? 16:53:01 <jforbes> I guess the only other question is, how much of a performance boost is this, and how much weight do you give reviews? 16:53:03 <TheExorcist[m]> adamw: I feel, it is not worth releasing, if it is working fine in its present form, than risking new issues.. 16:53:59 <Eighth_Doctor> lruzicka, frantisekz: that's what the llvm maintainers told us, yeah... how much of a breakage occurs between RCs is not quantified because they've never shipped them in Fedora before 16:54:38 <adamw> benchmarks would be useful, sure. i doubt any site other than phoronix would care what llvm version we ship in final. 16:54:39 <Eighth_Doctor> jforbes: from a reputation pov, we get major brownie points in reviews for having the latest driver stacks, so there's that 16:54:43 <frantisekz> it was also, unfortunately held back by spirv-headers > spirv-llvm-translator chain 16:54:55 <frantisekz> which llvm usually don't depend on, but llvm 16 did this time 16:55:21 <TheExorcist[m]> We always can release with new upgrade with more stable updated packages. 16:55:22 <TheExorcist[m]> its my opinion. 16:55:27 <frantisekz> and it took me a week to get X ack for bump on spirv-headers 16:55:34 <lruzicka> So I am still not quite sure, but I somehow feel like there is a risk we will not be able to get a stable RC at all. 16:55:57 <lruzicka> in time 16:56:31 <Eighth_Doctor> can we get this stack into a compose before we integrate it? 16:56:42 <Eighth_Doctor> and see if it breaks anything? 16:56:58 <frantisekz> imo, we don't need to, we can revert mesa to BR llvm15? 16:57:02 <frantisekz> in case 16:57:12 <Eighth_Doctor> that's true 16:57:23 <Eighth_Doctor> from an actual system risk perspective, it's actually quite low 16:57:34 <Eighth_Doctor> if it sucks, we can force mesa back 16:57:44 <adamw> it's a timing thing 16:57:55 <adamw> we have several months of people using f38 with the current mesa on the current llvm 16:58:01 <adamw> we have tests of basic graphics mode, all that stuff 16:58:16 <adamw> we do not have any history of people using rebuilds of mesa (and all the other stuff that builds on llvm) against a new major release of llvm 16:58:26 <adamw> what if we put it in and it's all fine at first then in a week someone finds a major problem? 16:58:31 <adamw> what if someone finds a major problem the day after release? 16:58:35 <adamw> this is why we have change deadlines 16:59:12 <adamw> especially for something like mesa, "if it breaks" is not necessarily a thing that is super obvious the moment we put out a compose 16:59:57 <frantisekz> if mesa is the problem, it can be ommited imo? 17:00:11 <frantisekz> it'll pull llvm15-libs, if the rebuild isn't included 17:00:25 <adamw> that sort of breaks the main alleged benefit of the new llvm, though - better performance in mesa. 17:00:30 <adamw> so then why are we pulling it in? 17:00:33 <bcotton> agreed. the accepted deadline is very generous and it still wasn't met. i don't see a compelling reason to grant an FE here 17:01:21 <frantisekz> bcotton: I think it can technically be met by having the bodhi update by tomorrow? it's a bit muddy depending on perspective 17:01:36 <adamw> as of now we're at -3/+2 17:01:46 <adamw> frantisekz: to me, if it needs an FE, it clearly didn't mean the deadline. 17:01:59 <bcotton> frantisekz: possibly, but then it wouldn't need an FE anyway :-) 17:06:18 <adamw> proposed #agreed 2184091 - punt (delay decision) - we do not have a clear vote on this (we are at +2 / -3 for a total of -1), so we will punt it. note this is effectively close to a rejection, as we are very unlikely to accept this later if we don't accept it now. 17:06:41 <geraldosimiao> ack 17:06:47 <frantisekz> ack 17:06:47 <bcotton> ack 17:06:48 <marcdeop[m]> ack 17:06:50 <Eighth_Doctor> ack 17:06:50 <lruzicka> ack 17:07:03 <adamw> #agreed 2184091 - punt (delay decision) - we do not have a clear vote on this (we are at +2 / -3 for a total of -1), so we will punt it. note this is effectively close to a rejection, as we are very unlikely to accept this later if we don't accept it now. 17:07:09 <adamw> #topic (2176759) Some apps take much longer to start in Plasma in F38 than F37 if xdg-desktop-portal-gnome is installed 17:07:12 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2176759 17:07:14 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1133 17:07:17 <adamw> #info Proposed Freeze Exceptions, xdg-desktop-portal-gnome, POST 17:07:19 <adamw> #info Ticket vote: FinalFreezeException (+2,0,-0) (+adamwill, +geraldosimiao) 17:07:38 <bcotton> +1 FE 17:07:39 <adamw> this is an easy +! for me 17:07:42 <adamw> +1* 17:07:53 <frantisekz> +1 17:08:02 <lruzicka> +1 17:08:10 <Eighth_Doctor> +1 17:08:18 <adamw> brb, sorry 17:08:18 <kparal> +1 17:08:22 <adamw> if another chair wants to sign this off, go ahead 17:08:26 <adamw> just picking up an ikea delviery 17:11:01 <TheExorcist[m]> +1 17:11:35 <marcdeop[m]> +1 17:11:37 <kparal> #chair 17:11:39 <kparal> will it tell me who's in #chair? I guess not 17:11:45 <lruzicka> I am 17:11:45 <geraldosimiao> adam, ben and lruzicka 17:12:31 <bcotton> proposed #agreed 2176759 - AcceptedFreezeException - This is behavior would be good to fix for the live images. 17:12:45 <bcotton> patch 17:12:46 <geraldosimiao> ack 17:12:54 <bcotton> proposed #agreed 2176759 - AcceptedFreezeException - This is behavior that would be good to fix for the live images. 17:13:06 <adamw> ack 17:13:07 <lruzicka> ack 17:13:08 <geraldosimiao> ack 17:13:11 <adamw> oh 17:13:17 <adamw> thanks 17:13:26 <kparal> and not just live images 🙂 17:13:27 <kparal> ack 17:13:27 <TheExorcist[m]> ack 17:13:33 <Eighth_Doctor> ack 17:13:41 <adamw> #agreed 2176759 - AcceptedFreezeException - This is behavior that would be good to fix for the live images. 17:13:44 <bcotton> #agreed 2176759 - AcceptedFreezeException - This is behavior that would be good to fix for the live images. 17:13:51 <adamw> snap 17:14:05 <adamw> alrighty, that's all the FEs. let's do a quick review of... 17:14:10 <adamw> #topic Accepted Final blockers 17:14:15 <adamw> #topic (2171350) anaconda failed to detect the fcoe target(only affects ixgbe) 17:14:19 <bcotton> doubly agreed! 17:14:20 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2171350 17:14:23 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1041 17:14:26 <adamw> #info Accepted Blocker, kernel, NEW 17:14:35 <geraldosimiao> 😆 17:14:39 <adamw> as of this morning we have some new info that lili was testing on different hardware 17:14:47 <adamw> and it seems like it's been broken on that hw for a while 17:15:07 <adamw> so we'll try and test on the hardware that worked for f34->f37 and if it works we can probably say this isn't a blocker 17:15:10 <TheExorcist[m]> +1 17:15:16 <adamw> we're not voting, we're reviewing 17:15:32 <adamw> #info this is pending re-testing with different hardware, it may not be a blocker in the end. see details in bug 17:15:47 <TheExorcist[m]> OK 17:17:57 <adamw> #topic (2179591) Logging out of Plasma 5.27.3 on Wayland as the second user on the system resulted in a black screen 17:18:00 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2179591 17:18:03 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1122 17:18:06 <adamw> #info Accepted Blocker, plasma-workspace, NEW, depends on other bugs 17:18:30 <adamw> it seems like debugging is still ongoing here, but nothing concrete... 17:18:37 <adamw> i'm a bit concerned about the timeframe at this point 17:21:43 <adamw> Conan Kudo: anything from kde perspective on this one, or is it just a case of keep trucking on it? do we fallback to x11 again if we can't figure it out? 17:23:57 <geraldosimiao> I cannot reporduce it anymore 17:23:59 <geraldosimiao> reproduce 17:24:14 <marcdeop[m]> I've contacted a couple of KDE developers and they don't know anything 17:24:15 <marcdeop[m]> d_ed might know something, I need to get hold of him 17:24:30 <adamw> there's definitely some inconsistency in reproduction... 17:24:39 <adamw> kparal reported the same 17:25:06 <marcdeop[m]> taking into account that we have multiuser and user switching disabled by default... I still don't consider this a blocker 17:25:11 <Eighth_Doctor> adamw: it seems to affect both x11 and wayland though? 17:25:25 <marcdeop[m]> Eighth_Doctor: I think it's only wayland 17:25:46 <geraldosimiao> I just runned some tests on Fedora-KDE-Live-x86_64-38-20230331.n.0.iso and thi bug didn't showed anymore, at my VM setup. 17:26:07 <Eighth_Doctor> and I haven't seen this bug before either 17:26:25 <TheExorcist[m]> adamw: it could be related to RAM and swapping, so reproducing the issue would be difficult. it happens once in 10 times or more.. 17:27:18 <adamw> marcdeop: i didn't think the bug required user switching to trigger? 17:28:43 <TheExorcist[m]> TheExorcist[m]: and something related to memory management. 17:29:11 <adamw> #info this is still under investigation, but it seems difficult to reproduce reliably and debug. we will continue to work on it 17:29:27 <marcdeop[m]> adamw: I am probably wrong here. Apologies 17:30:09 <Eighth_Doctor> adamw: I am of the opinion that this might be sufficiently difficult to reproduce, track down, and fix for it to be a blocker 17:30:26 <adamw> i think we can consider that later, if we can't get any further with fixing it 17:30:29 <adamw> for now we still have some time 17:30:29 <Eighth_Doctor> fwiw, I have 3 separate systems that I can't repro it on 17:31:11 <adamw> #topic (2113005) Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards 17:31:14 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2113005 17:31:17 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/1087 17:31:20 <adamw> #info Accepted Blocker, shim, NEW 17:31:22 <adamw> not much news here 17:31:25 <adamw> we're probably gonna have to waive this 17:32:41 <geraldosimiao> yeah, probably a thing for F39... 17:33:22 <lruzicka> I need to leave, sorry about that. Take care. 17:34:04 <adamw> i can't find any movement on the upstream patch set since the middle of march 17:34:47 <adamw> #info this is still waiting on the upstream NX patches, which AFAICS haven't moved since mid-March. we will likely have to waive it 17:35:16 <Eighth_Doctor> I think we're screwed at this point 17:35:33 <jforbes> With timing now, I think even if that patch set were posted and reviewed, it would be a solid wait for the signed shim 17:36:11 <adamw> jforbes: the patch set is posted, isn't it? well, v5 was the last i caught 17:36:20 <adamw> there was a lot of discussion around v5 on march 14/15 then...nothing further 17:36:33 <adamw> https://lkml.org/lkml/2023/3/14/390 17:36:40 <jforbes> I expected we would see a v6 17:36:46 <adamw> ah i see 17:39:04 <adamw> #topic Open floor 17:39:18 <adamw> that's all the bugs on the list, any other business? anything we missed? 17:43:09 <TheExorcist[m]> nothing on my list for this meeting. 17:43:15 <marcdeop[m]> I just want to thank you all for your outstanding work 17:43:25 <marcdeop[m]> <3 17:44:21 <TheExorcist[m]> adamw: I guess we can conclude. 17:45:43 <adamw> yup, seems like it 17:45:47 <adamw> thanks everyone for coming 17:45:55 <adamw> #endmeeting