18:01:09 <smooge> #startmeeting EPEL
18:01:09 <zodbot> Meeting started Wed Aug 31 18:01:09 2016 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:09 <zodbot> The meeting name has been set to 'epel'
18:01:09 <smooge> #meetingname EPEL
18:01:09 <zodbot> The meeting name has been set to 'epel'
18:01:09 <smooge> #chair smooge nirik Evolution bstinson avij
18:01:09 <zodbot> Current chairs: Evolution avij bstinson nirik smooge
18:01:09 <smooge> #topic aloha
18:01:15 <nirik> morning
18:01:44 <smooge> .hello smooge
18:01:45 <zodbot> smooge: smooge 'Stephen J Smoogen' <smooge@gmail.com>
18:01:51 <tpokorra> .hello tpokorra
18:01:52 <zodbot> tpokorra: tpokorra 'Timotheus Pokorra' <timotheus.pokorra@solidcharity.com>
18:02:07 <Evolution> morning
18:02:14 <avij> .hello avij
18:02:15 <zodbot> avij: avij 'Anssi Johansson' <rhbugs@miuku.net>
18:02:32 <bstinson> hi all
18:04:33 <smooge> #topic Outstanding issues
18:04:41 <smooge> OK from the list.
18:04:55 <smooge> 1) I and bstinson have made no headway on a PRD for EPEL.
18:05:18 <smooge> 2) there has been a lot of discussion on the lists about various proposals
18:05:32 <Evolution> that was a polite way to bring up SCLs
18:05:35 <Evolution> :-P
18:05:39 <smooge> 3) Tibbs came up with the rest of the agenda
18:05:47 <tibbs> Sorry...
18:07:13 <smooge> #topic Adding newer tools to EPEL build roots
18:07:32 <smooge> So the discussion on the list was about adding SCLs for C++ 11
18:07:42 <smooge> and similar monstrosities :)
18:07:55 <nirik> I am very against adding all scls. I'm ok with devtoolset if we can just do that one only.
18:08:23 <tibbs> Hopefully whatever configurations mock uses will be updated to add the same things.
18:08:32 <tibbs> Otherwise development can get difficult.
18:09:04 <nirik> it's still not clear to me that we can just enable devtoolset. I guess I need to sit down and look into it.
18:10:12 <smooge> nirik, want to put that as a "deliverable by 2 meetings from now"?
18:10:32 <smooge> and probbaly more than just you looking at it
18:10:34 <nirik> sure. I can add it to my todos
18:11:18 <Evolution> so, pardon my understanding here, but I thought fedora reached some flavor of decision on scls a while back
18:11:19 <orc_fedo> nirik: problem with experimentation and deciding to proceed, is that your testing might miss a problem, or conflicts might emerge later -- then someone fat-fingers a NEVR stroing, and the builder gtets poisoned --- reverting out mistakes seems harder without explicit engineering policies, which I don't think you can get articulated with'devtools'
18:11:37 <Evolution> there was a reasonably impassioned mailing list thread about it
18:11:40 <Evolution> (or several)
18:11:40 <nirik> Evolution: yes, it's "no"
18:11:59 <smooge> though some people seem to have interpreted no as yes
18:12:16 <nirik> orc_fedo: I'm not sure I understand what you are proposing. ;)
18:12:51 <orc_fedo> nirik: I think it is a mistake to put devtools in without understanding the rules under which it will be curated over time
18:13:19 <nirik> oh, I agree... the todo I was talking about above was to see if it's even possible to just enable that.
18:13:26 <nirik> I know we will need more policy...
18:13:32 <nirik> it has a 3 year lifecycle for example
18:16:06 <tibbs> Note that accepting SCLs into the distribution without Fedora being allowed to change anything at all, and EPEL enabling a Red Hat-supplied SCL, are rather different things.
18:17:20 <Evolution> it all still needs planning/policy
18:17:36 <tibbs> In Fedora one implies the other, but EPEL is a bit different.
18:17:43 <Evolution> but I think this is a case where EPEL policy could(should?) differ from fedora proper
18:17:57 <tibbs> Really it shouldn't be hard at all to just package the stuff, but someone has to maintain it.
18:18:47 <smooge> well there are 3 things:
18:19:11 <smooge> s/well/
18:19:47 <smooge> 1) Do CentOS and RHEL SCLs look similar to someone doing a mock/koji build.
18:19:52 <nirik> devtoolset is a bit of a different case... since it doesn't affect the users and has a specific narrow usecase
18:20:09 <smooge> s/SCLs/devtoolset/
18:20:09 <nirik> I just looked and yes, devtoolset for rhel is it's own seperate repo.
18:20:30 <nirik> I don't know how it's setup in centos off hand
18:20:41 <smooge> 2) Does it allow for just it being turned on. (Yes according to nirik)
18:21:15 <smooge> 3) What are the policies for packages built with it when devtoolset gets major updates etc
18:21:30 <smooge> 4) What are the policies for dealing with devtoolset different life
18:21:34 <smooge> 5) I can't count
18:22:44 * nirik nods. Yes, it needs a detailed writeup.
18:23:36 <smooge> is there anything i am missing?
18:23:40 <nirik> I see that it has scl-utils in it, and so does epel6
18:25:34 <nirik> so, perhaps we communicate back to the thread and see if anyone wants to write up a more detailed proposal (on the wiki?)
18:25:38 <tibbs> Anyone know if enabling the devtoolset would cause the scl RPM macros to be installed?
18:26:05 <tibbs> Because those things are very fragile and I already had to work around them in epel-rpm-macros.
18:26:30 <smooge> tibbs, no
18:26:56 <smooge> 6) Does installing devtoolset enable scl RPM macros
18:27:10 <nirik> are they in scl-utils? or somewhere else?
18:27:41 <nirik> yeah, they are in a package in that repo:
18:27:43 <nirik> rpm -qp scl-utils-build-20120613-1.el6.x86_64.rpm -l
18:27:48 <nirik> /etc/rpm/macros.scl
18:31:21 <smooge> yay
18:32:09 <smooge> I will put the above onto the list and we can try to work on some policy.
18:32:36 <smooge> anything else for this subject? tibbs nirik Evolution ?
18:32:49 <tibbs> Nah, I think that was my only concer.
18:32:53 <tibbs> concern.
18:32:59 <Evolution> not for this, no.
18:33:13 <nirik> The life cycle will be a pain. ;) but no, nothing more here now
18:34:23 <smooge> i have an emergency downstairs. can someone take over please?
18:34:32 <nirik> sure.
18:34:38 * nirik looks back up for what else we had
18:35:06 <nirik> tpokorra: you wanted to talk mono for a minute?
18:35:13 <tpokorra> yes, please
18:35:17 <nirik> #topic Mono
18:35:36 <tpokorra> my proposal is to do a bootstrap of Mono 4.2 in Epel7, using buildroots
18:35:53 <tpokorra> or do you prefer I work with a side tag?
18:36:16 <tpokorra> will put the packages into testing, until Epel 7.3 comes out of beta
18:36:23 <nirik> I don't know much about the stack... is there a lot of build requires?
18:36:31 <tpokorra> about 15 or 20 packages
18:36:36 <nirik> ie, would you need to submit a bunch of overrides?
18:36:45 <nirik> yeah, side tag sounds easier then
18:36:52 <nirik> request one at releng trac
18:36:58 <tpokorra> mainly mono, but one other package I came already across
18:37:02 <tpokorra> yes, fine, will do that
18:38:23 <nirik> cool. Anything else on this?
18:38:34 <nirik> perhaps a email to epel-announce mentioning the coming upgrade...
18:38:41 <tpokorra> yes, when it is in testing
18:39:02 <tpokorra> or already earlier?
18:39:13 <tpokorra> I plan do put it into testing in the next couple of days
18:39:36 <nirik> when in testing is fine
18:39:46 <tpokorra> ok
18:40:35 <nirik> cool.
18:40:43 <nirik> Did we have any other topics folks wanted to bring up?
18:41:21 <Evolution> pbrobinson said that he's got the aarch64 builder somewhat operational now
18:41:36 <Evolution> so hopefully we'll see epel7 materialize for that arch soon
18:42:06 <nirik> yeah, rhey are up on rhel7.2 at least, so we can run them as vmhosts and run fedora aarch64 builders on em
18:43:55 <nirik> #topic Open Floor
18:44:01 <nirik> anyone have items for open floor?
18:44:06 <nirik> if not, will close out in a minute
18:45:24 <nirik> thanks for coming everyone
18:45:27 <nirik> #endmeeting