17:59:43 #startmeeting EPEL (2020-02-05) 17:59:43 #meetingname epel 17:59:43 #topic aloha 17:59:43 #chair nirik smooge tdawson bstinson Evolution pgreco sgallagh merlinm 17:59:43 Meeting started Wed Feb 5 17:59:43 2020 UTC. 17:59:43 This meeting is logged and archived in a public location. 17:59:43 The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:43 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:59:43 The meeting name has been set to 'epel_(2020-02-05)' 17:59:43 The meeting name has been set to 'epel' 17:59:43 Current chairs: Evolution bstinson merlinm nirik pgreco sgallagh smooge tdawson 17:59:43 #info Meeting is run from https://board.net/p/epel 18:00:40 hey everybody! 18:00:50 Howdy 18:00:58 .hello2 18:00:58 sgallagh: sgallagh 'Stephen Gallagher' 18:01:20 hello 18:01:21 * sgallagh really needs to put this meeting on his calendar; it keeps being a surprise for me 18:01:40 sgallagh, 18:01:50 Who's there? 18:01:58 LAND SHARK 18:02:11 Land shark... who? 18:02:54 I think that was the punch line but it has been 30 years since I watched Saturday Night Live 18:03:14 morning 18:03:32 candygram 18:03:45 #topic EPEL-6 18:03:45 #info EPEL-6 is End of Life in 2020-11. It will be moved to archives in 2020-12 18:03:45 #info THIS IS NOT A DRILL. 18:04:14 any other EPEL-6 items? 18:04:50 #topic EPEL-7 18:05:16 ok anyone have epel7 items? 18:06:21 alright then.. 18:06:25 #topic EPEL-8 18:06:25 #info modularity is enabled. 18:06:58 I've been on other stuff for a few weeks, but I was just sitting down to try to solve the missing -devel problem when I got pinged for this meeting 18:07:08 understood 18:07:14 (Weird bit of synchronicity there) 18:08:04 we should decide and document what epel agrees to not overlap with. ;) 18:08:07 so I would like to get some feedback from the CentOS people bstinson and such as I believe they have a solution they are looking at also 18:08:08 there's a thread on the list 18:09:29 so going from contyk's(?) email... the libssh2 will have to be a module so it can install over the libssh2 items in RHEL-8 18:09:36 I've been operating on the assumption that modular EPEL 8 is allowed to overlap with anything so long as it's not a default stream 18:09:46 (And we don't allow default streams in EPEL8 presently) 18:10:10 we're starting with the non-modular case in CentOS 18:10:11 the problem seems that the libssh2 items were in a default stream but aren't(?) now 18:11:05 smooge: That shouldn't be permissible in RHEL. What happened there? 18:11:05 No, it still is, from everything I've tested. 18:12:27 so I don't know.. the module (virt people) author says it shouldn't be there anymore. 18:13:02 it was only there because it was needed for one thing and it was causing all kinds of headaches so it was supposed to be removed from 8.0 -> 8.1 18:13:13 however as tdawson says.. it is still there 18:13:47 so ¯\_(ツ)_/¯ 18:14:52 Maybe they (RHEL release) need to work on their module dropping a package skills. Maybe they tried to remove it. 18:15:27 Well, right now there's no mechanism in DNF for allowing that, so it may have just been postponed anyway. 18:15:44 Or at least for dropping it out of a module and into the non-modular content 18:15:47 * sgallagh shrugs 18:17:03 so looking at our systems 18:17:33 it is in ./virt-devel:rhel:8000020190828150510:f8e95b4e:x86_64/libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.i686.rpm but it is not in any later module 18:18:57 so the way grobisplitter works.. it is not available for koji to use 18:19:34 tdawson, so it looks like it is removed but because of dnf and the fact that rhn sees all old modules.. it is still there? 18:20:00 OK, so it really has been removed from the module, so epel8 can't see it, but if you are running RHEL8 .. you still see it. ugg ... weird. 18:20:15 yep. 18:20:30 The fact that RHEL 8 sees it is a bug 18:20:37 OK, well, that explains why I can still see it in my tests. 18:21:06 contyk(?) explained it in his email that it is how dnf deals with modules and it is on a roadmap to fix someday 18:21:30 "Someday" is "targeted at 8.3", last I heard. 18:21:45 (The previous statement should not be construed as making any promises) 18:21:59 so for the time being.. we could come up with some sort of fix where we build this somewhere? 18:23:03 so, the proposed rule would be: no overlapping bare rpms, no overlapping things in default modules? 18:23:05 nirik, if we figure out how to override pdc?/src?/whatever? to allow a branch we could try a build in EPEL-8 and see what else might not work 18:23:32 smooge: well, we need to know the rules to adjust the script that makes that json file. 18:23:37 agreed 18:23:52 right now it includes all rpms from everything modular and not 18:24:18 I would go with no overlapping bare rpms, no overlapping things in default 8.latest modules 18:24:42 since we really only care about X.latest for any RHEL release 18:25:09 does that sound workable? 18:25:18 so it would have to somehow know what modules are 'default'. ;( 18:26:37 and I realized that virt-devel was not a default module (don't know if it is now) 18:26:39 nirik: That's easily retrieved from the metadata 18:27:05 sure, but that script would have to grow that ability. 18:27:09 what is the syntax for a proposal in zodbot? #propose #proposal 18:27:15 right now it just gets all the rpms from the metadata and puts them in a json file 18:27:28 smooge: whatever you like, it doesn't have any proposal function. ;) 18:28:32 #propose EPEL does not allow for EPEL packages to overlap rpms which are either bare or in enabled modules in the latest 8 sub release. 18:29:32 the metadata it would use to determine this would be in the metadata from rhel/rhel8/koji/latest/x86_64/ 18:29:48 which just has the packages which we would build against 18:30:38 enabled? you mean default? 18:31:13 well I realized that querying that data you would not see any modular data 18:31:40 you would just see the rpms that we build against and wouldn't want to conflict with 18:32:03 but some of those are in non default modules that we do want to allow overlaping with? 18:32:34 I was trying to come up with something we could do without too much 'growing new things' we have little time to do 18:33:01 if we can grow something to learn what is default and isn't etc.. then we could go with just the default modules 18:33:14 FTR, "list all the default streams" is a single API call in libmodulemd once the data is loaded 18:34:06 sgallagh, I currently would not be able to look at adding any functionality until July with my current schedule... so it would require someone else finding time to do so. 18:34:31 I am guessing Kevin is in a similar boat 18:34:37 * sgallagh nods 18:34:43 well, this is the rhel2json script pingou wrote... so probibly he would be the one to check with on changes.. 18:34:57 If one of you can point me in that direction, I could try to do it. 18:36:03 https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/repo2json in ansible... 18:36:08 not sure if it has another upstream. 18:36:55 it looks like it uses the modular repos directly before grobisplitting? 18:36:59 thanks sgallagh I also didn't want to commit you to working on it :) 18:37:36 I'm not making promises, but I'll have a look 18:38:00 understood completely 18:38:17 ok I have one more item from the discussions if we are done here? 18:39:12 sure 18:39:14 #topic Un-responsive maintainers in EPEL. 18:39:53 Grab the pitchforks! 18:40:03 this came up on devel list from someone who got tickets from EPEL assigned to them because they weren't getting dealt with 18:40:38 part of this comes from the pkgdb changes of 3-4 years ago, and some others come from lack of rules on our part 18:40:55 well, it's hard to know with the info we have sadly 18:41:16 I am not sure exactly what to do about it at the moment (brain empty) but wanted to say it was at least brought up here versus ignored 18:41:47 I think we will need a policy that can be followed by security and other groups when dealing with packages not getting fixes 18:41:59 take package foo... has 3 co-maintainers and fedora and epel branches. maintainers 1 and 2 work on fedora, 3 on epel. Maintainer 3 disappears... how can we know the epel branches are not being looked after? ;( 18:42:25 I do not have time to write said policy and as nirik says.. this is complicated and not easy to deal with. 18:42:54 ideally we can bring back seperate epel/fedora maintainers at least... that would help... 18:43:23 so input from the community is wanted. I will put more in a mail later today and if we can figure out what and where that would live I would love it 18:44:33 any other input here because someone asked about a related topic when I started on this 18:45:28 #topic What is the policy and steps for someone on request-for-branch tickets not getting responses? 18:45:49 skywalker, the floor is yours 18:46:54 sure, thanks smooge 18:47:12 so, i have a few tickets on releng regarding claming ownership of packages from people that don't respond. the tickets have been sitting there for 10 days now 18:47:31 is there anything we could do about them? am i doing anything wrong? 18:47:55 skywalker: releng is basically just 3 people... and we were all traveling and doing the mass rebuild... 18:48:05 the goal is just to have those packages on EPEL 8. i am willing to have their ownership for EPEL or at least have commit/push permissions 18:48:23 the current maintainers haven't replied to bugs? 18:48:31 oh, i see. i didn't know that, nirik. it's alright then 18:48:45 they have not. i filed most of those bugs back in 2019. in sep/oct 18:48:46 sorry it's slow, but.... sometimes it is. ;( 18:48:55 wow... thats a while. ;) 18:49:40 yes, right? but that's ok. i can wait :) i see that the releng team have ~130 tickets right now 18:50:32 I thought it was 170? oh... 165 looks like 18:50:43 anyhow, I can try and get those this week for you.... 18:51:14 thanks, if i can help somehow, please let me know 18:52:18 ok thanks skamath 18:52:25 ok thanks skywalker 18:52:33 :) thank you guys 18:52:39 I have another meeting in 5 so I am going to put htis in into end of meeting 18:52:43 Any other replies? 18:52:48 requests 18:52:52 * nirik too 18:52:53 returns? 18:53:01 #endmeeting