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