20:00:14 <tdawson> #startmeeting EPEL (2021-09-15)
20:00:14 <zodbot> Meeting started Wed Sep 15 20:00:14 2021 UTC.
20:00:14 <zodbot> This meeting is logged and archived in a public location.
20:00:14 <zodbot> The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:14 <zodbot> The meeting name has been set to 'epel_(2021-09-15)'
20:00:14 <tdawson> #meetingname epel
20:00:14 <zodbot> The meeting name has been set to 'epel'
20:00:14 <tdawson> #chair nirik tdawson bstinson pgreco carlwgeorge michel dcavalca
20:00:14 <tdawson> #topic aloha
20:00:14 <zodbot> Current chairs: bstinson carlwgeorge dcavalca michel nirik pgreco tdawson
20:00:29 <tdawson> Hi nirik :)
20:00:43 <carlwgeorge> .hi
20:00:44 <zodbot> carlwgeorge: carlwgeorge 'Carl George' <carl@redhat.com>
20:00:46 <dcavalca> .hi
20:00:47 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
20:00:55 <tdawson> Hi carlwgeorge
20:01:10 <pgreco> hello!
20:01:11 <tdawson> Hi dcavalca
20:01:14 <tdawson> Hi pgreco
20:01:49 <rsc> .hello robert
20:01:50 <zodbot> rsc: robert 'Robert Scheck' <redhat@linuxnetz.de>
20:01:54 <anitazha> .hi
20:01:55 <zodbot> anitazha: anitazha 'None' <the.anitazha@gmail.com>
20:02:03 <tdawson> Hi rsc
20:02:06 <anitazha> oh boy i need to fix that
20:02:08 <tdawson> Hi anitazha
20:02:39 <tdawson> anitazha: Your a new name.  Are you here for something specific, or just lurking?
20:03:03 <anitazha> i am lurking for something specific. Davide has a topic i'm interested in
20:03:23 <tdawson> Sounds good ... welcome.
20:03:26 <carlwgeorge> anitazha: the 'None' happens if you have private checked off in accounts.fp.o
20:03:41 <carlwgeorge> took me a while to figure that out
20:04:12 <pgreco> let me try mine
20:04:13 <pgreco> .hi
20:04:14 <zodbot> pgreco: pgreco 'Pablo Sebastian Greco' <pablo@fliagreco.com.ar>
20:04:16 <anitazha> ah thanks! i would have burned a lot of time on that lol
20:04:39 <nirik> morning
20:04:56 <tdawson> Hi nirik ... you made it back in time
20:05:11 <tdawson> #topic Old Business
20:05:25 <tdawson> Lets start with epel-next
20:05:33 <tdawson> nirik carlwgeorge Any news this week?
20:07:02 <carlwgeorge> next goal is to make fedscm_admin aware of epel9-next, and block branch requests if the package is in c9s
20:07:44 <tdawson> Oohh ... so ... I can get my stuff branched even if I don't own it, if I do it quick?
20:07:49 <carlwgeorge> currently for epel8 and epel8-next, it looks at https://infrastructure.fedoraproject.org/repo/json/pkg_el8.json, which is generated from the imported rhel data
20:08:08 <ssmoogen> oh hi
20:08:14 <carlwgeorge> tdawson: no, right now it will fail because pkg_el9.json doesn't exist
20:08:14 <tdawson> Hi ssmoogen
20:09:15 <tdawson> bummer ... and ... not that I would do that ... again
20:09:19 <nirik> it might make sense to manually check packages for now and add this check later?
20:09:35 <carlwgeorge> right now our blindspot is if a package is in c8s but not rhel8 yet, we allow an epel8-next branch, when we probably shouldn't
20:10:05 <carlwgeorge> nirik: i suggested a "fail open" (allow if pkg_el$v.json is 404) but mboddu said no
20:10:29 <carlwgeorge> i'm working on a pr to have fedscm_admin check c9s compose metadata instead of that pkg json file
20:10:55 <nirik> we could also make it generate a pkg_el9s or something...
20:11:03 <nirik> but yeah, going aginst the real metadata is better
20:12:15 <carlwgeorge> i do have a question for the group.  it was suggested to me that we should also block epel9 branch requests based on c9s metadata, because if the package is in c9s it's probably coming to rhel9 in <=6 months, so the maintainer should be aware and have to ask for a manual override if they really absolutely have to have it short term.
20:12:59 <nirik> that seems reasonable
20:13:00 <carlwgeorge> i don't hate the idea, but the most technically correct approach would be strictly checking c9s for epel9-next, and rhel9 (when it exists) for epel9
20:13:36 <tdawson> carlwgeorge: It makes sense ... I'm sorta neutral.  Would it be hard to implement?
20:13:39 <carlwgeorge> in practical terms, that would mean we have to modify fedscm_admin again when rhel9 comes out
20:14:11 <carlwgeorge> not at all, really i just want input before i submit my pr.  it just determines how i set up my if statements.
20:14:15 <nirik> not many people need to update, so I don't think thats a big deal
20:14:26 <dcavalca> both approaches seem reasonable to me
20:15:03 <carlwgeorge> i.e. `if branch == 'epel9-next':` or `if branch.startswith('epel9'):`
20:15:10 <pgreco> I think I prefer c9s blocking everything
20:15:56 <carlwgeorge> looking ahead, our other problem will be we need to get a versioned symlink of https://composes.stream.centos.org/production/latest-CentOS-Stream/ so that way this still works after c10 comes out
20:16:13 <pgreco> question, what about "deprecated" packages?
20:16:14 <tdawson> Ya, if it's not a pain in the rear to implement, I'd say block on c9s.
20:16:33 <pgreco> I mean, rhel has stopped shipping packages in the past
20:16:58 <carlwgeorge> pgreco: i believe if it's deprecated it will disappear from the compose and be unblocked, so that should just work
20:17:19 <carlwgeorge> it doesn't now because the check is based on rhel packages that are deprecated but not removed
20:17:27 <pgreco> ack, good
20:17:29 <carlwgeorge> but the latest compose only has the latest rpms
20:18:08 <nirik> do note that we can override it when it's wrong... just don't want it to be wrong too much
20:18:36 <tdawson> carlwgeorge: oof ... I think the latest-CentOS-Stream/  stuff is on me.  I'll see if I can get that changed to latest-CentOS-Stream-9/
20:19:13 <carlwgeorge> tdawson: my hero
20:19:21 <tdawson> Ha!!
20:19:33 <dcavalca> tdawson: pls post an announcement when you do that, as it'll probably break folks that are mirroring it, like us :)
20:19:35 <carlwgeorge> i don't mind there being an unversioned one too, but fedscm_admin needs to match the major version
20:20:03 <tdawson> dcavalca: Ya ... that's the problem I'm worried about ... I/we should have seen that back when I/we were getting it setup.
20:20:48 <dcavalca> as long as folks know it's coming it should be fine
20:20:55 <tdawson> But, better to get it done now ... anyway, it's now on my list of stuff to; do.
20:22:14 <tdawson> carlwgeorge: I assume we can't make epel-release, or fedpkg-minimal until we are able to branch, correct?
20:23:00 <carlwgeorge> that i'm not sure about.  maybe we can override it for those.
20:23:15 <carlwgeorge> i'm not sure how the fedscm_admin override works
20:23:26 <nirik> ywell, fedpkg-minimal we should just tag in from epel8...
20:23:33 <nirik> but we need to make epel-release. ;)
20:23:49 <nirik> yeah, you can override it's checks... it just tells the admin you overrode it.
20:24:01 <carlwgeorge> i'll add epel-release to my agenda
20:24:08 <tdawson> My scratch build worked fine without either of them ... but I'd feel better with them (and epel-macros) in the build.
20:24:27 <tdawson> carlwgeorge: great.  Thanks.
20:25:02 <tdawson> Anything else for -next ?
20:25:06 <carlwgeorge> i think that's all i got for now
20:25:58 <tdawson> OK ... just letting people know I'm taking documentation off the agenda, except for a few wiki pages that I missed with re-direction, I think we're done with the conversion.
20:26:21 <dcavalca> thanks again for working on that tdawson
20:26:57 <tdawson> Badges, logo's, and mascott
20:27:13 <ssmoogen> burn the wiki?
20:27:31 <tdawson> ssmoogen: Yep ... though I'm doing it one page at a time.
20:27:41 * ssmoogen gets the kerosene
20:28:10 <tdawson> It sounds like, if we like the logo we have on our docs, that can be our logo.
20:28:31 <tdawson> https://docs.fedoraproject.org/en-US/epel/_images/epel-logo.svg
20:28:59 <tdawson> Are we ok with that?  Does anyone want to change it?
20:29:08 <dcavalca> +1
20:29:32 <tdawson> I'm +1 too
20:30:19 <pgreco> good! +1
20:30:25 <tdawson> If people are ok with it, I'd like a formal vote, so we can make t-shirts
20:30:27 <carlwgeorge> i was curious what it would look like if we removed the middle piece
20:30:29 <tdawson> or hats
20:30:39 * nirik is +1
20:31:33 <tdawson> carlwgeorge: I could do that, wouldn't be hard ... I just can't while I'm running a meeting :)
20:31:44 <tdawson> Want me to try that and we have the formal vote next week?
20:31:48 <carlwgeorge> yes please
20:31:59 <carlwgeorge> i can comment the same on the logo issue
20:32:10 <tdawson> OK, I'm fine with that.
20:32:56 <tdawson> carlwgeorge: Yep, put a comment in the issue, and we'll see how things look next week - https://pagure.io/design/issue/770
20:33:19 <maxamillion> .hello2
20:33:20 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
20:33:24 <tdawson> Hi maxamillion
20:33:26 <maxamillion> (super late, I know ... sorry)
20:33:38 * carlwgeorge waves at maxamillion
20:34:16 <maxamillion> \o
20:34:30 <tdawson> Moving on past the logo ...
20:35:03 <tdawson> Last week we talked about "CPE to staff EPEL work" ... but, I don't know that we had anything that needed to be brought up this week.
20:35:24 <tdawson> And I want to make sure we have time for whatever dcavalca has
20:35:40 <tdawson> dcavalca: Does your item deal with the SIG or it it more for Open Floor?
20:36:00 <dcavalca> tdawson: I think it's reasonable for packagers SIG
20:36:23 <tdawson> dcavalca: OK, I'll make sure we have plenty of time for that.
20:36:34 <dcavalca> thanks
20:37:02 <tdawson> Did we have any more (serious) questions about "CPE to staff EPEL work" ?
20:37:18 <tdawson> We can do the less serious ones on Open Floor.
20:37:27 * nirik has one small announcement for open floor.
20:38:18 <tdawson> I'm going to move on, so we have time
20:38:24 <tdawson> #topic EPEL-7
20:38:34 <tdawson> Anything for EPEL 7 this week?
20:38:59 <carlwgeorge> yes
20:39:09 <tdawson> carlwgeorge: Sure, what's up?
20:39:27 <carlwgeorge> i retired libev from epel7.  it's been in rhel7 for a long time with a higher nvr, so just a cleanup thing.
20:39:35 <carlwgeorge> and no missing -devel thankfully
20:39:56 <tdawson> Ya!!
20:40:27 <tdawson> Anything else?
20:40:27 <carlwgeorge> that's all on that, we can move on
20:40:37 <pgreco> just one note
20:40:46 <pgreco> 2 actually
20:40:58 <pgreco> 1, the issue we discussed about git-cola/python-qtpy
20:41:15 <pgreco> seems like this week it was solved on both epel7 and epel8, but in different formats
20:41:25 <pgreco> 7 bundling again, 8 with a separate package
20:41:47 <pgreco> and the other thing is what we want to do with the systemd macros that we discussed a few weeks ago
20:41:55 <tdawson> Cool
20:42:41 <nirik> if they are easy to add, we should add em to epel-rpm-macros...
20:42:56 <tdawson> Cool to the first part ... and what nirik said.
20:43:13 <tdawson> Though, make sure they have plenty of testing ... if you can find a package that uses them.
20:43:34 <tdawson> pgreco: Do you mind making a pull request on epel-rpm-macros ?
20:43:40 <pgreco> I have a PoC, that seems to be ok, I need to make it go through the proper channels
20:44:21 <tdawson> cool
20:45:07 <tdawson> Start getting it through the proper channels, and we'll see how it works out.
20:45:36 <tdawson> We're getting a little short on time, and dcavalca has been very patient .... so ...
20:45:44 <tdawson> #topic EPEL-Packaging-SIG
20:46:03 <tdawson> dcavalca go for it.
20:46:06 <dcavalca> so, as you might know, as part of Hyperscale we build the latest systemd for c8s
20:46:31 <dcavalca> upstream systemd is considering moving from their 3+ ssl implementations to openssl 3.0
20:46:38 <dcavalca> as that would cover everything they need and has a sane license
20:46:49 <dcavalca> now, obviously c8s isn't going to bump openssl to 3.0
20:47:03 <dcavalca> and I can't sensibly ship this as part of Hyperscale, as I'd have to rebuild half the distro
20:47:15 <dcavalca> Eighth_Doctor suggested we could ship a coinstallable openssl3 package in EPEL
20:47:24 <dcavalca> and then depend on that for the systemd builds in Hyperscale
20:47:34 <dcavalca> does that seems like a reasonable approach to y'all?
20:47:54 <carlwgeorge> yup, that's how i'd do it
20:48:10 <carlwgeorge> and many people will be happy to see a parallel openssl3 in epel8
20:48:13 <tdawson> Can it be done?  I usually trust Eighth_Doctor, so I'm assuming the answer is yes.  But if it can be done, I'd say ya, go for it.
20:48:31 <Eighth_Doctor> yes
20:48:32 <Eighth_Doctor> it can be done
20:48:33 <dcavalca> practically speaking, I'm assuming this would require a full package review, as it's a new package
20:48:34 <Eighth_Doctor> it's been done for gnutls before
20:48:37 <dcavalca> even if it's just for EPEL
20:48:37 <tdawson> And what carlwgeorge said.  I think alot of people would like that.
20:48:42 <Eighth_Doctor> and openssl too in the past
20:48:52 <Eighth_Doctor> dcavalca: if we do it before Rawhide has it, yes
20:48:58 <nirik> seems ok... but might be more work than you think...
20:49:02 <Eighth_Doctor> otherwise it'll fall under the versioned package guidelines
20:49:03 <dcavalca> security support for this will be "fun", I'm sure
20:49:16 <dcavalca> Eighth_Doctor: oh yeah, let's just wait for Rawhide, less work for everybody for sure
20:49:33 <nirik> hopefully thats not long...
20:49:44 <rsc> It's built, but not tagged in?
20:49:52 <Eighth_Doctor> I think it'd make sense to sync it with c9s
20:49:57 <dcavalca> https://lists.freedesktop.org/archives/systemd-devel/2021-September/046881.html is what I wrote on the systemd list in the meantime, in case you want the context there
20:50:03 <nirik> it's in a side tag right now, things are rebuilding against it.
20:50:04 <Eighth_Doctor> at the moment, c9s and F36/Rawhide should be in sync
20:50:10 <dcavalca> luckily for us, c9s already has 3.0 so it won't be a problem there
20:50:34 <Eighth_Doctor> yup
20:50:49 <Eighth_Doctor> once it's tagged in, we should be good to go
20:51:13 <Eighth_Doctor> then either dcavalca or I can branch it for epel8
20:51:56 <dcavalca> alright, sounds like we have a plan then
20:51:58 <nirik> well, you need it to be parallelable installable no?
20:52:06 <dcavalca> nirik: yes, definitely
20:52:14 <dcavalca> I'm hoping/assuming the .so won't conflict
20:52:45 <dcavalca> and nothing should depend on the CLI, so that we can just rename to openssl3
20:53:00 <pgreco> any idea how hard would it be to incorporate the parallel option into rawhide?
20:53:06 <rsc> 3 or 3.0?
20:53:29 <pgreco> with the right flags I mean
20:53:31 <nirik> well, I seem to recall someone saying it wasn't easy and thats why it didn't land in rawhide first... but I don't recall who or where.
20:53:41 <nirik> but worth a try. :)
20:54:13 <tdawson> Yep, definatly worth a try.
20:54:20 <carlwgeorge> quick observation, rawhide's openssl-libs uses `/usr/lib64/engines-1.1`, and c9s's uses `/usr/lib64/engines-3`, so they look different enough
20:54:27 <dcavalca> pgreco: my personal preference is to have all the logic in the rawhide specfile, but it'd going to depend on what the openssl maintainers want to do
20:54:48 <carlwgeorge> and considering the 3 in the path, it seems the package would track 3.x, not 3.0.x
20:54:57 <nirik> you can always submit a PR or ask them and see what they say
20:55:07 <pgreco> dcavalca: yeah, which won't be easy I think, but worth a shot
20:55:24 <dcavalca> yep, agreed
20:55:49 <tdawson> We're getting a little short on time, anthing else SIG related before we go to Open Floor?
20:56:10 <dcavalca> that's all I had on my end
20:56:22 <tdawson> #topic General Issues / Open Floor
20:56:29 <tdawson> nirik - you had something?
20:56:48 <nirik> I just had one quick announcement (which I also sent to the list): ansible-core is now in stream 9...
20:57:04 <tdawson> Ya!!
20:57:05 <ssmoogen> what is in "core" these days
20:57:25 <tdawson> Ha!!  ssmoogen beat me to the question. :)
20:57:32 <nirik> ansible-core is the engine... and some base modules/connection plugins, etc...
20:57:49 <ssmoogen> so ansible-playbook and ansible command?
20:57:50 <nirik> but lots of the other functionality that was in ansible (2.9/classic) is moved to collections...
20:58:13 <nirik> yes, and ssh connection plugins, etc... but not things like the rabbitmq module or acl module or such
20:58:51 <ssmoogen> ok understood.. when people say engines it sometimes means the libs and background and you will need to still get the command which uses them
20:59:37 <tdawson> So it sounds like we won't need ansible in epel9, correct?
20:59:43 <nirik> for basic things it will be enough, but if you use any more complicated modules, etc you will likely need to install a collection or two
20:59:59 <nirik> now a days 'ansible' means 'ansible-core + a bunch of collections"
21:00:08 <nirik> tdawson: right.
21:00:15 <tdawson> Cool.
21:00:31 <nirik> the collections might be worth packaging (at least the ones we already have in fedora/epel)
21:00:46 <tdawson> Looks like our time is up.  Thank you everyone for coming and for the good discussions.
21:01:08 <tdawson> And than you all for all you do for EPEL and the community.
21:01:17 <tdawson> Talk to ya'll next week, if not sooner.
21:01:30 <tdawson> #endmeeting