17:00:47 <sgallagh> #startmeeting FESCO (2022-05-31)
17:00:47 <zodbot> Meeting started Tue May 31 17:00:47 2022 UTC.
17:00:47 <zodbot> This meeting is logged and archived in a public location.
17:00:47 <zodbot> The chair is sgallagh. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:47 <zodbot> The meeting name has been set to 'fesco_(2022-05-31)'
17:00:47 <sgallagh> #meetingname fesco
17:00:48 <zodbot> The meeting name has been set to 'fesco'
17:00:48 <sgallagh> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, mboddu, tstellar, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:00:48 <sgallagh> #topic init process
17:00:48 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mboddu mhroncok nirik sgallagh tstellar zbyszek
17:01:02 <dcantrell> .hello2
17:01:04 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
17:01:14 <decathorpe> .hello2
17:01:15 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
17:01:18 <sgallagh> .hi
17:01:19 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:22 <zbyszek> .hello2
17:01:22 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
17:01:53 <nirik> morning
17:02:06 <zbyszek> afternoon
17:02:23 <sgallagh> We have quorum, but I'll wait another minute or two for any stragglers.
17:03:51 <sgallagh> OK, I suppose we can get started.
17:04:14 <sgallagh> There are two topics for discussion today, both of them likely to take a while to go through. Any preference on the order?
17:04:32 <sgallagh> SPDX Licensing and static JDK are the two proposals
17:05:37 <zbyszek> The chairman's choice.
17:05:57 <sgallagh> Alright, let's start with JDK, since that's targeted at F37
17:06:19 <sgallagh> #topic F37 Change proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib
17:06:46 <zbyszek> I think the first part of the tri-part proposal (i.e. what this ticket is about), is OK.
17:06:55 <nirik> yeah, same here.
17:06:58 <tstellar> .hello tstellar
17:06:59 <zodbot> tstellar: tstellar 'Tom Stellard' <tstellar@redhat.com>
17:07:00 <nirik> sadly, but I understand the need
17:07:11 <sgallagh> For the logs, can you summarize?
17:07:28 <zbyszek> Our guidelines say that it's within maintainers' prerogatives to bundle things if appropriate, and in this case it seems to be so.
17:07:31 <sgallagh> .fesco 2794
17:07:32 <zodbot> sgallagh: Issue #2794: F37 Change proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib - fesco - Pagure.io - https://pagure.io/fesco/issue/2794
17:08:40 <zbyszek> sgallagh: was this for nirik or me?
17:08:58 <sgallagh> I'm personally wary of the sheer amount of bundling going on, but not enough to dispute the maintainers.
17:09:16 <sgallagh> zbyszek: Either, and thank you for answering it.
17:09:48 <sgallagh> I thought you had meant this Change itself was tri-part, but you meant this WAS the first part of three Changes
17:10:15 <zbyszek> Yeah, it's not ideal… but if upstream is against something, with a behemoth like java it's just so much work to fight it.
17:10:30 <zbyszek> sgallagh: yes, sorry for being unclear.
17:10:55 <sgallagh> No problem, I just wanted to make sure I understood (as did anyone who reads these minutes later)
17:11:40 <dcantrell> as others have said, I'm also not generally a fan of the bundling but if this is the way the java ecosystem works, it's probably better to have it working than not working
17:11:42 <mboddu> .hello mohanboddu
17:11:43 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
17:12:38 <nirik> I'm not sure we specifically asked change owners what they would think of us accepting the first of these and rejecting the others.
17:12:38 <decathorpe> Personally, I feel like some other suggestions on the devel list for reducing the workload for packaging OpenJDK on Fedora have been acknowledged, but basically ignored, which kind of leaves the bad taste of "this has already been decided" in my mouth
17:12:38 <sgallagh> My primary wariness is around zlib, libjpeg, giflib and libpng which all have high rates of CVEs
17:12:55 <sgallagh> But as Java is backed by a megacorp, they probably keep up on that fairly well.
17:12:59 <sgallagh> (I would hope, anyway)
17:13:10 <dcantrell> I doubt they do, actually
17:13:19 <dcantrell> but again, we're just guessing/assuming
17:13:26 <dcantrell> decathorpe: what other suggestions in general?
17:14:04 <decathorpe> reducing the number of OpenJDK versions that are available in parallel, or not backporting new LTS versions to older Fedora branches
17:14:09 <dcantrell> a bundling concern I do have is what happens if we approve this for JDK (and it's large)....where do we then draw the line on no bundling?
17:14:25 <tstellar> Do I understand correctly that upstream builds the way they are proposing for Fedora.
17:14:54 <zbyszek> Re: reducing the number of versions, I think Jiri gives a comprehensive reply in e80c0a41-cadc-aeb3-00f8-0595b0c65623@redhat.com
17:14:55 <sgallagh> tstellar: I believe so, yes
17:14:56 <dcantrell> decathorpe: ah, yes.  my understanding there was that the multiple versions being available is more useful to Java devs than not.
17:15:03 <decathorpe> dcantrell: I think we lost the bundling battle a long time ago, with librsvg2, 389-ds, rpm-ostree, etc.
17:15:12 <sgallagh> zbyszek: Bad link
17:15:19 <dcantrell> decathorpe: *sigh*, true
17:15:26 <zbyszek> It's not a link, it's a Message-ID;)
17:16:02 <sgallagh> Doesn't help
17:16:08 <dcantrell> are the change owners proposing using the library source that comes with the JDK or bundling using static libs available in Fedora?
17:16:17 <dcantrell> that's unclear to me
17:16:42 <sgallagh> In this Change, using the Fedora libs
17:16:49 <zbyszek> .link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FDQLBR37GMYW6L42ZCLYEMG5465CF3XQ/
17:16:57 <sgallagh> The further Changes in their plans differ, and I don't like it.
17:16:57 <dcantrell> ok, then that puts us in a better position wrt CVEs
17:16:58 <zbyszek> #info https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FDQLBR37GMYW6L42ZCLYEMG5465CF3XQ/
17:17:17 <tstellar> Oh, I thought they were using in-tree for everything except libstdc++.
17:17:23 <sgallagh> Oh, I misstated that.
17:17:41 <sgallagh> right, sorry. I was just about to correct that
17:18:13 <dcantrell> oh
17:18:34 <dcantrell> (brb)
17:19:52 <sgallagh> I just had a really outlandish idea: what if we made OpenJDK a buildroot-only package and advised people to use the official releases for runtime? (Or provided an easy method to get it, like we do for nVidia drivers and Chrome)?
17:20:33 <sgallagh> So stuff IN Fedora would be able to build against it, but would run against the certified versions.
17:20:33 <zbyszek> Please no. I find it very useful to run various java scientific programs using the packaged JDK. I don't want to deal with some upstream shite.
17:21:14 <decathorpe> That ignores the fact that some programs we ship need a JRE.
17:21:17 <smooge> things built against it would need to have the JDK to work.
17:21:18 <tstellar> sgallagh: I was thinking something similar, but I think it's too hard to communicate that to users.
17:21:33 <smooge> sorry a JRE
17:21:41 <sgallagh> Eh, it was just an idle thought.
17:22:57 <tstellar> I think it would be good to get some input from the Fedora libstdc++ maintainers about this.
17:23:04 <nirik> so, should we vote on this one, and/or should we tell change owners the others are not getting great support?
17:23:44 <sgallagh> Is anyone on FESCo in favor of https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs as a whole?
17:24:05 <sgallagh> Because if the answer to that is "no", then they may not even bother with this step.
17:24:41 <zbyszek> Hmm, I don't think this implication is true.
17:24:54 <zbyszek> I'm leaning towards +1 on the first step, and it's useful without the other ones.
17:25:02 <sgallagh> I said "may" for a reason :)
17:25:10 <tstellar> So is the long-term  plan to have a single rpm for all Fedora releases?
17:25:36 <sgallagh> tstellar: Yes, and one that is actually just shipping the pre-compiled upstream binaries.
17:25:43 <dcantrell> (ok, back now)
17:25:47 <sgallagh> Which is the part I am a "Hell No" on.
17:25:47 <zbyszek> If I understand Jiri's reasoning, this first step should reduce the number of test failures, and the other steps are designed to reduce the number of test runs. Both would be independently useful to some extent.
17:26:13 <zbyszek> sgallagh: hmm, are you sure?
17:26:26 <sgallagh> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Make_the_normal_rpms_to_not_built_jdk.2C_but_to_repack_the_portable_rpms_with_all_integration
17:26:31 <tstellar> sgallagh: They want to just ship upstream binaries?  So, wouldn't that make this first proposal obselete in the future?
17:26:39 <nirik> I think it's two rpms per stream... one that builds it for F(stable) and one that just includes the built version for all the releases
17:27:09 <zbyszek> "It is also not a goal, to pack third party blob. Jdk will still continue to build in koji as it should. " ← sgallagh
17:27:09 <sgallagh> Actually, rereading that, I think they may just be carrying the contents from another Fedora build.
17:27:16 <sgallagh> Which seems... wasteful
17:27:22 <nirik> well, more... One building on oldest fedora and One per Fedora inculding that build x each stream
17:28:34 <sgallagh> We're coming up on 30 minutes on this topic. Do we want to continue or take it back to the list for a week?
17:28:44 <dcantrell> ok, reading in to this more, I do not like their plan for tzdata or cacerts
17:29:27 <dcantrell> like this:  "This is actually cauisng buggy behavior - in some corenrcase - when tzdata in system are so much newer, jdk is not ready for them."
17:29:34 <dcantrell> to which I ask "what?"
17:29:42 <zbyszek> I think another week of discussion would be OK. Ideas are still being floated.
17:29:44 <dcantrell> how is the JDK tzdata in a different format?
17:29:57 <dcantrell> yeah, another week of discussion
17:30:07 <mboddu> +1 to another week of discussion
17:30:33 <jwboyer> the thread seems to have died out.  it's in a repetitive loop of "we don't like bundling".  what is another week going to accomplish?
17:31:03 <nirik> The only thing I can think of is to ask if the first step is worth doing if the others aren't accepted.
17:31:11 <sgallagh> The bundling is excessive, but I can live with that part if it's sufficiently marked in the specfile/Provides
17:31:30 <decathorpe> nirik: +1, because I don't think the follow-up change is going to be accepted.
17:31:33 <dcantrell> the bundling doesn't just cover libs either, if the tzdata and cacerts parts are included.  how necessary is that?
17:32:11 <sgallagh> dcantrell: It's unclear if the tzdata and cacerts were part of this specific Change
17:32:16 <sgallagh> We should get clarity on thast
17:32:18 <tstellar> Is the bundling of tzdata proposed in this proposal or a future proposal?
17:32:23 <sgallagh> s/thast/that/
17:32:26 <zbyszek> tstellar: future
17:32:50 <sgallagh> Actually, cacerts is explicitly excluded from this. See "non goal" in the Change page.
17:32:52 <dcantrell> as described, it feels like it would need to happen in order to achieve the final goal, but still unclear
17:32:59 <zbyszek> jwboyer: OK, you have a point. The last mail in the thread is from the 29th.
17:33:27 <zbyszek> I'm changing my vote to +1.
17:33:57 <dcantrell> sgallagh: it's noted as a non-goal, but the lower section suggests it should use both the system cacerts and the bundled ones
17:33:59 <dcantrell> so....
17:34:18 <tstellar> I would really like if for change proposals like this that are large and complex if the feeback section had comments from other experts (e.g. libstdc++ maintainer talking about implictations of static linking).
17:34:28 <sgallagh> dcantrell: I think you may be looking at the end-goal page, not the Change page.
17:34:36 <dcantrell> tstellar: +1
17:34:46 * dcantrell checks browser tabs
17:34:52 <sgallagh> https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic (this Change) vs https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs (the big picture)
17:34:53 <dcantrell> sgallagh: you may be right
17:34:57 <jwboyer> as a suggestion, if you're going to ask further questions you should ask the Change owners what their plan is if the overall approach is rejected.  they seemed pretty clear in the discussion that they can't sustain the current packaging solution.
17:35:50 <smooge> jwboyer, +1
17:37:30 <decathorpe> Can we ask them in the FESCo ticket? I don't think bringing this back to the mailing list is worth it.
17:37:48 <dcantrell> yes we can, we are fesco
17:39:18 <sgallagh> I feel like making tests less flaky is a worthwhile goal. Being able to run them less frequently seems like the sort of problem best solved by throwing hardware at it.
17:40:21 <nirik> well, I asked that... and they said it was more the fixing/dealing with failed things that was the timesync
17:41:17 <sgallagh> I can't imagine it saves that much time, since presumably those failures are still going to happen on the older release.
17:41:31 <decathorpe> Side note: I wonder if java-*-openjdk packages should be protected like grub2 and shim, given that we apparently can't ship builds that pass a supersecret test suite?
17:41:38 <smooge> I think there are 2 different time holes going on. One is that the TCK certification has a level of 'mother may i' with an outside organization which looks over things and asks for changes. The other is local failure/problems
17:42:30 <zbyszek> I'd imagine that it's like the OpenQA tests that AdamW manages: *any* change in the environment may cause minor details to change, leading to failures of tests.
17:42:51 <zbyszek> For this, using the exact same versions of libs as upstream just makes things easier.
17:43:57 <nirik> decathorpe: but unlike secure boot signing we don't have any way to know when the tests pass... and I guess TCK 'releases' are considered stable updates... so pushing non tested to testing while the tests run is what they do now? and only push to stable on passing.
17:44:22 <zbyszek> Either upstream makes the effort to make the testsuite portable, proactively tests with different versions of libraries and tools in different distros, or the testsuite becomes bound to some specific versions of dependencies. It seems java does the latter.
17:44:42 <tstellar> Similar to what sgallagh suggested, maybe we could just convince upstream to build RPMs and have their own repo and we could just add that to the default repos in Fedora.
17:44:56 <zbyszek> tstellar: but how is that better for us?
17:45:30 <zbyszek> Right now we can do updates and local patches and other integration on *our* terms.
17:45:35 <sgallagh> zbyszek: We get to ship Java-based packages without the extreme overhead of maintaining a JDK?
17:45:53 <sgallagh> (I'm not really advocating for it, but you asked)
17:46:01 <zbyszek> But that applies to pretty much anything. Why do we ship gnome, instead of downloading stuff from jhbuild?
17:46:28 <sgallagh> That's kind of an unfair comparison.
17:46:48 <sgallagh> GNOME isn't actively hostile to distro packaging the way that Java and some other languages are.
17:47:15 <decathorpe> tstellar:I'd rather have no JDK in Fedora than do that.
17:47:17 <tstellar> zbyszek: Because they want to deviate significantly from Fedora packaging standards to be more like upstream.  It seems like we can save a lot of work by just going with upstream builds.
17:48:36 <tstellar> I'm not necessarily advocating for this, but it seems like a valid option considering their desired endstate.
17:49:32 <zbyszek> I disagree. I think we're better off with some bundling (and even some of the steps discussed in the bigger proposal), then with having an upstream binary built on Ubuntu 11.04.
17:49:44 <jwboyer> so essentially reversing what we do with h264?
17:50:28 <zbyszek> E.g. there's the issue with harfbuzz/fonts. If we were to use upstream builds, we'd lose control over this entirely.
17:50:29 <nirik> sounds like yeah...
17:51:23 <smooge> again I think we need to talk with the proposers to see what their alternative is if the proposal is not approved.
17:51:54 <nirik> perhaps we could vote on the first step now? and continue on list with the other items?
17:52:08 <zbyszek> nirik: wfm
17:52:13 <sgallagh> OK, I'll start a formal vote on JUST this Change
17:52:40 <sgallagh> Proposal: FESCo approves the use of bundled libraries and static libstdc++ for building Java
17:52:50 <zbyszek> +1
17:52:56 <nirik> +1
17:53:08 <dcantrell> +1
17:53:14 <decathorpe> 0
17:53:38 <smooge> to be clear as outlined in this https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic proposal?
17:53:42 <sgallagh> +1 (weakly; I'm deferring to "maintainer knows best", despite reservations)
17:53:50 <sgallagh> smooge: No
17:54:02 <sgallagh> smooge: https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
17:54:07 <sgallagh> err, whoops
17:54:13 <sgallagh> Sorry, got those backwards.
17:54:19 <sgallagh> smooge: You were correct the first time
17:54:24 <tstellar> +1
17:54:25 <smooge> yeah..which is why I was asking :)
17:54:38 <zbyszek> Phew, you both had me scared for a moment there.
17:55:07 <smooge> I was getting confused on which parts so wanted to make sure people flaming this meeting in a couple of hours know which part to flame
17:55:10 <sgallagh> I count (+5, 1, -0). Motion passes
17:55:27 <sgallagh> #agreed FESCo approves the use of bundled libraries and static libstdc++ for building Java (+5, 1, -0)
17:55:32 <tstellar> I'm not a huge fan of this, but having seen the heroics done by firefox/chromium maintainers, I think it's good to be pragmatic and move closer to upstream especially for huge projects like this.
17:56:04 <sgallagh> Do we want to discuss the SPDX topic today or push it to next week? We're nearly at an hour already.
17:57:09 <decathorpe> Has the "will we be able to merge this to older branches as well" question been settled?
17:57:40 <sgallagh> I haven't been following it close enough to tell, TBH
17:57:59 <dcantrell> we discussed that question and there's no reason to prevent this on older branches.
17:58:12 <dcantrell> I don't know if the change proposal has been updated, but I can check
17:58:19 <zbyszek> dcantrell: it hasn't
17:58:21 <dcantrell> we can push this to next week though
17:58:25 <dcantrell> ok, I'll do that today
17:58:34 <nirik> there's 2 cases where it's unclear right? MIT and something else?
17:59:11 <dcantrell> nirik: ok, I will work through the proposal today and try to get things clarified
17:59:26 <zbyszek> dcantrell: could you also adjust the proposal to be explicit about the new format, i.e. give an example of a 'License:' line from a .spec file? Right now the proposal implies how this will look, but it's not stated outright.
17:59:38 <sgallagh> dcantrell: I think he means that the mapping is unclear.
17:59:38 <dcantrell> zbyszek: yes, I can do that
17:59:47 <sgallagh> Between the Fedora and SPDX representations
17:59:52 <dcantrell> yep, I can do that
17:59:57 <decathorpe> The only question I have is "how do I mark a package with License: MIT as "this is already SPDX and doesn't need to be converted again" :D
18:00:06 <nirik> sorry I meant that those cases are where we can't tell which the License is using...
18:00:47 <sgallagh> #topic #2799 F38 Change proposal: SPDX License Phase 1
18:00:50 <sgallagh> .fesco 2799
18:00:51 <zodbot> sgallagh: Issue #2799: F38 Change proposal: SPDX License Phase 1 - fesco - Pagure.io - https://pagure.io/fesco/issue/2799
18:00:53 <zbyszek> I think it'd also be nice to discuss what maintainers are supposed to do in the unclear cases. (IIUC, we accept the amgiguity, but it'd be better to have this spelled out.)
18:00:58 <sgallagh> (Since we are discussing it at least partly)
18:01:43 <dcantrell> yeah, that's reasonable.  I'll add that in today.
18:02:12 <zbyszek> dcantrell++
18:02:12 <zodbot> zbyszek: Karma for dcantrell changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:02:18 <sgallagh> #info We will revisit this topic next week once the proposal is updated.
18:02:29 <sgallagh> #action dcantrell to update the proposal
18:02:39 <sgallagh> #topic Next week's chair
18:03:12 <sgallagh> Bueller?
18:04:11 * sgallagh has a mental image of everyone checking their watches or otherwise refusing to meet my eyes
18:04:16 <tstellar> I can do it.
18:04:23 <sgallagh> Thanks
18:04:35 <sgallagh> #action tstellar will chair next meeting
18:04:40 <sgallagh> #topic Open Floor
18:04:53 <sgallagh> Anyone have a topic for Open Floor?
18:05:46 <sgallagh> OK, I'll take that as a no.
18:05:58 <sgallagh> Thanks for coming, folks. Have a good rest of your day.
18:06:01 <sgallagh> #endmeeting