17:00:57 <smooge> #startmeeting EPEL
17:00:57 <zodbot> Meeting started Fri Sep 25 17:00:57 2015 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:14 <bstinson> hi all
17:01:18 <bryanpkc> hi
17:01:24 <smooge> #chairs dgilmore nirik Evolution bstinson avij
17:01:30 <avij> hello
17:01:33 <smooge> #chair dgilmore nirik Evolution bstinson avij
17:01:33 <zodbot> Current chairs: Evolution avij bstinson dgilmore nirik smooge
17:01:39 <smooge> #topic Hellos
17:02:15 <avij> good evening everyone
17:03:26 <smooge> I am in aother meeting
17:03:46 <smooge> nirik is building a new server.
17:03:52 <smooge> dgilmore, is in the same meeting as I am in
17:04:03 <smooge> and Evolution is at a show
17:04:21 <smooge> so I don't think we have quorum
17:05:22 <smooge> avij, or bstinson could you run things for 15 minutes while I try to get out of this meeting?
17:05:47 <bstinson> sure, let me grab a copy of the agenda
17:06:54 <dgilmore> hola
17:07:01 <dgilmore> what smooge said
17:07:18 <bstinson> #topic EPEL for ${alternate_arches}
17:08:30 <bstinson> #info CentOS is closing on a GA release of the i686 build. We need to re-spin the install media and some other bits
17:08:58 <bryanpkc> last time I think nirik was going to check with the Fedora secondary arch maintainer on wrangling Koji to build alternate arches; I wonder what he found out (I know nirik is not here atm)
17:09:47 <smooge> actually it was dgilmore who was going to say what was needed I believe
17:10:31 <smooge> bryanpkc, but since it hasn't moved forward I have added a personal ticket to get that asked
17:10:53 * bryanpkc just looked at last meeting's minutes
17:11:03 <bryanpkc> smooge, thanks
17:11:33 <bryanpkc> i can make a brief update on package building progress...
17:12:03 <bryanpkc> we are figuring out the reasons for the failures for a bunch of packages, and will file bugzillas for them in the next week or so
17:12:44 <bstinson> bryanpkc: great!
17:12:54 <bryanpkc> but we just found out that the SRPMs we downloaded from dl.fedoraproject.org were old (circa late 2014)
17:13:14 <bryanpkc> some of the bugs (e.g. spacecmd failing with pylint errors) have been fixed in later releases of the SRPMs
17:13:55 <bryanpkc> This is where we got our SRPMs: https://dl.fedoraproject.org/pub/epel/7/SRPMS/
17:14:35 <bryanpkc> So some of the bugs we see may be dups
17:16:36 <bryanpkc> Did we download the SRPMs from the right place? Or is there a better way to get up-to-date SRPMs?
17:17:12 <avij> dunno, I do see fresh srpms in there
17:18:07 <avij> admittedly not that particular spacecmd-2.3.20 ..
17:18:35 <bryanpkc> ok
17:18:48 <avij> oh, https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-5852 tells me that spacecmd is still in testing. it's not in stable.
17:19:39 <avij> so it looks like the srpms on dl.fedoraproject.org are only for the EPEL packages that are in stable
17:19:48 <smooge> ok meeting over
17:19:51 <bryanpkc> avij, thanks! good to know.
17:19:58 <smooge> dgilmore, you can focus here now
17:20:23 <bstinson> bryanpkc: http://pkgs.fedoraproject.org/cgit/ <- that will give you SPECs for the latest and greatest (see the epel branches)
17:20:29 <dgilmore> okay
17:20:36 <dgilmore> sorry for the delay
17:21:03 <bryanpkc> issues we are still facing: cyclic deps, deps not found in RHEL (I suspect they are only found in Fedora or CentOS), and differences between java-devel-openjdk and java-devel (defaults to java-devel-ibm)
17:21:24 <dgilmore> bryanpkc: that location is the latest srpms
17:21:39 <bryanpkc> dgilmore: thanks for confirming
17:23:15 <bryanpkc> bstinson: thanks for the link
17:23:28 <bstinson> do we have updates for aarch64 and/or ppcle?
17:24:34 <dgilmore> so we will need to setup a rsync job for 32 bit CentOS
17:24:49 <dgilmore> and add aarch64 and ppc64le to the existing RHEL syncing
17:25:13 <dgilmore> to do s390 we would need to look at the builder situation
17:25:22 <dgilmore> but down the road it may be possible
17:25:31 <bryanpkc> dgilmore: IBM can supply free VMs for open source communities
17:25:41 <bryanpkc> the debian community has got a couple of builders that way
17:26:19 <dgilmore> bryanpkc: we have some ideas.  just trying to sort out the details. It is likely e a little later if we do it
17:26:34 <bryanpkc> ok
17:26:45 <dgilmore> we would need to do some bootstrapping and use that as a temporary external repo
17:27:07 <bstinson> bryanpkc: we're definitely glad to have you working on those bugs, that will make things much easier
17:27:17 <dgilmore> then scratch build everything. there is aprocess we can follow to import those scratch builds and logs to add teh extra arches
17:27:34 <dgilmore> once thats done we can drop the temporary external repo
17:27:38 <dgilmore> and profit
17:27:57 <bryanpkc> dgilmore: I think I get the idea.
17:27:59 <dgilmore> none of it is overly difficult
17:28:03 <dgilmore> just time consuming
17:28:16 <dgilmore> we will have some power 8 builders available soon
17:28:23 <dgilmore> so we could build ppc64le
17:29:04 <bryanpkc> thank you all. i have to run to another meeting. before i go, just a quick question:
17:29:11 <avij> for CentOS rsync, rsync from mirror.centos.org is only available for publicly listed mirrors. if you want to rsync from mirror.c.o, you would need to ask Arrfab to add the appropriate IP addresses to the ACL.
17:29:34 <dgilmore> avij: cheers. we would need to do that
17:29:42 <bryanpkc> mock config for epel-7-x86_64 comes configured with CentOS repos... that is not how EPEL 7 officially builds right?
17:30:16 <dgilmore> bryanpkc: correct
17:30:32 <bryanpkc> would EPEL 7 builds source dependencies from only RHEL 7, or from both RHEL 7 and Fedora?
17:30:41 <dgilmore> bryanpkc: the ppc one i think likely points at a non existant CentOS ppc tree also
17:31:00 <dgilmore> bryanpkc: EPEL 7 only gets dependencies from RHEL
17:31:13 <dgilmore> there is no cross polenation from Fedora
17:31:17 <bryanpkc> ok, thanks for confirming
17:31:27 <bryanpkc> except when bootstrapping ghc, I think ;-)
17:31:35 <dgilmore> we point the mock configs at CentOS as that is available to everyone
17:31:46 <dgilmore> ghc was a special nasty case
17:32:01 <bryanpkc> yeah, we chatted with the maintainer (sorry can't remember the name)
17:32:06 <bryanpkc> ok thanks a lot
17:32:09 <bryanpkc> have a great weekend
17:33:11 <bstinson> ok, anything else new for alternate architectures?
17:34:24 <dgilmore> Jens
17:34:32 <dgilmore> nada
17:34:48 <bstinson> #topic EPEL and CentOS SIGs
17:35:40 * nirik is sort of kinda here, but also busy with a migration
17:35:42 <dgilmore> So what would it take to enable EPEL as a external repo in CBS?
17:36:22 <nirik> dgilmore: I'm not sure that will meet there needs, but then I am not fully sure what the needs are.
17:37:23 <bstinson> dgilmore: that's something for the SIGs + the Core SIG to decide i think
17:37:30 <dgilmore> nirik: I am not sure why it wouldn't meet thier needs, but I am thinking there is something I am missing and do not understand
17:37:36 <bstinson> we haven't really had our own discussion in centos space for that
17:37:46 <avij> I'm primarily of the opinion that CentOS SIG people should work with EPEL package maintainers to make sure the EPEL packages would be OK for their needs without needing a rebuild within SIGs.
17:37:51 <bstinson> as it sits, the policy is "if you need it, you have to build it"
17:37:55 <dgilmore> bstinson: Okay, I think it would completely suit the purpose
17:38:34 <smooge> so I think part of the issue is that the problem is being presented as something that is affecting all SIGs but i think it is more like 1-2
17:38:53 <smooge> and trying to fix it for those 1-2 may actually break it for the others
17:39:05 <smooge> bstinson, when are the SIG meetings?
17:39:30 <nirik> some clear examples/use cases might help us... to know what they want to do
17:39:37 <nirik> so we could figure out how best to do it
17:39:45 <bstinson> we're having a CBS meeting on Monday at 14UTC in #centos-devel
17:39:59 <bstinson> there was call for a special meeting sometime someplace to discuss this topic
17:40:50 <dgilmore> smooge: you could enable it only for those 1-2
17:40:58 <dgilmore> have it just in the buildroots for them
17:41:21 <smooge> dgilmore, so what I think is that they want newer stuff than what EPEL has in it
17:41:25 <dgilmore> but I also am not fully aware of how CentOS is setting up tags and buildroots for the SIG's in CBS
17:41:49 <dgilmore> smooge: in that case they are on their own
17:41:51 <smooge> but I am confused also what the problem is
17:42:09 <dgilmore> depending on what it is and how it fits into EPEL's policy
17:42:25 <smooge> bstinson, I have added it to my calender. Can this be brought up in a soon meeting to get a better idea of what is the problem tyring to be solved
17:42:28 <dgilmore> smooge: I think everyone is confused as to what the problem is
17:42:40 <smooge> and who needs it fixed and where
17:42:50 <dgilmore> so hopefully bstinson can make it clearer on Monday
17:42:51 <bstinson> so the problem is: say I'm in the virt sig, i need dozens of python libraries to satisfy my dependencies, and those deps have to come from somewhere
17:43:26 <bstinson> as it exists, i need to build all those deps in my SIG tag before i can get back to the starting line with building openstack
17:43:50 <dgilmore> sure
17:43:52 <bstinson> (my opinion is that's a feature not a bug, but that's irrelevant)
17:44:12 <bstinson> a common pattern is to pull the SPECS + sources from EPEL and build those deps in the tag
17:44:24 <dgilmore> if those things exist in EPEL then add epel to your buildroot tag structure and they are there
17:44:43 <dgilmore> but they are the versions in epel
17:45:11 <dgilmore> then you need to tell people using your sig's output they have to enable EPEL and the sig
17:45:17 <bstinson> current policy is: if you depend on it, you build it (soon to be added: if you build it, it comes from git.centos.org)
17:45:26 <dgilmore> if they buld it all tmselves they could add just the sig
17:45:34 <dgilmore> bstinson: okay
17:46:47 <avij> what I'm missing here are the actual technical reasons why SIGs can't use EPEL packages. "it's the policy" does not convince me.
17:47:18 <dgilmore> avij: technically there is no reason
17:47:38 <dgilmore> you create a tag that has epel as an external repo
17:47:39 <bstinson> avij: i wan't around for the policy discussions, but i do think there's value in shipping a closure from every SIG (base + SIG repo)
17:47:48 <dgilmore> then you add that tag into inheritance
17:47:58 <dgilmore> and you get epel available to build against
17:48:17 <dgilmore> bstinson: there is some value in that yes
17:48:26 <avij> if it's that the SIGs need newer versions, SIGs should offer their assistance to the EPEL package maintainers to bump up the version, hopefully without breaking anyone's existing installations. not breaking existing installations should also be a goal for the SIGs, even if they use their own rebuilds.
17:48:42 <dgilmore> a lot of this sounds like the types of discussions I have seen about layered products
17:49:09 <smooge> avij, a lot of the software the SIGs are working on is more of the "break every release" type
17:49:11 <dgilmore> avij: right, we get into EPEL updating policy there
17:50:20 <smooge> anyway.. this is the weeds since most of this is outside of this groups control
17:50:24 <bstinson> but from our (EPEL) perspective, we shouldn't care much what the SIGs are doing. I personally would like to see them treat EPEL like an upstream, pick what deps they need, and build it in their tags (or in a cbs-common repo)
17:50:37 <avij> the discussions so far have centered around building the packages, but I'm also concerned about end users. it might be messy if someone used some SIG's repository (including rebuilt EPEL packages) and EPEL together.
17:51:19 <smooge> I am guessing that like all layered products.. don't cross the streams (mix the repos) is going to be the solution
17:53:29 <smooge> ok anyway.. we are coming up to the top of the hour.
17:53:35 <bstinson> i think we can work on a few things from our (EPEL) end
17:53:48 <smooge> bstinson, I will be at the meeting on Monday and will try to be helpful
17:53:49 <bstinson> the epel-provenpackager discussion is interesting, and i know we've talked about it before
17:54:38 <avij> I'll try to be around in the CBS meeting as well
17:55:23 <bstinson> awesome!
17:55:53 <smooge> ok time to move onto open floor?
17:56:11 <smooge> #topic open flood?
17:56:27 <smooge> any items for next meeting?
17:56:51 <smooge> if not I am going to close in 1 minute?
17:57:09 <smooge> thank you avij and bstinson for steering this meeting
17:57:30 <smooge> #endmeeting