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