14:00:31 #startmeeting FESCo (2020-10-21) 14:00:31 Meeting started Wed Oct 21 14:00:31 2020 UTC. 14:00:31 This meeting is logged and archived in a public location. 14:00:31 The chair is decathorpe. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:31 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:31 The meeting name has been set to 'fesco_(2020-10-21)' 14:00:37 #meetingname fesco 14:00:37 The meeting name has been set to 'fesco' 14:00:42 #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor 14:00:42 Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku cverna dcantrell decathorpe ignatenkobrain mhroncok nirik sgallagh zbyszek 14:00:56 morning 14:00:56 #topic Init Process 14:00:59 hello 14:01:07 .hello2 14:01:08 bcotton: bcotton 'Ben Cotton' 14:01:25 good afternoon / morning 14:01:41 .hello2 14:01:41 hey 14:01:41 sgallagh: sgallagh 'Stephen Gallagher' 14:01:52 good $TIMEOFDAY! 14:02:22 greetings, $FPL 14:02:35 .hello2 14:02:41 dcantrell: dcantrell 'David Cantrell' 14:02:42 lol decathorpe 14:03:25 I already count 6 FESCo members as present, so we have quorum, I'll give the others until :05 14:04:14 .hello2 14:04:15 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 14:04:20 zbyszek hello! 14:04:52 Hi, excuse the tardiness. 14:05:00 we haven't started yet :) 14:05:42 #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/REFRCU3EQIXM6WADFBVYHYJNJ2RYXEDF/ schedule 14:06:25 #topic #2479 F33 UEFI Secure Boot signing keys 14:06:27 .fesco 2479 14:06:28 decathorpe: Issue #2479: F33 UEFI Secure Boot signing keys - fesco - Pagure.io - https://pagure.io/fesco/issue/2479 14:06:29 there's just this minor thing :) 14:06:37 * Eighth_Doctor waves 14:06:39 .hello ngompa 14:06:40 Eighth_Doctor: ngompa 'Neal Gompa' 14:06:42 sorry I'm late 14:06:44 I'm trying to find pjones to speak to us about this 14:06:54 my employer went public this morning and I lost track of time :) 14:07:03 congratulations! 14:07:04 Eighth_Doctor: congrats. 14:07:15 yup, Datto is $MSP on NYSE :D 14:07:24 datto++ 14:07:29 OK, pjones is here. 14:07:36 congrats! 14:07:46 Eighth_Doctor: haha, suckers 14:07:51 pjones: welcome 14:08:01 So, the basic question before us is this: given new information about the rate of hitting this issue, do we still want to block on it? 14:08:28 what is the exact new information about the rate of hitting this? 14:08:40 if people boot ubuntu, do they still hit this? 14:08:43 pjones: any status update from your end? 14:08:49 mhroncok: Mostly that Fedora QA has been trying to reproduce it and isn't able to do so consistently. 14:08:49 nirik: still debugging 14:08:59 It's apparently not as simple as "boot ubuntu and then you die" 14:09:16 so to me it sounds like it's harder to trigger this issue than we initially thoguht 14:09:23 pjones: ok, fair enough 14:10:03 and pjones sounds like it's not just "make one with new key and we can ship in two weeks"? 14:10:20 unfortunately, we're also now at the point that the new dbx is available publicly from multiple sources 14:10:26 including LVFS 14:10:30 mattdm: not sure I understand what you're asking 14:10:57 pjones: I need the FPL level view of: if we slip this week, does that even buy us anything? 14:11:14 mattdm: *probably*? 14:11:33 I could help come up with some horrible hack to build shim with older gcc than what's in fedora right now 14:12:00 like, if you can't get it to build with current gcc today or tomorrow, then we could try to do a hack with older one? 14:12:07 that's not the issue; something in our efi runtime is interacting with ld in a weird way 14:12:13 aha 14:12:57 pjones: what's your feeling on shipping vs. delay for this at this point? 14:13:43 mattdm: at this point I'd still like to get a fix in before we spin media if we can? regardless of the current situation regarding when ubuntu applies the update, we know it will get worse. 14:14:06 ok, so that's "slip". 14:14:23 with the US election day one week later, that presumably means a two-week slip. 14:14:44 on the other hand, this can be worked around with "turn off secure boot", right? 14:14:49 go vote, and get Fedora as your reward for voting? :P 14:14:49 unless we want to try some kind of weird 1.5 week slip or something. 14:14:56 mattdm: yes 14:15:14 I'm still inclined to encourage us to not slip and common bugs this 14:15:36 the fact that it stays on the media forever is however :/ 14:15:38 Secure boot is important in the big picture, but as a matter of individual risk....... 14:15:43 mattdm: yes, but we really shouldn't go down that road because that will become a known thing that will travel message boards for years "in fedora you need to turn off secure boot..." 14:15:48 I don't think that people who download fedora to try it out would read common bugs 14:15:58 I'm with Matthew, although it feels like the least-bad choice 14:16:09 mhroncok: well, it's six months. and we could consider an official respin. 14:16:21 consider and do is a big difference 14:16:22 dcantrell: people already do for nvidia :( 14:16:36 lenovo decided to ship with it off for this reason -- even on the intel model 14:16:44 I think an official respin could be a way out. 14:16:47 FWIW I am taking the 3rd and 4th for PTO, as I anticipate 0 chance of getting any work done on those days, but of course if this subject comes to me working that day, things have to gone very badly. 14:16:50 yeah, but I don't care about that because they don't participate. we actively participate with secureboot and are included, it should be a key feature 14:17:07 zbyszek: I wouldn't be opposed to not slipping with the understanding that we're /planning/ to re-spin media. 14:17:17 Proposal: If an updated and signed shim can be included in time for the release next week, we do so, and if not, we don't block on it, include it as a "Common bug" in the release notes, and advise affected users to *temporarily* disable secure boot, until an updated shim is available. 14:17:26 it would also be a black eye if we admit that we need secure boot turned off 14:17:34 decathorpe: -1 14:17:35 since we've been literally the only champion of the technology 14:17:48 decathorpe: We can't do that from a technical/delivery perspective. -1 14:17:52 Only in some obscure situations though -- it's not most users 14:17:54 I don't think this is going to just affect fedora. ;) 14:17:58 Eighth_Doctor: I don't think us being the only champion of it is a fair assessment 14:18:02 nirik: it will only impact fedora 14:18:09 openSUSE and Ubuntu are resigned already 14:18:32 I'm in the process of checking Debian, but I believe they've already fixed this back when BootHole happened in the first place 14:18:32 sgallagh: I'm not sure what you mean 14:18:32 I suspect there's a lot of other distros/vendors out there that are still scrambling. 14:19:02 most distros don't do secure boot period 14:19:03 decathorpe: That literally means "respun today". Which is impossible. 14:19:08 there are some minor distros that'll be hit, but we'll be the largest by far. 14:19:16 Eighth_Doctor: that is simply not true 14:19:17 sgallagh: we have a rc with everything except this. 14:19:28 do we have to release on a Tuesday ? I think doing a 1,5 split might be a good alternative 14:19:33 1,5 week 14:19:38 Maybe I'm misunderstanding his proposal. 14:19:47 decathorpe: Could you rephrase? 14:19:48 To me, the downside of missing our schedule is bigger than the downside of common-bugsing something that a small number of people will hit. Both are bad, but that's how I personally weight it. 14:20:11 mattdm++ 14:20:11 zbyszek: Karma for mattdm changed to 9 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:20:13 cverna: We don't have to but I don't see 1½ as buying us anything. 14:20:18 Eighth_Doctor: or plausibly only true if you're really buying in to the long trail of how small something is and still be included in "most distros" 14:20:54 pjones: Fedora, Debian, Ubuntu, openSUSE, RHEL, and SLE are the main ones that work with secure boot 14:21:02 beyond that, secure boot support is rare 14:21:08 I consider shipping functional release more important than shipping on schedule 14:21:09 sgallagh: I mean, if we don't have the resigned shim in time for the GA images, then a small number of people *might* need to temporarily turn off secure boot for installing fedora 33. but after getting the shim update via "dnf upgrade" they should be able to turn it back on, or am I missing something? 14:21:11 mattdm: the danger is that the affected people increase over time... 14:21:15 The dbx will continue to roll out, it's in the wild, vendors push dbx with firmware updates, and at some point Microsoft will put it in Windows Update, so they have said. 14:21:17 nirik: how much work would a respin with just the updated shim package be? 14:21:24 mattdm: I guess for me the biggest concern with not shipping it is the question of how many will hit it 5 months from now, not how many will hit it next month 14:21:28 mhroncok there's *always* bugs. 14:21:35 mattdm: sorry, with shipping without a fix 14:21:38 what are to downside of missing our date ? I don't have a clear picture 14:21:40 in five months we can tell people "f34 beta is here!" 14:21:41 zbyszek: what do you mean by 'respin' I guess... 14:22:08 pjones: of the distributions I've listed with secure boot, only Fedora and Debian so far don't have updated shim with new certs 14:22:13 nirik: new compose with just the updated packages, updated on the mirrors 14:22:20 mattdm: not sure if "just run the next beta" is any better than "turn off secure boot" 14:22:21 and Debian still hasn't updated their docs saying secure boot is even supported 14:22:23 so most don't care 14:22:25 respinning live imgaes would be pretty easy. creating a 33.1 compose would be very hard 14:22:32 part of the problem is that we don't know when Microsoft will push it out, as i understand it. so if it happens after the F34 GA then we don't really care, imo. if it does, then it gets bigger (but we don't know how much bigger) 14:22:46 We, however, have made secure boot part of our security story and publicly affirm it 14:22:47 Eighth_Doctor: okay, if you frame it that way I can concede your statement, I just don't see that it's relevant to the discussion. 14:22:57 bcotton: yes we do 14:23:14 pjones: "care" or "know how much bigger"? 14:23:38 pjones: it's only important if you say that other distributions ship secure boot that matter that are impacted too 14:23:52 right now, aside from Debian, I know of no other 14:24:19 bcotton: we don't know it with specific precision, but they're saying no earlier than Q2 of 2021 14:24:19 and from an outsider's perspective, it's weird that RHEL has it fixed and Fedora does not 14:24:47 will people who are running F32 be potentially affected too? 14:24:48 (of course, I know that it's because shim has been FTBFS for a couple of years now) 14:24:50 pjones: okay, so there's a reasonable chance that it ends up after the F34 GA then 14:25:22 Eighth_Doctor: which has been always dismissed as "not an issue" 14:25:36 mattdm: that's a good point. will dual booting with windows break existing f32 installs at that point? 14:25:37 * nirik doesn't think this is helping 14:25:42 Eighth_Doctor: no it isn't, quit fucking lying. 14:25:50 decathorpe: or updated with lvfs even? 14:26:00 pjones: stop that language please 14:26:03 I'm not lying, that's the reason I was told why we don't have updated shim 14:26:13 pjones: Please moderate your tone. Eighth_Doctor please do not be dismissive of people's hard work. 14:26:17 mhroncok: fair, but he's saying something is the case which I have *repeatedly* told him is not. 14:26:32 pjones: that does not justify your language 14:26:52 OK, let's move past that. 14:26:52 mhroncok: already conceded, thank you for bringing it up. 14:27:07 pjones: Can you answer mattdm's question about F32 users? 14:27:43 you know what, screw it 14:27:43 mattdm: can you rephrase the question? I'm not sure I understand which full scenario you're asking about. 14:28:17 Someone has Fedora Workstation 32 dual booting with Windows, Windows gets the update. 14:28:39 mattdm: if we fix it after GA and those people apply updates, they'll be fine 14:29:12 So we need to update shim for all currently supported fedora releases anyway? 14:29:15 if the boot Fedora and update before windows breaks it 14:29:21 decathorpe: yes 14:29:27 pjones: once the build issue is resolved, what are the chances that we'd get the signature from msft within a week? Within two weeks? (I'm asking because if it's low, then slipping is not useful.) 14:29:28 *if they 14:29:30 oh, just to note also... we do have a respins sig that does respin all the media with updates... that could also be a path forward for users, although if it comes to that we might want to promote those over official stuff 14:29:38 decathorpe: yes; currently I'm planning on building this in f31 and tagging it in to later versions. 14:29:49 zbyszek: almost certainly within a week 14:30:13 pjones: does that work? (build on f31) 14:30:13 But in the meantime, F32 users are in the same situation as F33 new installs. That again tilts towards "shouldn't be a release blocker" to me. 14:30:48 mhroncok: it's a stand alone binary that doesn't have any runtime dependencies on anything else; it's effectively what we already do 14:31:03 mattdm: "the latest Fedora release you can download doesn't boot" is different than f32 users 14:31:21 pjones: does it build on f31? I know that if it does, it'll work on f33 14:31:27 mhroncok: yeah, "my currently-installed system stopped booting" is significantly worse 14:31:43 mattdm: and reviewers will fail Fedora for not booting on their computers 14:31:43 mattdm: and we cannot block on that, but we can release the update asap 14:31:48 which also could happen if people don't apply updates. ;) 14:31:51 mhroncok: the compiler ouuputs a binary, right now it doesn't work right because of something the linker is doing. 14:32:02 (again, this has never been an FTBFS issue) 14:32:03 pjones: ack 14:33:16 pjones: if you build it on fedora 28, does the binary work? can we do that today? 14:33:26 nope 14:33:31 Eighth_Doctor: if reviewers even have this problem, which most won't. And we can make sure the issue is noted in our PR materials. Pretty confident that it won't be a big deal. Again, not great, but the perception of slipping will be a bigger negative. 14:33:35 mhroncok: picking a different builder is not going to solve this, debugging it is. 14:33:37 nirik: nope as in doesn't work? 14:33:49 when a release goes eol we disable it in koji. it would require re-adding a bunch of things. 14:34:04 nirik: we sould tag everything needed from f28 to a side tag etc. 14:34:11 nirik: if it actually helps, it's possible 14:34:42 I suppose it's possible, but pretty messy. But could be an option sure. 14:34:57 can we build it in EPEL? 14:34:59 nirik: but it's weird to me that if we replicate the buildroot from the latest shim build that works on runtime, we get a new build that doesn't work on runtme :/ 14:35:00 only half joking 14:35:04 no 14:35:08 mattdm: it builds and runs on EL8 14:35:19 so, yes, technically 14:35:29 fine, don't listen to me. 14:35:30 but I don't think Koji can do that 14:35:37 Eighth_Doctor: it can 14:35:39 pjones: you literally said yesterday it links fine on RHEL 8 14:35:43 pjones: I'm definitely listening to you! 14:35:57 yes, and that's not the same as building in epel 14:36:02 but pjones says that weven if you rebuild shim in the same buildroot as the latest working shim, it somehow doesn't work 14:36:19 that's not actually what I said. 14:36:28 pjones: we can construct a RHEL builder from the EPEL configuration 14:36:33 pjones: so if you build shim in epel8, it works on epel8, but fails in fedora? 14:36:33 if we needed to 14:36:45 Maybe let pjones explain before we go too far here? 14:36:54 pjones: or s/epel8/rhel 14:38:02 (note that in case people don't know, Fedora Koji EPEL 8 builders use RHEL 8 content) 14:38:11 okay, look, I appreciate that you all are trying to find creative ways to work with a weird timeline, but I need it to be debugged regardless, and I don't particularly trust that a hobbled up build environment we've never used for anything is a good idea without having actually done that debugging, so what I'm going to do is debug it. 14:38:12 okay? 14:38:34 s/hobbled/cobbled/ but I think you got what I'm saying. 14:38:55 Yeah, I think this discussion is going nowhere right now 14:38:55 yes that's fair 14:39:02 * nirik nods. 14:39:04 Ironically, both words kind of work :-P 14:39:14 let's go to the orginal question 14:39:23 Still, this doesn't help us make a decision about blocking or not blocking in it 14:39:35 should we still block on this? I think everybody has some idea at this point 14:39:51 FWIW I have an opinion but I don't think people with the other view are unreasonable here 14:40:06 And I can spin whichever decision as the right one in the media :) 14:40:09 it's a tough call... 14:40:13 Proposal: We should slip until shim is fixed. 14:40:13 (I'm -1) 14:40:14 given the information we have right now, I think sticking to the schedule is appropriate 14:40:15 exactly. 14:40:21 yeah, ok 14:40:28 I am more on the -1 to block 14:40:47 oh, negative proposals, love it 14:40:58 OK, I can reverse it. 14:41:03 np 14:41:11 We should slip until shim is fixed + 14:41:11 ok but if you reverse it draw a line so it's not confusing :) 14:41:14 We should slip until shim is fixed +1 14:41:34 mhroncok: -1 14:41:36 slip until shim is fixed +1 14:41:42 Well, the positive version of this is "FESCo re-asserts this to be a blocker" 14:41:47 I obviously can't vote on this, but again I'd be okay with shipping as is if we have a plan to update boot media if it becomes more important. Otherwise, I think we should slip. 14:42:01 So the votes are still in the same direction' 14:42:05 (obviously, we can revisit this if it's not fixed yet in e.g. February) 14:42:28 slip until fixed: weak +1 14:42:31 we have no infrastructure to respin everything (including boot/netinst/pxe/etc) 14:42:33 cverna: Your vote is unclear. 14:42:43 I say stick to the schedule because (a) this affects a subset of machines now, (b) pjones still has to fix this regardless but that requires an unknown amount of time at the moment and I'd rather him not be in the hot seat with everyone asking is it ready yet and (c) we can address this in PR materials as mattdm said 14:42:45 I think I am slightly -1 to slip until it's fixed. I think we could respin media if needed or test/advertise the respins... 14:43:00 slip until shim is fixed -1 14:43:47 not that I'd be happy to ship if I'd know we are able to release new media with updated shim after GA, but frankly, I don't think we have the resources to do so 14:43:51 *note 14:43:55 dcantrell: I'll be sure to make it clear that we definitely want people to run with secure boot so this is a temporary situation 14:43:57 dcantrell: I would *only* be okay with us even considering it (knowing that we cannot respin everything post-GA) if we made a Fedora Magazine article explaining this to *everyone* 14:44:30 I count: (+3,0, -3) at the moment. 14:44:37 respinning everything would be hard... livemedia would be pretty easy... but yes that would leave pxe and such broken... 14:44:39 I think that's doable and would actually be really a good way to let Fedora explain to everyone (reviewers) why we're doing this 14:44:40 yes, sgallagh's proposal has (+3, 0, -3) votes 14:44:49 dcantrell: Are you -1 then? 14:44:49 nirik: install media would be broken 14:44:55 Eighth_Doctor: yes 14:44:56 yes -1 to your proposal 14:44:57 I will say that if we decide not to slip, and then it turns out I have a solution sooner rather later, I can keep fesco informed and we could interrupt shipping if so decided. 14:45:06 ok, (+3, 0, -4) for now 14:45:23 pjones: I'm open to that idea. 14:45:32 pjones: that sounds reasonable 14:45:45 sgallagh: that's more or less my original proposal :) 14:45:45 pjones: that gives you until friday morning because the PR machine will be turning 14:46:05 Who hasn't voted? 14:46:05 we'll probably need the article anyway for F32 and older 14:46:11 We don't technically have an agreement yet. 14:46:12 mattdm: yeah, and that's very unlikely as a timeframe, but I'll do what I gotta do. 14:46:18 zbyszek's vote is missing 14:46:22 pjones++ 14:46:22 mattdm: Karma for pjones changed to 9 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:46:27 Yeah... 14:46:37 no pressure :D 14:46:39 if we don't agree, I guess it stays as a blocker. ;) 14:46:44 OK, so -1 to slip. 14:46:44 decathorpe: bit late for that ;) 14:47:18 Eighth_Doctor: #action bcotton to work on magazine article :) 14:47:24 OK, that's (+3, 0, -5) which means we've opted not to block on it. 14:47:42 * Eighth_Doctor sighs 14:47:44 so 14:47:47 thanks everyone. I appreciate the difficult call. 14:47:49 does this mean... 14:47:50 * pjones goes back to work 14:47:54 thanks pjones! 14:47:56 1) this is no longer a fesco blocker 14:48:00 pjones: thanks! 14:48:04 thanks pjones 14:48:08 1) yes 14:48:09 pjones++ 14:48:09 mhroncok: unfortunately, yes 14:48:15 2) this can be decided on go/no-go withotu fesco majority? 14:48:21 yep 14:48:24 3) this is not any blocker right now? 14:48:31 yes 14:48:32 well, it could anyhow? 14:48:43 nirik: it could not, we changed the rules last week 14:49:08 we changed the rule to allow any fesco members present at the go/no-go to decide even if they were not a majority... (at least I thought?) 14:49:08 1) yes, 2) N/A 3) It *could* become a blocker by normal process if they wanted it to. 14:49:14 yes 14:49:22 it either needed fesco majority of unianimous consent by the attendees 14:49:24 s/of/or/ 14:49:26 can we at least keep it regular blocker, so qa etc. can decided to waive it tmrw? 14:49:26 it was / is already a blocker by that 14:49:55 nirik: I don't think it was ever voted on formally by the regular blocker process 14:49:59 Because it came to us and we voted 14:50:10 sgallagh: that's my recollection too 14:50:13 because unfortunately, we lack an explicit criteria around secure boot 14:50:15 yea,h it has votes, but it was never decided. and the votes were 2 week sago 14:50:23 wait, we're going to go through this again tomorrow? wheeeeee 14:50:33 sgallagh: but it had 4+ 14:50:35 https://pagure.io/fedora-qa/blocker-review/issue/135 14:50:47 (we probably should develop criteria around secure boot, it's a pretty bad failing that we lack that) 14:51:16 I only found out this was a problem was that people tweeted at me about it 14:51:17 hmm 14:51:18 if Fedora QA can reliably reproduce a bug that is a release blocker, that's a separate thing. adamw already mentioned on this secureboot issue that Fedora QA has not been able to reliably reproduce this secureboot issue 14:51:21 mattdm: yeah, seems so. 14:51:58 Is there actually anything anybody still wants for FESCo to decide about this, or can we move on to the next topic? 14:52:01 well, now you can reproduce it by forcing fwupd to apply the update 14:52:09 since it's on LVFS now 14:52:13 decathorpe: I would like to know what e just decided 14:52:19 technically, there was a proposal that was rejected 14:52:29 We decided it dropped FESCo Blocker status 14:52:41 I guess the spirit of the rejection is to revoke the fesco blocker status 14:52:41 https://fwupd.org/lvfs/devices/org.linuxfoundation.dbx.x64.firmware 14:52:43 Eighth_Doctor: sure but I can DoS my own box any number of ways. Including just going into the firmware and enrolling the kernel in dbx. 14:53:03 pjones: sure, I'm saying that if Fedora QA wants to reproduce it, they can just apply the update 14:53:10 We're no longer forcing it to be a blocker, but that doesn't mean that we're demanding it *not* be a blocker, I think. 14:53:19 sgallagh: right 14:53:21 and I'm saying that's reproducing the symptom without reproducing the issue. 14:53:21 "We should slip until shim is fixed" got (+3, 0, -5) so, no longer FESCo blocker, but no other decision made 14:53:21 sgallagh: right 14:53:44 pjones: that's fair 14:54:05 I don't think that is pushed out, I think it's in testing... but I could be wrong (I surely don't get it here tho) 14:54:35 nirik: I don't know how Ubuntu is handling secure boot and firmware updates between the interaction of debs and snaps 14:54:40 nirik: " Warning: This firmware is in the testing state and may not be suitable for production systems. " 14:54:43 it's really hard to figure out 14:55:00 the best guess we have now is that Ubuntu has been pushing it out "randomly" 14:55:04 • UEFI dbx has no available firmware updates 14:55:08 rather than at full scale 14:55:14 (as they were a few weeks ago) 14:55:40 anyhow, move on. 14:56:15 Just to clarify: What's the latest point at which we could include a shim update as Freeze Exception before the media for the GA gets generated? 14:56:23 Friday 14:56:24 https://twitter.com/mattdm/status/1318927392715526148 14:56:35 bcotton: we can skip the go/no-gi :D 14:56:39 in theory even Saturday, but that's super-unlikely 14:56:41 *go/no-go 14:57:15 so, if shim is fixed by then, we can include it, and if not, it gets shipped as an update 14:57:16 mhroncok: hooray! ;-) 14:57:32 well, we have no other blockers I guess 14:57:36 so, here we go? 14:57:45 uh... thursday? unless everyone agrees to hero work 14:58:08 we will need to make a new rc, qa will have to test it. 14:58:14 mattdm: Isn't there a saying about eggs that applies here? 14:58:15 Ben Cotton: then I guess that means we'll see a Fedora Magazine article about this from you :P 14:58:24 okay, so, it's unlikely 14:58:42 sgallagh: the omelet one? :) 14:58:47 #topic Next Week's Chair 14:59:09 mattdm: no 14:59:27 "I can eat 50 eggs!" 14:59:27 I thought it was spelled omelette 14:59:53 We spell it "omlet" ;) 14:59:54 sgallagh is defintely thinking of "I can eat 50 eggs." couldn't possibly be anything else. 15:00:13 obluette? 15:00:13 * dcantrell updates personal hunspell dictionary 15:00:16 omelette is the French spelling, so naturally we use it in English :) 15:00:23 so many volunteers to chair the next meeting, wow 15:00:39 lol 15:00:41 sorry 15:00:53 the phonetic spelling in English (which is also valid) is omelet 15:01:11 decathorpe: I'll do it 15:01:27 #info https://www.merriam-webster.com/dictionary/omelet 15:01:33 dcantrell: thanks! 15:01:38 mattdm: https://pjones.fedorapeople.org/50eggs.png <-- there you go 15:01:40 decathorpe: np 15:01:40 #action dcantrell to chiair the next meeting 15:01:56 pjones: not raw I hope? :) 15:01:57 pjones: yes 15:01:58 #topic Open Floor 15:02:13 So... has anyone heard from ignatenkobrain lately? 15:02:16 TIL that omelets are Persian in origin 15:02:25 no 15:02:30 No. 15:02:32 I'm worried about him 15:02:34 nope. ;( 15:02:44 do we have anyone who might be able to check in on him? 15:02:45 yeah me too 15:03:10 In theory maybe zbyszek 15:03:22 how does that theory work? 15:03:25 or mhroncok actually 15:03:32 ! 15:03:52 Poland is close to Czechia, no? :P 15:03:54 Hello guys, I'm woring in the i3 SIG 15:04:05 though you being in Czechia is even better :) 15:04:14 I could possibly ask somebody at gooddata 15:04:16 And we are wondering if there is something related to a GTK race condition in anaconda 15:04:28