18:00:26 <smooge> #startmeeting EPEL
18:00:26 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:26 <zodbot> The meeting name has been set to 'epel'
18:00:26 <smooge> #meetingname EPEL
18:00:26 <zodbot> The meeting name has been set to 'epel'
18:00:26 <smooge> #chair smooge nirik Evolution bstinson avij
18:00:26 <zodbot> Current chairs: Evolution avij bstinson nirik smooge
18:00:26 <smooge> #topic aloha
18:00:36 <nirik> morning
18:00:39 <avij> hello world
18:00:40 <smooge> good day
18:01:27 <Evolution> moonin
18:02:10 <bstinson> hi all
18:02:24 <smooge> bstinson is probably recovering from install.. no never mind
18:03:01 <smooge> #topic Agenda Light
18:03:12 <nirik> aarch64 landing
18:03:22 <smooge> #info aarch64 landing
18:03:34 <smooge> #info arinov> telegram-cli must be removed from el6 repository, it works only on new version of libc
18:04:34 <smooge> anything else?
18:04:50 <smooge> nirik, what is needed for the aarch64? RHEL-7.3
18:05:02 <nirik> it's landing now, pbrobinson is working on it.
18:05:10 <nirik> 7.2 is new enough
18:05:13 <smooge> ah ok
18:05:25 <nirik> so, there may be some churn as things are added, etc...
18:05:35 <nirik> but hopefully it will be as smooth as the ppc stuff was
18:05:46 * pbrobinson waves
18:06:08 <smooge> #info smooge owes pbrobinson a beer. [and not a Foster's]
18:06:17 <nirik> we all do. ;)
18:06:38 <pbrobinson> 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 <smooge> that makes sense
18:07:19 <nirik> 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 <pbrobinson> so I've still not come up with or been offered a decent solution to that
18:08:15 <smooge> oh I thought you had a solution to that
18:08:33 <smooge> maybe we just do them in a different koji/builder system
18:08:40 <pbrobinson> 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 <pbrobinson> so we could end up with builds built against two different versions
18:09:07 <smooge> and we tie that koji/builder system to the centos builders since they would be the ones pushing it
18:09:36 <pbrobinson> smooge, but them we hold up the primary arches which is the vast majority of users
18:09:53 <smooge> well it would not be connected to the main one
18:10:10 <pbrobinson> so like a koji-shadow style system?
18:10:24 <smooge> could be.
18:10:51 <pbrobinson> 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 <smooge> 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 <nirik> yeah, it's all tricky.
18:11:53 <smooge> 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 <pbrobinson> smooge: so basically what Evolution has been doing with some of the aarch64 stuff to date.
18:12:04 <smooge> I was actually going to say we look at something else also
18:12:06 <pbrobinson> which is basically EPEL but not EPEL
18:13:23 <smooge> 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 <Evolution> for that case, do we ask epel to be able to use the name EPEL?
18:13:51 <Evolution> or include as a component of the repo name
18:14:00 <nirik> or just call it something else?
18:15:28 <Evolution> I think we'd need to include epel in the name as a reference to where the sources are coming from
18:15:34 <smooge> well I am not looking for a solution right here. I wanted to get people thinking abou it if possible
18:16:17 <nirik> yeah, perhaps something brilliant will occur. )
18:17:15 <smooge> #topic Doing a release rebuild
18:18:20 <smooge> 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 <avij> I don't know yet, but chances are that some packages will need to be recompiled against new libraries
18:20:08 <smooge> 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 <smooge> 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 <nirik> sometimes things need rebuilding, but usually it's not much
18:21:54 <avij> sounds like a brute force solution, but in theory it shouldn't break anything
18:22:43 <smooge> also tie into it "if you need major updates to packages, put them into this cycle"
18:23:05 <nirik> so thats when 7.3 rhel comes out, not centos?
18:23:34 <smooge> nirik, yeah.. that way when centos 7.3 is 'ready' there is a good chance this is ready to roll out
18:24:19 <avij> 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 <smooge> 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 <smooge> since they have talked about updating desktops in RHEL more frequently
18:25:05 <nirik> but then how do we handle normal updates during that time?
18:25:28 <nirik> we do a mass rebuild, then critical security update comes... does it build against something else?
18:25:42 <nirik> and we also currently don't keep all the old external repos...
18:25:53 <nirik> ie, when 7.3 comes out, our repo updates to 7.3
18:26:22 <smooge> well ok lets take this the opposite way
18:26:43 <smooge> 7.3 comes out and we have major ABI changes across the board.. what do we want to do?
18:27:07 <nirik> perhaps we could id all the stuff that does need rebuilds and do them? a targeted mass rebuild
18:27:21 <smooge> 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 <nirik> but that still leaves centos users in a lerch
18:28:12 <smooge> 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 <nirik> 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 <smooge> ah the joys of not knowing or controlling what might come into our laps
18:29:02 <nirik> but that doesn't help security updates...
18:29:03 <avij> 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 <smooge> bstinson, Evolution any other ideas?
18:29:56 <avij> it's always a bit of a hassle with these point releases.. it's hard to avoid all problems.
18:30:06 <smooge> avij, yes the CR have been very quick
18:30:11 <Evolution> smooge: no. I'm mostly cheering pbrobinson on aarch64
18:30:47 <nirik> 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 <smooge> ok I think nirik's plan sounds like the best one. how hard is that to implement?
18:31:41 <nirik> well, once we have the release we can do a repoclosure pretty easily...
18:31:47 <nirik> that should get obvious stuff.
18:32:53 <pbrobinson> 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 <nirik> perhaps we just havent had enough beer yet. ;)
18:33:51 <Evolution> I wonder if the rpm-abi tool thrown around mailing lists recently would help with this
18:34:05 <Evolution> or if a simple repoclosure check is enough
18:35:13 <avij> theoretically repoclosure should be enough. if the ABI changes, the library names should be changed as well.
18:37:17 <avij> there may have been some cases where the changes have been stealthy, but at a minimum, they're very rare.
18:37:21 <smooge> 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 <nirik> it mostly just needs people to remember to actually work on it.
18:37:45 <smooge> if there are things that need a bigger bump, we work with the maintainer to get them in place
18:38:08 <smooge> if nothing comes up because we were very lucky, we unblock the builders
18:38:36 <smooge> well unblock moving from updates-testing -> regular
18:38:44 <avij> 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 <nirik> I'll be happy to assist if someone reminds me to do so. ;)
18:42:13 <smooge> ok will do so
18:42:46 <smooge> I am going to say we have hit BEEROCKLOCKAHMANWHEREISTHEBOTTLE time
18:42:59 <smooge> #topic Open Floor
18:43:06 <smooge> does anyone have anything for open floor
18:43:17 <smooge> pbrobinson++ for aarch64
18:43:17 <zodbot> 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 <smooge> okie dokie.
18:43:54 <smooge> will close out in 1 minute
18:46:04 <pbrobinson> 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 <smooge> ok
18:46:19 <nirik> ok.
18:46:23 <nirik> hopefully it will be fine
18:46:23 <smooge> #endmeeting