16:00:23 <sgallagh> #startmeeting ELN (2023-05-19)
16:00:23 <zodbot> Meeting started Fri May 19 16:00:23 2023 UTC.
16:00:23 <zodbot> This meeting is logged and archived in a public location.
16:00:23 <zodbot> The chair is sgallagh. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:23 <zodbot> The meeting name has been set to 'eln_(2023-05-19)'
16:00:23 <sgallagh> #meetingname eln
16:00:23 <zodbot> The meeting name has been set to 'eln'
16:00:23 <sgallagh> #topic init process
16:00:38 <bstinson> \o
16:00:55 <yselkowitz[m]> .hello yselkowitz
16:00:56 <zodbot> yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
16:01:04 <davide> .hello dcavalca
16:01:05 <zodbot> davide: dcavalca 'Davide Cavalca' <davide@cavalca.name>
16:01:17 <tdawson> Howdy
16:01:19 <sgallagh> .hi
16:01:20 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:01:37 <michel> .hello salimma
16:01:38 <zodbot> michel: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
16:03:03 <sgallagh> #topic Agenda
16:03:26 <sgallagh> #info Agenda Item: Status of the ELN compose and rebuilds
16:03:54 <sgallagh> Does anyone have any other topics to bring up?
16:04:18 <bstinson> i have a short topic about tags in discourse
16:04:42 <sgallagh> OK then
16:04:51 <sgallagh> #topic Status of the ELN compose and rebuilds
16:05:07 <sgallagh> #info Compose is working again since yesterday.
16:05:20 <sgallagh> The issue we were dealing with was, for a change, not our fault!
16:05:52 <sgallagh> There's been some wild instability with the ODCS system for the last few weeks. I think it's been sorted out now, but there's a chance we will still have to deal with occasional outages.
16:07:04 <yselkowitz[m]> #info dropped ~70 SRPMs from runtime set and another ~200 from the buildroot in the last two weeks
16:07:06 <sgallagh> So today is the first time in about a week that Content Resolver has been able to update with the latest minimization changes.
16:07:14 <sgallagh> #chair yselkowitz
16:07:14 <zodbot> Current chairs: sgallagh yselkowitz
16:07:22 <sgallagh> Could you rerun that # info?
16:07:25 <yselkowitz[m]> #info dropped ~70 SRPMs from runtime set and another ~200 from the buildroot in the last two weeks
16:07:30 <sgallagh> Thanks
16:07:49 <sgallagh> We're headed in the right direction, it seems.
16:08:30 <sgallagh> yselkowitz: Could you provide a quick update on the rust situation for the meeting record?
16:08:40 <yselkowitz[m]> sure
16:09:13 <yselkowitz[m]> RHEL rust-based packages use vendored deps rather than installed packages
16:09:50 <yselkowitz[m]> so I've been filing PRs for those rust-based packages that we actually want in RHEL to use vendoring, thereby dropping their dynamic BRs from ELN buildroot
16:10:17 <yselkowitz[m]> some upstreams package their own vendor tarballs, which simplifies things, but in many cases they do not
16:10:43 <yselkowitz[m]> so some maintainers have preferred to maintain vendoring changes in eln branch rather than rawhide
16:11:17 <michel> eln branch might be a better idea anyway? IIRC the best practice for Fedora rust packaging is to regenerate the spec each release
16:11:20 <yselkowitz[m]> the potential downside is that the branch will need to be maintained separately from rawhide, but much better that than importing hundreds of unwanted packages into c10s
16:11:27 <michel> so any change you made will just get blown over each time
16:11:47 <yselkowitz[m]> these are going in through PRs, so if the maintainer accepts them, then great
16:11:54 <yselkowitz[m]> and a few have been accepted into rawhide
16:12:16 <yselkowitz[m]> but any where there are hesistations or lack of response will likely end up in eln branches
16:12:47 <michel> yeah... I wonder if the maintainers who accept the PR thought about what would happen at the next update though
16:12:49 * decathorpe is here
16:13:06 <decathorpe> (I can answer any Rust related questions if there are any)
16:13:20 <yselkowitz[m]> not all rust packages regenerate their spec files with each release
16:13:41 <yselkowitz[m]> and if dynamic buildrequires creep back in, then we'll deal with it
16:13:43 <sgallagh> Fabio Valentini: One thing I've wanted to ask: is there any way we could automate converting the Rawhide build to the vendored ELN build?
16:13:52 <sgallagh> That seems like it would be the ideal situation.
16:14:09 <decathorpe> yselkowitz[m]: basically all Rust packages for *crates* do, because it's necessary. packages for Rust projects that are *not crates* don't need to regenerate for every version
16:14:27 <decathorpe> sgallagh: it depends on the kind of package, I guess.
16:14:53 <decathorpe> for Rust crates we could just have a different spec template in rust2rpm for ELN / RHEL
16:15:13 <decathorpe> for packages that are not *crates* but just happen to have Rust code it's not always that simple to "convert"
16:15:23 <sgallagh> Tell me more about this rust2rpm idea?
16:15:43 <decathorpe> https://pagure.io/fedora-rust/rust2rpm/blob/main/f/rust2rpm/templates/crate.spec
16:15:48 <decathorpe> is the template for Rust packages
16:15:51 <michel> aha, right. for the ones shipped in RHEL presumably most will be 'apps' (not library crates)?
16:15:59 <decathorpe> we could have another one that uses vendored dependencies
16:16:25 <yselkowitz[m]> #link https://github.com/fedora-eln/eln/issues/124
16:16:59 <yselkowitz[m]> apps and a couple C libraries
16:18:07 <sgallagh> Fabio Valentini: So it sounds like that won't really help with the packages RHEL really cares about.
16:18:32 <decathorpe> yes, it won't help with librsvg2 for example
16:18:41 <tdawson> I need to verify my rust terminology.  I thought crates were just the libraries.  So for ELN we are trying to remove the crates.  Why do we need rust2rpm for crates if that is what we are trying to remove?
16:18:58 <yselkowitz[m]> some apps are distributed as crates
16:19:11 <tdawson> Ahh ... ok, so it's more than just the libraries.
16:19:18 <tdawson> Thanks, that makes sense to me now.
16:19:25 <decathorpe> exactly - for the applications that are distributed as crates, rust2rpm a RHEL-y template would help
16:19:34 <decathorpe> for the applications that use a different build system, it obviously won't
16:20:28 <decathorpe> either way, I'd be open to adding support for that to rust2rpm, even if it wouldn't help for all packages
16:20:50 <yselkowitz[m]> that would be welcome
16:21:18 <davide> Yeah having done the vendoring dance by hand many times, being able to automate this would be a lot nicer
16:21:21 <yselkowitz[m]> in the meantime, I suppose that means we should assume eln branches for the remaining app crates at a minimum
16:21:41 <sgallagh> Probably a reasonable assumption
16:21:59 <yselkowitz[m]> we'll need releng help to branch some unresponsive packages
16:22:29 <yselkowitz[m]> but once complete that should knock out another ~600 SRPMs from buildroot
16:23:05 <sgallagh> Excellent
16:24:39 <yselkowitz[m]> #info creating eln branches for vendoring deps in rust-based RHEL packages
16:25:04 <yselkowitz[m]> #info that will help drop ~600 SRPMs from ELN buildroot
16:25:26 <yselkowitz[m]> anything else wrt rust?
16:26:19 <yselkowitz[m]> ok, then the other big dep chain is in the python ecosystem
16:26:56 <yselkowitz[m]> in many cases, it's a matter of disabling docs and/or tests to avoid unwanted deps
16:27:35 <yselkowitz[m]> I'm getting closer to chopping off a major branch from the dep tree
16:28:10 <yselkowitz[m]> which includes ipython->pandoc->ghc-*
16:28:52 <yselkowitz[m]> but experience is show that it's hard to predict when I'll finally get that cleanly out
16:28:57 <yselkowitz[m]> *showing
16:29:41 <sgallagh> In the current term, disabling tests and docs is the right move. Long-term, we might want to look into vendoring the build-systems for the docs at least.
16:29:56 <yselkowitz[m]> #info still working on unwanted python build deps
16:30:00 <yselkowitz[m]> #link https://github.com/fedora-eln/eln/issues/125
16:30:07 <yselkowitz[m]> #link https://github.com/fedora-eln/eln/issues/115
16:31:16 <yselkowitz[m]> even if they were built would they be shipped in RHEL though?
16:31:48 <sgallagh> Unlikely
16:32:25 <yselkowitz[m]> in many cases there are already bconds present to disable docs/tests, just a matter of defaulting to off for RHEL/ELN builds
16:33:17 <sgallagh> Ack
16:34:13 <davide> Should we encourage packagers to make these conditional in the packaging guidelines?
16:34:51 <sgallagh> Good question. That's probably worth bringing up with the Packaging Committee
16:35:06 <sgallagh> I don't think we have a rule on it at present, but it sure would make a lot of things easier.
16:35:33 <davide> Yeah, I try to do it on mine but sometimes it's a bit of a chore
16:35:45 <michel> I'm pretty sure we don't, having looked at the Python packaging guideline just yesterday
16:36:21 <davide> I'm a bit wary about not running tests for rhel builds. Won't that potentially lead to broken packages if eg one misses a dependency?
16:36:29 <michel> in practice the packages that are also in EPEL do have this, but would be nice to have official recommendation -- e.g. there's a bootstrap macro I think?
16:36:49 <sgallagh> Davide Cavalca: Generally, the tests get run in CI and by QA in RHEL
16:37:03 <michel> with bootstrap I think the idea is you build once without tests, then package the test packages, then rebuild. otherwise it's chicken and egg
16:37:26 <bstinson> on the RHEL side (for the docs we ship specifically), it's perfectly acceptable to pre-generate and include in the lookaside
16:37:33 <sgallagh> Bootstrap is used for many things.
16:37:43 <sgallagh> Most notably compilers
16:37:49 <michel> nods
16:38:03 <michel> oh, so we could even put this in the non-Python general guidelines
16:38:11 <yselkowitz[m]> bootstrap also modifies the dist-tag though
16:38:13 <sgallagh> Right, I think that would be better
16:38:19 <yselkowitz[m]> so it's not for general use
16:38:42 <sgallagh> We have a commonly-used pattern of %bcond tests 1 that could be made officially recommended.
16:39:04 <michel> that's... the same as %bcond_without tests ? Just more readable I guess
16:39:15 <michel> the without/with always confuses me if I have not used it for some time
16:39:21 <sgallagh> Michel Alexandre Salim: Yes, the format you just used is deprecated in RPM
16:39:24 <yselkowitz[m]> note that %bcond is relatively new, only supported in RHEL 9.2+ iirc?
16:39:36 <sgallagh> It should work on RHEL 8, I thought?
16:39:37 <michel> Stephen Gallagher: alhamdulillah
16:39:51 <yselkowitz[m]> was it backported to 8?
16:40:03 <sgallagh> Time for a password-change, Michel Alexandre Salim ?
16:40:24 <michel> in practice for Python packages, the EL8 branch has diverged anyway because it can't use dynamic requirements so ... it should not matter
16:40:39 <michel> sgallagh: haha. nah that's a joke. that just means thank goodness in Arabic
16:41:17 <sgallagh> yselkowitz: I remembered incorrectly. It indeed will only work in Fedora right now
16:41:39 <michel> :(
16:41:56 <sgallagh> Actually it DID get added to RHEL 9.2
16:42:02 * sgallagh checks RHEL 8.
16:42:23 <sgallagh> Nope. But we can at least rely on it for EPEL 9
16:44:58 <sgallagh> Does anyone want to volunteer to bring the %bcond-for-docs/tests  proposal up to the Packaging Committee?
16:45:35 <michel> when is that meeting? need to check my calendar
16:45:47 <michel> (if no one else wants to do it and I can make it, sure)
16:46:42 <sgallagh> Well, start with a ticket on the FPC issue-tracker.
16:47:01 <sgallagh> Just bringing it up at a meeting won't give people adequate time to consider.
16:47:35 <michel> oh of course
16:47:41 <decathorpe> Filing a ticket is a good way to get it ignored ;) but I will tag it accordingly so that doesn't happen
16:48:14 <michel> looks like I can make the meetings, so yeah I can file a ticket
16:48:19 * michel doesn't want to be a no-show if and when it actually gets discussed
16:48:38 <sgallagh> #action Michel Alexandre Salim to propose `%bcond`s for docs and tests as packaging best practices to the FPC
16:50:13 <tdawson> Don't want to take over the agenda, but I think bstinson said he had a quick topic.
16:51:11 <sgallagh> No problem. I was just about to move us to Open Floor
16:51:32 <sgallagh> bstinson: You have something for us?
16:51:42 <bstinson> yes! a small bikeshed to paint
16:52:23 <bstinson> #topic ELN and CentOS Stream tags in discussion.fp.o
16:52:23 <michel> Stephen Gallagher Fabio Valentini https://pagure.io/packaging-committee/issue/1281
16:52:28 <michel> we can discuss / add details later after bstinson
16:53:00 <sgallagh> #topic ELN and CentOS Stream tags in discussion.fp.o
16:53:28 <bstinson> we'll have changes going on in ELN that we want to make that we want to be transparent about as we head toward CentOS Stream 10
16:53:42 <bstinson> a previous example is for the x86_64-v3 baseline bump that we did
16:53:58 <bstinson> I'd like to start posting on discussion.fedoraproject.org but we don't have ELN specific tags there
16:54:05 <bstinson> https://discussion.fedoraproject.org/t/how-to-request-a-new-team-tag-or-a-team-workflows-subcategory/35557/16
16:54:26 <bstinson> ^i've requested them here, if someone has other thoughts please jump in
16:54:54 <sgallagh> Ah, I think I missed that notification
16:55:44 <sgallagh> I don't see anything controversial about doing that.
16:56:00 <michel> lgtm
16:57:14 <bstinson> davide: this is not exactly the contributable release-notes idea you had, but following these 2 tags can help folks notice new and exciting features
16:58:12 <bstinson> that's it from me this week :)
16:58:25 <davide> Nice, thank you
16:59:17 <davide> Only thing from me is that I'll be at devconfcz and will be giving a talk about what we're doing with ELN at Meta
17:00:11 <sgallagh> ooo
17:00:53 <sgallagh> That will be cool to see
17:01:12 <sgallagh> #info Davide Cavalca will be presenting on Meta's use of ELN at Devconf.cz
17:01:21 <sgallagh> And with that, we are over time.
17:01:31 <sgallagh> Does anyone have any urgent last-minute topics?
17:02:39 <sgallagh> Alright, thank you everyone for coming
17:02:43 <sgallagh> #endmeeting