14:00:23 <bstinson> #startmeeting CBS/Infra
14:00:23 <centbot> Meeting started Mon Nov 24 14:00:23 2014 UTC.  The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:23 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:33 <imcleod> .hellomynameis imcleod
14:00:46 <MerlinTHP> Hello
14:00:47 <bstinson> #chair alphacc Arrfab kbsingh MerlinTHP
14:00:47 <centbot> Current chairs: Arrfab MerlinTHP alphacc bstinson kbsingh
14:00:54 <bstinson> hi everyone
14:00:59 <alphacc> hi all
14:01:04 <imcleod> hiya
14:01:13 <bstinson> #topic Agenda
14:01:22 <bstinson> #info Topic: Status Updates
14:01:38 <bstinson> #info Subtopic: Centralized Authentication
14:01:46 <bstinson> #info Subtopic: Git Infrastructure
14:01:52 <bstinson> #info Subtopic: Koji/Repos
14:02:03 <bstinson> #info Subtopic: Centpkg
14:02:09 <bstinson> #info Topic: Open Floor
14:02:36 <bstinson> #topic Status Updates
14:02:46 <MerlinTHP> I'm in a work conf call, so I might be a bit distracted.
14:03:39 <bstinson> MerlinTHP: no problem, we'll just #action everything to you :)
14:03:44 <MerlinTHP> Fair.
14:04:14 * imcleod thought MerlinTHP was indicating that this might distract him from his work call.....
14:04:58 <Evolution> 'work' is such a strong term....
14:05:22 <MerlinTHP> I'm trying to do three things at once here
14:06:39 <bstinson> so let's talk a litle bit about Koji and buildsys packages
14:06:52 <MerlinTHP> The issue from the weekend?
14:07:31 <bstinson> sounds like Arrfab and alphacc have that fixed permanently, but we do need to work on building some packages into our repos
14:08:13 <alphacc> #info koji builder mock was updated to mock 1.2.1 and causes problem. it has been fixed at 9am UTC on Monday.
14:08:29 <alphacc> bstinson: mock and koji are now rebuilt on our tags
14:08:30 <Arrfab> bstinson: well, rule #1 would be : never depend on external repositories : our default puppet baseline has a yum update cron job, but obviously, adding repositories that we don't control ain't a good thing
14:08:57 <mikem> good morning
14:09:06 <alphacc> I propose to enable infrastrcture6-stable repo on builders.
14:09:10 <Arrfab> so alphacc started to rebuild packages that we use on the cbs side, so that those packages would be "locked" to that version, and through internal admin repo
14:09:25 <MerlinTHP> What version of mock are we looking to use, then?
14:09:31 <bstinson> is that also a build target in koji?
14:09:41 <MerlinTHP> 1.2.1 is just broken, we need to go to 1.2.2 if we're going for 1.2.x
14:10:01 <eparis> having never done a build in centos, i'm clueless, but are epel packages available at build time in CentOS ?
14:10:06 <alphacc> However one question about the client, should we ship it somewhere else or we still use epel at this time ? (I didn't update default config to cbs in the /etc but can be done at next iteration)
14:10:24 <alphacc> eparis: if SIG decide they want to depend on epel yes
14:10:49 <alphacc> eparis: by default no
14:11:25 <alphacc> bstinson: build target is infrastructure6-el6
14:11:51 <bstinson> cool
14:12:03 <eparis> second question: is %{?rhel} as an rpm spec macro true in centos builds ?
14:12:11 <alphacc> MerlinTHP: I'll do the mock evaluation in next week, but no rush to move to 1.2.X in my opinion
14:12:46 <bstinson> +1
14:13:11 <bstinson> alphacc: you're talking about the koji client in your "still use epel" statement above?
14:13:25 <alphacc> bstinson: yes
14:13:47 <alphacc> bstinson: I don't think we want infra6 activated on all users machine right ?
14:14:17 <MerlinTHP> alphacc: I don't really see a need to move, I was just noting that 1.2.1 itself is broken.
14:14:21 <Evolution> eparis: yes.
14:14:33 <alphacc> MerlinTHP: agreed.
14:14:43 <eparis> Evolution: thanks (trying to make sure you guys don't break when my crap ends up there   :))
14:14:54 <mikem> There is no need to run a bleeding edge mock in koji. I don't.
14:14:59 <eparis> alphacc: thank you.
14:15:12 <alphacc> eparis : however each sig can have a buildsys-macro-sig to override default
14:16:17 <alphacc> #action enable infra6 repo on builder and update to new package. I'll announce a date on centos-devel.
14:17:46 <Arrfab> alphacc: let's work on that, as that would implies packages signing too
14:17:50 <bstinson> should we be thinking about releasing some of the rebuilt packages to users?
14:17:54 <Arrfab> s/implies/imply/
14:18:24 <alphacc> Arrfab: yes.
14:20:14 <kbsingh> ideally, we dont want to use / consume EPEL inside the buildroots.
14:20:29 <kbsingh> if someone wants to, they should have a very very good reason - and should thrash it out on a mailing list first
14:22:37 <bstinson> i guess i can talk a little about centpkg, since that might help the rebuild process
14:23:09 <bstinson> #info centpkg is ready to build, since it now supports the sig SRPM workflow
14:23:30 <alphacc> bstinson: great
14:23:41 <bstinson> i am still having trouble pushing to the repo on git.c.o, i wonder if we can blow that away and recreate it
14:26:47 <imcleod> kbsingh: Am curious about the motivation for an exception-only default policy for EPEL in the CBS.  Do we expect folks with significant EPEL deps to pull CBS rebuilds of the EPEL packages into their SIG or somewhere else?
14:28:21 <mikem> Well, one issue is that epel is sort of a sprawling mess
14:28:22 <Arrfab> imcleod: probably, or at least having repoclosure
14:29:00 <walters> imcleod, is the imagefactory that runs in CBS the epel version?
14:29:19 <imcleod> walters: Yup.  There is no core or even layered product version of Factory.
14:30:02 <walters> ok, just wanted to verify there wasn't a centos infrastructure-private repo
14:30:20 <Arrfab> walters: can you elaborate ?
14:31:14 <walters> Arrfab, ah...not sure how to rephrase.  Basically I wanted to know where the imagefactory package that was providing CBS' image building functionality came from
14:31:40 <Arrfab> walters: ah, no idea, but yes, we have a centos infrastructure-private repo for centos.org nodes
14:31:58 <walters> ok
14:33:56 <imcleod> mikem: True enough, but it is the de-facto sprawling mess for upstream packages that wish to support RHEL that are not in RHEL.  I fear that putting it beyond reach (by default) for CentOS builds is going to prove a significant barrier to entry for new projects/SIGs.
14:34:05 <imcleod> mikem: But perhaps that's the idea.
14:38:48 <bstinson> we may need to discuss this on the list
14:39:04 <kbsingh> imcleod: so the fix is to try and help epel get sorted, rather than inflict more broken on everyone else as well.
14:39:08 <alphacc> I am in favor that it should be a sig decision and a well weighted one.
14:39:43 <kbsingh> alphacc: that works for me, as long as the sig can demonstrate they have some level of influence on the leaf nodes they rely on in epel
14:39:50 <bstinson> extra weight given if SIGs maintain their deps in EPEL
14:40:18 <kbsingh> alphacc: and then find a set of standards we expect an external repo to meet before inclusion, then let anyone who meets that standard be included.
14:40:45 <alphacc> kbsingh: ok I can draft smthg and submit to the list.
14:41:25 <mikem> There is value in our sig ecosystem being self contained build-wise. I believe we had some plans for dealing with common packages among the sigs.
14:41:34 <mikem> Fairly sure we don't want or need all that is is epel
14:42:36 <alphacc> mikem: I agree in general (and we should inform sig of the risk) but I still think sig may have the last word
14:42:47 <Evolution> especially given epel's upcoming mass extinction event
14:42:56 <alphacc> Evolution: :)
14:43:16 <imcleod> Evolution: Oh?
14:43:42 <Evolution> imcleod: epel is full of unmaintained/orphaned packages.
14:43:50 <Evolution> they're set to be removed mid-december.
14:44:11 <imcleod> Evolution: Ahh.  Well, good. :-)
14:44:13 <Evolution> this is a good example of why depending on epel could be problematic during builds.
14:44:26 <walters> but does duplicating the packages solve that problem?
14:44:29 <imcleod> I myself just experienced the pain of depending on an EPEL package that went way.
14:44:48 <imcleod> But yes, per walters, if people _Are_ maintaining stuff in EPEL, and want to join the CentOS fold, we don't want to make it more difficult for them.
14:44:52 <Evolution> FYI -> https://lists.fedoraproject.org/pipermail/epel-devel/2014-November/010511.html
14:45:29 <Evolution> imcleod: correct. however this is a problem as old as rpm repos themselves.
14:45:40 <alphacc> walters: duplicating and maintaining solve the problem
14:45:42 <imcleod> Evolution: Roger that.
14:47:23 <bstinson> #topic Open Floor
14:48:35 <Evolution> in the interest of fixing EPEL, (as KB noted earlier) there's a 'bug squashing day' on 2 dec. (next tuesday), as well as the previously linked mass extinction
14:49:09 <Evolution> if you rely on epel, I would strongly urge you to look at the package lists, or what epel packages you use for bugs, testing and feedback.
14:49:26 <Evolution> (semi-related to builds here)
14:52:18 <bstinson> anything else before we go?
14:53:01 <Arrfab> bstinson: well, probably worth pointing people to the FAS vs IPA thread that started on the centos-devel
14:54:18 <bstinson> indeed
14:54:57 <bstinson> #info please join the FAS/IPA discussion here: http://lists.centos.org/pipermail/centos-devel/2014-November/012288.html
14:55:10 <bstinson> #info or here: http://lists.centos.org/pipermail/centos-devel/2014-November/012376.html
14:55:32 <alphacc> Let's add a link to software collection thread as well
14:57:06 <bstinson> alphacc: you have a link handy?
14:57:52 <alphacc> bstinson: forget about it. scratch that for now.
14:58:43 <bstinson> ok, closing in 1 minute
14:59:35 <bstinson> #endmeeting