21:00:40 #startmeeting EPEL (2020-06-19) 21:00:40 Meeting started Fri Jun 19 21:00:40 2020 UTC. 21:00:40 This meeting is logged and archived in a public location. 21:00:40 The chair is tdawson. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:40 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:40 The meeting name has been set to 'epel_(2020-06-19)' 21:00:41 #meetingname epel 21:00:41 The meeting name has been set to 'epel' 21:00:43 #chair nirik tdawson bstinson Evolution pgreco carlwgeorge 21:00:43 Current chairs: Evolution bstinson carlwgeorge nirik pgreco tdawson 21:00:44 #topic aloha 21:00:54 howdy yall 21:01:01 hi carlwgeorge 21:01:26 * nirik is sort of here, sort of busy 21:01:55 hi nirik ... understood. We'll be sure to ping if it's pressing. 21:03:26 * pgreco arrives a bit late 21:03:34 hi pgreco 21:03:46 I'll wait about two more minutes, see if anyone else shows up 21:04:21 I'm not allowed to say howdy since I'm not texan, but still, howdy ;) 21:04:30 :) 21:05:35 #topic Old Business 21:05:47 #info EPEL-6 is End of Life in 2020-11. It will be moved to archives in 2020-12 21:05:48 #info THIS IS NOT A DRILL. 21:06:25 We didn't have a meeting last week, and I didn't have anything written down as leftover from two weeks ago ... so, as far as I know, no new business. 21:06:43 .... no ... old business 21:06:59 just let it die silently... 21:07:16 :) 21:07:22 #topic EPEL-7 21:07:51 I haven't seen any issues for EPEL7. Does anyone else know of any? 21:07:59 carlwgeorge: oniguruma/jq rebuilt for armhfp too 21:08:02 no issues 21:08:22 excellent 21:09:15 oh, I have an issue in 7, let me get the package names 21:09:29 ok 21:10:35 I'm trying to rebuid perl-MooseX-Types-DateTime-MoreCoercions for armhfp, and it fails due to missing BR 21:10:55 gotta love that name. :) 21:11:11 hehe, yeah 21:12:23 as soon as it fails again, I'll get the missing name, hopefully it is just something that just needs releasing 21:12:29 let's move on while this builds 21:12:35 OK 21:12:52 #topic EPEL-8 21:13:40 I have a question on this one, dealing with this pull request 21:13:48 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/15 21:14:04 I saw that one, do we have unversioned /usr/bin/python ? 21:14:30 Basically it's requesting that some macros that got put into the fedora macro's get put into epel8 ... wait is it using unversioned python? 21:15:00 old name (without version) 21:15:26 iirc, 8 only has /usr/bin/python2 and /usr/bin/python3, but no /usr/bin/python 21:15:30 I may be mistaken 21:15:32 there are macros that use %{__python} without necessarily defining it, to allow spec files to define it themselves 21:16:05 i.e. using `%py_shebang_fix` will fail if you don't define `%{__python}` yourself (i think) 21:16:06 carlwgeorge: correct 21:16:26 yeap, that's where I was going 21:16:58 i do that in a spec file that is py2/py3 compatible, define __python different based on the default python for the distro, then use unversioned macros in the rest of the spec file 21:18:29 ah, it's even more explicit than i thought: 21:18:31 `error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly` 21:19:23 good, I like that 21:19:54 So, do you think this will break that? Or work with it? 21:20:33 i think it will be fine 21:21:07 OK. I really needed a second opinion. 21:21:27 I'll merge, build, and do the usual. 21:21:28 I like having compatible macros for in epel/fedora 21:21:49 yup, keeps spec files cleaner and makes it easier to bring stuff to epel8 from rawhide 21:21:53 I do too ... at least for the latest epel ... for the older ones, I always get nervous. 21:22:21 well, 7 has 4 more years to go, we may need to add them eventually 21:22:49 True ... and we have added some. But some of these python ones don't work on epel7. 21:23:20 Any other epel8 things? Cuz I think carlwgeorge has an issue that sorta lands on open floor, since it covers all releases. 21:24:21 #topic General Issues / Open Floor 21:25:39 carlwgeorge: I believe the issue you wanted to bring up was from xavierb 21:26:10 ha, i told him to come to the meeting and champion it 21:26:40 :) 21:27:00 i can summarize it i guess. the suggestion was to modify policy to allow epel maintainers to leave packages in epel after they are added to rhel, until the corresponding centos is built. 21:27:28 The time between a RHEL and a CentOS release is a real pain for EPEL. 21:27:51 We at least have the archive now that we do for each RHEL release. 21:27:52 if the new rhel one was always 'newer' it would be less of a problem doing this. 21:28:14 considering that several 8.1 additions were missed by all of us and stayed in epel until 8.2, i think the impact is pretty low. but that will of course be case by case. 21:29:04 True .. to both of you 21:29:06 i'm on the fence about it honestly, i see the benefit of the change and i also see the benefit of the policy being strict 21:29:29 another reason i didn't want to champion it :D 21:29:43 I think this may be based on the zstd issue 21:30:14 which was made worse by the epel maintainer jumping the gun and pulling it early before rhel 8.2 was even GA 21:30:23 if epel is older than rhel, I don't mind keeping it around for a while, since it will be updated anyway 21:30:43 but in the zstd case, epel was newer, so the earliest we remove it, the better 21:31:09 and those who actually need it, can use the archive 21:31:10 i think when the rhel build is newer is usually the case when it gets missed for a long time 21:31:50 we also have stream now, so it was trivial for people to get zstd from there 21:32:01 yeap, exactly 21:32:08 And the archive. Yep. Two places. 21:32:28 based on that, i'm -1 to the proposal i'm "champinoning" 21:32:55 :) 21:33:16 it's got tradeoffs... hard to tell which way is worse... neither is clearly better 21:33:57 What about some halfway policy. If it's newer than RHEL's, we remove it immediately. If it's not, let it sit the the CentOS release. 21:33:58 my take is, if you notice it, you know how to solve it :) 21:34:41 tdawson, yeap, that's what I think 21:34:47 tdawson: codifying what already happens, works for me 21:36:04 Does anyone have a nice easy "compare what's in epel to rhel" script? 21:36:44 I may have some repodiff scripts somewhere 21:38:41 * pgreco boots an old laptop to try to find repodiff.... 21:39:48 I was looking to see if we had this on a policy or FAQ somewhere. I don't see it. 21:40:19 Closest I found was this - https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F 21:40:25 tdawson, we can talk after the meeting if you want, we'll come up with something 21:40:36 OK. 21:40:49 pgreco: Did your build fail yet? 21:41:14 'perl(DateTimeX::Easy) >= 0.085' 21:42:24 pgreco: Looks like there is an updated version for that in EPEL7 ... did it not build on your arm builds? 21:42:32 https://koji.fedoraproject.org/koji/buildinfo?buildID=1519745 21:42:45 built yes, but maybe not released yet 21:43:14 not enough karma yet? 21:44:17 Huh ... it says it's released ... yet I'm not seeing it. 21:44:34 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-cdf9943b6a 21:45:04 it was pushed an hour ago! 21:45:13 Ah ... just an hour ago ... gotta filter through the system. 21:45:38 well, all is good then :) 21:46:43 Anything else for open floor? 21:47:55 I don't have anything else either. 21:48:14 nothing here 21:48:27 Thanks for coming. I'll talk to ya'll next week. 21:48:47 bye, thanks! 21:48:50 #endmeeting