17:01:16 #startmeeting F37 Final Go/No-Go meeting 17:01:16 Meeting started Thu Oct 27 17:01:16 2022 UTC. 17:01:16 This meeting is logged and archived in a public location. 17:01:16 The chair is bcotton. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 17:01:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:16 The meeting name has been set to 'f37_final_go/no-go_meeting' 17:01:16 #meetingname F37-Final-Go_No_Go-meeting 17:01:16 The meeting name has been set to 'f37-final-go_no_go-meeting' 17:01:21 #topic Roll Call 17:01:31 \o 17:01:34 morning 17:01:37 looks like I picked the wrong week to quit sniffing glue 17:02:07 :) 17:02:16 there's no good week. 17:02:27 pong 17:02:56 .hi 17:02:57 sgallagh: sgallagh 'Stephen Gallagher' 17:02:59 .hello siosm 17:03:00 travier: siosm 'Timothée Ravier' 17:03:41 .hi 17:03:42 bytehackr: bytehackr 'Sandipan Roy' 17:03:47 .hello2 17:03:47 coremodule: coremodule 'Geoffrey Marr' 17:04:32 * nirik wonders if anyone put out the adamw signal. 17:04:55 he 17:05:04 he's explaining why i am the way that i am to his cat 17:05:04 get out your magic 8 balls folks (i said it earlier, but want it in the minutes) 17:05:24 :D 17:05:37 just used my SeaGL magic 8 ball and it said "review logs". i'm not sure how to interpret that 17:05:48 .hello gui1ty 17:05:49 Penguinpee: gui1ty 'Sandro .' 17:05:50 but! let's start the process 17:05:57 .hello2 17:05:58 cmurf: cmurf 'Chris Murphy' 17:06:05 #topic Purpose of this meeting 17:06:05 #info Purpose of this meeting is to check whether or not F37 is ready for shipment, according to the release criteria. 17:06:05 #info This is determined in a few ways: 17:06:12 #info 1. No remaining blocker bugs 17:06:12 #info 2. Release candidate compose is available 17:06:12 #info 3. Test matrices for Final are fully completed 17:06:19 #topic Current status - blockers 17:06:19 #link https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist 17:06:33 #info 1 Proposed Blockers 17:06:33 #info 2 Accepted Blockers 17:06:35 SO! 17:06:45 #topic (2137661) upcoming critical openssl vulnerability 17:06:45 #link https://bugzilla.redhat.com/show_bug.cgi?id=2137661 17:06:45 #link https://pagure.io/fedora-qa/blocker-review/issue/987 17:06:51 .hi 17:06:52 dustymabe: dustymabe 'Dusty Mabe' 17:06:52 #info Proposed Blocker, openssl, NEW 17:06:52 #info Ticket vote: FinalBlocker (+11,0,-3) (+bytehackr, +mattdm, +bcotton, +ngompa, +geraldosimiao, +chrismurphy, +nixuser, +copperi, +sumantrom, +frantisekz, +augenauf, -sgallagh, -catanzaro, -gui1ty) 17:07:08 quite a lot of +1s 17:07:42 .hello2 17:07:45 frantisekz: frantisekz 'František Zatloukal' 17:07:48 indeed 17:07:48 most of them chosen ones 17:08:15 the main hesitation, which i understand, is that we don't know what the vulnerability actually is 17:08:17 I'm not sure what critera is being used here...I don't think we have much that fits this 17:08:28 .hello copperi 17:08:29 copperi[m]: copperi 'Jan Kuparinen' 17:08:46 ""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)."" 17:08:52 #info Criterion: 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). 17:08:52 .hello ngompa 17:08:53 Eighth_Doctor: ngompa 'Neal Gompa' 17:08:57 #link https://fedoraproject.org/wiki/Fedora_37_Final_Release_Criteria#Security_bugs 17:09:11 right, but we don't know if it could be resolved by an update or not... 17:09:16 fwiw, I'm not a "chosen one" for being able to review the bug 17:09:27 I have no idea and I'm going off what the "chosen ones" say 17:09:37 yeah, i don't have access to the actual bug either 17:09:41 My argument is that there currently isn't a known bug that fits that description 17:09:46 All we have is supposition. 17:09:49 riight and as per pre-announce security bulletin of red hat its a critical: https://access.redhat.com/security/vulnerabilities/RHSB-2022-004 17:09:56 could someone wearing a red head dress at least give some indication s to the severity and scope. 17:10:11 sorry, lost track of time 17:10:12 Penguinpee: We don't have access either. Only the Product Security Team 17:10:13 .hello adamwill 17:10:14 adamw: adamwill 'Adam Williamson' 17:10:27 and I am not sure they can really say much of anything... 17:10:33 ah, I see. 17:10:33 (and some of the QA people have access too...) 17:10:38 Penguinpee: anyone who know details of the bug really is not allowed to say anything beyond what's publicly disclosed already 17:10:41 my preference would actually be to not block on this, but I'm super wary of ignoring RH security 17:10:41 So we have to work from the public information 17:10:52 There is nothing in the bug of any substance 17:11:15 * Penguinpee divides time between cooking dinner and IRC 17:11:31 well unfortunately RH security isn't saying whether Fedora 37 as it is, should be released or delay 17:11:41 even if it's just informational advise 17:11:54 so I guess the big thing is if it affects common things like curl / web browsers... as people often use live media to run those things for testing/whateevr. 17:11:54 they recommended to mattdm we delay 17:11:54 cmurf: yes, they did. 17:12:20 nirik: it doesn't affect Firefox, since that uses NSS 17:12:23 Eighth_Doctor: they did? i didn't see that, ok that's sorta changes the calculation I suppose 17:12:24 https://pagure.io/fedora-qa/blocker-review/issue/987#comment-822932 17:12:27 but it does affect everything else 17:12:32 "RH product security tells me that they advise making sure our installation media and various images are updated." 17:12:51 yeah interesting 17:12:51 got it 17:12:52 it could affect netinst too I guess? 17:12:56 technically we could satisfy this if we could do regular image composes, but we can't 17:13:04 FWIW in Fedora CoreOS we have a bit more control over our users update schedule (automated updates) so we're considering delaying our rebase to F37 for our `testing` stream until after the SSL CVE fix has been rolled out. 17:13:07 adamw: but that begs the question sgallagh posed in the ticket 17:13:23 Eighth_Doctor: right. 17:13:31 yes, that is a reasonable concern 17:13:37 anyhow, I guess I'm +1 also to blocking on it. ;( 17:13:40 the underlying problem is we have no process to re-compose media and roll that out 17:13:47 adamw: Which is? 17:13:49 we have respins sig for x86 media, but that's it 17:13:55 Eighth_Doctor: agreed 17:13:58 the fact that we're largely stuck with this for 6 months (and entirely stuck on anythign that the Respins SIG doesn't Respin) makes the thought of waiting a week a lot more palatable 17:14:02 knowing we have that time constraint, would it be feasible to push go/no-go next week to friday? or can we not do that? 17:14:04 Conan Kudo: Other than the Respins? 17:14:18 example 92 why we need easier re-compose ability 17:14:25 adamw: which time constraint? 17:14:25 Stephen Gallagher: respins is technically not a re-compose process for all deliverables 17:14:29 Conan Kudo: we have no process because we don't want the burden of doing it. the process isn't the hard part. 17:14:43 finding time for releng and qa to go through a whole spin-and-test cycle multiple times during a release is the hard part. 17:14:51 i've been told in the past that we cannot rely on CPE to do any of the releng work over the weekend, so a friday go/no-go seems unpossible 17:15:00 nirik: the constraint that the openssl disclosure/release is planned for next tuesday 17:15:12 which puts us on a tight timeframe to try and build, test and sign off next thursday 17:15:15 now, could we do a go/no-go the following monday or tuesday and then release on thursday/friday? maybe 17:15:21 as sgallagh pointed out at https://pagure.io/fedora-qa/blocker-review/issue/987#comment-823010 17:15:33 it could be tight, but I think it's possible... 17:15:45 afaik tuesday releases are mostly 1. tradition and 2. press timing 17:16:11 and 0. timing for all the things that need to be done for a release 17:16:15 we could release on Thursday as a special case if we want to push it out next week 17:16:51 i feel like changing the release date is a bigger and more difficult change than squeezing the go/no-go, but i'm not the one who does the work between thursday and tuesday, i guess 17:16:54 i'd have to defer to nirik on that 17:17:09 and yes, getting the fix on tuesday and signing off on thursday is possible, it's just tight 17:17:23 the openssl update will trigger OpenQA runs at least, so we can get some reasonable data on how much it breaks 17:17:23 we need the disclosure to happen, then we need the openssl build to run, then we need the compose to run 17:17:28 then we have whatever time is left to validate 17:17:36 adamw: I think it's too tight, since openssl drives so much of the distro 17:17:39 i'm not sure we can do sufficient regression testing between tuesday and thursday 17:17:45 we're getting a little ahead of ourselves at this point 17:17:46 I don't think it's practical to release on thursday... say thing comes out tuesday, we make a rc, we need to test it, get sign off, sync it to mirrors, etc. 17:17:50 I wouldn't be comfortable carrying over the results of earlier composes 17:17:53 we don't know when tuesday the fix will appear, or how much longer it'll take to get a compose 17:17:57 first we have to decide if this is a blocker 17:18:11 then we can figure out what to do about it 17:18:15 blocker +1 17:18:26 my preference would to be to not block on it, but everyone else suggests we should so... 17:18:34 because F36 is equally impacted, as is RHEL 9 17:18:36 everyone is toast 17:18:54 +1 blocker here. 17:18:56 given that i'm not a security expert, the details aren't public, and the advice from rh's security experts is to patch it, i'm still +1 17:19:04 My point is that if we had shipped on the original schedule, we wouldn't have ground the gears to a halt after Go/No-Go with so little info to go on 17:19:16 sgallagh good point 17:19:38 Conan Kudo: that's outside our area of competency. but if rh prodsec is saying that to us, i would assume they'll also be telling RH that a new RHEL 9.x is needed asap 17:19:40 sgallagh: true but knowledge and our position in the timeline changes things 17:19:45 I'd actually be more confident about not blocking if we could update the images :( 17:19:46 RHEL does do 'respins', in that sense, of course. 17:20:06 If I remember correctly, we did an official re-compose at least once in the past 17:20:09 adamw: it's probably going to slip right into RHEL 9.1 releasing next month, but who knows 17:20:21 * mattdm is here. sorry, family thing 17:20:25 nb: Followed immediately by a general agreement never to do so again 17:20:28 nb: we did it forever ago, when the compose process was different and we had a lot fewer things, iirc. 17:20:41 I am not in favor of doing a release, then doing another release right after when we could wait and do it once. ;) 17:20:44 since then we've done kinda unofficial single image fixups, but never a full rebuild 17:20:45 we also don't generally have a "make images" button 17:21:19 have we heard from anaconda folks? 17:21:34 .hello churchyard 17:21:35 that may not be the only thing impacted on the media but seems like the most important thing potentially impacted 17:21:35 mhroncok: churchyard 'Miro Hrončok' 17:21:36 I think I am a weak +1 to block. If Product Security Team says they recommend it, then we might should listen to them 17:21:48 as much as I want to not block 17:21:49 so i'm seeing roughly +12/-4, which is a pretty strong outcome 17:22:02 So RH is mostly concerned about vulnerable images getting out into the wild? But that's still true for all current images. 17:22:02 I'm maintaining my +1 even though I really want to do -1 17:22:18 i keep saying, don't focus overly on the installer 17:22:27 we also have to consider anything people might plausibly do on live imaegs 17:22:29 adamw: I'm more worried about arm images 17:22:41 live images don't bother me at all 17:22:46 Penguinpee: yes, all existing images are vulnerable, but if we don't wait, we don't have one that is not 17:22:49 Penguinpee: yes, but if we slip a week and include the fix in f37, we have non-vulnerable images out for the public in a week and a half 17:22:52 adamw: Which is bullcrap, IMHO. Since all of our existing images are riddled with holes 17:22:57 I'm not factoring them into my decision, since those are respun regularly 17:22:57 if we don't slip, we do not have non-vulnerable images out for another six months 17:23:13 Conan Kudo: not all of them and not on non-x86_64 17:23:13 I'm not too worried about live images - respins sig makes them every 2 weeks 17:23:21 but ARM and installer and stuff don't get respun 17:23:34 Conan Kudo: since the respins are not official, and not that widely publicized, that's not really a safe assumption. 17:23:38 adamw: why is that. there are respins of almost everything. 17:23:43 Ben Cotton (he/him): yes, my point is x86 live images are the only things I am not using as a factor for my decision 17:23:45 There's also things like server kvm image 17:23:56 adamw: which is a mistake in itself that we should seriously fix 17:23:58 none of the labs get respun, either, as far as i can tell 17:24:02 I wish I had data on cloud images -- how many people actually update, or ever use later versions than the first. 17:24:05 But it's guesswork. 17:24:09 Penguinpee: there's no validation. we don't really know if the respins...work. and i'm not having QA go through a full validation cycle every two weeks. 17:24:12 so respins are absolutely not the answer here 17:24:12 quite a lot of the +12 is predicated on a presumption that there's something on the media affected by a zero day exploit, if that's not true or has more limited impact, the vote might swing in the exact opposite direction 17:24:13 If someone is installing the KVM image and not immediately doing a DNF update, they deserve what they get 👍️ 17:24:13 I wish I had more data period 17:24:21 but all we have is public information, which is almost nothing 17:24:22 The problem is not so much about what folks might do with live image but more how bad it can impact netinstalls. If I can compromise a netinstall then it's really bad 17:24:24 mattdm: I know people _try_ to use updated cloud images, but that build process breaks so often lately... 17:24:29 and the discoverability is super-low 17:24:31 i think anaconda uses its own ssl unless passing a flag to use openssl? 17:24:34 adamw the respins get tested, maybe not to the extent of what QA normally does, but respins does have their own testnig process 17:24:37 we get questions about it in the cloud-sig all the time 17:24:38 what if the process of updating itself (TLS is everywhere) could compromise the system 17:24:58 then all those other distros are going to be looking to re-spin their install media too 17:25:12 cmurf: we have to consider that possibility based on the public information (a critical vuln in openssl). it's a much safer thing to do to assume that might be the case, than assume it *isn't* the case. 17:25:14 We have the same issue for FCOS, even though we don't use that much openssl: if you can compromise the first boot of FCOS then that's really bad 17:25:14 dustymabe: What if openssl turns out it's been a trojan horse all along? 17:25:21 We can make up whatever boogeymen we want. 17:25:26 it feels a bit like meeting a secret agent: trust me (and then all hell breaks loose) 17:25:36 * Eighth_Doctor shrugs 17:25:37 better safe now than sorry later 17:25:39 sgallagh: or maybe they are trying to zip through a trojan horse with this update - rememember remember the 1st of november 17:25:49 this is the downside of centralizing your crypto, even if it doesn't happen too often, it's painful when it does 17:25:51 Ha 17:26:01 sgallagh: (I am not quite sure I'm comfortable with that as a statement. But that's probably another discussion.) 17:26:28 okay, well we can argue all day, but i don't see any minds changing one way or another so 17:26:30 proposed #agreed 2137661 - AcceptedBlocker(Final) - Given the limited public information, we determine this violates"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" 17:26:37 ack 17:26:41 ack 17:26:42 That was overstated, but honestly: if you don't patch your systems, we can't do much for you 17:26:46 Ben Cotton (he/him): ack 😭 17:26:48 as usual, Stephen Gallagher retains his right to "i told you so" 17:26:51 ack 17:26:53 Stephen Gallagher: there's also the publicity angle to consider, of course. i do agree to some extent with a lot of your points, but it kinda looks pretty bad if we ship a release on the day this openssl news comes out and people say "so that's fixed, right?" and we say "no"... 17:27:03 * Penguinpee is not changing his mind (based on too little available info) 17:27:05 ack 17:27:06 ack 17:27:12 i'll also point out that we could still choose to waive this blocker ;-) 17:27:20 ack 17:27:24 * sgallagh slugs Ben Cotton (he/him) 17:27:24 i would probably word it to be less definitive about "this violates", but whatever 17:27:25 ack 17:27:36 patch 17:27:38 well, it's difficult-to-fix given the code doesn't exist 17:27:38 and yes, we can continue arguing about it if someone wants to propose waiving it. ;) 17:27:45 nack 17:27:48 Stephen Gallagher: patch away 17:27:49 Penguinpee: Let me clarify that a little bit. I wish I could give even more information but I don't have much to go on. Since we have so little, I asked some people with more access for their opinions, and they shared it. 17:27:50 so you could waive under that condition :P 17:27:50 Conan Kudo: sure it exists. it's just not public yet. 17:28:01 adamw: doesn't exist to me 17:28:04 or anyone else 17:28:10 we actually don't even know if a patch is ready either 17:28:15 proposed #agreed 2137661 - AcceptedBlocker(Final) - Given the limited public information, we are unable to definitively determine whether this violates"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". We therefore are blocking out of an abundance of caution. 17:28:28 we know a disclosure is happening on Nov 1 with a release, we don't know if they're working right up to the deadline 17:28:29 ack 17:28:32 ack 17:28:33 ack 17:28:37 sure, ack 17:28:44 ack 17:28:44 ack 17:28:46 +1 17:28:47 Stephen Gallagher: ack 😭 17:28:50 ack 17:28:50 +1 17:28:57 yeah, i like that more, ack 17:28:59 ick err ack 17:29:00 Conan Kudo: Generally speaking, we can actually make that assumption. 17:29:07 mattdm: thanks. yet I'm not comfortable with making a decision on little to no info. So, maybe I should vote FinalBlocker 0 17:29:21 #agreed 2137661 - AcceptedBlocker(Final) - Given the limited public information, we are unable to definitively determine whether this violates"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". We therefore are blocking out of an abundance of caution. 17:29:31 Stephen Gallagher: having been involved in a few of these before, I don't make that assumption anymore 17:29:31 Historically, an embargo lift date is never given until a fix is identified (or the embargo has been lifted by other means, such as an accidental disclosure) 17:29:40 Conan Kudo: sure we do. they've declared a release date. 17:29:51 sgallagh: that is a rather bold statement 17:29:52 .hello geraldosimiao 17:29:53 geraldosimiao: geraldosimiao 'Geraldo S. Simião Kutz' 17:29:54 Penguinpee: the way I look at is it if my good friend told me to not go outside today, and to trust them. I'd stay inside 17:29:54 okay, moving on 17:29:56 Conan Kudo: they didn't announce that they're (only) disclosing an issue, they announced the release of 3.0.7, containing a fix for a CRITICAL issue. 17:30:05 let's review the already-accepted blockers 17:30:06 #topic (2135772) Editing the recurring event freezes Calendar. 17:30:06 #link https://bugzilla.redhat.com/show_bug.cgi?id=2135772 17:30:06 #link https://pagure.io/fedora-qa/blocker-review/issue/977 17:30:06 #info Accepted Blocker, gnome-calendar, NEW 17:30:07 s/never/rarely/ then? 17:30:27 Stephen Gallagher: we'll go with that 17:30:27 so, if we didn't have anything else, i'd be in favor of waiving this 17:30:36 but, now we have something else. 17:30:36 dustymabe: https://xkcd.com/1170/ 17:30:36 sgallagh: frequently embargo lift dates are set before work has even begun on a fix 17:30:41 So this is the one that upstream said "wow, this is totally bad" 17:30:59 I would propose to waive 2135772 17:31:16 That tends to happen more with cross-project flaws than ones in a specific library. 17:31:19 i don't see any point in waiving it now if we're gonna slip for openssl 17:31:34 in fact we kinda only intended the waiver process to be used in order to sign off a release 17:31:38 Like if an algorithm is discovered as vulnerable in multiple implementations. 17:31:39 dustymabe: i'd be with you if this were about a good friend. i don't feel like that regarding RH (no offense) 17:31:44 #info Upstream says "I'm pretty positive nothing about recurrent events has ever worked properly. There's a lot more that needs to be done to make it work reliably, and I'm considering how to do that, but yeah, it's just stupidly broken." 17:31:48 adamw well, true 17:31:51 if we agree to waive this but we're still no-go, it puts it in a kind of weird twilight zone 17:32:06 waive them both 17:32:11 so, is anyone going to propose that we waive the openssl bug? 17:32:14 waivers are only valid until the next go/no-go, imo, whether that's the same release or the next milestone 17:32:19 difficult to fix and late proposed blockers 17:32:43 let's get through reviewing all of the blockers and then we'll discuss waiving 17:32:57 fair 17:33:06 anything else to add on 2135772? 17:33:06 is this one likely to get a fix? 17:33:22 sounds like it's ambiguous whether it gets a fix 17:33:40 nirik: i wouldn't bet on it getting a fix for f37 at this point 17:33:45 I don't think this is getting a fix 17:33:46 * nirik wonders if we could disable recurrent events until they are fixed 17:33:55 it's not a data loss or corrupting bug, it just doesn't change the recurring event and the program crashes? 17:33:58 unless the fix is hiding editing recurring events 17:34:20 cmurf: Can't be deleted, either 17:34:27 it's a bad bug but i'd say it's going to get fixed on its own time scheduled regardless of what we have to say about it 17:34:33 that sounds like a question for the Workstation WG to decide 17:34:40 if it's made a blocker, Workstation WG will just remove it from the media 17:34:50 so let's look at our last accepted blocker 17:34:50 we've discussed it and that's what would happen 17:34:56 #topic (2137600) Plasma on Wayland hangs at startup when booting with nomodeset ("basic graphics" mode) on UEFI 17:34:57 #link https://bugzilla.redhat.com/show_bug.cgi?id=2137600 17:34:57 #link https://pagure.io/fedora-qa/blocker-review/issue/986 17:34:57 #info Accepted Blocker, kwin, NEW 17:35:04 cmurf: It's already declared a blockr 17:35:15 Ohh, that 17:35:16 *blocker 17:35:36 (Blockr is the dating app for blocker bug meeting participants...) 17:35:37 ... 17:35:42 Stephen Gallagher: wow, worst dating app *ever* 17:36:04 so, yeah, we basically know what's going on here and the proposed kernel patches would probably fix it 17:36:07 🤦‍♂️ 17:36:25 yeah, it also looks like we're going to add basic graphics mode testing too 17:36:42 hopefully we can stop this trend of discovering bugs with basic graphics mode at the very last second 17:36:43 well, we already had it, but we've extended it to make it clearer what combinations need testing 17:36:56 which is a sad chart of sadness, but hey. 17:37:02 yeeeeeah 17:37:11 Reading the bug I was wondering who would be doing that but now I get it 🍎 17:37:25 yuuuup 17:37:40 blame fancy computers 17:37:51 Will we officially support M1's with F37? 17:37:57 NO 17:38:12 so we should probably not block then 17:38:52 travier: the bug we have does not affect M1s 17:38:56 in fact they're likely the only thing that works 17:39:01 oh 17:39:06 (well, them and any other platform that uses a native 10-bit framebuffer) 17:39:11 M1s for everyone! 17:39:12 no, it broke non-M1 17:39:19 that's why the bug 17:39:28 M1 is the only type that works right now 🤣 17:39:38 Oh, so it's for NVIDIA setups then? 17:39:45 yup 17:39:48 earlier on i was suggesting we could go with a patch that fixes other things but breaks M1s, but that's not a concern any more, the proposed kernel patches ought to make things work for everyone. 17:40:00 so it sounds like there are at least short-term patches in the works that we could incorporate relatively quickly 17:40:01 ok, so it makes more sense to block on it then 17:40:10 travier: it's already a blocker 17:40:11 perhaps even Actual Fixes™? 17:40:20 we're at the point in the meeting where we discuss existing blockers and see what's going on with them 17:40:24 .👍 17:40:24 yeah, we can probably ship it into the kernel nowish if drm folks are tentatively okay with it 17:40:31 so, assuming we're not still trying to ship this week, this should be fine. 17:41:03 wait, what? I thought this was a kwin bug, not kernel 17:41:05 we'll let the drm folks fight about it a bit then jforbes can include...whatever they decide on. or something we decide on if they can't agree. 17:41:12 jforbes: it's both 17:41:19 jforbes: it's...sort of both, but we have proposed kernel patches to fix it 17:41:28 lovely 17:41:44 jforbes: see https://bugzilla.redhat.com/show_bug.cgi?id=2137600#c37 17:41:44 should we re-assign this bz to the kernel component? 17:41:51 kwin is working on a fix too, but it might not be backportable to 5.26 17:42:00 apparently v1 of that patch incited a hot controversy on "IRC", i've no idea what IRC channel or what the controversy was. 17:42:03 definitely don't expect a 5.25 backport, since the 5.25 series just ended 17:42:09 Ben Cotton (he/him): i think it's okay, everyone relevant is on it. 17:42:15 roger 17:42:28 #info kernel patches exist to address this issue 17:42:28 * jforbes notes that 6.0.5 kernels are in updates-testing now. 17:42:53 Which, given that 5.19 is EOL, and 5.19.17 is known broken, isn't such a bad thing, but... 17:42:56 * Eighth_Doctor notes plasma 5.26 is in updates-testing now 17:43:20 yeah, i don't know if we're having that debate in this meeting... 17:43:44 kernel and plasma are in the same boat at the same time :/ 17:44:20 okay, anything else on this one? 17:44:44 adamw: I know, and given the workflow now, I can always go back, but F35 and 36 will be moving forward either way, not going to hold them back 17:44:47 adamw: could we add basic graphics mode testing to OpenQA? 17:45:07 even to just suss out super-basic stuff like this would be a huge win 17:45:15 I could maybe be talked into a one-week slip if we have small, targeted fixes for the blockers. But if we're bumping major components, I'm going to push for a two-week slip. 17:45:23 it doesn't encounter this issue in vms 17:45:36 it's reproducible in UEFI VMs 17:45:54 okay, sounds like we've said all that we need to say on this particular bug for now. so 17:45:57 Eighth_Doctor: Yes 17:46:11 #topic Current status - blockers 17:46:11 #info 3 Accepted Blockers 17:46:34 does anyone want to propose that we waive all three accepted blockers? 17:47:32 two of the three blockers have fixes we could release nowish 17:47:37 Conan Kudo: we could, yeah. i didn't do it in the past because it's not considered 'valid' for release validation, but yeah, might be worth it to catch some problems. the concern might be that it would run into some bug that nobody wants to fix because it only affects VMs and there's no reason to use nomodeset in a VM 17:47:57 Conan Kudo: if we waive them, they don't get released 17:47:57 Conan Kudo: er...two? 17:48:12 there's a patch for calendar to hide editing recurring events, afaik 17:48:27 and see aforementioned dri-devel posts for kernel fixes 17:49:06 oh, okay. not sure if hiding recurring events is really the answer, but meh. i would say, one way or another, i don't want to slip for the calendar bug alone. whether that means waiving it or removing calendar or hiding recurring events i don't care 17:49:21 the KDE nomodeset one i was willing to waive for being discovered late and having a workaround (use the X11 session) 17:49:33 sure 17:49:33 but the openssl one feels like...we really should block on it 17:49:42 -1 to waiving openssl 17:49:47 it doesn't make much sense to say "we're accepting it as a blocker out of caution" and then say "...but we're not actually blocking on it" 17:49:56 Right. :) 17:50:04 I agree. We need to block for openssl at this point. 17:50:20 Decision was made, let's stick to it. 17:50:24