18:00:26 #startmeeting EPEL 18:00:26 Meeting started Wed Oct 12 18:00:26 2016 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:26 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:26 The meeting name has been set to 'epel' 18:00:26 #meetingname EPEL 18:00:26 The meeting name has been set to 'epel' 18:00:26 #chair smooge nirik Evolution bstinson avij 18:00:26 Current chairs: Evolution avij bstinson nirik smooge 18:00:26 #topic aloha 18:00:36 morning 18:00:39 hello world 18:00:40 good day 18:01:27 moonin 18:02:10 hi all 18:02:24 bstinson is probably recovering from install.. no never mind 18:03:01 #topic Agenda Light 18:03:12 aarch64 landing 18:03:22 #info aarch64 landing 18:03:34 #info arinov> telegram-cli must be removed from el6 repository, it works only on new version of libc 18:04:34 anything else? 18:04:50 nirik, what is needed for the aarch64? RHEL-7.3 18:05:02 it's landing now, pbrobinson is working on it. 18:05:10 7.2 is new enough 18:05:13 ah ok 18:05:25 so, there may be some churn as things are added, etc... 18:05:35 but hopefully it will be as smooth as the ppc stuff was 18:05:46 * pbrobinson waves 18:06:08 #info smooge owes pbrobinson a beer. [and not a Foster's] 18:06:17 we all do. ;) 18:06:38 I wanted to do 7.2 before 7.3 lands, when I did ppc64le I had huge amounts of extra work as I did it right after 7.2 GA due to RHEL bumps 18:07:11 that makes sense 18:07:19 the tricky one(s) will be i686 and armv7... since there's no rhel there, we need to setup centos... so not sure how that will all work. 18:08:00 so I've still not come up with or been offered a decent solution to that 18:08:15 oh I thought you had a solution to that 18:08:33 maybe we just do them in a different koji/builder system 18:08:40 the problem is the delta in time between a new release goes GA on "primary" arches, and when the same NVRs land for non primary 18:09:01 so we could end up with builds built against two different versions 18:09:07 and we tie that koji/builder system to the centos builders since they would be the ones pushing it 18:09:36 smooge, but them we hold up the primary arches which is the vast majority of users 18:09:53 well it would not be connected to the main one 18:10:10 so like a koji-shadow style system? 18:10:24 could be. 18:10:51 the other way would be to branch epel with each dot release, with the big move each el7 release there's possibly demand for that as well 18:11:04 or they use the same method that CentOS used to be built.. they look for updated srpms and trigger builds against it in their system 18:11:17 yeah, it's all tricky. 18:11:53 pbrobinson, that is what I was thinking also. The RHEL release cycle looks a lot more aggressive in what changes every release 18:12:00 smooge: so basically what Evolution has been doing with some of the aarch64 stuff to date. 18:12:04 I was actually going to say we look at something else also 18:12:06 which is basically EPEL but not EPEL 18:13:23 pbrobinson, yeah. We give some sort of 'we recognize these builders to be epeljr' or some other line. It sounds flippant (since I am usually flippant) but it is what I have been stewing on how to square the circle 18:13:32 for that case, do we ask epel to be able to use the name EPEL? 18:13:51 or include as a component of the repo name 18:14:00 or just call it something else? 18:15:28 I think we'd need to include epel in the name as a reference to where the sources are coming from 18:15:34 well I am not looking for a solution right here. I wanted to get people thinking abou it if possible 18:16:17 yeah, perhaps something brilliant will occur. ) 18:17:15 #topic Doing a release rebuild 18:18:20 So with the more aggressive rebuilds on RHEL I was wondering if we should look at doing a dot release rebuild of packages in EPEL 18:19:55 I don't know yet, but chances are that some packages will need to be recompiled against new libraries 18:20:08 Basically wait for 7.3 to come out. Create a epel/development/7.3/ tree and rebuild all the packages in EPEL into that 18:20:55 Do N weeks of 'testing', and then archive off old EPEL 7 and move epel/development/7.3 to current epel? 18:21:37 * nirik doesn't like the idea, mostly because it would be a bunch of work for not much gain. ;) 18:21:52 sometimes things need rebuilding, but usually it's not much 18:21:54 sounds like a brute force solution, but in theory it shouldn't break anything 18:22:43 also tie into it "if you need major updates to packages, put them into this cycle" 18:23:05 so thats when 7.3 rhel comes out, not centos? 18:23:34 nirik, yeah.. that way when centos 7.3 is 'ready' there is a good chance this is ready to roll out 18:24:19 I'll get to know how many EPEL packages need rebuilding once I get my hands on 7.3 QA rpms. those with access to RHEL 7.3 (even beta) would know sooner. 18:24:28 most of this is in case RHEL-7.4 goes with "Lets put in Gnome from Fedora 27" or some crazy thing 18:24:58 since they have talked about updating desktops in RHEL more frequently 18:25:05 but then how do we handle normal updates during that time? 18:25:28 we do a mass rebuild, then critical security update comes... does it build against something else? 18:25:42 and we also currently don't keep all the old external repos... 18:25:53 ie, when 7.3 comes out, our repo updates to 7.3 18:26:22 well ok lets take this the opposite way 18:26:43 7.3 comes out and we have major ABI changes across the board.. what do we want to do? 18:27:07 perhaps we could id all the stuff that does need rebuilds and do them? a targeted mass rebuild 18:27:21 the builders are going to be building stuff which people with 7.2 cant use until they update and the stuff we might have already built may not work on the 7.3 18:27:23 but that still leaves centos users in a lerch 18:28:12 I figure centos users in that case are going to be like people who don't update from 7.2 -> 7.3 for a month or two to see how it goes 18:28:47 I guess we could stop all updates when the rhel release comes out, rebuild things that need it and wait. When centos comes out push all that live 18:29:01 ah the joys of not knowing or controlling what might come into our laps 18:29:02 but that doesn't help security updates... 18:29:03 we do try to get the ContinuousRelease packages available quickly, so if there are problems with a too new EPEL package, we can tell people to enable CR and get the updated CentOS package 18:29:51 bstinson, Evolution any other ideas? 18:29:56 it's always a bit of a hassle with these point releases.. it's hard to avoid all problems. 18:30:06 avij, yes the CR have been very quick 18:30:11 smooge: no. I'm mostly cheering pbrobinson on aarch64 18:30:47 I think the best thing we can do is actually identify and rebuild stuff... rather than our usual lazy let the maintainers sort it out. 18:31:00 ok I think nirik's plan sounds like the best one. how hard is that to implement? 18:31:41 well, once we have the release we can do a repoclosure pretty easily... 18:31:47 that should get obvious stuff. 18:32:53 nirik: on the brilliance ... I've been trying, chatted to bstinson and Evolution about it and still not come up with that... 18:33:48 perhaps we just havent had enough beer yet. ;) 18:33:51 I wonder if the rpm-abi tool thrown around mailing lists recently would help with this 18:34:05 or if a simple repoclosure check is enough 18:35:13 theoretically repoclosure should be enough. if the ABI changes, the library names should be changed as well. 18:37:17 there may have been some cases where the changes have been stealthy, but at a minimum, they're very rare. 18:37:21 ok let us go with that. After 7.3 goes GA and we see it, we block building and do a repoclosure and do a bump/rebuild for anything that we can 18:37:22 * nirik nods. 18:37:40 it mostly just needs people to remember to actually work on it. 18:37:45 if there are things that need a bigger bump, we work with the maintainer to get them in place 18:38:08 if nothing comes up because we were very lucky, we unblock the builders 18:38:36 well unblock moving from updates-testing -> regular 18:38:44 right. I'll make sure to file bugs and/or send appropriate notifications when/if I see such a rebuilding need arise. 18:40:33 I'll be happy to assist if someone reminds me to do so. ;) 18:42:13 ok will do so 18:42:46 I am going to say we have hit BEEROCKLOCKAHMANWHEREISTHEBOTTLE time 18:42:59 #topic Open Floor 18:43:06 does anyone have anything for open floor 18:43:17 pbrobinson++ for aarch64 18:43:17 smooge: Karma for pbrobinson changed to 7 (for the f24 release cycle): https://badges.fedoraproject.org/tags/cookie/any 18:43:39 * nirik has nothing off hand 18:43:47 okie dokie. 18:43:54 will close out in 1 minute 18:46:04 smooge: nirik: so I'm about to kick off the first pass, don't hesitate to poke if there's koji issues, I'm running them all --background with a bit of sleep between 18:46:18 ok 18:46:19 ok. 18:46:23 hopefully it will be fine 18:46:23 #endmeeting