17:03:00 <dgilmore> #startmeeting EPSCo (2015-05-15)
17:03:01 <zodbot> Meeting started Fri May 15 17:03:00 2015 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:03:21 <dgilmore> #chairs avij bstinson dgilmore Evolution nirik
17:03:28 <nirik> morning
17:03:29 <dgilmore> #topic init
17:03:37 <dgilmore> #chair avij bstinson dgilmore Evolution nirik
17:03:37 <zodbot> Current chairs: Evolution avij bstinson dgilmore nirik
17:03:41 <avij> good evening
17:03:50 <bstinson> hi all
17:04:28 <Evolution> morning
17:04:33 <dgilmore> so im pretty unorganised
17:04:46 <dgilmore> and I am honestly not 100% sure what items we have to discuss
17:05:19 <dgilmore> #topic python3
17:05:34 <dgilmore> nirik: did we get epel-rpm-macros stable?
17:05:42 <nirik> I just submitting it this morning.
17:06:09 <dgilmore> okay, so we can add it to the build and srpm-build minimal buildroots as soon as its tagged stable
17:06:09 <nirik> the review hasn't started yet for python34, but hopefully abompard will take it.
17:06:21 <dgilmore> will need to add it to buildsys-build in comps also
17:06:58 <nirik> ok. can you take care of that part? or would you like me to?
17:07:04 <dgilmore> I can do it
17:07:15 <nirik> cool
17:07:42 <dgilmore> #action dgilmore to add epel-rpm-macros to correct groups for comps and koji
17:08:01 <dgilmore> #topic meeting time
17:08:12 <dgilmore> seemed this meeting slot was the winner still
17:08:20 <nirik> yep. So I think we just stick with it.
17:08:28 <bstinson> +1
17:08:37 <avij> ok for me
17:08:38 <dgilmore> I added it to the epel calendar today
17:08:54 <dgilmore> and set it up to send a reminder to the list 12 hours before
17:09:11 <nirik> ok.
17:09:37 <dgilmore> mostly for my own needs
17:09:51 <dgilmore> I fail to do things without appropriate reminders
17:09:56 <dgilmore> I get distracted too much
17:10:31 <dgilmore> #topic restart epic discussions
17:10:57 <bstinson> i've been meaning to collaborate with smooge_away about this, but i haven't had a chance to yet
17:11:03 <dgilmore> okay
17:11:26 <dgilmore> I think there is value in having a seperate repo that allows things to move faster
17:12:00 <dgilmore> #action bstinson to talk with smooge and present a plan
17:12:00 <nirik> there could be. There's tons of ways to do it tho.
17:12:07 <dgilmore> indeed there is
17:13:40 <dgilmore> #topic meeting process
17:14:07 <dgilmore> So when doing today poorly I realised we do not have documented how to run meetings etc
17:14:29 <nirik> yeah, we should clone the fesco process and adjust it. ;)
17:14:37 <dgilmore> I think we should setup a wiki page witha  meeting process, much like the FESCo and releng ones
17:14:43 <dgilmore> yeah
17:14:55 <dgilmore> makes things nice to do
17:15:01 <dgilmore> nirik: do you want to do that?
17:15:15 <bstinson> +1 from me
17:15:34 <Evolution> I'm good with it.
17:15:37 <nirik> I can I suppose if no one else wants to. ;)
17:15:39 <avij> sure
17:16:52 <nirik> oh, question related to that: should we start doing our meetings in #fedora-meeting?
17:17:04 <nirik> might make more people know we exist and they could get involved?
17:18:08 <dgilmore> nirik: probably best to do them in one of the meeting rooms
17:19:47 <bstinson> i don't have a problem with that but if we're changing locations, we should announce very loudly
17:19:49 <dgilmore> proposed #agreed move the meeting to an available #fedora-meeting room
17:19:57 <dgilmore> bstinson: sure :)
17:20:10 <dgilmore> im +1 obviously
17:21:00 <avij> I'm not opposed to that
17:21:06 <bstinson> +1
17:21:10 <nirik> #fedora-meeting is open at this time, seems fine.
17:21:25 <dgilmore> nirik: perfect
17:22:21 <dgilmore> #agreed move the meeting to #fedora-meeting
17:22:31 <dgilmore> #topic next weeks chair
17:22:42 <dgilmore> who would like to run the meeting next week?
17:23:25 <dgilmore> don't all speak up at onece ;)
17:23:27 <Evolution> I can do the one after. I'm not familiar with the 'fedora' way of doing meetings
17:23:50 <dgilmore> Evolution: its easy :) and we will have a wiki page that tells you exactly what to do
17:23:54 <nirik> https://fedoraproject.org/wiki/EPEL-meeting-process
17:23:59 <Evolution> wfm
17:24:03 <Evolution> I'll take the next one then.
17:24:10 <nirik> I can do next week
17:24:13 <dgilmore> #info Evolution to run next weeks meeting
17:24:22 <nirik> oh, or Evolution can. thats great.;)
17:24:27 <Evolution> heh
17:24:32 <dgilmore> #topic open floor
17:24:49 <Evolution> only thing I wanted to bring up is aarch64.
17:24:59 <dgilmore> I had something but I forget it right now :(
17:25:04 <dgilmore> Evolution: okay
17:25:07 <Evolution> We've got an alpha out the door, and hopefully in a month or so we'll be 'official'
17:25:14 <dgilmore> awesome
17:25:32 <Evolution> how can we get epel building on that without duplicating it ourselves.
17:25:42 <dgilmore> are we wanting to add it as an offical arch?
17:25:50 <dgilmore> or setup some secondary arch process?
17:26:13 <Evolution> that's essentially my question
17:26:18 <Evolution> what makes the most sense for it?
17:26:40 <Evolution> I don't fully grasp the difference in how the builders are set up for 'official' vs secondary arch
17:26:59 <Evolution> for centos, it's an alt arch effort, so it's not 'official' on our end.
17:27:02 <dgilmore> we should be able to do either
17:27:07 <Evolution> though it may become so later.
17:27:15 <dgilmore> though we do not have any production hardware in phx2
17:27:52 <dgilmore> whats the status of i386?
17:28:18 <Evolution> johnny's got it built and will be doing media soon.
17:28:23 <dgilmore> okay
17:28:24 <Evolution> we have to work out how we sign it.
17:28:40 <dgilmore> there was people wanting 32 bit wine
17:28:41 <Evolution> some of the noarch is already signed with the official key, but we're not going to sign alt-arch with the same key.
17:28:47 <dgilmore> which is not doable
17:29:07 <Evolution> hopefully we'll have the signing sorted fairly soon and put it out.
17:29:18 <dgilmore> cool
17:29:35 <dgilmore> koji-shadow does not support external repos
17:29:39 <Evolution> lorax working makes things quite easy.
17:29:50 <Evolution> oh, hmmm
17:29:50 <dgilmore> so to do it as a secondary arch effort is going to take tooling development
17:30:07 <dgilmore> Evolution: there is a epel7 branch of pungi
17:30:20 <dgilmore> Evolution: it should work for making media
17:30:35 <dgilmore> if you are using it with extra patches I would be interested in them
17:31:53 <Evolution> okay. I'm fine with doing it as an 'official' arch if that makes it easier.
17:32:17 <Evolution> right now I've put mock and its deps in our 'extras' repo but they're clones of what's in epel, so the transition should be easy
17:32:29 <dgilmore> okay
17:32:50 <dgilmore> I know some people want ppc64le added to epel
17:33:12 <dgilmore> its easier for building and shipping if we do all arches together
17:33:29 <dgilmore> we would need to setupsomething to provide a base to build on
17:33:41 <dgilmore> that would take some experimentation in the staging koji
17:33:51 <Evolution> we'd also have to line up the package differences.
17:34:03 <Evolution> iirc there was something on the list earlier about ppc64le and thunderbird
17:34:08 <dgilmore> I am happy to ship 32 bit x86, aarch64 and ppc64le as part of epel proper
17:35:21 <Evolution> the more usage/adoption we can get the better.
17:35:29 <dgilmore> indeed
17:35:52 <dgilmore> its just going to take some finangling on the backend to get it all working right
17:35:58 <avij> one of the problems has been that RHEL does not provide all packages for all architectures, causing build issues for some EPEL packages. it'd be nice if RHEL provided the same packages for all architectures.
17:36:27 <rsc> avij: yes, but my business ticket with Red Hat was refused
17:36:29 <dgilmore> avij: thats almost a non issue in rhel7
17:36:43 <Evolution> avij: bstinson was talking about building some of those checks into jenkins/ci.
17:37:02 <Evolution> I *think* task-o-tron or whatever on the fedora side can do similar.
17:37:18 <Evolution> I'll defer to dgilmore or nirik on that one
17:37:52 <dgilmore> we have ways to detect the differences
17:38:08 <nirik> IMHO, when rhel doesn't offer a package on some arch we should exclude that arch on the epel package that needs it too.
17:38:29 <nirik> but sadly, we allowed the limited arch packages, so I guess the ship has sailed.
17:38:55 <dgilmore> biggest place it caused issues was java
17:39:07 <dgilmore> and openjdk ships on all arches in rhel7
17:39:30 <nirik> sure, there are others too tho... like qemu... but anyhow, we digress. ;)
17:39:39 <dgilmore> indeed
17:39:52 <avij> yes, the limited arch package situation can be a bit messy, especially if some EPEL packagers don't follow the rules re versioning
17:40:24 <dgilmore> yeah, we really need bodhi to enforce the rules
17:40:39 <avij> right
17:40:47 <bstinson> dgilmore: are those checks published anywhere?
17:41:16 <dgilmore> bstinson: kinda
17:42:21 <dgilmore> bstinson: https://infrastructure.fedoraproject.org/repo/json/
17:42:32 <dgilmore> we have json files for each el release
17:42:41 <dgilmore> it has the builds and arches etc
17:42:59 <dgilmore> so we have what is needed to automate making sure people do not violate the rules
17:43:11 <dgilmore> its implemented in pkgdb afaik
17:43:20 <dgilmore> i.e. you can not brancha  rhel package
17:43:29 <dgilmore> we do not have enforcement in the bodhi side
17:43:58 <rsc> But sometimes you need to branch if RHEL doesn't cover all archs?
17:44:44 <dgilmore> rsc: it is supposed to allow that
17:45:20 <avij> I'm pretty sure I've seen RHEL packages end up duplicated to EPEL, so that check does not seem to be implemented in pkgdb
17:45:43 <nirik> avij: are you sure they are not limited arch packages?
17:45:50 <rsc> Yes, I think lzo or one of the packages that I maintain is affected by that.
17:45:57 <nirik> and yes, in the past there have been mistakes... the pkgdb check is pretty recent
17:46:00 <dgilmore> avij: its only fairly new
17:46:20 <avij> nirik: as in, I've seen EPEL packages that want to update RHEL (or rather, CentOS) packages. yes.
17:46:26 <dgilmore> it was added to pkgdb when we added support to request branches in pkgdb
17:46:45 <nirik> avij: yes, sure, I have too. Hopefully tho that will be less likely moving forward now.
17:47:01 <nirik> of course it's also a moving target.
17:47:30 <dgilmore> right
17:47:50 <avij> ok. I'll continue keeping an eye on this. I'll get an alert by email every time someone screws up.
17:47:51 <dgilmore> we need to setup automated processes to know when to yank things out of epel
17:47:52 <bstinson> not sure how much time i can spend on it, but i'll take a look at the problem space (my motivation is to get some basic tests in our CI environ so other 3rd party repos can be validated against CentOS)
17:48:08 <bstinson> avij: i might ping you soon about the work you've done
17:48:16 <avij> bstinson: ack
17:48:42 <dgilmore> so back to Evolution's question I think we should support the arches we can
17:48:57 <bstinson> +1 on that :)
17:49:16 <dgilmore> for i386 we would need to build against CentOS
17:49:28 <dgilmore> probbaly for aarch64
17:49:38 <dgilmore> though we need hardware for aarch64
17:50:14 <Evolution> I'm fairly certain we can make the hardware happen.
17:50:31 <Evolution> that or we can always raid jcm's house for spare parts.
17:50:49 <dgilmore> Evolution: well main issue is getting production level supported hardware
17:51:02 <Evolution> *cough*
17:51:03 <rsc> dgilmore: don't we have aarch64 hardware because of Fedora?
17:51:04 <dgilmore> since phx2 is an unmanned colo
17:51:06 <Evolution> uh... that exists?
17:51:17 <dgilmore> Evolution: soonish
17:51:19 <nirik> it will soon hopefully
17:51:49 <dgilmore> rsc: fedora's aarch64 boxes are not in phx2
17:52:05 <rsc> dgilmore: and we can only build in phx2?
17:52:42 <dgilmore> rsc: that is where we have control. we would need hardware, proxy server and other bits elsewhere
17:54:07 <dgilmore> #info consenus is that we want to support more arches in epel. but we need to come up with a plan and do some testing to implement
17:54:20 <dgilmore> anyone else have anything to bring up?
17:54:49 <avij> just my two cents.. my background is in testing -- I'm fine with all kinds of proposals to improve EPEL, as long as things don't break. I have a few topics that I'd like to bring up re EPEL testing, but I'll need to think them through myself first. I'll write a summary of my thoughts to the list next week (hopefully).
17:55:41 <dgilmore> avij: :) awesome
17:55:53 <dgilmore> epel can do with more testing
17:57:46 <dgilmore> okay, taking that as nothing more
17:57:50 <dgilmore> #endmeeting