18:01:18 #startmeeting EPEL (2020-02-26) 18:01:18 Meeting started Wed Feb 26 18:01:18 2020 UTC. 18:01:18 This meeting is logged and archived in a public location. 18:01:18 The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:18 The meeting name has been set to 'epel_(2020-02-26)' 18:01:27 #meetingname epel 18:01:27 The meeting name has been set to 'epel' 18:01:34 #chair nirik tdawson bstinson Evolution pgreco merlinm carlwgeorge 18:01:34 Current chairs: Evolution bstinson carlwgeorge merlinm nirik pgreco tdawson 18:01:37 morning 18:01:44 #topic aloha 18:01:56 aloha 18:02:03 #info Meeting is run from https://board.net/p/epel 18:02:16 aloha all 18:02:45 howdy 18:04:53 howdy nirik smooge and carlwgeorge 18:05:45 * tdawson gives it one more minute before moving on 18:06:38 #topic New Business 18:06:38 hi tdawson 18:06:44 #info poll for new meeting times https://framadate.org/hXYmD86z3U5jTXqm 18:07:20 pgreco: Howdy, glad you could make it. 18:08:02 Thus far, It's looking like the later time is better for more people, except pgreco 18:08:27 tdawson, yeap, on a work call right now 18:08:41 but 1 hour from now is ok, my other work call is in 2 hours 18:09:59 either way, if this is the time we end up settling on, I'll try to be on, at least at 50% ;) 18:10:06 OK. We'll leave it up one more week, and I'll send out another annoucement, see if there are others who would come if the time was right, and then next week we'll have our final discussion and change. 18:10:18 pgreco: OK, thank you. 18:10:43 no problem 18:11:02 i like this poll thing but i wish the "best choices" reflected the "if needed" votes 18:11:16 So, next week, same time, same day, but the week after we'll have our new time. 18:11:56 +1 18:12:14 sounds good 18:12:15 carlwgeorge: Ya, I wish at the end of each line had (3) Yes, (2) Maybe 18:12:46 I think in the email I'll put the current tally, with those stats. 18:13:08 #topic Old Business 18:13:14 #info https://pagure.io/fedora-infrastructure/issue/8558 - libssh2 18:13:19 .ticket 8558 18:13:21 tdawson: Issue #8558: EL8 libssh2 - fedora-infrastructure - Pagure.io - https://pagure.io/fedora-infrastructure/issue/8558 18:14:28 I opened a bugzilla this past week about this, and ended up with an email conversation (instead of in the ticket). 18:15:06 https://bugzilla.redhat.com/show_bug.cgi?id=1805260 18:15:48 In the email, I was told that a work-around is to create a libssh2 module, and when that is enabled, dnf will choose the highest NVR 18:16:21 * nirik nods 18:16:42 I have a proposal that we create such a module, but there are some pro's and cons. 18:17:45 In my proposal, I specifically say to not have the module be default, but I'm wondering about back tracking on that. Mainly because the RHEL8 module with libssh2 in it, is default. 18:18:18 I thought it was not? 18:18:25 * nirik looks 18:18:59 Oh ... if it isn't, that would change my thinking. I just know it's always on whenever I install RHEL8. 18:19:08 so it is split 18:19:21 the virt modules which have it are 'default' 18:19:27 the virt-devel modules are not 18:19:45 then there are the later virt/virt-devel modules where it isn't in at all 18:19:49 well, it's in appstream? 18:20:03 virt is in appstream, virt-devel is in code-ready 18:21:00 I don't think we care about devel here... 18:21:04 OK, since virt is default, then I'm thinking of changing my proposal to have it be default. 18:21:29 But I really worry about setting a presidence here. 18:21:51 the question then becomes: can non modular epel8 packages build against that? I think the answer is no, without more releng work 18:22:18 nirik: Even if it's default? They still wouldn't be able to build against it? 18:24:05 tdawson: I don't think so. We would need to make grobisplitter also consume and split the epel8-modular repo... which I suppose it might do, but I don't think so? 18:24:50 Which brings up a subject I was saving for RHEL8, but I'll bring it up here, what about if this proposal was implemented - https://pagure.io/fedora-infrastructure/issue/8690 18:25:17 we have to fight with that a lot building centos, until koji understands modules, all you can do is inherit tags 18:25:41 at least, that's been the case for us, I'd be glad to be proven wrong in this subject :) 18:25:44 we would have to have some way to import modules into mbs/koji. 18:25:44 If we go down to smooges comment at the bottom, he is talking about changing from gobisplitter, to just using the three RHEL8 repo's as external repos 18:26:23 that would not work I don't think. mbs needs to know about the modules and how to build against them. 18:26:38 Oh ... ok ... I thought that was already done. 18:26:56 well, again, I didn't do that work, so I could be wrong here. 18:27:06 we might need merlin or mboddu ? 18:27:10 i don't know myself and was assuming the same thing 18:27:30 tdawson, I think I have fulfilled the AssUMe role there 18:27:43 * mboddu reading back 18:27:48 OK, we'll have to investigate that more this week, and bring in merlin and mboddu. 18:28:37 #info Need to discuss importing modules into mbs/koji with merlin and/or mboddu 18:29:06 and... they would likely need to be from centos... so that adds more worms. ;) 18:29:50 Oh ... yipee :) 18:30:21 dragons 18:30:32 Any other suggestions/comments on libssh2 before I move on? 18:31:12 Just throwing this out, but both a regular rpm *and* a module rpm ... but that sounds like madness right now. 18:31:38 as long as they were kept exactly the same it could work 18:32:19 this isnt' madness, this is Spartularity 18:32:29 *laughs* 18:32:45 lol 18:33:02 #topic EPEL-6 18:33:08 #info EPEL-6 is End of Life in 2020-11. It will be moved to archives in 2020-12 18:33:13 #info THIS IS NOT A DRILL. 18:33:21 * tdawson pauses for dramatic effect. 18:33:58 #topic EPEL-7 18:34:12 Anything for epel 7? 18:34:40 koji is broken in el6... I am not sure how to fix it, and probibly will just not care until it dies. 18:34:50 nothing epel7 wise 18:34:52 i have something that isn't specific to epel7 but will impact it the most 18:34:55 https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Conflicts_in_compat_packages 18:35:28 specifically the "at this time" part, i'd like to see if we can revisit allowing it 18:36:45 carlwgeorge: That makes me nervous, but why would you want/need to do that? 18:37:23 nirik: When you say koji is broken in el6, do you mean just the program? The fedora koji servers are still able to build epel6 packages, correct? 18:37:31 nirik, when you say koji is broken in el6.. do you mean we can't make packages in koji for el6 or .. what tdawson said 18:38:00 lots of software doesn't easily support looking for alternatively named (or alternatively located) pc files 18:38:06 .. steps back .. remembers he is supposed to let someone else run things 18:38:09 smooge: The scariest thing about what you wrote, is that it's word for work what I wrote for half of it. 18:38:35 mind meld complete. 18:38:49 yes, the koji package: https://bugzilla.redhat.com/show_bug.cgi?id=1806193 and https://bugzilla.redhat.com/show_bug.cgi?id=1497923 18:39:17 conflicts are really lousy for the end user... 18:39:57 dnf install foobar -> looks ok, 'y', -> downloads a ton of packages -> rpm transaction test failed: conflict. 18:40:26 carlwgeorge: True, but why would you need to do a compat package for one that is already in RHEL? 18:40:27 that is drastically minimized by only allowing it on the -devel packages 18:42:09 lets say some software requires libzip >= 1. el7 has 0.10, the library can be easily made parallel, but the devel package cannot. a libzip1-devel package that conflicts with libzip-devel is the most straightforward approach. 18:42:43 * nirik nods 18:43:19 True, but what if a user wants to use the libzip 0.1 devel headers? 18:43:43 some software makes it easy to say "look in this dir for libzip.pc" or even "look for libzip by this name (libzip1.pc)", but not many 18:44:15 I'd be ok relaxing the rule, but we should probibly float it on the list and get other feedback rather than just doing it. 18:44:31 tdawson: then they install the stock libzip-devel. i know it's not perfect, hence why it's currently prohibited, but making exceptions has value. 18:45:00 * tdawson agrees with nirik, let float it on the list. 18:45:03 i'd also be ok with it being a case-by-case rather than blanket approval 18:45:22 i'll draft up an email for it, thanks for letting me bounce it off yall first 18:45:54 carlwgeorge: I'm not against it, I'm just going to try to think of various cases, for and against, so it wont' bite us a year or two down the road. 18:46:28 Anything else for EPEL6 or 7? 18:47:11 #topic EPEL-8 18:48:24 I already brought up the one topic I wanted to discuss some, which is https://pagure.io/fedora-infrastructure/issue/8690 18:48:57 That would allow our developers making modules, to build off non-default RHEL8 modules. 18:49:34 But, I'll contact merlin and mboddu to see if this would work. 18:49:52 yeah, I don't see how it is currently. 18:49:54 So, anything else for EPEL8? 18:50:02 yeah.. or figure out how to get the data through grobisplitter so that it can be done 18:50:31 We could discuss it in our next releng meeting 18:50:49 Also, what smooge said will also work ;) 18:50:54 Ya, one way or another, I think it's a good thing. 18:51:01 mboddu: thank you. 18:52:04 Last week bstinson said to watch the centos-devel mailling list about work on the missing -devel packages. 18:52:32 I'm not meaning to rush anyone too much, I just wondered if I missed any emails. 18:52:54 you haven't missed anything yet 18:52:59 :) 18:53:20 OK, I'll be patient then. bstinson thank you for all you've been doing on that. 18:53:55 Anything else before we move to open floor? 18:54:42 #topic Open Floor 18:55:40 * tdawson gives it one more minute 18:56:02 * nirik has nothing off hand 18:56:22 #endmeeting