<@zbyszek:fedora.im>
17:01:08
!startmeeting FESCO (2025-01-07)
<@meetbot:fedora.im>
17:01:09
Meeting started at 2025-01-07 17:01:08 UTC
<@meetbot:fedora.im>
17:01:10
The Meeting name is 'FESCO (2025-01-07)'
<@zbyszek:fedora.im>
17:01:13
!meetingname fesco
<@meetbot:fedora.im>
17:01:13
The Meeting Name is now fesco
<@zbyszek:fedora.im>
17:01:17
Chairs: @conan_kudo:matrix.org, @ngompa:fedora.im, @nirik:matrix.scrye.com, @humaton:fedora.im, @zbyszek:fedora.im, @sgallagh:fedora.im, @fale:fale.io, @dcantrell:fedora.im, @decathorpe:fedora.im, @salimma:fedora.im
<@zbyszek:fedora.im>
17:01:24
!topic Init Process
<@nirik:matrix.scrye.com>
17:01:37
morning
<@conan_kudo:matrix.org>
17:01:40
!hi
<@zbyszek:fedora.im>
17:01:40
!hi
<@dcantrell:fedora.im>
17:01:42
!hi
<@zodbot:fedora.im>
17:01:43
Zbigniew Jędrzejewski-Szmek (zbyszek)
<@zodbot:fedora.im>
17:01:43
Neal Gompa (ngompa) - he / him / his
<@zodbot:fedora.im>
17:01:44
David Cantrell (dcantrell) - he / him / his
<@humaton:fedora.im>
17:01:51
!hi
<@zodbot:fedora.im>
17:01:52
Tomáš Hrčka (humaton) - he / him / his
<@zbyszek:fedora.im>
17:02:05
We even have quorum.
<@zbyszek:fedora.im>
17:02:45
OK, I think we can start the discussion.
<@zbyszek:fedora.im>
17:02:51
If people join, they can review the log.
<@zbyszek:fedora.im>
17:02:56
!topic #3304 Change: Intel SGX Software Stack
<@zbyszek:fedora.im>
17:02:56
!fesco 3304
<@zbyszek:fedora.im>
17:03:23
Hmm, so the multiline paste is not supported by zodbot again?
<@zbyszek:fedora.im>
17:03:28
!fesco 3304
<@zodbot:fedora.im>
17:03:29
● **Opened:** 3 weeks ago by amoloney
<@zodbot:fedora.im>
17:03:29
**fesco #3304** (https://pagure.io/fesco/issue/3304):**Change: Intel SGX Software Stack**
<@zodbot:fedora.im>
17:03:29
<@zodbot:fedora.im>
17:03:29
● **Last Updated:** 55 minutes ago
<@zodbot:fedora.im>
17:03:29
● **Assignee:** berrange
<@salimma:fedora.im>
17:03:34
!hi
<@zodbot:fedora.im>
17:03:37
Michel Lind (salimma) - he / him / his
<@nirik:matrix.scrye.com>
17:03:39
you can't do topic and more lines I think is the bug
<@berrange:matrix.org>
17:03:57
!hi
<@zodbot:fedora.im>
17:03:59
Daniel Berrangé (berrange)
<@sgallagh:fedora.im>
17:04:09
!hi
<@zodbot:fedora.im>
17:04:10
Stephen Gallagher (sgallagh) - he / him / his
<@zbyszek:fedora.im>
17:04:15
danpb: Thanks for joining on the short notice.
<@zbyszek:fedora.im>
17:04:53
We had two +1 votes in the ticket.
<@zbyszek:fedora.im>
17:05:00
Folks who had doubts, please speak up.
<@nirik:matrix.scrye.com>
17:05:14
I just somehow missed this one, I'm +1.
<@sgallagh:fedora.im>
17:05:19
Hi danpb, thanks for coming.
<@sgallagh:fedora.im>
17:06:07
I know in the past, there was a similar feature that we denied because we had no realistic way of testing it, because all testing required access to the vendor's keys. If that's not the case here, I have no remaining issues.
<@berrange:matrix.org>
17:06:57
not sure what you mean by access to the vendor's keys, but everything in my linked copr repo can be tested by any Fedora user with suitable HW
<@sgallagh:fedora.im>
17:07:38
I mean that it wasn't possible to run our compiled software at all if it hadn't been signed by the hardware vendor
<@sgallagh:fedora.im>
17:07:55
There was no "insecure mode" allowing us to test things without a round-trip to the vendor.
<@berrange:matrix.org>
17:08:57
well this proposal is primarily requesting to treat SGX architectural enclaves as firmware, so we wouldn't be compiling them, unless going for the academic exercise of proving reproducibility
<@conan_kudo:matrix.org>
17:11:30
I don't think most folks in Fedora would consider that a reasonable request
<@sgallagh:fedora.im>
17:11:32
From our perspective, would it look any different (or require special consideration) to install an OS in such an enclave?
<@conan_kudo:matrix.org>
17:12:05
Nitro enclaves don't require this kind of weirdness, for example
<@sgallagh:fedora.im>
17:12:18
Conan Kudo: Please refrain from putting words in others' mouths.
<@berrange:matrix.org>
17:12:22
an enclave is not something you install an OS into - it is a execution context for small bits of code - typically individual functions
<@conan_kudo:matrix.org>
17:13:06
that's not true
<@berrange:matrix.org>
17:13:07
also note we're not talking about all enclaves - *exclusively* the architectural enclaves, which are the low level part that establishes the root of trust to the HW
<@conan_kudo:matrix.org>
17:13:14
an enclave is a secondary computer that can do _anything_
<@sgallagh:fedora.im>
17:13:18
OK, I'll admit I have a very poor understanding of how this works. (Clearly)
<@berrange:matrix.org>
17:13:32
the architectural enclaves are conceptually "firmware" for SGX
<@conan_kudo:matrix.org>
17:13:36
it's purely limited by how much you can store there
<@salimma:fedora.im>
17:13:58
For comparison - how big a footprint are we talking about, and how does it compare to say nvidia’s “firmware” for its open source drivers?
<@conan_kudo:matrix.org>
17:14:08
and enclaves do not have to be small, that's why we're having this discussion about SGX in the first place
<@salimma:fedora.im>
17:14:47
SGX will still be more open than that anyway, as @danpb noted we can rebuild to prove reproducibility if we need
<@berrange:matrix.org>
17:14:50
a enclave still runs in ring-3, so can't do "anything" - and communication with the enclave needs a special call mechanism initiated from OS code, not the reverse
<@salimma:fedora.im>
17:15:35
(I’m already +1 but a size comparison might help assuage concerns or put this in context)
<@berrange:matrix.org>
17:15:37
Conan Kudo: again, we're not talking about everything that *application* enclaves could do - i'm only proposing that the *architectural* encalves are treated as firmware
<@conan_kudo:matrix.org>
17:16:07
but can we fix anything? we are ultimately responsible for the code we deliver, the reproducibility argument is academic only because even if we find a flaw, we can't do anything about it
<@salimma:fedora.im>
17:16:28
That’s the same with firmware issues though
<@berrange:matrix.org>
17:16:34
that's true of all firmware we ship
<@salimma:fedora.im>
17:16:42
We can fix by rolling back a botched version
<@zbyszek:fedora.im>
17:16:53
sgx-enclave-prebuilt-pce-signed-2.25-1.fc42.x86_64.rpm 2024-Nov-15 17:48:04 933.04K RPM File
<@zbyszek:fedora.im>
17:16:53
sgx-enclave-prebuilt-tdqe-signed-2.25-1.fc42.x86_64.rpm 2024-Nov-15 17:48:02 880.94K RPM File
<@zbyszek:fedora.im>
17:16:53
sgx-enclave-prebuilt-qe3-signed-2.25-1.fc42.x86_64.rpm 2024-Nov-15 17:48:06 892.32K RPM File
<@zbyszek:fedora.im>
17:16:53
sgx-enclave-prebuilt-ide-signed-2.25-1.fc42.x86_64.rpm 2024-Nov-15 17:48:05 90.33K RPM File
<@zbyszek:fedora.im>
17:17:09
(This is from the copr.)
<@conan_kudo:matrix.org>
17:17:36
we've never accepted shipping pre-built things that we can actually build though
<@conan_kudo:matrix.org>
17:17:41
not even for firmware
<@salimma:fedora.im>
17:17:47
Thanks, I’m still on my phone (running late)
<@salimma:fedora.im>
17:18:18
If we can build but can’t run that seems functionally equivalent as not being able to build
<@berrange:matrix.org>
17:18:21
most firmware will still require a vendor signature to be trusted by the HW on load, so we'd be in the same scenario there
<@salimma:fedora.im>
17:18:26
It’s like ftbfs vs fro
<@conan_kudo:matrix.org>
17:18:45
not really, we could easily attach a signature back for an artifact we build
<@zbyszek:fedora.im>
17:18:57
Because of the signing, for all intents and purposes, sgx enclave code behaves like firmware.
<@fale:fale.io>
17:19:01
I think one of the question is what "we can actually build" means in this context. Does the loose of a feature (due to the signing outside the Intel certs chain) make it rebuildable or not?
<@conan_kudo:matrix.org>
17:19:15
the fact we don't do that for secure boot artifacts is a quirk of our own infrastructure, it's not impossible
<@salimma:fedora.im>
17:19:23
We don’t really want to adopt the maximalist FSF position here do we 🫠
<@berrange:matrix.org>
17:19:29
you can't attach a signature unless what we built was identical to the original firmware payload
<@zbyszek:fedora.im>
17:19:41
We can introspect it and do test builds, but to actually use it on real hardware, we need the exact binary blessed by upstream.
<@salimma:fedora.im>
17:20:41
Is that a decent compromise?
<@salimma:fedora.im>
17:20:41
Require a rebuild and gate the release of a new version to having an identical or small enough delta to the signed blob, once the signature is stripped
<@salimma:fedora.im>
17:20:41
<@zbyszek:fedora.im>
17:21:14
The Change page tries to answer that question…
<@berrange:matrix.org>
17:21:31
NB, new releases could involve new toolchain versions, so gating releases on rebuilds could delay issuing of CVE updates
<@berrange:matrix.org>
17:21:50
because the update could get blocked behind new package review process
<@conan_kudo:matrix.org>
17:21:57
then maybe Intel should bless _our_ builds
<@sgallagh:fedora.im>
17:22:28
Conan Kudo: That seems unrealistic.
<@sgallagh:fedora.im>
17:22:39
(Intel is having a hard time delivering its own stuff these daysP
<@conan_kudo:matrix.org>
17:22:41
it is only if we don't push for this
<@sgallagh:fedora.im>
17:22:43
(Intel is having a hard time delivering its own stuff these days)
<@decathorpe:fedora.im>
17:22:54
!hi
<@zodbot:fedora.im>
17:22:55
Fabio Valentini (decathorpe) - he / him / his
<@decathorpe:fedora.im>
17:23:02
(sorry, was stuck in a phone call)
<@conan_kudo:matrix.org>
17:23:02
improving the freedom of our systems comes only if we push for it
<@berrange:matrix.org>
17:23:05
fyi, i've spent over a year discussing this with intel and its not going to happen i'm afraid
<@zbyszek:fedora.im>
17:23:18
I don't think that's accurate. Compat packages don't require review. It'd be better to say that it might require a lot of packaging work to have the tools in the appropriate version. (As the Change page says.)
<@conan_kudo:matrix.org>
17:23:26
if we don't even try as a project, then we're not doing a good job for our community
<@berrange:matrix.org>
17:23:31
unless our build is 100% byte-for-byte identical to the official build
<@berrange:matrix.org>
17:23:54
at which point "signing" our buld just involves sending us the original pre-built enclaves they already ship
<@sgallagh:fedora.im>
17:24:01
Conan Kudo: Effort we know is wasted isn't doing anyone any favors
<@conan_kudo:matrix.org>
17:24:07
can you get them to publicly tell us why they think only they should be offering SGX firmware?
<@conan_kudo:matrix.org>
17:24:55
that is not only uncalled for, but there are so many examples against that it isn't even funny
<@sgallagh:fedora.im>
17:24:58
Conan Kudo: It seems pretty self-explanatory: the whole purpose is to ensure that they're the sole source of trust and it can't be replaced by anyone in the middle
<@conan_kudo:matrix.org>
17:25:04
samba, nvidia, rdp, etc.
<@berrange:matrix.org>
17:25:33
Conan Kudo: the goal of SGX is to allow software to establish that it is running on genuine Intel hardware and that requires a chain of trust back to Intel's root CA for SGX
<@sgallagh:fedora.im>
17:25:39
Conan Kudo: That's not wasted effort, because actual deliverables come from those efforts.
<@salimma:fedora.im>
17:25:43
I’m not sure how samba and rdp is relevant here
<@salimma:fedora.im>
17:26:02
Those are just reverse engineering and surely we can’t do that for sgx
<@berrange:matrix.org>
17:26:04
that eliminates the OS vendor specific signatures as a viable option
<@conan_kudo:matrix.org>
17:26:11
they are both closed standards that took a lot of pushback and effort to make open
<@conan_kudo:matrix.org>
17:26:39
both smb and rdp have been published standards with open implementations precisely because of pushback
<@berrange:matrix.org>
17:26:44
so the only other option would be for intel to verify and sign OS vendor's builds, like microsoft does for vendor's shim builds
<@conan_kudo:matrix.org>
17:26:54
that's what I want to see, yes
<@berrange:matrix.org>
17:27:35
and they don't consider it acceptable from a security POV to have a huge number of distinct signed builds all built with slightly different toolchanis
<@zbyszek:fedora.im>
17:27:49
Realistically, I think that spending huge maintainer effort on this would be counterproductive. With all due respect for Dan's work, I don't expect more than a handful of enthusiasts to use this on Fedora. The proposed approach provides a reasonable benefits without creating a crazy amount of work for each package update.
<@conan_kudo:matrix.org>
17:28:11
whatever
<@conan_kudo:matrix.org>
17:28:33
I think there's a security benefit in this, but we're going to disagree on this point
<@conan_kudo:matrix.org>
17:28:57
regardless, my vote is still -1, I'm backing out of this discussion because it's going in circles
<@fale:fale.io>
17:29:03
is this decision also going to potentially impact other softwares or is SGX-only?
<@sgallagh:fedora.im>
17:29:24
Shall we call a vote and see if we have agreement one way or the other at this point?
<@fale:fale.io>
17:29:41
(ie: will other different software be able to make the claim "it was ok for SGX, so why not for xyz"?)
<@salimma:fedora.im>
17:29:41
SGX only
<@berrange:matrix.org>
17:29:58
fyi, personally i would really like it if intel would sign OS vendor's builds, but having explored that option for over a year, i'm pretty certain it won't ever happen
<@salimma:fedora.im>
17:30:10
But presumably others could try putting up similar proposals and this is sort of a precedent for evaluating those
<@salimma:fedora.im>
17:30:27
Jinx
<@berrange:matrix.org>
17:30:30
Fale: anyone else would have to justify why their software meets the 'firmware exception'
<@conan_kudo:matrix.org>
17:30:48
it's not hard to do if everyone keeps using the coprocessor argument
<@salimma:fedora.im>
17:30:51
Stepping out for 5 mins but I already voted
<@zbyszek:fedora.im>
17:30:55
Yeah, they'd need to put a CPU model and a foundry first, so I wouldn't worry that much.
<@sgallagh:fedora.im>
17:30:57
Proposal: The Change is accepted.
<@sgallagh:fedora.im>
17:31:05
+1, based on this conversation
<@dcantrell:fedora.im>
17:31:09
+1
<@conan_kudo:matrix.org>
17:31:12
-1
<@zbyszek:fedora.im>
17:31:18
+1
<@fale:fale.io>
17:31:26
0 = I'm not fully convinced on the ramifications
<@nirik:matrix.scrye.com>
17:31:34
+1
<@decathorpe:fedora.im>
17:31:36
0
<@humaton:fedora.im>
17:31:45
0
<@sgallagh:fedora.im>
17:32:12
Michel Lind 🎩 UTC-6 was +1
<@sgallagh:fedora.im>
17:32:39
I count (+5, 3, -1).
<@zbyszek:fedora.im>
17:32:43
!agreed APPROVED (+5, 3, -1)
<@zbyszek:fedora.im>
17:33:20
danpb++ thanks for coming.
<@zodbot:fedora.im>
17:33:22
zbyszek gave a cookie to berrange. They now have 1 cookie, 1 of which was obtained in the Fedora 41 release cycle
<@berrange:matrix.org>
17:33:23
thank you all for the debates !
<@zodbot:fedora.im>
17:33:30
sgallagh gave a cookie to berrange. They now have 2 cookies, 2 of which were obtained in the Fedora 41 release cycle
<@zbyszek:fedora.im>
17:33:32
danpb:
<@sgallagh:fedora.im>
17:33:48
danpb: Thanks for putting up with my ignorant questions :)
<@zbyszek:fedora.im>
17:34:17
!topic #3317 Change: Automated Packit Onboarding
<@zbyszek:fedora.im>
17:34:20
!fesco 3317
<@zodbot:fedora.im>
17:34:21
<@zodbot:fedora.im>
17:34:21
**fesco #3317** (https://pagure.io/fesco/issue/3317):**Change: Automated Packit Onboarding**
<@zodbot:fedora.im>
17:34:21
● **Opened:** 23 hours ago by amoloney
<@zodbot:fedora.im>
17:34:21
● **Assignee:** lbarczio
<@zodbot:fedora.im>
17:34:21
● **Last Updated:** 2 hours ago
<@zbyszek:fedora.im>
17:34:47
I didn't have time to read the discussion…
<@sgallagh:fedora.im>
17:35:16
I feel like most of the opposition here boils down to misunderstanding what "opt-out" means in this context.
<@zodbot:fedora.im>
17:35:25
salimma gave a cookie to berrange. They now have 3 cookies, 3 of which were obtained in the Fedora 41 release cycle
<@salimma:fedora.im>
17:35:55
Even a PR being done by default would be just wrong for a subset of packages though
<@salimma:fedora.im>
17:36:03
Like Rust and golang
<@dcantrell:fedora.im>
17:36:08
I don't want to have to continually opt-out. Like will PRs come every 6 months or so and I have to re-opt-out?
<@sgallagh:fedora.im>
17:36:11
Michel Lind 🎩 UTC-6: Sure, which is why it's a merge request and not an automatic push
<@fale:fale.io>
17:36:18
I'm +1 on this, as long as the text is very clear on potential issues and it is one PR in the lifetime of the package, and only applies to new packages
<@sgallagh:fedora.im>
17:36:24
dcantrell: As I understand it, it's only for new package additions
<@decathorpe:fedora.im>
17:36:32
not every packager is experienced enough to know that this is footgun-as-a-service
<@salimma:fedora.im>
17:36:42
Yeah but that would confuse new contributors to a space
<@decathorpe:fedora.im>
17:36:44
which is why I would like to have the PR creation opt-in
<@conan_kudo:matrix.org>
17:36:45
I think being done by default is going to be wrong for a long time to come
<@salimma:fedora.im>
17:36:48
As Fabio said
<@conan_kudo:matrix.org>
17:37:01
we are missing too many pieces to give packagers the opportunity to make informed choices from packit PRs
<@salimma:fedora.im>
17:37:10
I will be plus one if they make the fedpkg flag opt in
<@sgallagh:fedora.im>
17:37:12
As Fale says, I'd like to require that the MR description be very verbose about the possible risks
<@nirik:matrix.scrye.com>
17:37:16
see also: https://discussion.fedoraproject.org/t/f42-change-proposal-automated-onboarding-to-packit-release-automation-for-new-packages-system-wide/139530/25
<@sgallagh:fedora.im>
17:37:23
I think that's sufficient warning about the proverbial "foot-gun"
<@salimma:fedora.im>
17:37:43
And I also would like to see more options about what branches get pushed by packit, presumably as fedpkg options
<@zbyszek:fedora.im>
17:37:44
I don't think this is a fair statement. A PR is just a PR. Maintainers need to evaluate PRs.
<@conan_kudo:matrix.org>
17:37:50
we lack reverse dependency checks, we lack reverse dependency test rebuilds, we lack compatibility verification
<@conan_kudo:matrix.org>
17:38:04
without these things, those PRs are just asking for trouble
<@salimma:fedora.im>
17:38:16
Also - license audit, esp when vendoring is involved
<@decathorpe:fedora.im>
17:38:20
reverse installability check would be the minimum I would require for this to be enabled by default
<@sgallagh:fedora.im>
17:38:24
Agreed: if they blindly accept bad merge requests, that's something we should probably try to find out early.
<@salimma:fedora.im>
17:38:35
I’m a big packit fan and I only judiciously turn it on
<@conan_kudo:matrix.org>
17:38:36
that already happens now with opt-in packit
<@conan_kudo:matrix.org>
17:38:43
that was a complaint from both python and rust folks
<@sgallagh:fedora.im>
17:39:07
Conan Kudo: What, specifically?
<@conan_kudo:matrix.org>
17:39:12
we want to use packit with kde and we _can't_ because of this
<@sgallagh:fedora.im>
17:39:14
I'm not sure which comment you were replying to there
<@conan_kudo:matrix.org>
17:39:38
"blindly accept bad [pull] requests"
<@conan_kudo:matrix.org>
17:40:06
and some people even configure packit to automerge and build on rawhide
<@decathorpe:fedora.im>
17:40:49
hm, I thought auto-merge + auto-build was explicitly not possible?
<@conan_kudo:matrix.org>
17:40:50
we don't give people the tools to make the right calls with packit PRs
<@salimma:fedora.im>
17:41:15
Uh… example?
<@salimma:fedora.im>
17:41:24
Pretty sure merges are manual
<@conan_kudo:matrix.org>
17:41:33
I think python-dbusmock and anaconda are managed this way
<@conan_kudo:matrix.org>
17:41:38
same for cockpit too, IIRC
<@salimma:fedora.im>
17:41:43
Auto build was one of my concern, I would not want to see the default be anything but rawhide
<@conan_kudo:matrix.org>
17:42:24
the containers tooling stuff is like this too IIRC
<@zbyszek:fedora.im>
17:42:26
If there's a maintainer who doesn't understand what they are doing, that needs to change. Or they need to stop being a maintainer. Trying to prevent bad changes by some arbitrary limitations on how those changes are introduced doesn't seem helpful at all.
<@zbyszek:fedora.im>
17:42:26
I find this discussion very strange. It's trivially easy to push a commit that doesn't work using a local workflow: just edit the version number, add sources, push, build. With a PR we at least get a scratch build and some zuul checks.
<@zbyszek:fedora.im>
17:42:26
<@salimma:fedora.im>
17:42:37
That sounds like custom automation though?
<@salimma:fedora.im>
17:42:46
I’d be ok with a policy banning that
<@conan_kudo:matrix.org>
17:42:55
zbyszek: the problem is that if a robot does it, there is no one to teach
<@salimma:fedora.im>
17:42:58
A human must be responsible for code changes
<@conan_kudo:matrix.org>
17:43:09
computers cannot be held accountable
<@sgallagh:fedora.im>
17:43:21
Michel Lind 🎩 UTC-6: I don't think that's enforceable
<@sgallagh:fedora.im>
17:43:31
Or practical, really
<@conan_kudo:matrix.org>
17:44:09
it has to be, since we have no protection for bad builds/pushes
<@sgallagh:fedora.im>
17:44:14
In the case of e.g. Cockpit, they have (for example) such a rigorous upstream commit review and testing policy that I'm perfectly happy trusting them to push changes automatically and build in Fedora.
<@decathorpe:fedora.im>
17:44:47
the problem with bot-created updates is when *things go wrong* though. nobody gets bodhi notifications, for example.
<@salimma:fedora.im>
17:44:48
I’m all for automation to help. But a packager must at least either author or review surely?
<@conan_kudo:matrix.org>
17:44:51
and on the flipside, I have no trust for the containers projects because they do regularly break things without qualification
<@fale:fale.io>
17:45:01
I think there are three different issues: 1. are maintainer evaluating properly the PRs? 2. have people set up automation to auto-merge? 3. Should packit open a PR for every new package to "offer" its services? I think this ticket is only about number 3
<@sgallagh:fedora.im>
17:45:07
Michel Lind 🎩 UTC-6: A packager authored the automation...
<@conan_kudo:matrix.org>
17:45:12
and nobody knows until its too late because it's all done by bots
<@zbyszek:fedora.im>
17:45:21
We already allow pulls to be opened automatically (e.g. via packit) and used. The proposed change just makes it easier to have those pull requests opened. It's still up to the maintainers to a) accept the packit config, b) merge the prs.
<@salimma:fedora.im>
17:45:26
That feels like too much indirection
<@salimma:fedora.im>
17:45:44
FWIW I’m ok granting exceptions to those who prove the processes are safe like cockpit
<@salimma:fedora.im>
17:45:47
But by default?
<@conan_kudo:matrix.org>
17:45:56
Fale: it's also about making fedpkg turn it on by default
<@fale:fale.io>
17:45:57
my understanding is that fedup should not block packit to open the PR by default
<@conan_kudo:matrix.org>
17:46:08
turning it on for everything now, and in the future on by default
<@conan_kudo:matrix.org>
17:46:28
with how things work now, it's a hard "no" from me
<@salimma:fedora.im>
17:46:39
Yeah, points 1 and 2 are relevant because of the opt out nature of the proposal
<@salimma:fedora.im>
17:46:52
We are thus discussing whether it’s even safe
<@sgallagh:fedora.im>
17:47:01
All of the oppositional arguments sound like they're boiling down to "I don't trust our packagers to review the merge requests".
<@sgallagh:fedora.im>
17:47:13
Which... that seems like a MUCH bigger problem than this Change.
<@zbyszek:fedora.im>
17:47:14
No, not by default. The change page says:
<@zbyszek:fedora.im>
17:47:14
> Performing Koji builds and Bodhi updates automatically after merging the updates by the maintainer.
<@zbyszek:fedora.im>
17:47:25
I.e. the maintainer has to make the merge.
<@conan_kudo:matrix.org>
17:47:27
and I question whether it will ever become safe given recent announcements from the teams managing automation saying they have no time for Fedora
<@salimma:fedora.im>
17:47:33
it’s not that, it’s that for some SIG packages opt out would just be wrong by default
<@decathorpe:fedora.im>
17:47:41
I don't trust *all* packages to *always* know that they're doing. that's a different thing.
<@decathorpe:fedora.im>
17:47:59
I don't trust _all_ packages to _always_ know what they're doing. that's a different thing.
<@decathorpe:fedora.im>
17:48:22
(counting myself in that list, ftr)
<@sgallagh:fedora.im>
17:48:52
I think I missed those announcements. They'd be news to me, since my new role as of Jan 1st is to try to unify the automation in Fedora, CentOS Stream and Red Hat more so they can share effort.
<@sgallagh:fedora.im>
17:49:01
I think I missed those announcements. They'd be news to me, since my new role at Red Hat as of Jan 1st is to try to unify the automation in Fedora, CentOS Stream and Red Hat more so they can share effort.
<@nhanlon:beeper.com>
17:49:19
my opinion is I like the idea but gives me a lot of pause
<@conan_kudo:matrix.org>
17:49:29
there was an announcement from the OSCI team a while back saying that they will not be putting any efforts into Fedora and concentrating on CentOS/RHEL for the foreseeable future
<@zbyszek:fedora.im>
17:49:40
Which SIGs would like to opt out completely? Rust?
<@conan_kudo:matrix.org>
17:49:57
KDE would completely opt out
<@conan_kudo:matrix.org>
17:50:03
Packit is unsafe for the KDE stack
<@salimma:fedora.im>
17:50:17
And the problem is we can’t use globs to determine the opt out
<@conan_kudo:matrix.org>
17:50:24
not being revdep aware makes it dangerous
<@sgallagh:fedora.im>
17:50:24
Conan Kudo: That was overstated; that should have read closer to "we're going into maintenance mode until the new forge is in place".
<@salimma:fedora.im>
17:50:29
Not all Rust packages start with rust for example
<@decathorpe:fedora.im>
17:50:38
yes - using packit without a custom config is unsafe for Rust packages (rust-*)
<@zbyszek:fedora.im>
17:50:39
OK, so should be ask for the default behaviour for `fedpkg` to be dependent on the package type? E.g. "no" for `rust-*`, `kde-*` or something like that?
<@salimma:fedora.im>
17:50:57
Well, if only it’s that simple
<@salimma:fedora.im>
17:51:07
Why don’t ask them to make this opt in for at least one release
<@sgallagh:fedora.im>
17:51:17
Well, we could definitely conditionalize some *known* cases easily enough
<@salimma:fedora.im>
17:51:19
What’s the rush?
<@nirik:matrix.scrye.com>
17:51:28
what would 'opt in' look like that it's not currently?
<@sgallagh:fedora.im>
17:51:40
But yeah, given the pushback, I suppose I can be on board with asking them to take another Fedora cycle to polish the idea
<@decathorpe:fedora.im>
17:51:43
(I'm hoping that with dynamically generated specparts that restriction can be lifted for most Rust packages in the future, but that's ... ***far*** future, given that our spec files need to support RHEL 9)
<@sgallagh:fedora.im>
17:51:46
And ask again then
<@conan_kudo:matrix.org>
17:51:46
I would have been fine if it was just adding a flag to `fedpkg request-repo` that allows initializing a repo with packit enabled
<@salimma:fedora.im>
17:51:50
Have fedpkg request repo has a flag or several to also configure packit
<@conan_kudo:matrix.org>
17:52:16
even to this day, we don't auto-onboard everything to koschei
<@conan_kudo:matrix.org>
17:52:22
and it's been 8 years
<@salimma:fedora.im>
17:52:28
(I’d say requesting packit builds for stable branches should be a second flag )
<@sgallagh:fedora.im>
17:52:30
Proposal: Ask that they switch to opt-in on fedpkg for Fedora 42 and revisit opt-out as an option for Fedora 43.
<@fale:fale.io>
17:52:38
+1
<@zbyszek:fedora.im>
17:52:44
Stephen Gallagher: +1
<@conan_kudo:matrix.org>
17:52:51
Stephen Gallagher: +1
<@salimma:fedora.im>
17:52:53
+1
<@humaton:fedora.im>
17:52:57
+1
<@decathorpe:fedora.im>
17:52:59
+1
<@nirik:matrix.scrye.com>
17:53:28
I suppose... +1
<@dcantrell:fedora.im>
17:53:50
+1
<@zbyszek:fedora.im>
17:54:59
"!agreed The proposal is approved with the modification that it's just opt-in for F42. For switch to opt-out can be proposed for F43." OK?
<@salimma:fedora.im>
17:55:24
"For switch" -> Switching
<@sgallagh:fedora.im>
17:56:11
Proposed: !info FESCo also requests that the Packit team investigate conditionalizing for known problematic packages such as rust-* to be excluded from future opt-out.
<@zbyszek:fedora.im>
17:56:19
!agreed The proposal is approved with the modification that it's just opt-in for F42. Switching to opt-out can be proposed for F43 (+9, 0, 0)
<@zbyszek:fedora.im>
17:56:32
!info FESCo also requests that the Packit team investigate conditionalizing for known problematic packages such as rust-* to be excluded from future opt-out.
<@zbyszek:fedora.im>
17:56:46
Phew.
<@zbyszek:fedora.im>
17:56:52
!topic Meeting time
<@zbyszek:fedora.im>
17:57:10
Are we all OK with not changing the time?
<@fale:fale.io>
17:57:38
I'm ok. I would prefer a time with DST to have constant time through the year but it's ok even without DST 🙂
<@sgallagh:fedora.im>
17:58:30
DST changes depending on your locale, so that's impossible.
<@fale:fale.io>
17:59:06
Italy
<@nirik:matrix.scrye.com>
17:59:11
This time is okish. I'd prefer an hour later, but I know others don't, so sticking with this is fine.
<@sgallagh:fedora.im>
17:59:23
Fale: Out of curiosity, where are you located?
<@zbyszek:fedora.im>
17:59:48
!info FESCo meetings will reuse the same time slot
<@salimma:fedora.im>
17:59:55
for US-EU meetings not following daylight saving seems a decent compromise
<@salimma:fedora.im>
18:00:14
if we follow DST, which one, and also it makes the meetings either permanently late for EU or permanently early for US :)
<@salimma:fedora.im>
18:00:28
following UTC means half the year it's early for US and half the year it's late for EU :p
<@zbyszek:fedora.im>
18:00:51
OK, I think we're mostly in agreement that it's acceptable. Let's move on.
<@zbyszek:fedora.im>
18:00:55
!topic Next week's chair
<@sgallagh:fedora.im>
18:00:59
For West Coast US, yeah. Less terrible for those of us on the good coast ;-)
<@sgallagh:fedora.im>
18:01:20
I can run the meeting next week
<@zbyszek:fedora.im>
18:01:39
!action Stephen Gallagher will chair the next meeting
<@zbyszek:fedora.im>
18:01:43
!topic Open Floor
<@zodbot:fedora.im>
18:01:49
decathorpe has already given cookies to sgallagh during the F41 timeframe
<@sgallagh:fedora.im>
18:01:58
I have a topic
<@zbyszek:fedora.im>
18:02:09
!info The mass rebuild is supposed to start next Wednesday.
<@zbyszek:fedora.im>
18:02:13
Stephen Gallagher: go
<@sgallagh:fedora.im>
18:03:38
First, I'd like to formally apologize for my screw-up when writing the Devel announcement draft about the provenpackager issue. Naming him directly was bad form and I didn't consider it properly at the time.
<@nirik:matrix.scrye.com>
18:04:12
We are all (except not Fale to blame. ;(
<@decathorpe:fedora.im>
18:04:30
Yeah, that's not just on you though. We should have noticed this before it was sent out.
<@nirik:matrix.scrye.com>
18:05:03
I was going to ask if we should look at writing up a policy... or just wait until the council comes back.
<@salimma:fedora.im>
18:05:06
yeah... as nirik said. even those of us who did not think it might be a good idea did not catch it in time
<@zbyszek:fedora.im>
18:05:16
Did we send out the summary that was being prepared for the council?
<@dcantrell:fedora.im>
18:05:21
wait until the council is done investigating this issue
<@sgallagh:fedora.im>
18:05:35
Not that I have seen.
<@zbyszek:fedora.im>
18:05:45
Right, so we should do that.
<@decathorpe:fedora.im>
18:05:59
the HackMD doc has the current state, and I think I addressed all comments
<@nirik:matrix.scrye.com>
18:06:00
Note: the FPL is on the fesco list. So he should have anything mentioned there.
<@sgallagh:fedora.im>
18:06:07
That was going to be the rest of this topic: I realize that the Council has decided to weigh in here.
<@sgallagh:fedora.im>
18:06:40
I think I missed the HackMD doc (I went on PTO about an hour after the announcement got sent and only got back to a computer yesterday). I'll look for it in my email history.
<@decathorpe:fedora.im>
18:06:53
it's linked from the fesco ticket.
<@sgallagh:fedora.im>
18:06:57
OK, thanks
<@zbyszek:fedora.im>
18:08:02
So… let's say one final day for review and on Thursday we send it out to the council?
<@sgallagh:fedora.im>
18:08:09
I kind of want to draft an announcement reminding people of the expected behavior of a provenpackager, but I worry that doing so *right now* would come across as accusatory.
<@dcantrell:fedora.im>
18:08:30
please don't. wait for the council to finish their investigation first
<@zbyszek:fedora.im>
18:08:30
I was thinking about an announcement like that too. I think we should do it.
<@zbyszek:fedora.im>
18:08:50
dcantrell: Why is that related?
<@decathorpe:fedora.im>
18:09:11
I'd rather not put fuel onto a fire that has thankfully died down to embers over the holidays
<@nirik:matrix.scrye.com>
18:09:12
There is already some more discrussion today on pp stuff
<@sgallagh:fedora.im>
18:09:20
I'll look at it this afternoon.
<@dcantrell:fedora.im>
18:09:24
anything we send now to the community related to this incident before the council has weighed in will just restart the mega thread from December
<@dcantrell:fedora.im>
18:09:26
we don't need to do that
<@zbyszek:fedora.im>
18:10:31
Meh. OK.
<@dcantrell:fedora.im>
18:11:30
I'd also like to add here that I felt like the fallout from this fell on me. I know that's not right, but it certainly felt that way because we dumped the announcement "with the trash" on a Friday and then everyone seemingly vanished. I started getting direct messages asking what is going on and aside from posting the one message apologizing for FESCo's actions, I asked council to take over and do an investigation.
<@dcantrell:fedora.im>
18:11:44
TL;DR, this was not how I wanted to wrap up 2024 :)
<@salimma:fedora.im>
18:12:11
it felt heaviest on Josh I feel, as the initial messenger
<@salimma:fedora.im>
18:12:35
but yeah, sorry for any trouble that fell your way dcantrell
<@decathorpe:fedora.im>
18:12:47
I think none of us did ...
<@sgallagh:fedora.im>
18:14:32
I think we can all agree that we did not handle this particularly well. We'll need to learn from it.
<@nirik:matrix.scrye.com>
18:14:55
Definitely.
<@decathorpe:fedora.im>
18:16:05
there are some docs that definitely need a refreshening, and it would probably be a good idea to put some more formalized process into place for removing people from pp / packager groups . right now it's only vaguely mentioned as "something that FESCo can make happen"
<@nirik:matrix.scrye.com>
18:16:35
yes, sadly we need a policy.
<@zbyszek:fedora.im>
18:16:46
We also have https://pagure.io/fesco/fesco-docs/pull-request/94 unfinished
<@zbyszek:fedora.im>
18:17:24
Anyhow… any other topics?
<@decathorpe:fedora.im>
18:17:54
please no 😅
<@zbyszek:fedora.im>
18:17:55
If not, I'll end the meeting in a minute.
<@zbyszek:fedora.im>
18:18:15
After a short minute:
<@zbyszek:fedora.im>
18:18:16
!endmeeting