13:58:28 <bstinson> #startmeeting CBS/Infra
13:58:28 <centbot> Meeting started Mon Feb 13 13:58:28 2017 UTC.  The chair is bstinson. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:58:28 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:58:36 <bstinson> #chair alphacc Arrfab kbsingh
13:58:36 <centbot> Current chairs: Arrfab alphacc bstinson kbsingh
13:58:43 <bstinson> #topic Agenda
13:58:54 <bstinson> #info Topic: Status Updates
13:59:00 <bstinson> #info Topic: Account Requests
13:59:05 <bstinson> #info Topic: Open Floor
13:59:40 <bstinson> #topic Status Updates
14:01:14 <bstinson> I don't know if I have any updates from Devconf/FOSDEM/Cfgmgmtcamp, I ended up spending most of my time on CI things
14:04:25 <alphacc> Still waiting for -extras on altarches for koji/koji builder updates
14:06:10 <bstinson> alphacc: thanks, anything I can help with?
14:07:36 <alphacc> push and sign ? :) I think rpms are built for aarch64 & ppc64le
14:07:58 <alphacc> check with jpoc and Evolution
14:08:10 <Arrfab> alphacc: in the centos-admin repo ?
14:08:40 <Arrfab> also ppc64 is needed too
14:08:54 <Evolution> I have a series of pushes for updates and extras that should be out today
14:09:01 <Evolution> along with hrw's docker container.
14:10:19 <alphacc> This is more a general question, than an koji specific update issue, how do we get -extras in sync to not break building for SIGS using alt arches.
14:11:47 <Arrfab> alphacc: altarch were supposed to be secondary arches, meaning never slowing the x86_64 distro. if suddenly we have a need for extras to be in sync, and so the os too, that's becoming complex
14:12:08 <Arrfab> as that would mean delaying x86_64 because of the other arches, which I think will never be done
14:12:34 <alphacc> delaying vs having extras in sync within few days is a different matter
14:13:05 <Arrfab> alphacc: the real issue is that there is no policy for what lands (or not) in extras either
14:13:25 <alphacc> yes correct.
14:13:29 <Arrfab> if hughesjr wants to push to x86_64 extras, I doubt he cares about other arches
14:13:52 <alphacc> but we could easily script koji to catch srpm and rebuild automatically
14:13:52 <Arrfab> and maybe some pkgs for altarch were pushed to extras for a reason that doesn't exist in other arches
14:14:06 <kbsingh> why do we need them to be in sync?
14:14:16 <Arrfab> except that what lands in Extras/x86_64 isn't built in koji/cbs either
14:14:49 <alphacc> yes the goal is to review that
14:16:44 <alphacc> kbsingh: it's not until a package is need in the buildroot
14:17:45 <alphacc> my point is that it could be automated to rebuild new extras package in cbs
14:18:39 <alphacc> or in any other system for that matter
14:19:45 <kbsingh> ok
14:20:00 <alphacc> Let's revive Tier1 vs Tier2 arch on the ML as discussed at Fosdem
14:20:44 <kbsingh> life all around gets easierif all the bits line up
14:21:17 <alphacc> yes and contributing to extras a more streamlined process
14:21:30 <kbsingh> and maybe the goal should be to achiece that, ir try and get asclose to that  but i dont think we can actually be 100 in sync
14:21:49 <Arrfab> alphacc: so would the proposal be that hughesjr only builds through koji/cbs (and not on his other build system) and so for all enabled arches ?
14:21:58 <kbsingh> humm. bit of keyboard fail there
14:22:19 <kbsingh> for extras cbs will be fine
14:22:44 <alphacc> Arrfab: in a perfect world we would all use the same build server. "I had dream"
14:22:45 <bstinson> i think it's reasonable to expect some differences (for arch-specific packages), but we should be able to depend on the same python libraries (for example) across arches
14:23:18 <Arrfab> alphacc: try to convince now hughesjr :)
14:23:32 <alphacc> Arrfab: or automate
14:24:09 <alphacc> Arrfab: as short term solution I'll rebuild for all arches on our tags
14:24:19 <Arrfab> alphacc: yes, but do you remember the issue when a pkg in extras had to be built on a specific os version ? if so, that means that you'll have to wait for *all* altarches to be available before you can submit a new pkg o extras
14:25:32 <alphacc> Arrfab: yep corner case will always exists, but we can fix that with <arch>-only tag and merge later for others arches
14:27:11 <alphacc> I'll ping the list with all these questions
14:27:18 <kbsingh> ok
14:27:18 <alphacc> and proposal(s)
14:27:33 <Arrfab> kbsingh: can we add that in the meeting minutes and so ensure that hughesjr will from now only build through cbs for extras ?
14:27:35 <alphacc> the idea is to discuss I dont pretend to have a magic solution
14:27:38 <Arrfab> if we all agree that is
14:31:21 <alphacc> We need to know what Evolution and jpoc think
14:32:13 <alphacc> #action alphacc Email list about alt-arches experience in cbs
14:33:28 <bstinson> alphacc: if you start that thread, i'll be sure we follow up with everyone listed if there are no responses by next meeting
14:35:31 <bstinson> let's get the accounts recorded and pick up anything else in open floor
14:35:35 <bstinson> #topic Account Requests
14:36:20 <bstinson> #info CI: 1 request (NetworkManager) is pending, working through the onboarding conversations with those folks this week
14:36:39 <bstinson> kbsingh: anything going on in ACO?
14:39:29 <kbsingh> not a lot
14:39:39 <kbsingh> we've got quite a few people who've not come back and renewed certs
14:39:56 <kbsingh> what did we say we would do for people who dont do that for 120 days or something ? put them in suspend mode ?
14:40:25 <bstinson> we can mark them inactive
14:40:41 <kbsingh> is that something in the UI
14:41:19 <bstinson> there's a checkbox for admins, but it's scriptable too
14:41:42 <kbsingh> ok, will investigate
14:42:12 <bstinson> or it might be a dropdown...i don't have a running instance in front of me to look at
14:44:01 <bstinson> #info ACO: No new account requests of note, working on marking folks inactive who haven't renewed certs in 120 days
14:44:07 <bstinson> #topic open floor
14:45:28 <kbsingh> one thing that came up earlier in the chat with Arrfab  was that in the past, we've signed with an altarch key noarch content that came from a srpm that also has binary content
14:45:36 <kbsingh> and not replace it with the matching x86_64/ tree hosted noarch
14:45:48 <kbsingh> going forward, is that still the best thing to be doing ?
14:46:01 <kbsingh> if its not a problem, i would like to just have noarch matching
14:46:52 <hughesjr> Arrfab: why would I only build through cbs
14:47:21 <hughesjr> that is going to mean is it going to be impossible for me to build atomic and docker stuff
14:47:33 <hughesjr> and do dist tags correctly,etc.
14:48:37 <hughesjr> if someone fixes koji so it really works for 're'-building a distro, i'll be happy to use it :)
14:48:59 <hughesjr> (we have had these discussions for 4 years)
14:50:34 <bstinson> hughesjr: i think we can get there while the feature work for that is ongoing. i don't think we're saying switch -today-, but we want to investigate further
14:53:07 <hughesjr> ok
14:54:35 <bstinson> anything else for the last 4 minutes?
14:55:43 <kbsingh> did anyone have an opinion on the noarch's ?
14:59:07 <bstinson> do we know the impact user-side?
14:59:21 <kbsingh> shouldnt be any, the noarch's should be identical
14:59:56 <kbsingh> atleast i dont know of any that has arch specific content
15:01:44 <bstinson> yeah, not sure i have enough information to have an opinion myself. can we get input from the the rest of the altarch folks on the list?
15:02:34 <hughesjr> kbsingh: there may be some noarches in ppc64 only packages, etc.  But the common ones should be the same
15:04:39 <hughesjr> also wrt extras and x86_64 and i686 .. there are many (most) things in x86_64 that are not in i686 on purpose (for example)
15:04:41 <Arrfab> kbsingh: I remember that we discussed with hughesjr and Evolution and that they wanted to keep noarch from a SRPM that produced both noarch and $arch rpms pkgs
15:05:17 <Evolution> correct. otherwise koji gets bitchy about it
15:05:26 <hughesjr> right
15:05:42 <hughesjr> if it is not identical, koji goes nuts
15:06:37 <Arrfab> Evolution: well, what you mean is in fact replacing those with the x86_64 noarch, not keeping them ?
15:08:17 <Evolution> Arrfab: I use the noarch pkgs that hughesjr builds as part of the x86_64 build
15:08:39 <Evolution> maintaining the main distro signature.
15:09:02 <Arrfab> Evolution: ok .. in the past I remember that you said you were keeping the noarch from your build (if it produced also .aarch64 pkg)
15:09:22 <Arrfab> but true that koji will complain if there are multiple variant of the same NEVR for noarch
15:09:50 <hughesjr> Arrfab: that is only for things (if there are any) that do not exist in x86_64
15:10:41 <hughesjr> there are SRPMs that are not for x86_64 that are for ppc64, ppc64le and maybe some for aarch64
15:11:46 <hughesjr> I know of serveral for ppc64(le) .. none come to mind for aarch64 right now, but there COULD be some
15:12:26 <bstinson> perhaps this needs a proposal + list of cases to centos-devel
15:13:34 <bstinson> we're about 15 minutes over time, i'll leave this open for 2 minutes in case there are any parting thoughts
15:15:13 <bstinson> thanks all!
15:15:16 <bstinson> #endmeeting