14:00:31 <decathorpe> #startmeeting FESCo (2020-10-21)
14:00:31 <zodbot> Meeting started Wed Oct 21 14:00:31 2020 UTC.
14:00:31 <zodbot> This meeting is logged and archived in a public location.
14:00:31 <zodbot> The chair is decathorpe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:31 <zodbot> The meeting name has been set to 'fesco_(2020-10-21)'
14:00:37 <decathorpe> #meetingname fesco
14:00:37 <zodbot> The meeting name has been set to 'fesco'
14:00:42 <decathorpe> #chair nirik, ignatenkobrain, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, cverna, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
14:00:42 <zodbot> 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 <nirik> morning
14:00:56 <decathorpe> #topic Init Process
14:00:59 <cverna> hello
14:01:07 <bcotton> .hello2
14:01:08 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
14:01:25 <decathorpe> good afternoon / morning
14:01:41 <sgallagh> .hello2
14:01:41 <mhroncok> hey
14:01:41 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:01:52 <mattdm> good $TIMEOFDAY!
14:02:22 <decathorpe> greetings, $FPL
14:02:35 <dcantrell> .hello2
14:02:41 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
14:02:42 <mattdm> lol decathorpe
14:03:25 <decathorpe> I already count 6 FESCo members as present, so we have quorum, I'll give the others until :05
14:04:14 <zbyszek> .hello2
14:04:15 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
14:04:20 <decathorpe> zbyszek hello!
14:04:52 <zbyszek> Hi, excuse the tardiness.
14:05:00 <decathorpe> we haven't started yet :)
14:05:42 <decathorpe> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/REFRCU3EQIXM6WADFBVYHYJNJ2RYXEDF/ schedule
14:06:25 <decathorpe> #topic #2479 F33 UEFI Secure Boot signing keys
14:06:27 <decathorpe> .fesco 2479
14:06:28 <zodbot> decathorpe: Issue #2479: F33 UEFI Secure Boot signing keys - fesco - Pagure.io - https://pagure.io/fesco/issue/2479
14:06:29 <mhroncok> there's just this minor thing :)
14:06:37 * Eighth_Doctor waves
14:06:39 <Eighth_Doctor> .hello ngompa
14:06:40 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
14:06:42 <Eighth_Doctor> sorry I'm late
14:06:44 <sgallagh> I'm trying to find pjones to speak to us about this
14:06:54 <Eighth_Doctor> my employer went public this morning and I lost track of time :)
14:07:03 <decathorpe> congratulations!
14:07:04 <nirik> Eighth_Doctor: congrats.
14:07:15 <Eighth_Doctor> yup, Datto is $MSP on NYSE :D
14:07:24 <bcotton> datto++
14:07:29 <sgallagh> OK, pjones is here.
14:07:36 <dcantrell> congrats!
14:07:46 <pjones> Eighth_Doctor: haha, suckers
14:07:51 <dcantrell> pjones: welcome
14:08:01 <sgallagh> 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 <mhroncok> what is the exact new information about the rate of hitting this?
14:08:40 <mhroncok> if people boot ubuntu, do they still hit this?
14:08:43 <nirik> pjones: any status update from your end?
14:08:49 <sgallagh> mhroncok: Mostly that Fedora QA has been trying to reproduce it and isn't able to do so consistently.
14:08:49 <pjones> nirik: still debugging
14:08:59 <sgallagh> It's apparently not as simple as "boot ubuntu and then you die"
14:09:16 <decathorpe> so to me it sounds like it's harder to trigger this issue than we initially thoguht
14:09:23 <nirik> pjones: ok, fair enough
14:10:03 <mattdm> and pjones sounds like it's not just "make one with new key and we can ship in two weeks"?
14:10:20 <Eighth_Doctor> unfortunately, we're also now at the point that the new dbx is available publicly from multiple sources
14:10:26 <Eighth_Doctor> including LVFS
14:10:30 <pjones> mattdm: not sure I understand what you're asking
14:10:57 <mattdm> pjones: I need the FPL level view of: if we slip this week, does that even buy us anything?
14:11:14 <pjones> mattdm: *probably*?
14:11:33 <kalev> 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 <kalev> 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 <pjones> that's not the issue; something in our efi runtime is interacting with ld in a weird way
14:12:13 <kalev> aha
14:12:57 <mattdm> pjones: what's your feeling on shipping vs. delay for this at this point?
14:13:43 <pjones> 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 <mattdm> ok, so that's "slip".
14:14:23 <mattdm> with the US election day one week later, that presumably means a two-week slip.
14:14:44 <mattdm> on the other hand, this can be worked around with "turn off secure boot", right?
14:14:49 <Eighth_Doctor> go vote, and get Fedora as your reward for voting? :P
14:14:49 <nirik> unless we want to try some kind of weird 1.5 week slip or something.
14:14:56 <nirik> mattdm: yes
14:15:14 <mattdm> I'm still inclined to encourage us to not slip and common bugs this
14:15:36 <mhroncok> the fact that it stays on the media forever is however :/
14:15:38 <mattdm> Secure boot is important in the big picture, but as a matter of individual risk.......
14:15:43 <dcantrell> 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 <mhroncok> I don't think that people who download fedora to try it out would read common bugs
14:15:58 <bcotton> I'm with Matthew, although it feels like the least-bad choice
14:16:09 <mattdm> mhroncok: well, it's six months. and we could consider an official respin.
14:16:21 <mhroncok> consider and do is a big difference
14:16:22 <mattdm> dcantrell: people already do for nvidia :(
14:16:36 <mattdm> lenovo decided to ship with it off for this reason -- even on the intel model
14:16:44 <zbyszek> I think an official respin could be a way out.
14:16:47 <pjones> 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 <dcantrell> 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 <pjones> zbyszek: I wouldn't be opposed to not slipping with the understanding that we're /planning/ to re-spin media.
14:17:17 <decathorpe> 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 <Eighth_Doctor> it would also be a black eye if we admit that we need secure boot turned off
14:17:34 <mhroncok> decathorpe: -1
14:17:35 <Eighth_Doctor> since we've been literally the only champion of the technology
14:17:48 <sgallagh> decathorpe: We can't do that from a technical/delivery perspective. -1
14:17:52 <mattdm> Only in some obscure situations though -- it's not most users
14:17:54 <nirik> I don't think this is going to just affect fedora. ;)
14:17:58 <pjones> Eighth_Doctor: I don't think us being the only champion of it is a fair assessment
14:18:02 <Eighth_Doctor> nirik: it will only impact fedora
14:18:09 <Eighth_Doctor> openSUSE and Ubuntu are resigned already
14:18:32 <Eighth_Doctor> 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 <decathorpe> sgallagh: I'm not sure what you mean
14:18:32 <nirik> I suspect there's a lot of other distros/vendors out there that are still scrambling.
14:19:02 <Eighth_Doctor> most distros don't do secure boot period
14:19:03 <sgallagh> decathorpe: That literally means "respun today". Which is impossible.
14:19:08 <pjones> there are some minor distros that'll be hit, but we'll be the largest by far.
14:19:16 <pjones> Eighth_Doctor: that is simply not true
14:19:17 <nirik> sgallagh: we have a rc with everything except this.
14:19:28 <cverna> do we have to release on a Tuesday ? I think doing a 1,5 split might be a good alternative
14:19:33 <cverna> 1,5 week
14:19:38 <sgallagh> Maybe I'm misunderstanding his proposal.
14:19:47 <sgallagh> decathorpe: Could you rephrase?
14:19:48 <mattdm> 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 <zbyszek> mattdm++
14:20:11 <zodbot> zbyszek: Karma for mattdm changed to 9 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:20:13 <mattdm> cverna: We don't have to but I don't see 1½ as buying us anything.
14:20:18 <pjones> 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 <Eighth_Doctor> pjones: Fedora, Debian, Ubuntu, openSUSE, RHEL, and SLE are the main ones that work with secure boot
14:21:02 <Eighth_Doctor> beyond that, secure boot support is rare
14:21:08 <mhroncok> I consider shipping functional release more important than shipping on schedule
14:21:09 <decathorpe> 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 <nirik> mattdm: the danger is that the affected people increase over time...
14:21:15 <cmurf> 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 <zbyszek> nirik: how much work would a respin with just the updated shim package be?
14:21:24 <pjones> 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 <mattdm> mhroncok there's *always* bugs.
14:21:35 <pjones> mattdm: sorry, with shipping without a fix
14:21:38 <cverna> what are to downside of missing our date ? I don't have a clear picture
14:21:40 <mattdm> in five months we can tell people "f34 beta is here!"
14:21:41 <nirik> zbyszek: what do you mean by 'respin' I guess...
14:22:08 <Eighth_Doctor> 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 <mattdm> nirik: new compose with just the updated packages, updated on the mirrors
14:22:20 <mhroncok> mattdm: not sure if "just run the next beta" is any better than "turn off secure boot"
14:22:21 <Eighth_Doctor> and Debian still hasn't updated their docs saying secure boot is even supported
14:22:23 <Eighth_Doctor> so most don't care
14:22:25 <nirik> respinning live imgaes would be pretty easy. creating a 33.1 compose would be very hard
14:22:32 <bcotton> 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 <Eighth_Doctor> We, however, have made secure boot part of our security story and publicly affirm it
14:22:47 <pjones> 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 <pjones> bcotton: yes we do
14:23:14 <sgallagh> pjones: "care" or "know how much bigger"?
14:23:38 <Eighth_Doctor> pjones: it's only important if you say that other distributions ship secure boot that matter that are impacted too
14:23:52 <Eighth_Doctor> right now, aside from Debian, I know of no other
14:24:19 <pjones> bcotton: we don't know it with specific precision, but they're saying no earlier than Q2 of 2021
14:24:19 <Eighth_Doctor> and from an outsider's perspective, it's weird that RHEL has it fixed and Fedora does not
14:24:47 <mattdm> will people who are running F32 be potentially affected too?
14:24:48 <Eighth_Doctor> (of course, I know that it's because shim has been FTBFS for a couple of years now)
14:24:50 <bcotton> pjones: okay, so there's a reasonable chance that it ends up after the F34 GA then
14:25:22 <mhroncok> Eighth_Doctor: which has been always dismissed as "not an issue"
14:25:36 <decathorpe> 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 <pjones> Eighth_Doctor: no it isn't, quit fucking lying.
14:25:50 <mattdm> decathorpe: or updated with lvfs even?
14:26:00 <mhroncok> pjones: stop that language please
14:26:03 <Eighth_Doctor> I'm not lying, that's the reason I was told why we don't have updated shim
14:26:13 <sgallagh> pjones: Please moderate your tone. Eighth_Doctor please do not be dismissive of people's hard work.
14:26:17 <pjones> mhroncok: fair, but he's saying something is the case which I have *repeatedly* told him is not.
14:26:32 <mhroncok> pjones: that does not justify your language
14:26:52 <sgallagh> OK, let's move past that.
14:26:52 <pjones> mhroncok: already conceded, thank you for bringing it up.
14:27:07 <sgallagh> pjones: Can you answer mattdm's question about F32 users?
14:27:43 <Eighth_Doctor> you know what, screw it
14:27:43 <pjones> mattdm: can you rephrase the question?  I'm not sure I understand which full scenario you're asking about.
14:28:17 <mattdm> Someone has Fedora Workstation 32 dual booting with Windows, Windows gets the update.
14:28:39 <pjones> mattdm: if we fix it after GA and those people apply updates, they'll be fine
14:29:12 <decathorpe> So we need to update shim for all currently supported fedora releases anyway?
14:29:15 <mhroncok> if the boot Fedora and update before windows breaks it
14:29:21 <mhroncok> decathorpe: yes
14:29:27 <zbyszek> 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 <mhroncok> *if they
14:29:30 <nirik> 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 <pjones> decathorpe: yes; currently I'm planning on building this in f31 and tagging it in to later versions.
14:29:49 <pjones> zbyszek: almost certainly within a week
14:30:13 <mhroncok> pjones: does that work? (build on f31)
14:30:13 <mattdm> 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 <pjones> 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 <mhroncok> mattdm: "the latest Fedora release you can download doesn't boot" is different than f32 users
14:31:21 <mhroncok> pjones: does it build on f31? I know that if it does, it'll work on f33
14:31:27 <mattdm> mhroncok: yeah, "my currently-installed system stopped booting" is significantly worse
14:31:43 <Eighth_Doctor> mattdm: and reviewers will fail Fedora for not booting on their computers
14:31:43 <mhroncok> mattdm: and we cannot block on that, but we can release the update asap
14:31:48 <nirik> which also could happen if people don't apply updates. ;)
14:31:51 <pjones> mhroncok: the compiler ouuputs a binary, right now it doesn't work right because of something the linker is doing.
14:32:02 <pjones> (again, this has never been an FTBFS issue)
14:32:03 <mhroncok> pjones: ack
14:33:16 <mhroncok> pjones: if you build it on fedora 28, does the binary work? can we do that today?
14:33:26 <nirik> nope
14:33:31 <mattdm> 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 <pjones> mhroncok: picking a different builder is not going to solve this, debugging it is.
14:33:37 <mhroncok> nirik: nope as in doesn't work?
14:33:49 <nirik> when a release goes eol we disable it in koji. it would require re-adding a bunch of things.
14:34:04 <mhroncok> nirik: we sould tag everything needed from f28 to a side tag etc.
14:34:11 <mhroncok> nirik: if it actually helps, it's possible
14:34:42 <nirik> I suppose it's possible, but pretty messy. But could be an option sure.
14:34:57 <mattdm> can we build it in EPEL?
14:34:59 <mhroncok> 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 <mattdm> only half joking
14:35:04 <pjones> no
14:35:08 <Eighth_Doctor> mattdm: it builds and runs on EL8
14:35:19 <Eighth_Doctor> so, yes, technically
14:35:29 <pjones> fine, don't listen to me.
14:35:30 <Eighth_Doctor> but I don't think Koji can do that
14:35:37 <mhroncok> Eighth_Doctor: it can
14:35:39 <Eighth_Doctor> pjones: you literally said yesterday it links fine on RHEL 8
14:35:43 <mattdm> pjones: I'm definitely listening to you!
14:35:57 <pjones> yes, and that's not the same as building in epel
14:36:02 <mhroncok> 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 <pjones> that's not actually what I said.
14:36:28 <Eighth_Doctor> pjones: we can construct a RHEL builder from the EPEL configuration
14:36:33 <mhroncok> pjones: so if you build shim in epel8, it works on epel8, but fails in fedora?
14:36:33 <Eighth_Doctor> if we needed to
14:36:45 <sgallagh> Maybe let pjones explain before we go too far here?
14:36:54 <mhroncok> pjones: or s/epel8/rhel
14:38:02 <Eighth_Doctor> (note that in case people don't know, Fedora Koji EPEL 8 builders use RHEL 8 content)
14:38:11 <pjones> 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 <pjones> okay?
14:38:34 <pjones> s/hobbled/cobbled/ but I think you got what I'm saying.
14:38:55 <decathorpe> Yeah, I think this discussion is going nowhere right now
14:38:55 <mattdm> yes that's fair
14:39:02 * nirik nods.
14:39:04 <sgallagh> Ironically, both words kind of work :-P
14:39:14 <mhroncok> let's go to the orginal question
14:39:23 <decathorpe> Still, this doesn't help us make a decision about blocking or not blocking in it
14:39:35 <mhroncok> should we still block on this? I think everybody has some idea at this point
14:39:51 <mattdm> FWIW I have an opinion but I don't think people with the other view are unreasonable here
14:40:06 <mattdm> And I can spin whichever decision as the right one in the media :)
14:40:09 <nirik> it's a tough call...
14:40:13 <sgallagh> Proposal: We should slip until shim is fixed.
14:40:13 <sgallagh> (I'm -1)
14:40:14 <dcantrell> given the information we have right now, I think sticking to the schedule is appropriate
14:40:15 <mattdm> exactly.
14:40:21 <dcantrell> yeah, ok
14:40:28 <cverna> I am more on the -1 to block
14:40:47 <mhroncok> oh, negative proposals, love it
14:40:58 <sgallagh> OK, I can reverse it.
14:41:03 <mhroncok> np
14:41:11 <mhroncok> We should slip until shim is fixed +
14:41:11 <mattdm> ok but if you reverse it draw a line so it's not confusing :)
14:41:14 <mhroncok> We should slip until shim is fixed +1
14:41:34 <cverna> mhroncok: -1
14:41:36 <Eighth_Doctor> slip until shim is fixed +1
14:41:42 <sgallagh> Well, the positive version of this is "FESCo re-asserts this to be a blocker"
14:41:47 <pjones> 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 <sgallagh> So the votes are still in the same direction'
14:42:05 <mhroncok> (obviously, we can revisit this if it's not fixed yet in e.g. February)
14:42:28 <decathorpe> slip until fixed: weak +1
14:42:31 <Eighth_Doctor> we have no infrastructure to respin everything (including boot/netinst/pxe/etc)
14:42:33 <sgallagh> cverna: Your vote is unclear.
14:42:43 <dcantrell> 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 <nirik> 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 <cverna> slip until shim is fixed -1
14:43:47 <mhroncok> 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 <mhroncok> *note
14:43:55 <mattdm> 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 <Eighth_Doctor> 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 <sgallagh> I count: (+3,0, -3) at the moment.
14:44:37 <nirik> respinning everything would be hard... livemedia would be pretty easy... but yes that would leave pxe and such broken...
14:44:39 <dcantrell> 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 <decathorpe> yes, sgallagh's proposal has (+3, 0, -3) votes
14:44:49 <sgallagh> dcantrell: Are you -1 then?
14:44:49 <Eighth_Doctor> nirik: install media would be broken
14:44:55 <nirik> Eighth_Doctor: yes
14:44:56 <dcantrell> yes -1 to your proposal
14:44:57 <pjones> 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 <sgallagh> ok, (+3, 0, -4) for now
14:45:23 <sgallagh> pjones: I'm open to that idea.
14:45:32 <dcantrell> pjones: that sounds reasonable
14:45:45 <decathorpe> sgallagh: that's more or less my original proposal :)
14:45:45 <mattdm> pjones: that gives you until friday morning because the PR machine will be turning
14:46:05 <sgallagh> Who hasn't voted?
14:46:05 <Eighth_Doctor> we'll probably need the article anyway for F32 and older
14:46:11 <sgallagh> We don't technically have an agreement yet.
14:46:12 <pjones> mattdm: yeah, and that's very unlikely as a timeframe, but I'll do what I gotta do.
14:46:18 <decathorpe> zbyszek's vote is missing
14:46:22 <mattdm> pjones++
14:46:22 <zodbot> mattdm: Karma for pjones changed to 9 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:46:27 <zbyszek> Yeah...
14:46:37 <decathorpe> no pressure :D
14:46:39 <nirik> if we don't agree, I guess it stays as a blocker. ;)
14:46:44 <zbyszek> OK, so -1 to slip.
14:46:44 <pjones> decathorpe: bit late for that ;)
14:47:18 <mattdm> Eighth_Doctor: #action bcotton to work on magazine article :)
14:47:24 <sgallagh> 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 <mhroncok> so
14:47:47 <mattdm> thanks everyone. I appreciate the difficult call.
14:47:49 <mhroncok> does this mean...
14:47:50 * pjones goes back to work
14:47:54 <mattdm> thanks pjones!
14:47:56 <mhroncok> 1) this is no longer a fesco blocker
14:48:00 <dcantrell> pjones: thanks!
14:48:04 <nirik> thanks pjones
14:48:08 <sgallagh> 1) yes
14:48:09 <bcotton> pjones++
14:48:09 <Eighth_Doctor> mhroncok: unfortunately, yes
14:48:15 <mhroncok> 2) this can be decided on go/no-go withotu fesco majority?
14:48:21 <Eighth_Doctor> yep
14:48:24 <mhroncok> 3) this is not any blocker right now?
14:48:31 <Eighth_Doctor> yes
14:48:32 <nirik> well, it could anyhow?
14:48:43 <Eighth_Doctor> nirik: it could not, we changed the rules last week
14:49:08 <nirik> 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 <sgallagh> 1) yes, 2) N/A  3) It *could* become a blocker by normal process if they wanted it to.
14:49:14 <sgallagh> yes
14:49:22 <Eighth_Doctor> it either needed fesco majority of unianimous consent by the attendees
14:49:24 <Eighth_Doctor> s/of/or/
14:49:26 <mhroncok> can we at least keep it regular blocker, so qa etc. can decided to waive it tmrw?
14:49:26 <nirik> it was / is already a blocker by that
14:49:55 <sgallagh> nirik: I don't think it was ever voted on formally by the regular blocker process
14:49:59 <sgallagh> Because it came to us and we voted
14:50:10 <zbyszek> sgallagh: that's my recollection too
14:50:13 <Eighth_Doctor> because unfortunately, we lack an explicit criteria around secure boot
14:50:15 <bcotton> yea,h it has votes, but it was never decided. and the votes were 2 week sago
14:50:23 <mattdm> wait, we're going to go through this again tomorrow? wheeeeee
14:50:33 <mhroncok> sgallagh: but it had 4+
14:50:35 <mhroncok> https://pagure.io/fedora-qa/blocker-review/issue/135
14:50:47 <Eighth_Doctor> (we probably should develop criteria around secure boot, it's a pretty bad failing that we lack that)
14:51:16 <Eighth_Doctor> I only found out this was a problem was that people tweeted at me about it
14:51:17 <sgallagh> hmm
14:51:18 <dcantrell> 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 <nirik> mattdm: yeah, seems so.
14:51:58 <decathorpe> 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 <Eighth_Doctor> well, now you can reproduce it by forcing fwupd to apply the update
14:52:09 <Eighth_Doctor> since it's on LVFS now
14:52:13 <mhroncok> decathorpe: I would like to know what e just decided
14:52:19 <mhroncok> technically, there was a proposal that was rejected
14:52:29 <sgallagh> We decided it dropped FESCo Blocker status
14:52:41 <mhroncok> I guess the spirit of the rejection is to revoke the fesco blocker status
14:52:41 <Eighth_Doctor> https://fwupd.org/lvfs/devices/org.linuxfoundation.dbx.x64.firmware
14:52:43 <pjones> 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 <Eighth_Doctor> pjones: sure, I'm saying that if Fedora QA wants to reproduce it, they can just apply the update
14:53:10 <sgallagh> 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 <mhroncok> sgallagh: right
14:53:21 <pjones> and I'm saying that's reproducing the symptom without reproducing the issue.
14:53:21 <decathorpe> "We should slip until shim is fixed" got (+3, 0, -5) so, no longer FESCo blocker, but no other decision made
14:53:21 <dcantrell> sgallagh: right
14:53:44 <Eighth_Doctor> pjones: that's fair
14:54:05 <nirik> 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 <Eighth_Doctor> nirik: I don't know how Ubuntu is handling secure boot and firmware updates between the interaction of debs and snaps
14:54:40 <zbyszek> nirik: " Warning: This firmware is in the testing state and may not be suitable for production systems. "
14:54:43 <Eighth_Doctor> it's really hard to figure out
14:55:00 <Eighth_Doctor> the best guess we have now is that Ubuntu has been pushing it out "randomly"
14:55:04 <nirik> • UEFI dbx has no available firmware updates
14:55:08 <Eighth_Doctor> rather than at full scale
14:55:14 <Eighth_Doctor> (as they were a few weeks ago)
14:55:40 <nirik> anyhow, move on.
14:56:15 <decathorpe> 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 <Eighth_Doctor> Friday
14:56:24 <mhroncok> https://twitter.com/mattdm/status/1318927392715526148
14:56:35 <mhroncok> bcotton: we can skip the go/no-gi :D
14:56:39 <Eighth_Doctor> in theory even Saturday, but that's super-unlikely
14:56:41 <mhroncok> *go/no-go
14:57:15 <decathorpe> so, if shim is fixed by then, we can include it, and if not, it gets shipped as an update
14:57:16 <bcotton> mhroncok: hooray! ;-)
14:57:32 <Eighth_Doctor> well, we have no other blockers I guess
14:57:36 <Eighth_Doctor> so, here we go?
14:57:45 <nirik> uh... thursday? unless everyone agrees to hero work
14:58:08 <nirik> we will need to make a new rc, qa will have to test it.
14:58:14 <sgallagh> mattdm: Isn't there a saying about eggs that applies here?
14:58:15 <Eighth_Doctor> Ben Cotton: then I guess that means we'll see a Fedora Magazine article about this from you :P
14:58:24 <decathorpe> okay, so, it's unlikely
14:58:42 <mattdm> sgallagh: the omelet one? :)
14:58:47 <decathorpe> #topic Next Week's Chair
14:59:09 <sgallagh> mattdm: no
14:59:27 <mattdm> "I can eat 50 eggs!"
14:59:27 <dcantrell> I thought it was spelled omelette
14:59:53 <zbyszek> We spell it "omlet" ;)
14:59:54 <mattdm> sgallagh is defintely thinking of "I can eat 50 eggs." couldn't possibly be anything else.
15:00:13 <nirik> obluette?
15:00:13 * dcantrell updates personal hunspell dictionary
15:00:16 <Eighth_Doctor> omelette is the French spelling, so naturally we use it in English :)
15:00:23 <decathorpe> so many volunteers to chair the next meeting, wow
15:00:39 <mattdm> lol
15:00:41 <mattdm> sorry
15:00:53 <Eighth_Doctor> the phonetic spelling in English (which is also valid) is omelet
15:01:11 <dcantrell> decathorpe: I'll do it
15:01:27 <mattdm> #info https://www.merriam-webster.com/dictionary/omelet
15:01:33 <decathorpe> dcantrell: thanks!
15:01:38 <pjones> mattdm: https://pjones.fedorapeople.org/50eggs.png <-- there you go
15:01:40 <dcantrell> decathorpe: np
15:01:40 <decathorpe> #action dcantrell to chiair the next meeting
15:01:56 <Eighth_Doctor> pjones: not raw I hope? :)
15:01:57 <mattdm> pjones: yes
15:01:58 <decathorpe> #topic Open Floor
15:02:13 <sgallagh> So... has anyone heard from ignatenkobrain lately?
15:02:16 <Eighth_Doctor> TIL that omelets are Persian in origin
15:02:25 <Eighth_Doctor> no
15:02:30 <zbyszek> No.
15:02:32 <Eighth_Doctor> I'm worried about him
15:02:34 <nirik> nope. ;(
15:02:44 <nirik> do we have anyone who might be able to check in on him?
15:02:45 <decathorpe> yeah me too
15:03:10 <Eighth_Doctor> In theory maybe zbyszek
15:03:22 <mhroncok> how does that theory work?
15:03:25 <Eighth_Doctor> or mhroncok actually
15:03:32 <x3mboy> !
15:03:52 <Eighth_Doctor> Poland is close to Czechia, no? :P
15:03:54 <x3mboy> Hello guys, I'm woring in the i3 SIG
15:04:05 <Eighth_Doctor> though you being in Czechia is even better :)
15:04:14 <mhroncok> I could possibly ask somebody at gooddata
15:04:16 <x3mboy> And we are wondering if there is something related to a GTK race condition in anaconda
15:04:28 <zbyszek> Eighth_Doctor: it's surprisingly far
15:04:33 <x3mboy> That prevents the installer from running
15:04:40 <decathorpe> x3mboy: probably the wrong place to ask right now
15:04:47 <dcantrell> x3mboy: try #anaconda
15:04:51 <defolos> Conan Kudo: Czechia is becoming a Corona-lockdown zone
15:05:03 <Eighth_Doctor> oh dear
15:05:07 <defolos> traveling might be heavily restricted
15:05:25 <x3mboy> Ok
15:05:31 <defolos> emphasis on might
15:05:32 <x3mboy> Thanks guys
15:06:03 <dcantrell> I was supposed to renew my Global Entry yesterday at the Derby Line, Vermont border crossing but my appointment was cancelled due to Vermont restrictions on out of state visitors.  not that I can travel anywhere right now, I just don't want global entry to expire on me
15:06:40 <Eighth_Doctor> oh crap
15:06:42 <sgallagh> OK, so aside from my concern about Igor himself, we are also effectively short a FESCo member, given his absence.
15:06:48 <Eighth_Doctor> I forgot about that
15:07:13 <mhroncok> I've messaged ignatenkobrain on telegram. if he doesn't reply soon, I'll try to call him
15:07:40 <decathorpe> sgallagh: when are the F34 elections?
15:07:48 <Eighth_Doctor> he hasn't responded via Telegram for a while for me :(
15:07:55 * cverna I have to go afk, thanks everyone o/
15:07:56 <mhroncok> since we are pretty operational, I don't think we need to rush any actions
15:08:05 <decathorpe> cverna++
15:08:41 <decathorpe> yeah, I don't think we need to rush anything
15:09:13 * nirik agrees
15:10:14 <decathorpe> alright, unless there's anything else, I'll close the meeting in 2
15:12:11 <zbyszek> decathorpe: thanks for chairing
15:13:10 <decathorpe> #endmeeting