16:00:18 <adamw> #startmeeting F37-blocker-review
16:00:18 <zodbot> Meeting started Mon Oct 31 16:00:18 2022 UTC.
16:00:18 <zodbot> This meeting is logged and archived in a public location.
16:00:18 <zodbot> The chair is adamw. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:18 <zodbot> The meeting name has been set to 'f37-blocker-review'
16:00:21 <adamw> #meetingname F37-blocker-review
16:00:21 <zodbot> The meeting name has been set to 'f37-blocker-review'
16:00:25 <adamw> #topic Roll Call
16:00:40 <adamw> ar324: yes, of course
16:01:48 <adamw> ahoyhoy folks, who's around for blocker review?
16:02:07 <Penguinpee> .hello gui1ty
16:02:08 <zodbot> Penguinpee: gui1ty 'Sandro .' <gui1ty@penguinpee.nl>
16:02:48 * kparal lurks, but afk for 15 min
16:03:04 <geraldosimiao> .hello geraldosimiao
16:03:05 <zodbot> geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' <geraldo.simiao.kutz@gmail.com>
16:05:20 <bcotton> .hello2
16:05:21 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
16:06:31 <adamw> how's everybody doing
16:06:41 <adamw> #chair bcottom kparal
16:06:41 <zodbot> Current chairs: adamw bcottom kparal
16:06:43 <adamw> grr
16:06:46 <adamw> #undo
16:06:46 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f933b1e3da0>
16:06:53 <bcotton> i'm about ready to turn my laptop into slag :-)
16:06:54 <adamw> sigh really?
16:07:01 <adamw> #topic Roll Call
16:07:11 <adamw> #chair bcotton kparal
16:07:11 <zodbot> Current chairs: adamw bcottom bcotton kparal
16:07:12 <nb> hi
16:07:25 <adamw> #unchair bcottom
16:07:25 <zodbot> Current chairs: adamw bcotton kparal
16:07:27 <adamw> guessed wrong? sigh
16:07:31 <adamw> oh no, guessed right
16:07:46 <OnuralpSezerhehi> .hello2 thunderbirdtr
16:07:47 <zodbot> OnuralpSezerhehi: Sorry, but user 'OnuralpSezerhehi' does not exist
16:07:47 <OnuralpSezerhehi> o/ hello
16:07:51 <adamw> if this was at defcon, somebody would definitely have won the race to do /nick bcottom there
16:08:14 <Penguinpee> adamw: one of in bcotton's nick for chairs
16:08:23 <OnuralpSezerhehi> .hello thunderbirdtr
16:08:24 <zodbot> OnuralpSezerhehi: thunderbirdtr 'Onuralp SEZER' <thunderbirdtr@gmail.com>
16:08:35 <adamw> incoming boilerplate alert!
16:08:41 <adamw> #topic Introduction
16:08:43 <adamw> Why are we here?
16:08:47 <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:08:49 <adamw> #info We'll be following the process outlined at:
16:08:52 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:08:54 <adamw> #info The bugs up for review today are available at:
16:08:56 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:08:59 <adamw> #info The criteria for release blocking bugs can be found at:
16:09:01 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:09:04 <adamw> #link https://fedoraproject.org/wiki/Fedora_37_Beta_Release_Criteria
16:09:05 <adamw> #link https://fedoraproject.org/wiki/Fedora_37_Final_Release_Criteria
16:09:13 <adamw> #info for Final, we have:
16:09:35 <adamw> #info 1 Proposed Blockers
16:09:36 <adamw> #info 3 Accepted Blockers
16:09:36 <adamw> #info 5 Proposed Freeze Exceptions
16:09:36 <adamw> #info 16 Accepted Freeze Exceptions
16:09:41 <adamw> who wants to secretarialize?
16:10:47 <adamw> i guess i'll do it!
16:10:52 <adamw> #info adamw will secretarialize
16:11:01 <adamw> alrighty, let's get started
16:11:05 <adamw> #topic Proposed Final blocker
16:11:11 <adamw> #topic (2135617) CVE-2022-3515 libksba: integer overflow may lead to remote code execution [fedora-all]
16:11:13 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2135617
16:11:16 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/997
16:11:17 <adamw> #info Proposed Blocker, libksba, ON_QA
16:11:20 <adamw> #info Ticket vote: FinalBlocker (+1,0,-0) (+gui1ty)
16:11:39 <adamw> so the key question here i guess is, what requires libksba
16:11:48 <adamw> at least gnupg2 does
16:11:57 <adamw> annd...that seems to be all
16:12:25 <adamw> but of course lots of things require gnupg2, including coreos-installer
16:13:07 <adamw> so, i don't really know for sure if this would really be exploitable, but at this point with some time still to go i'd say better safe than sorry, so probably +1
16:13:16 <nb> FinalBlocker +1
16:13:24 <OnuralpSezerhehi> FinalBlocker +1
16:13:45 <bcotton> +1
16:14:27 <geraldosimiao> +1
16:15:45 <Penguinpee> RH classifies it as important
16:15:57 <adamw> yep
16:16:50 <adamw> proposed #agreed 2135617 - AcceptedBlocker (Final) - this is accepted as a potential violation of "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)." We don't know for sure if this would be exploitable during install or live use, but it seems possible so we'd
16:16:50 <adamw> rather be safe than sorry
16:17:25 <Penguinpee> ack
16:17:44 <bcotton> ack
16:18:29 <MichaelCatanzaro> What is libksba and why can it not be satisfactorily resolved by a package update...?
16:18:57 <adamw> it's a thing gpg uses for certificate validation
16:19:10 <adamw> https://gnupg.org/software/libksba/index.html
16:19:20 <Penguinpee> "KSBA (pronounced Kasbah) is a library to make X.509 certificates"
16:19:33 <adamw> and the monologue above was why it doesn't seem safe to assume it can be resolved by an update
16:19:40 <MichaelCatanzaro> "A bug found in libksba, the library used by GnuPG for parsing the ASN.1 structures as used by S/MIME." this is for emails
16:20:00 <MichaelCatanzaro> S/MIME is not worth blocking on and certainly can be fixed by an update
16:21:34 <MichaelCatanzaro> Flaw in the CRL parser (certificate revocation list, nobody uses these anymore)
16:21:57 <MichaelCatanzaro> FinalBlocker -1
16:22:26 <nb> FinalBlocker -1
16:22:41 <nb> FinalBlocker -1 FinalFE +1
16:22:59 <Penguinpee> MichaelCatanzaro: "The release must contain no known security bugs of 'important' or higher impact"
16:23:17 <adamw> whether anyone uses CRLs normally or not doesn't matter, does it?
16:23:17 <MichaelCatanzaro> "which cannot be satisfactorily resolved by a package update"
16:23:23 <adamw> as long as the parser will parse one if it's there
16:23:25 <MichaelCatanzaro> We never release ever if we're not allowed to have any security bugs at all
16:23:26 <nb> Penguinpee .... which cannot be satisfactorily resolved by a package update"
16:23:44 <adamw> Michael Catanzaro: that's why the criterion says "known"
16:23:47 <adamw> and "important or higher"
16:23:50 <Penguinpee> if the live media depends on it, it can't
16:24:01 <MichaelCatanzaro> adamw: Why do we care about S/MIME bugs? These have zero impact on installation
16:24:03 <adamw> it means we do things like this: pull in known fixes for known CVEs during freeze
16:24:07 <Penguinpee> it's known and important
16:24:08 <adamw> the CVE says "for example"
16:24:10 <MichaelCatanzaro> We don't even have an email client in the live image
16:24:25 <adamw> do we know nothing else uses ASN.1 and hits this code path?
16:24:28 <adamw> Michael Catanzaro: KDE does.
16:25:28 <Penguinpee> Since there's already a fix available FinalBlocker is essentially the same as FinalFE
16:25:34 <MichaelCatanzaro> Looks like it's not limited to CRLs, but is limited to S/MIME: https://www.gnupg.org/blog/20221017-pepe-left-the-ksba.html
16:25:49 <adamw> Penguinpee: well, it means if the fix is bad, we block. if the bug's just an FE, if the fix is bad, we just drop it.
16:26:20 <MichaelCatanzaro> A freeze exception is fine, whatever, but this can be satisfactorily resolved by a package update. Reasonable users are not going to be using KDE live images to read email expecting it to be a secure thing to do...
16:26:26 <adamw> "A second user of Libksba is dirmngr, which is responsible for loading and parsing Certificate Revocation Lists (CRLs) and for verifying certificates used by TLS (i.e. https connections). Mounting an attack is a bit more complex but can anyway be easily done using a rogue web server to serve a Web Key Directory, certificates, or CRLs."
16:26:39 <Penguinpee> It's coming from RH. If it's bad we sent some hats flying. :-P
16:26:51 <adamw> (though i dunno if any browser we ship would use ksba for doing revocation lists)
16:26:55 <MichaelCatanzaro> I've never heard of dirmngr before
16:27:12 <MichaelCatanzaro> adamw: Assuredly not: no browser supports CRLs nowadays
16:27:27 <MichaelCatanzaro> Even if so, they wouldn't be using dirmngr
16:28:15 <Penguinpee> MichaelCatanzaro: I don't think it's save to assume what users do and don't do with live images.
16:28:20 <adamw> "Reasonable users are not going to be using KDE live images to read email expecting it to be a secure thing to do..."
16:28:25 <MichaelCatanzaro> Please, let's look for actual serious impact on installation or live media before declaring a CVE to be a blocker... something that's so bad we want it fixed even before a reasonable user's first initial system update
16:28:33 <adamw> i don't know what gave you the impression that users are reasonable. you've been around here long enough to know better. ;)
16:28:34 <MichaelCatanzaro> Penguinpee: Then we _never_ release, _ever_
16:28:42 <MichaelCatanzaro> There will always be more unfixed important CVEs
16:28:55 <adamw> Michael Catanzaro: we have a policy here. we can't just go rewriting it in meetings.
16:29:03 <adamw> if you disagree with the policy, send a mail and we'll re-discuss it
16:29:10 <MichaelCatanzaro> I agree with the policy
16:29:21 <adamw> but we have already wasted more time painting this bikeshed than it would take to pull the update into the next RC
16:29:57 <adamw> well, if you agree with the policy, you can't really then go saying things shouldn't be a blocker on the basis nobody should open the mail client in a live image, because that's...not what the policy says?
16:30:11 <MichaelCatanzaro> "which cannot be satisfactorily resolved by a package update" surely means what it says: "the bug cannot be fixed via updates."
16:30:14 <adamw> it doesn't say "which cannot be satisfactorily resolved by a package update or expecting users not to do silly things"
16:30:22 <Penguinpee> even blockers can be waived at the go/no-go, can't they?
16:31:04 * Southern_Gentlem totally lost now
16:31:31 <adamw> Penguinpee: yes, though we really intend not to use that mechanism a lot...
16:31:41 <Penguinpee> do we have enough +1 for the FE?
16:31:59 <adamw> we have +5/-2 blocker atm
16:32:03 <MichaelCatanzaro> adamw: So are you suggesting that if a package is on a live image, then it "cannot be satisfactorily resolved by a package update" because the lives don't get updated?
16:32:14 <MichaelCatanzaro> That seems like a very expansive interpretation of the policy
16:32:15 <adamw> but i just like to work through disagreements as far as possible rather than riding over them
16:32:36 <adamw> Michael Catanzaro: yes. that is the intent of the criterion. yes, i know live images go stale anyway. but the idea is that we make a best effort at the point of release.
16:32:44 <MichaelCatanzaro> I would interpret it to mean "it is truly impossible to fix this bug with an update" e.g. anything wrong in anaconda is impossible to fix
16:32:46 <adamw> Michael Catanzaro: i wrote it, and that's what it was meant to mean
16:32:50 <Southern_Gentlem> +1 FB
16:32:51 <Penguinpee> i'd be willing to throw in a FinalFE +1 if that unties the knot
16:32:54 <adamw> i will go dig out the discussion and see if this was clear at the time
16:33:10 <MichaelCatanzaro> adamw: In that case, I have five more CVEs to propose blocking on, haven't announced them yet but will soon
16:33:34 <MichaelCatanzaro> We won't win this game, I fear :)
16:33:55 <MichaelCatanzaro> Even if we release without any important/critical CVEs, there will be new ones 1 week later
16:33:57 <MichaelCatanzaro> So not sure what the point is
16:34:34 <Penguinpee> what comes in the future is not yet "known"
16:35:17 <kalev> I think I agree with Michael here, but there's not much point arguing here, just propose a change for the policy
16:35:51 <adamw> Michael Catanzaro: if you haven't announced them yet, they have no importance according to RH prodsec, so they aren't blockers
16:36:34 <adamw> https://lists.fedoraproject.org/pipermail/test/2012-October/111118.html was the original proposal. the discussion went down a different alley from 'what exactly doe fixable by an update mean?' and more down 'what release point should it be applied to?'
16:36:35 <MichaelCatanzaro> adamw: We'll announce later this week, so you can consider them at next week's meeting, I guess
16:36:47 <adamw> sure!
16:37:25 <MichaelCatanzaro> Also you can't rely on the Red Hat impact rating because that is designed only for RHEL, not for Fedora
16:38:06 <MichaelCatanzaro> E.g. all WebKitGTK CVEs max out at Moderate, even though that's a very easy way to attack Fedora users... just set up a captive portal and you force gnome-shell to open WebKitGTK and feed it whatever untrusted input you want, no user intervention required ;)
16:38:22 <MichaelCatanzaro> I guess this means my upcoming CVEs technically won't qualify though, since they'll only be Moderate :D
16:38:50 <adamw> we depend on prodsec because we need somebody to depend on. we're not going to evaluate every security bug here.
16:38:58 <adamw> if you have a better idea of who to rely on, patches welcome!
16:39:31 <adamw> anyway
16:39:43 <adamw> in the interests of getting the hell out of this meeting i am going with the proposed #agreed
16:39:58 <adamw> we can thrash this out further on the mailing list if you want to discuss how we should apply the criterion in future
16:40:11 <adamw> #agreed 2135617 - AcceptedBlocker (Final) - this is accepted as a potential violation of "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)." We don't know for sure if this would be exploitable during install or live use, but it seems possible so we'd rather
16:40:11 <adamw> be safe than sorry
16:40:26 <adamw> #topic proposed Final freeze exception issues
16:40:40 <adamw> #topic (2138491) The graphical install briefly shows "Initial Setup" even when the root account is disabled, after a fresh install, in all of the Fedora Spins
16:40:41 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2138491
16:40:41 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/994
16:40:41 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
16:40:44 <adamw> #info Ticket vote: FinalFreezeException (+2,0,-0) (+bcotton, +danya213)
16:41:41 <kparal> I don't think it's getting fixed, but +1 FE in principle
16:41:44 <Southern_Gentlem> +1 FE
16:41:51 <Penguinpee> I don't see this getting fixed in the coming days.
16:43:16 <adamw> yeah, same.
16:43:17 <adamw> +1 FE
16:44:05 <geraldosimiao> +1 FE too.
16:44:57 <Penguinpee> FinalFE +1 (for shits and giggles)
16:45:49 <adamw> proposed #agreed 2138491 - AcceptedFreezeException - this is accepted as a very visible annoyance during install that can't be fixed with an update.
16:45:57 <Southern_Gentlem> ack
16:46:01 <Penguinpee> ack
16:46:13 <geraldosimiao> Ack
16:46:23 <bcotton> ack
16:47:25 <adamw> #agreed 2138491 - AcceptedFreezeException - this is accepted as a very visible annoyance during install that can't be fixed with an update.
16:47:28 <adamw> #topic (2094075) btrfs-progs-6.0 is available
16:47:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2094075
16:47:35 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/996
16:47:39 <adamw> #info Proposed Freeze Exceptions, btrfs-progs, ON_QA
16:47:42 <adamw> #info Ticket vote: FinalFreezeException (+2,0,-0) (+chrismurphy, +ngompa)
16:49:12 <adamw> ehh, this seems a bit borderline, but i'm probably a weak +1
16:49:18 <adamw> if we're gonna pull in a new kernel, makes sense to sync this too
16:49:18 <Penguinpee> what's the impact of testing this?
16:49:36 <kparal> since we're refreshing almost everything, I guess we can easily pull this one too
16:49:42 <kparal> +1 FE
16:49:44 <bcotton> yeah. it seems good to keep this in sync with the kernel, but it scares me a little
16:49:51 <adamw> Penguinpee: main risk would be to installation
16:49:51 <bcotton> +1 FE with my eyes averted
16:49:54 <geraldosimiao> +1 FE
16:50:08 <Southern_Gentlem> +1 FE
16:50:10 <nb> +1 FE
16:50:11 <Penguinpee> "if we're gonna pull in a new kernel..." <- FinalFE +1
16:50:14 <adamw> so, run installs with btrfs storage (which is the default) and maybe try doing unusual things with it in custom partitioning...
16:51:34 <Penguinpee> a new kernel would entail a lot of additional testing anyway, I suppose. I thought the kernel was already pulled in...
16:52:27 <adamw> yes, it's in 1.5 but this isn't
16:52:41 <adamw> which is a bit unfortunate i guess, but the votes weren't in place when i did 1.5 and didn't want to keep waiting
16:53:00 <adamw> i'll try and get a new candidate today with the kde nomodeset fix and this, if we can get that fix
16:53:31 <Penguinpee> sounds good. keep 'em spinning...
16:53:42 <adamw> proposed #agreed 2094075 - AcceptedFreezeException (Final) - this is accepted on the basis that if we're freshening the kernel to 6.0, we should keep btrfs-progs in sync with it, as this is upstream's intent
16:53:57 <Penguinpee> ack
16:53:57 <nb> ack
16:53:58 <Southern_Gentlem> ack
16:54:47 <geraldosimiao> ack
16:55:16 <adamw> #agreed 2094075 - AcceptedFreezeException (Final) - this is accepted on the basis that if we're freshening the kernel to 6.0, we should keep btrfs-progs in sync with it, as this is upstream's intent
16:55:28 <adamw> #topic (2134742) Consider mesa-22.2.2-1 pull into F37
16:55:31 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2134742
16:55:33 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/973
16:55:37 <adamw> #info Proposed Freeze Exceptions, mesa, ON_QA
16:55:40 <adamw> #info Ticket vote: FinalFreezeException (+6,0,-3) (+gui1ty, +frantisekz, +geraldosimiao, +r00t, +ngompa, +kalev, -somethingsomethingfedora, -bcotton, -nb)
16:55:42 <adamw> whee, more disagreement!
16:55:55 <adamw> so, i took an executive decision and stuffed this into RC-1.5 even though it was still proposed
16:56:00 <adamw> just to give us some data for the decision
16:56:05 <adamw> so, has RC-1.5 blown up anyone's graphics card yet?
16:56:21 <bcotton> my -1 was weak so I don't hate you forever (at least not because of this)
16:56:31 <kparal> no issues on my Intel
16:57:16 <kalev> I just installed a VM with it and no issues yet with software rendering
16:57:32 <adamw> i didn't get to run it on metal yet, i'll try it later
16:57:43 <Penguinpee> bcotton: no love lost between you and adamw... ;)
16:57:53 <adamw> i think my position on this is +1 in principle, i will test on my boxes and look out for feedback before putting it in an RC we're actually going to release or pushing it stable
16:58:12 <bcotton> i'm okay with that position
16:58:33 <geraldosimiao> At vm it's fine. Didn't get to test it on bare metal yet.
16:59:20 <Penguinpee> I was surprised maintainer wasn't eager to get this in before release...
17:00:29 <adamw> proposed #agreed 2134742 - AcceptedFreezeException (Final) - this is accepted as part of the general freshening of key components while we wait for the openssl fix, it's always good to ship final code where possible. We will carefully review results from RC-1.5 testing (which included this) before actually pulling it into any true RC compose
17:00:37 <bcotton> ack
17:00:53 <geraldosimiao> Ack
17:00:57 <Penguinpee> ack
17:01:04 <bcotton> gotta drop for an appointment. don't make any decisions I wouldn't make
17:01:21 <adamw> suuuuure
17:01:26 <adamw> #agreed 2134742 - AcceptedFreezeException (Final) - this is accepted as part of the general freshening of key components while we wait for the openssl fix, it's always good to ship final code where possible. We will carefully review results from RC-1.5 testing (which included this) before actually pulling it into any true RC compose
17:01:33 <adamw> #topic (2138453) F37 beta - gnome-shell crashes when trying to work with mangled EDID color calibration information
17:01:36 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2138453
17:01:38 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/998
17:01:40 <adamw> #info Proposed Freeze Exceptions, mutter, POST
17:01:50 <Penguinpee> bcotton: I thought your job was to back whatever decision adamw makes...
17:02:03 <adamw> +1, not crashing on dumb monitors is a great idea. and the codepath that now errors out cleanly previously crashed, so the risk of this is pretty close to zero
17:02:12 <adamw> Penguinpee: that's my kind of thinking!
17:02:24 <Eighth_Doctor> +1
17:03:12 <Penguinpee> with low risk I give it my blessing: FinalFE +1
17:03:16 <kparal> +1 FE
17:03:21 <geraldosimiao> +1 FE
17:03:35 <nb> +1 FE
17:03:48 <kalev> +1 FE
17:07:25 <adamw> proposed #agreed 2138453 - AcceptedFreezeException (Final) - this is obviously a critical problem for affected systems (which includes the quite buzz-y Steam Deck) and cannot be resolved with an update
17:07:44 <kalev> ack
17:07:57 <geraldosimiao> Ack
17:08:02 <Penguinpee> ack
17:08:17 <adamw> #agreed 2138453 - AcceptedFreezeException (Final) - this is obviously a critical problem for affected systems (which includes the quite buzz-y Steam Deck) and cannot be resolved with an update
17:08:26 <adamw> #topic (2138870) The "Switch User" option is missing in the default XFCE screensaver.
17:08:28 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=2138870
17:08:31 <adamw> #link https://pagure.io/fedora-qa/blocker-review/issue/999
17:08:34 <adamw> #info Proposed Freeze Exceptions, xfce4-screensaver, NEW
17:08:36 <adamw> #info Ticket vote: FinalFreezeException (+1,0,-0) (+gui1ty)
17:08:41 <adamw> eh, this kinda seems like it could go as an update
17:08:46 <adamw> you're not gonna switch user on the live image
17:08:56 <geraldosimiao> It's the same thing as we have on kde spin?
17:09:12 <geraldosimiao> Or it's another problem that is causing it?
17:10:05 <Penguinpee> XFCE is not one of the blessed spins. With that in mind, I'd be willing to reconsider my vote.
17:10:10 <adamw> ar324 says it's to do with how the xfce screensaver daemon is started. i'm not any kind of expert on xfce internals.
17:10:34 <adamw> Penguinpee: that's not really relevant to this vote - that would only be relevant if it was proposed as a blocker (it would be a reason to reject it)
17:10:56 <adamw> bugs in non-blocking desktops can certainly be FEs
17:10:56 <Eighth_Doctor> insofar as FEs go, I don't see a reason not to permit it
17:11:03 <adamw> Conan Kudo: the rule for FEs is that we assume rejection
17:11:06 <adamw> we need a reason to accept
17:11:13 <kparal> I'd punt it until there's a patch, personally
17:11:22 <adamw> we've been a bit generous for the last few releases, but that's still how it's supposed to work :)
17:11:28 <geraldosimiao> +1 punt
17:11:36 <adamw> it just seems to me like this is a feature you would only use after install
17:11:42 <adamw> so an update is totally fine to address it
17:11:44 <Eighth_Doctor> yeah, it probably would be
17:11:55 <Eighth_Doctor> it'd need to be marked as a commonbug though
17:12:01 <Eighth_Doctor> otherwise nobody would know how to fix it
17:12:12 <adamw> ...install system updates?
17:12:29 <Penguinpee> there's a proposed fix in the bug...
17:13:46 <adamw> i'm not sure i can imagine a fix to which i'd say "oh yeah, including that to fix this thing nobody does on live images is worth the risk of breaking things that actually matter on live images"
17:15:31 <Eighth_Doctor> I'm +0, so I'm fine either way
17:15:32 <geraldosimiao> We already have a lot of new package updates to validate on a new iso
17:15:36 <Penguinpee> I didn't consider the live image scenario. So, I'm fine with punting or rejecting.
17:16:41 <Penguinpee> Actually, I'm Punt +1 (for lack of sufficient info)
17:18:59 <adamw> seems like nobody wants to jump on this one, so
17:19:26 <adamw> proposed #agreed 2138870 - punt (delay decision) - the general feeling here was that folks wanted more information on the nature of the problem and any proposed fix before voting
17:19:42 <Penguinpee> ack
17:19:43 <geraldosimiao> ack
17:20:26 <Eighth_Doctor> ack
17:21:13 <adamw> #agreed 2138870 - punt (delay decision) - the general feeling here was that folks wanted more information on the nature of the problem and any proposed fix before voting
17:21:32 <adamw> okay, time for a quick:
17:21:37 <adamw> #topic Accepted Blocker review
17:22:00 <adamw> #info 2135772 - we actually got a fix for this from upstream today, it will be in the next RC
17:22:34 <adamw> #info 2137600 - we broadly know the problem here and how to fix it, but the upstream fix relies on other code that landed in 6.1 and is tricky to backport to 6.0. jforbes is actively working on figuring out the best way forward for 6.0 and hopes to have a build soon
17:23:00 <adamw> #info 2137661 - this is still embargoed until tomorrow, as soon as the fix is released we'll be working to get it built ASAP
17:23:03 <Penguinpee> jforbes++
17:23:10 <adamw> aaand that's everything, really. anyone have additional notes?
17:24:40 <Eighth_Doctor> adamw: I'd filed an FE for btrfs-progs that I'd like to have included in our next compose that includes kernel 6.0
17:24:58 <geraldosimiao> adamw: what's the plan for release candidates? Another one today or tomorrow?
17:25:18 <adamw> Conan Kudo: we, uh, already discussed and approved it?
17:25:27 <Eighth_Doctor> oh I missed that 😅
17:25:38 <Eighth_Doctor> timezones and overlapping meetings
17:26:12 <adamw> the decision was "agreed 2094075 - AcceptedFreezeException (Final) - this is accepted on the basis that if we're freshening the kernel to 6.0, we should keep btrfs-progs in sync with it, as this is upstream's intent"
17:26:15 <Penguinpee> Eighth_Doctor: it's really confusing using different names in Matrix and IRC 😕
17:26:46 <adamw> geraldosimiao: yeah, probably. if we get the kernel nomodeset fix today i may do a quick rc-1.6 with that and btrfs-progs
17:26:59 <adamw> otherwise we'll maybe get a true RC tomorrow with the openssl fix too
17:27:18 <Eighth_Doctor> have we poked marcan for some assistance there?
17:27:27 * Penguinpee was wondering about adamw's state of mind when started talking to Conan Kudo
17:27:32 <jforbes> adamw: we will see. I am working on it, and do have the nuclear option if needed
17:27:55 <Eighth_Doctor> "nuclear option"?
17:28:00 <adamw> Conan Kudo: i was leaving it to jforbes if he wanted to
17:28:15 <jforbes> backport more of the simpledrm changes
17:28:39 <adamw> jforbes: what did you think of javier's suggestion to just implement the format conversion if backporting the other changes is too tricky?
17:28:55 <adamw> it's kind of dumb but it would probably work
17:28:56 <adamw> would just slow things down a bit
17:29:18 <jforbes> Yes, marcan has been contacted in that the patch is accepted upstream as CC stable, and I noted how much it does not apply, so we will see
17:29:22 <Eighth_Doctor> jforbes: ah, that's not too bad as a "nuclear option"
17:29:24 <jforbes> adamw: yeah, that is an option as well
17:29:43 <adamw> i'd probably prefer that to backporting more stuff, personally. people expect fallback paths to be slow. :P
17:30:16 <adamw> #topic Open floor
17:30:28 <adamw> just to move through the agenda, we can keep discussing the same thing if you like :P
17:30:36 <jforbes> Eighth_Doctor: well, it is in that there is a whole lot of churn (an 880 line file with a 750 line git diff from the 6.0 version). And we are only at rc3, so I am not sure just how well that has been tested
17:30:40 <adamw> or if anyone has anything else
17:30:49 <jforbes> Basically, I want to avoid that as much as possible
17:32:15 <Eighth_Doctor> fair
17:33:15 * Penguinpee has nothing for open floor
17:33:58 <geraldosimiao> Yup, mee too. Nothing for open floor.
17:37:23 <adamw> alrighty, thanks for coming everyone
17:37:52 <Penguinpee> \o
17:38:39 <adamw> #endmeeting