15:34:15 <masta> #startmeeting RELENG (2015-08-31)
15:34:15 <zodbot> Meeting started Mon Aug 31 15:34:15 2015 UTC.  The chair is masta. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:34:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:34:23 <masta> #meetingname releng
15:34:23 <zodbot> The meeting name has been set to 'releng'
15:34:32 <masta> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson pingou maxamillion
15:34:32 <zodbot> Current chairs: bochecha dgilmore masta maxamillion nirik pbrobinson pingou sharkcz tyll
15:34:32 <masta> #topic init process
15:34:37 <masta> howdy folks
15:34:42 <maxamillion> .hello maxamillion
15:34:43 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:35:04 <masta> Sounds off
15:35:12 <nirik> morning
15:35:52 <zodbot> dgilmore: Error: Can't start another meeting, one is in progress.
15:36:03 <dgilmore> #meetingname releng
15:36:03 <zodbot> The meeting name has been set to 'releng'
15:36:03 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson pingou maxamillion
15:36:03 <zodbot> Current chairs: bochecha dgilmore masta maxamillion nirik pbrobinson pingou sharkcz tyll
15:36:06 <dgilmore> #topic init process
15:36:32 <masta> hehe
15:36:51 <dgilmore> who all is here?
15:36:55 * maxamillion is here
15:37:21 <masta> so an fyi, our meeting process: https://fedoraproject.org/wiki/ReleaseEngineering/Meeting_Process <-- anybody can start our meeting following the process =)
15:37:46 <masta> sry dgilmore, I had probably started it prematurely
15:37:55 <dgilmore> masta: huh
15:37:57 * nirik is here
15:38:21 <dgilmore> I have no idea what you are talking about?
15:38:45 <dgilmore> oh I see
15:38:49 <masta> dgilmore: I had already started the meeting, figured you were grabbing coffee
15:39:04 <dgilmore> masta: its a good idea to not start the meeting unless you have been asked to run it
15:39:11 <masta> ack
15:40:13 * sharkcz is here
15:40:26 <dgilmore> #topic #6234 Requesting koji service account for Cockpit
15:40:34 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6234
15:41:03 <dgilmore> I see some issues with this
15:41:21 <dgilmore> mostly about how the plan to have the CI setup commit to pkgs git
15:41:26 <nirik> it could be made to work... but not sure if it opens us up to tons more of these. ;)
15:41:38 <nirik> sgallagh: you around?
15:41:55 <sgallagh> nirik: Hola
15:42:01 <dgilmore> the koji cert is doable
15:42:09 <dgilmore> but there is more to it than that
15:42:51 <nirik> not fully clear. Is this for scratch builds? or official builds?
15:42:54 <sgallagh> dgilmore: It's mostly about convenience; the Cockpit CI is very comprehensive.
15:42:57 <sgallagh> This is only for official builds
15:43:30 <sgallagh> /me notes that the Cockpit CI ends up being a pretty comprehensive test suite of Fedora in general, since it catches a lot of regressions in the base packages too
15:43:33 <nirik> then it would also need a ssh key
15:43:50 <sgallagh> /me asked stefw to join as well.
15:43:54 <stefw> o/
15:44:12 <sgallagh> stefw: http://fpaste.org/261545/10358451/
15:44:20 <dgilmore> sgallagh: scatch builds are easy
15:44:31 <dgilmore> we can give you a cert and blacklist the account in fas
15:44:40 <dgilmore> real builds are much more involved
15:45:02 <dgilmore> as you need to be able to commit to git
15:45:03 <stefw> we would like to deliver cockpit builds into the in development version of fedora
15:45:04 <sgallagh> stefw can better explain their use-case. I was mostly proxying the request for them
15:45:06 <nirik> yeah, then it would need ssh key, koji cert, etc etc
15:45:07 <dgilmore> upload to lookaside
15:45:11 <dgilmore> ssh key
15:45:34 <stefw> currently the builds are done automated, continuous delivery style
15:45:38 <dgilmore> stefw: what would your ideal workflow be?
15:45:40 <stefw> but require the credentials of a developer
15:45:47 <stefw> our ideal workflow looks like:
15:45:49 <sgallagh> stefw: Does that mean Rawhide only, or Rawhide+Branched?
15:45:52 <stefw> tag and sign a commit in git
15:46:12 <stefw> current target: rawhide+branched, until updates are required
15:46:16 <stefw> workflow:
15:46:22 <stefw> 1. tag and sign a commit in git to release
15:46:50 <stefw> 2. continuous delivery verifies this against large suite of CI tests (which run constantly all day long)
15:47:07 <stefw> 3. delivnery script releases the tag to fedora, docker hub, tarball, and documentation update
15:47:24 <stefw> fedora in this case is koji + copr
15:47:35 <stefw> currently we do all of this
15:47:41 <dgilmore> stefw: copr is outside of our view
15:47:52 <stefw> however we manually trigger the build so it can use a developer's credentials
15:48:11 <dgilmore> stefw: so we have no way to do what you are asking today
15:48:13 <stefw> we give the script access to all the credentials necessary
15:48:30 <dgilmore> anything we setup would basically need a packager setup in fas
15:48:57 <sgallagh> dgilmore: That's basically what is being asked for. A new FAS account that we sponsor into the packager group and give it permissions on the cockpit packge
15:49:22 <dgilmore> sgallagh: you can just go and do that
15:49:24 <sgallagh> Except that it wouldn't be a human attached to the account, but a set of scripts.
15:49:33 <dgilmore> you do not need our permission
15:49:42 <sgallagh> dgilmore: Strictly speaking, a script isn't allowed to sign the FPCA :)
15:50:02 <stefw> well a human can sign, the script runs on our behalf
15:50:03 <dgilmore> sgallagh: we have no way to do anything any other way
15:50:15 <dgilmore> its just not designed to enable it
15:50:19 <stefw> it just means that instead of giving the scirpt access to all of a packager's (such as me) packages
15:50:25 <stefw> we can just give it access to one
15:50:31 <sgallagh> dgilmore: The reason this ticket was opened was to find out if such a process would be permissible.
15:50:56 <sgallagh> Because I'm not aware of a precedent
15:50:58 <dgilmore> sgallagh: the fas account would be for the person responsible for the script
15:51:10 <dgilmore> sgallagh: why wouldnt it be?
15:51:29 <sgallagh> dgilmore: Well, what's being asked for is a *shared* FAS account separate from the users' normal ones.
15:51:39 <nirik> someday if/when we move to oauth2 like setup, we could do this kind of thing better
15:51:40 <sgallagh> That can be independently locked down to access only to limited packages
15:52:04 <nirik> then we could have it get only a token to allow builds/commits, but not unpushing or whatever
15:52:06 <sgallagh> dgilmore: Which is definitely a policy question
15:52:15 <dgilmore> sgallagh: what may be interesting and worth digging into is to setup a service kinda like koeschi but it uses some watching technique and does the process for upstream projects
15:52:23 <sgallagh> nirik: Yeah, that would be fantastic. Can we have that in a couple weeks? ;-)
15:52:29 <dgilmore> so for cockpit does the update
15:52:35 <dgilmore> and people could opt into it
15:52:39 <nirik> sgallagh: you haven't given me the time machine yet. ;)
15:52:44 * stefw notes that this is what the docker hub does
15:52:48 <stefw> it tracks a git repo and builds for you
15:53:03 <nirik> dgilmore: this could be related to the-new-hotness that does scratch builds for upstream releases.
15:53:13 <dgilmore> nirik: right
15:53:23 <stefw> we would still need to do scratch builds from our side of the script
15:53:25 <dgilmore> but rather than scratch builds it does real builds
15:53:32 <stefw> because we wait until every release section gives green
15:53:33 <nirik> "if the upstream release looks ok, just build it for me in rawhide"
15:53:34 <stefw> before we commit
15:53:52 <stefw> so we try to prepare for docker, for fedora, tarball release, docs ... and if everything is green
15:53:55 <stefw> then we tell them all to go
15:54:02 <stefw> for Fedora it's the scratch build that needs to happen
15:54:14 <nirik> stefw: just a scratch build?
15:54:17 <stefw> ie scratch build driven in a push manner, rather than pull
15:54:25 <stefw> well if the actual koji build was done as dgilmore suggests ...
15:54:36 <stefw> ... then just the scratch build would need to be done by a script
15:54:48 <stefw> right, now we do both from our continuous delivery scripts
15:54:54 <nirik> so, right now, really the only way is making a fas account to do this stuff for you and restricting it as much as possible.
15:55:09 <nirik> but someday yeah, we could have a service...
15:55:22 <sgallagh> nirik: What he means (I think) is that a scratch-build is done first, fed into CI and then if it succeeds, they would do an official build
15:55:37 <stefw> right
15:55:49 <nirik> makes sense, sure.
15:56:05 <dgilmore> sgallagh: I could see extending the-new-hotness to supporting that
15:56:13 <nirik> but we don't have anything right now to do this. ;)
15:56:16 <dgilmore> threebean: ^^^
15:56:47 <dgilmore> sgallagh: stefw: could you please update the ticket with teh workflow you would like to see
15:57:00 <sgallagh> nirik, dgilmore: OK, so your recommendation for now is to just create a brand-new FAS account and use that, correct?
15:57:03 <stefw> sure
15:57:08 * nirik nods.
15:57:25 <nirik> actually https://github.com/fedora-infra/the-new-hotness/issues might be best if you are willing to file there.
15:57:26 <sgallagh> stefw: OK, if you get the account created, I'll sponsor it into 'packager' for you.
15:57:38 <stefw> alright
15:57:45 <nirik> there's not much more we can do on the releng ticket I don't think until we have infra in place...
15:57:51 <stefw> thanks
15:58:16 <dgilmore> sgallagh: yes, thats what we can do today.  However I would like to look at having some way to offer a service for upstreams to opt into
15:58:32 <maxamillion> oh man, I didn't realize the-new-hotness was an actual thing, I thought that was a general term for some magical unknown future ... that's great
15:58:38 <sgallagh> dgilmore: Absolutely. We should follow up on the-new-hotness.
15:58:56 <dgilmore> sgallagh: it seems like a good fit but maybe it is not
15:59:03 <sgallagh> So when do we rename something else to old-and-busted?
15:59:20 <sgallagh> Sure, we'll see where that goes
15:59:37 <nirik> maxamillion: it's the thing that notices new releases and files bugs and kicks off scratch builds for you
16:00:05 <dgilmore> sgallagh: the account would need to be a packager and have commit access to cockpit  in pkgdb
16:00:11 <maxamillion> nirik: nice
16:00:23 <sgallagh> dgilmore: Yup, as I said; I'll sponsor it in and we can do the pkgdb magic
16:02:52 <nirik> shall we move on?
16:03:13 <dgilmore> yep
16:03:32 * dgilmore does not think that there was anything to discuss on the AFS ticket
16:03:56 <dgilmore> #info sgallagh to create an account in fas
16:04:56 <dgilmore> #info investigate options with threebean on adding support to the-new-hotness to automatically update packages rather than filing bugs, if a scratch build works
16:05:10 <nirik> on afs we were going to file some createrepo* rfes?
16:05:17 <nirik> to hash the drpms dir?
16:05:24 <dgilmore> nirik: oh right.
16:05:36 * nirik didn't do that. perhaps we should decide who is going to. ;)
16:05:36 <dgilmore> nothing to discuss right now though
16:05:49 <dgilmore> #topic #6200 Cannot mirror Fedora drpms using OpenAFS
16:05:59 <dgilmore> okay lets cover it quickly
16:06:27 <dgilmore> #info need to file RFE's with createrepo createrepo_c to hash drpm dirs
16:06:47 <dgilmore> anyone want to own the ticket?
16:07:03 <maxamillion> wait, isn't OpenAFS not merged upstream in the mainline kernel? or am I thinking of something else? (aufs?)
16:07:42 <dgilmore> maxamillion: I think its status is a bit dubious
16:07:55 <dgilmore> but there is at least one mirror that has their mirrors on it
16:09:26 <dgilmore> I guess I can do it
16:09:49 <dgilmore> #action dgilmore to file RFE's for hashing drpm dirs
16:10:17 <dgilmore> #topic Secondary Architectures updates
16:10:18 <dgilmore> #topic Secondary Architectures update - ppc
16:10:29 * nirik isn't sure pbrobinson or sharkcz are around today.
16:10:35 <dgilmore> pbrobinson has a public holiday today
16:10:38 <sharkcz> I'm
16:10:58 <dgilmore> I know that he worked on getting kickstarts all up and working for the power8 hardware last week
16:11:07 <nirik> yeah, at least one of them is up.
16:11:08 <sharkcz> F-23 Alpha for ppc was released last week
16:11:13 <dgilmore> sharkcz: anything on power to report?
16:11:29 <sharkcz> and yes, Peter work on the infra
16:11:55 <sharkcz> that should be all
16:12:41 <dgilmore> #topic Secondary Architectures update - s390
16:12:49 <dgilmore> sharkcz: where is s390 at?
16:13:12 <dgilmore> sharkcz: we have to have a plan to drop 31 bit
16:13:21 <dgilmore> I think we should drop it now
16:13:31 <dgilmore> and not ship it in f23
16:13:32 <sharkcz> we did Alpha RC and found a bug in s390 code path in blivet, fix already exists
16:13:40 <dgilmore> cool
16:14:17 <sharkcz> I don't want to drop 31-bit until we know we won't need it in the future, IBM discusses it internally and knows our position
16:14:32 <sharkcz> I'm a bit optimistic
16:15:14 <dgilmore> sharkcz: with changes I want to push to get done we likely will not be able to support it period in f24
16:15:42 <dgilmore> I think this is a case where we need to just tell IBM its done
16:16:30 <sharkcz> my worries are on the enterprise side ...
16:17:23 <dgilmore> sharkcz: They really have had long enough
16:17:43 <dgilmore> there has not been new 31 bit hardware in a long long time
16:19:14 <dgilmore> sharkcz: is tehre anything we can do to ensure that it happens?
16:20:42 <sharkcz> I've already provided input where 31-bit sucks, but still waiting for the decision, might be also useful to add more voices internally about it
16:21:01 <dgilmore> sharkcz: tell me where to speak up and I will
16:21:28 <sharkcz> dgilmore: will PM you later
16:21:38 <dgilmore> #info sharkcz to provide dgilmore with info to work on dropping 31 bit support
16:21:52 <dgilmore> #topic Secondary Architectures update - arm
16:22:05 <dgilmore> aarch64 alpha was released on Tuesday
16:22:36 <dgilmore> pwhalen: anything you want to add on aarch64 status?
16:23:54 <dgilmore> okay lest move on
16:23:59 <dgilmore> #topic open floor
16:24:07 <dgilmore> anyone have anything to bring up?
16:24:14 <maxamillion> not I
16:24:31 <nirik> I wanted to talk about urgent updates, but I need to talk to luke some more before it's ready to discuss... so no. ;)
16:25:35 <dgilmore> nirik: thats something we need to work on
16:26:19 <dgilmore> alright
16:26:28 <dgilmore> if nothing else we can wrap up
16:27:06 <nirik> oh...
16:27:15 <nirik> one more thing: next monday is a holiday, so I assume no meeting?
16:27:21 <nirik> (in the us)
16:27:33 <dgilmore> nirik: yeah.
16:27:44 <dgilmore> I will be headed to Argentina on Tuesday
16:30:41 <dgilmore> okay lets meet up in two weeks
16:30:44 <dgilmore> #endmeeting