16:31:46 <dgilmore> #startmeeting RELENG (2015-01-12)
16:31:46 <zodbot> Meeting started Mon Jan 12 16:31:46 2015 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:31:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:59 <dgilmore> #meetingname releng
16:31:59 <zodbot> The meeting name has been set to 'releng'
16:31:59 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson
16:31:59 <zodbot> Current chairs: bochecha dgilmore masta nirik pbrobinson sharkcz tyll
16:32:02 <dgilmore> #topic init process
16:32:10 <dgilmore> who is here
16:32:17 * sharkcz is here
16:32:20 * bochecha is in the middle of a release at work, not really available for the meeting
16:32:25 <nirik> hello
16:33:30 <masta> good morning
16:34:15 * nirik has to finish submitting a ticket here, then will be here.
16:35:33 <dgilmore> lets get started
16:35:39 <dgilmore> #topic #5931 [Proposal] Move new branch and unretire requests to pkgdb2
16:35:47 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5931
16:36:00 <pingou> ok so for this I believe most things are done
16:36:10 <dgilmore> pingou: one issue came up
16:36:18 <dgilmore> something we need to look at for epel
16:36:32 <pingou> there is 1 patch for which I'd like to have someone reviewing it that is on the rel-eng list (patch to mkbranch)
16:36:39 <pingou> dgilmore: what is it?
16:36:39 <dgilmore> okay
16:37:12 <dgilmore> pingou: http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL
16:37:26 <dgilmore> seems that the policy has been largely ignored
16:37:50 <dgilmore> I think we need a way to allow maintainers to opt out of epel
16:49:13 <pingou> reason that would be present in the fedmsg message
16:49:19 <pingou> and thus sent via FMN
16:49:45 * pingou is thinking about a "timeline" view of the package info
16:49:49 <dgilmore> I think we should move ahead anyway
16:49:57 <dgilmore> and get the rfe's handled
16:50:10 <dgilmore> we are not really any worse off
16:50:16 <dgilmore> it could just be better
16:50:24 <nirik> dgilmore: can you file the epel one? or you want someone else to? and the other one pingou will file?
16:50:55 <dgilmore> as long as i can file in fedorahosted i can do it
16:51:02 <pingou> it's in fedorahosted
16:51:11 <pingou> dgilmore: nirik for EPEL (only epel?) we basically need:
16:51:25 <pingou> a) 1 week time before a request can be processed
16:51:39 <pingou> b) a way for the current admins to block the request during that week
16:51:42 <pingou> correct?
16:51:47 <dgilmore> pingou: caveat thats only if the maintainer doesnt ack it
16:51:54 <nirik> or ack it so it processes right then
16:52:13 <nirik> or perhaps adjusts it too? ie, they want to be maintainer, not whoever requested it first
16:52:33 <dgilmore> pingou: and we need a way for a maintainer to say i don't care about epel people can request branches for my packages
16:52:43 <pingou> so block for one week, if approveacls people say nak -> deny request, if approveacls people say ok -> lift the 1 week waiting
16:52:55 <nirik> so: a) request epel branch, b) notify fedora maintainer(s), c) they can ack it or adjust/ack it and it happens then, d) or one week passes with no answer request goes,
16:53:16 <nirik> yeah
16:53:22 <pingou> which means that we could have:
16:53:46 <pingou> a) request epel branch, b) notify fedora maintainer(s) .. d) one week passes w/ no answer requests goes e) rel-eng blocks requests because package is in RHEL
16:54:43 <pingou> (pkgdb2 itself doesn't check if the package is in EPEL at the branch request creation, it's pkgdb-admin ran by rel-eng that does it)
16:54:58 <pingou> if the package is in RHEL*, sorry
16:55:08 <dgilmore> pingou: well i think we would check if the package is in rhel at branch request time and not allow the branch request
16:55:16 <nirik> perhaps have a per package nack thing... set by fedora maintainers or script
16:56:05 <nirik> This package can't be branched for epel because maintainers don't want it to, or its already in rhel.
16:57:01 <pingou> dgilmore: one thing is that pkgdb doesn't know about arch, and iirc you wanted to be able to distinguish between epel7-i686 and epel7-x86_64 at one point
16:57:09 <dgilmore> nirik: or the package has deps that are newer than whats in rhel
16:57:28 <nirik> anyhow, we are spending a lot of time on this? should we file rfe's and check next week?
16:57:32 <dgilmore> pingou: not distinguish
16:57:51 <dgilmore> pingou: but allow packages in epel that only exist in say epel7-x86_64
16:58:06 <dgilmore> then have bodhi enforce policy on them
16:58:20 <dgilmore> so that the nvr is never newer than whats in rhel
16:58:45 <pingou> hm, ok, I think I see
17:00:10 <dgilmore> pingou: so pkgdb only needs to know that yes this is in rhel, but its a limited arch package so we can branch it
17:00:26 <dgilmore> there is then a policy that says how it should be maintained
17:00:47 <dgilmore> which is basically use the rhel sources and add a 0. to the release
17:01:05 <dgilmore> so its the same content as rhel but a lower nvr
17:01:06 <pingou> dgilmore: sounds duable
17:01:07 * nirik would just disallow those if I had it to do over again. Oh well.
17:01:16 <dgilmore> nirik: indeed
17:01:24 <pingou> nirik: disallow package in epel that are in rhel?
17:01:41 <dgilmore> pingou: yeah, its pretty messy
17:01:49 <nirik> yeah. Don't allow epel to carry packages just to provide other arch support.
17:01:51 <dgilmore> RHEL makes things much harder than they need be
17:02:00 <nirik> yeah. indeed.
17:02:08 <pingou> I thought they were but with the drop of i686 I see the mess yes
17:02:19 <dgilmore> pingou: well there is ppc
17:02:38 <pingou> I wondered if at one point we couldn't/shouldn't move to a vers-arch model
17:02:41 <dgilmore> big issue there is java is x86 only
17:02:48 <pingou> having epel7-32 and epel-64 or so
17:03:01 <dgilmore> pingou: that makes no sense
17:03:26 <nirik> anyhow, should we move on? or actions for this?
17:03:34 <dgilmore> maybe epel7-x86_64 epel7-ppc64 epel7-ppc64le
17:03:45 <dgilmore> yeah we should move on getting a bit off topic
17:04:06 <pingou> agreed
17:04:07 <dgilmore> #action dgilmore file RFE for epel branch hadling in pkgdb2
17:04:28 <dgilmore> #action pingou file RFE for adding comments to events in pkgdb2
17:04:43 <nirik> FWIW the mkbranch patch seems fine to me.
17:05:03 <nirik> we could do that now and make sure it doesn't break anything before we even move anything else forward
17:05:17 <dgilmore> nirik: right
17:05:24 <pingou> nirik: and it would allow us to make it run by fedmsg
17:05:44 <pingou> > branch is created on pkgdb -> ansible is called and adjust git
17:05:50 <dgilmore> #info lets move this forward and get everything moved over
17:06:09 <nirik> note that the version of mkbranch actually used is in infra puppet/ansible. ;)
17:06:18 * nirik nods
17:06:28 <pingou> nirik: yes, but I wanted a second set of eyes
17:06:40 * pingou isn't quite a bash professional
17:06:50 <dgilmore> pingou: ill take a look also
17:06:53 <pingou> thanks
17:06:58 <dgilmore> lets get moving
17:07:02 <dgilmore> #topic #6016 Use fedpkg-minimal in Fedora buildroots
17:07:10 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6016
17:07:45 <dgilmore> not sure that the package was submitted for review
17:07:51 <dgilmore> but we should get this done
17:08:03 <dgilmore> it will make the srpm buildroot creation be much smaller
17:08:13 <nirik> yep. +1
17:08:14 <dgilmore> which will speed things up
17:08:25 <nirik> isn't it currently a subpackage of fedpkg?
17:08:37 <dgilmore> nirik: its not.
17:08:51 <dgilmore> and can't really be made so
17:08:53 <nirik> ok. So it needs packaging->review?
17:09:01 <dgilmore> since it provides /usr/bin/fedpkg
17:09:25 <dgilmore> i guess we could maybe make it put the script in /usr/sbin/fedpkg
17:09:38 <nirik> that sounds confusing...
17:09:40 <dgilmore> but that seems kinda shady and messy and prone to causing issues
17:10:02 <masta> yucky, lets just make it conflict with fedpkg pkg
17:10:12 <dgilmore> fedpkg in this case is a bash script that all it does is fetches the sources
17:11:00 <nirik> yeah.
17:11:16 <dgilmore> #action pbabinca to make sure package is filed for review
17:11:37 <nirik> happy to help review, etc.
17:11:51 <dgilmore> once its reviewed and in we will adjust the srpm-build group in koji to install fedpkg-minimal and not fedpkg
17:12:13 * nirik nods.
17:12:18 <dgilmore> #topic #5963 Orphaned vulnerable packages in EPEL
17:12:26 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5963
17:12:34 <dgilmore> tyll: can we  call this done now?
17:12:48 <nirik> I think there's one more round of them, but overall I think yes. '
17:13:15 <tyll> dgilmore: yes, at least it is take care of in a different ticket
17:13:36 <dgilmore> great. ill get this ticket closed
17:15:03 <dgilmore> #topic #6039 koji database read-only access request
17:15:12 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6039
17:15:59 <dgilmore> i do not think that we have all the provides and requires in the koji db anymore
17:15:59 <pingou> https://infrastructure.fedoraproject.org/infra/db-dumps/ ?
17:16:10 <dgilmore> afaik its now read from the rpms as needed
17:16:34 <dgilmore> so i do not object to the request. I just do not think it has the requested info
17:16:35 <nirik> so, yeah, the question is: is there sensitive data in the db
17:17:10 <nirik> it's pretty trivial to export the db dump if it's not.
17:18:12 <dgilmore> nirik: there is none that i know of
17:18:54 <nirik> ok, should we just start exporting it then? or do you want to check further?
17:19:01 <dgilmore> auth info is in the ssl cert/keys on each users machine
17:19:18 <dgilmore> maybe should do a quick check
17:19:37 <dgilmore> there is only one or two tables i can think of that might
17:19:48 <dgilmore> and if they do it should be removed
17:19:58 <nirik> ok, so check and revisit next week?
17:20:08 <dgilmore> sure
17:20:35 <dgilmore> #topic #6047 handle packages that are retired only in Branched but not Rawhide
17:20:41 <dgilmore> https://fedorahosted.org/rel-eng/ticket/6047
17:21:34 <dgilmore> so there is not a great solution here
17:21:59 <dgilmore> sometimes the answer is retire the package in rawhide and sometimes is unblock in rawhide
17:22:21 <dgilmore> I think we should unblock in rawhide and send a warning
17:22:22 <nirik> yeah. ;(
17:22:39 <nirik> seems reasonable...
17:22:41 <nirik> tyll: ^
17:24:18 <dgilmore> #info dennis to update ticket, then we can work out how to implement
17:24:52 <dgilmore> #topic #5886 need method for distributing urgent fixes... urgently
17:25:02 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5886
17:26:21 <nirik> we need to hash out the questions on the wiki page...
17:26:31 <nirik> perhaps on list or in a side meeting
17:27:39 <dgilmore> this probably needs its own meeting
17:27:54 <dgilmore> with people from high up in Fedora engineering and releng folks
17:28:00 <dgilmore> as well as infra
17:28:10 <dgilmore> and come up with a concrete plan
17:28:41 <nirik> yeah.
17:29:06 <dgilmore> #action dgilmore to call a meeting on getting everything lined up to provide a way to get things out really fast
17:29:19 <dgilmore> it probably needs SRT also
17:29:27 <nirik> there's pros and cons to various things, we just need to decide which way to go on them
17:29:50 <dgilmore> right
17:30:45 <tyll> sorry, for the delay - regarding the unblockin in rawhide, this conflicts with the automatic blocking or we always needs to first unblock a pkg in rawhide and block it later if it is retired there
17:31:33 <dgilmore> tyll: koji wont unblock the package if it doesnt think its blocked
17:31:54 <dgilmore> tyll: so you owuld need to block in say f22 then unblock in f23
17:32:19 <dgilmore> you would have to block check the status of devel in pkgdb then unblock
17:34:10 <dgilmore> lets wrap up the meeting, we can talk about the blocking/unblocking in the ticket and #fedora-releng
17:34:20 <nirik> so shall we move on? or are we out of time? I had a bunch of misc stuff to impart
17:34:28 <dgilmore> we will start next weeks meeting with secondary arches
17:34:38 <dgilmore> nirik: then lets do open floort
17:34:40 <dgilmore> floor
17:34:41 <tyll> ok
17:34:42 <nirik> ok.
17:34:45 <dgilmore> #topic openfloor
17:35:09 <nirik> ok, I had a few things to note:
17:35:39 <nirik> I reinstalled most all the builders with f21. Ran into a issue on the buildvm's but the curl then kernel maintainers were great and tracked it down to a kernel bug. ;)
17:35:58 <dgilmore> always fun
17:35:58 <nirik> sounds like new mock or somethig in f21 broke livecd creations, so we need to fix that up.
17:36:10 <nirik> arm02/arm04/buildvm/buildhw are all f21
17:36:18 <dgilmore> cool
17:36:26 <nirik> with f19 eol, do we want to add the arm01 socs into primary? or ?
17:36:53 <dgilmore> nirik: that or use them in infra
17:37:31 <nirik> I also made a koji01/02 that are rhel7/64bit... still need to sort out keepalived on them, but they seem to work to talk to the koji03 hub ok
17:37:44 <dgilmore> cool
17:38:01 <nirik> I also reinstalled koji01.stg with rhel7... but somehow I broke clients on it... I can't get it or buildvm-01.stg to work.
17:38:12 <nirik> it's saying there's a bad cert, but I am not sure which one. ;(
17:38:32 <dgilmore> nirik: that is likely a MD5 cert in there somewhere
17:38:33 <nirik> dgilmore: if you can look into that it would be great. Would be good to have stg builders up and running.
17:38:45 <nirik> ah, could be... but I thought we quashed them all
17:39:03 <dgilmore> i thought so also. but I do not think that is the case
17:39:36 <nirik> it's complaining about the CA I think... but I couldn't figure out why.
17:39:56 <dgilmore> okay
17:40:03 <dgilmore> will have to dig into it
17:40:16 <nirik> and finally... we need to finalize mass rebuild time and side tag in times...
17:40:28 <nirik> fesco set a pretty tight schedule...
17:40:42 <dgilmore> nirik: I have that on my list of things to review this week
17:40:53 <sharkcz> dgilmore: hi, are you coming for DevConf in February to Brno?
17:41:01 <dgilmore> from what I can tell there is no time for a mass rebuild
17:41:10 <nirik> ok. The tenative dates we set were not ok with ruby folks because they wouldn't have any time to do their side tag.
17:41:11 <dgilmore> sharkcz: AFAIK yes
17:41:18 <nirik> yeah, it's really tight
17:41:28 <nirik> anyhow, I think thats all I had.
17:41:36 <dgilmore> cool thanks
17:41:50 <dgilmore> sharkcz: I am supposed to be giving a talk
17:42:10 <sharkcz> dgilmore: yeah, then you should be here :-)
17:43:01 <dgilmore> #info FESCo schedule is crazy tight, likely no time for mass rebuild
17:44:18 <dgilmore> we should find out who will be at devconf
17:44:31 <dgilmore> tyll: are you going to fosdem or devconf?
17:44:56 <tyll> dgilmore: both
17:45:02 <dgilmore> tyll: excellent
17:45:29 <dgilmore> I am trying to get to fosdem to speak with some of the CentOS guys about EPEL collaboration
17:46:12 * pingou will be at both as well
17:46:31 <tyll> I am already on the list for the EPEL/CentOS meeting
17:46:37 <dgilmore> cool
17:47:33 <dgilmore> okay lets wrap up
17:47:45 <dgilmore> and reconvene next week
17:47:55 <dgilmore> #endmeeting