18:00:15 #startmeeting EPEL (2017-08-23) 18:00:15 Meeting started Wed Sep 20 18:00:15 2017 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:15 The meeting name has been set to 'epel_(2017-08-23)' 18:00:16 #meetingname EPEL 18:00:16 #topic aloha 18:00:16 The meeting name has been set to 'epel' 18:00:16 #chair avij bstinson Evolution nirik smooge 18:00:16 Current chairs: Evolution avij bstinson nirik smooge 18:00:34 hi all 18:00:42 hi 18:00:46 morning 18:00:49 ok so I missed my deadline of writing up proposals so we don't have them to talk about 18:00:54 morning 18:02:56 hello all 18:03:07 so the meeting agenda is down to a couple of items 18:03:29 1. there are a couple of packages which are in EPEL which are in RHEL which need to be blocked/removed 18:04:53 2. Various requests for rebuilding against EL7 due to openssl and other bumps. Can we trigger a mass rebuild? 18:05:45 #topic Duplicate packages 18:06:25 if we have a list we can ask releng in a ticket to quash them... 18:06:39 So bleve found this libmspack and they or someone else found another package I think 18:07:05 avij: did you have any other ones not mentioned/found yet? 18:07:10 the packages were in our squish list earlier but it happened during the src changeover so parts did not happen 18:07:30 the other package was vulkan, mentioned here https://pagure.io/releng/issue/6948 as removed, but it's still there 18:07:33 there was also the part where some packages were there because they weren't in RHEL 18:08:08 for specific arches 18:08:29 Evolution: I think these are all 18:08:56 avij, Evolution I am going to do a repodiff and repoclosure tonight to see what else might be lurking 18:09:15 smooge: is that a road we want to go down (keeping packages for certain arches)? 18:09:20 hum, vulkan is indeed marked dead.package 18:09:31 Evolution, so we have been on that road. I am tired of it 18:09:53 its filled with potholes 18:10:01 we have an actual approved policy on these. 18:10:10 not that anyone ever follows it. 18:10:15 18:10:52 https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages 18:11:35 which is where I am at also.. I think it is time to just rework it or remove it. 18:12:24 well, if folks followed the guideline things would be much easier to see. 18:13:14 vulkan is blocked now 18:13:15 we need to fix the policy since #6 isn't useful 18:13:36 true. 18:14:48 the second part in looking at it is that I was wondering if we should just have these packages in a different repository versus in EPEL 18:15:26 say one which was run by a group who are building things for different arches and have the base srpms 18:16:32 well, the reason people want them is so they can build their epel thing for the other arches too... and rhel doesn't provided all the needed packages 18:16:39 because normally the maintainer of the EPEL package doesn't want to maintain libfoobaz-1.0.1-0.1 they just want foobar to compile 18:17:09 so there is a group.. maybe really close inside of this meeting.. maybe not who do build those packages for other arches... 18:18:01 ... closes the door and locks it before bstinson and Evolution can escape 18:18:04 well, if they follow the limited arch process, they don't have to maintain it... just watch the rhel one and keep it in sync... the rhel maintainer would decide when to upgrade/etc 18:18:16 but of course keeping it in sync is work 18:18:37 and actually knowing what the RHEL one is tricky for various developers who don't want to deal with RHEL 18:19:35 so what I was wondering is if we just use the CentOS ones which are built for different arches. We then only support these packages if there is a CentOS arch of it 18:20:10 I don't think koji will have any way to do that 18:20:28 I think there are only 2 arches where that would matter currently 18:20:33 ppc64le and aarch64 18:21:00 I don't think our armv7hl is 100% yet, but would need to check with fabian. 18:21:08 and i686 is ostensibly a nightmare. 18:21:18 because of the blending with x86_64 18:21:30 well my look was more of ppc64le and aarch64 18:22:00 nirik, so koji can only look at one external repo? 18:22:36 smooge: I think it would be more challenging for it to look at repos where there are significant duplicates. 18:22:43 and we don't filter out what's not there from what is. 18:22:44 ah got it 18:23:12 because 6534 packages would be dups, and 10 would be new. 18:23:23 well, no, you can have it look at a number of them, but it operates on src.rpms/packages... so if package A is in rhel7 repo thats what it uses for anything from package A... even if it's also in centos7 repo that has more arches. 18:25:22 so I guess building against centos instead of rhel would "fix" things? or how does centos handle packages that are not in all rhel arches? 18:26:17 Evolution, ^^^^ 18:27:18 nirik: "it depends" 18:27:34 yeah, I was suspecting that would be the answer. ;) 18:27:46 nirik: for aarch64, I build as much as will actually compile and pass smoke testing 18:27:52 I include libvirt,etc which rhel doesn't. 18:27:59 but I put it where rhel does for x86_64 18:28:02 So let us talk about the 3 arches I care about at the moment: aarch64, ppc64le, x86_64 18:28:17 for ppc64le they were putting the packages in a different repo to show there was a differentiation 18:28:21 extras I think? 18:28:34 still available but 'not rhel default' 18:28:40 the source rpms are all still the same though 18:28:48 just the binary structure is slightly different 18:31:23 ok so again I am wondering is there anything we can make to enforce procedure better, live with it, or just drop the multi-arch? 18:31:44 is there a possibility of automating this somehow? 18:31:54 I am not going to put a vote or anything on it today.. I am just cranky from dealing with it over and over again 18:32:27 If I had to do it over again I would not have allowed them, but it seems poor to drop them now... but I guess we could. ;( 18:32:30 smooge: pronoun: it unclear -- the manual part, the removal, the unclarity between arches, more? 18:33:00 it would be very nice to have a list, and require any new ones to add to the list so we know whats doing it. 18:33:01 it == the current state of affiars 18:33:11 I hate dandruff as well 18:34:46 perhaps we could get a list of all overlaps and try and figure out which are trying to be limited arch and which are just needing blocked? 18:37:44 nirik, Evolution this is my super quick list https://paste.fedoraproject.org/paste/S7AYavSvd5vTVSdTNHUzAQ 18:38:00 generated by repodiff --old=/mnt/fedora/app/fi-repo/rhel/rhel7/x86_64/rhel-7-server-optional-rpms/ --old=/mnt/fedora/app/fi-repo/rhel/rhel7/x86_64/rhel-7-server-rpms/ --old=/mnt/fedora/app/fi-repo/rhel/rhel7/x86_64/rhel-ha-for-rhel-7-server-rpms/ --new=/srv/web/pub/epel/7/x86_64/ --simple -a noarch -a x86_64 --downgrade 18:38:58 cool. vulkan is dealt with... but we should check the rest. 18:39:20 ceph is enough of a pain in the ass it shouldn't really be there anyway 18:39:38 yeah, they are taking it out... 18:40:50 for ppc 18:41:28 https://paste.fedoraproject.org/paste/SjzdgGNi60077tl9-x0rOg 18:41:45 I don't know if we have other repos added than the ones I have above listed 18:43:35 and for aarch64 https://paste.fedoraproject.org/paste/erYtmN2vHhGUj6yhVMEJgw 18:45:24 It looks like most of these packages are done for ppc64 18:46:55 as the list for collides is only the following: 18:47:38 https://paste.fedoraproject.org/paste/EJLD4Q7WfMBOCFijINmyXQ 18:48:11 so I guess the ones which could be dropped out of EPEL currently are the ones in that last paste 18:49:54 ok nirik I can open a releng ticket on the ones in that last paste to have those packages removed 18:50:11 the finch pidgin ones are a special case I think 18:50:26 thats due to server not carrying some packages workstation does. ;( 18:50:57 or something. can't recall all the details 18:51:57 oh, I remember... they deliberately removed/don''t ship some things from pidgin.... 18:52:02 can you check src.rpms? 18:52:08 oh it looked like they are there now and while we aren't replacing packages.. anyone building against it aren't going ot have the right package 18:53:01 well, the src package I think is pidgin-epel or something. 18:53:29 they deliberately don't ship the libpurple devel library in rhel's pidgin package 18:54:01 it's a mess 18:54:39 nirik, I don't know where our copy of updated src.rpms are so I am using one I had a while ago https://paste.fedoraproject.org/paste/YRD4qOrjMnq1gl-M161z~w 18:55:34 yeah, so that doesn't show the pidgin/finch thing 18:56:18 ok so that to me says we are replacing a core RHEL package which I thought was a nono then 18:56:51 but we have to check that they aren't only for some arches... if they are 'older' than the rhel one 18:58:15 ok so we are at the top of the hour. 18:58:50 yeah... sorry we didn't seem to get anywhere... 18:59:19 I don't see anything coming to fruition at the moment so I think we need to close this out with ¯\_(ツ)_/¯ 18:59:53 except not with a smiley 19:00:04 ok anything from the floor today 19:00:09 #topic open floor? 19:00:32 smooge: koji can look at as many external repos as we want. but it filters builds out based on block lists and when it encounters srpms first 19:01:29 thanks for the info 19:01:42 I need to close this for the next people. I hope you all have a good week 19:01:47 #endmeeting