15:30:58 <dgilmore> #startmeeting RELENG (2014-09-15)
15:30:58 <zodbot> Meeting started Mon Sep 15 15:30:58 2014 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:58 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:31:04 <dgilmore> #meetingname releng
15:31:04 <zodbot> The meeting name has been set to 'releng'
15:31:10 <dgilmore> #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson
15:31:10 <zodbot> Current chairs: bochecha dgilmore masta nirik pbrobinson sharkcz tyll
15:31:24 <nirik> morning
15:31:31 <bochecha> hi everyone
15:31:36 <sharkcz> hi
15:32:00 * oddshocks is lurking
15:32:54 <dgilmore> #topic init process
15:34:50 <tyll_> hi there
15:34:54 * pbrobinson waves
15:35:06 <dgilmore> lets get going
15:35:34 <dgilmore> #topic #5931 [Proposal] Move new branch and unretire requests to pkgdb2
15:36:06 <dgilmore> pingu is on PTO this week I believe
15:36:53 <pbrobinson> where's the dedication :-P
15:37:35 <tyll_> #info nothing new
15:37:49 <dgilmore> #topic #5967 Enable source repo generation
15:37:55 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5967
15:38:04 * dgilmore forgot to start the conversation
15:38:43 <tyll_> #action dgilmore will ask the submitter for more info
15:39:06 <dgilmore> #topic #4071 Block pushes to origin/ in gitolite ACLs
15:39:13 <dgilmore> https://fedorahosted.org/rel-eng/ticket/4071
15:39:34 <nirik> this would be something to work on in stg now with gitolite3.
15:39:43 <dgilmore> yeah
15:39:51 <dgilmore> not sure its really that big of a problem
15:39:55 <tyll_> There is a simple hook in the ticket that needs to be integrated
15:40:07 <tyll_> I saw some of these branches in reality
15:40:17 <tyll_> #info < nirik> this would be something to work on in stg now with gitolite3.
15:41:00 <dgilmore> does some one want tow ork with bochecha on it>
15:41:03 <dgilmore> ?
15:41:34 * bochecha feels like he has just been volunteered :)
15:41:45 <dgilmore> bochecha: kinda ;)
15:41:47 <tyll_> I would take a look, but I lack the time
15:42:04 <tyll_> but it only needs the hook to be added to gitolite, so it should be rather simple
15:42:09 <bochecha> I'll have a look, just need someone to eventually push stuff to ansible as I can't do that yet
15:42:20 <bochecha> tyll_, just put somewhere in ansible then, so it gets installed in the right place?
15:42:37 <tyll_> IIRC you can just become infra apprentice to get push access to ansible
15:42:50 <bochecha> I'm apprentice
15:43:13 * bochecha goes to push random breakage, to test if that's enough :)
15:43:30 <dgilmore> bochecha: i think you can push. you just need someone to run it
15:43:34 <bochecha> anyway, I'll have a look tomorrow then
15:43:35 <tyll_> if not, I cann add it to ansible
15:43:58 <tyll_> #action bochecha will add it to pkg-stg via ansible
15:44:27 <dgilmore> perfect ;)
15:44:43 <dgilmore> anything else here?
15:45:07 <tyll_> imho no
15:45:19 <dgilmore> #topic #4355 metadata for "grouped" files on master mirror
15:45:22 <dgilmore> https://fedorahosted.org/rel-eng/ticket/4355
15:45:45 <tyll_> is this something that still needs to be done? The ticket is 4 years old.
15:45:57 <dgilmore> im really not sure what this request actually wants
15:46:22 <dgilmore> some bits really go together
15:46:31 <dgilmore> but some are good to go together
15:47:19 <tyll_> maybe this allows to select an mirror that has all the necessary bits if mm knows which bits belong together
15:47:34 <dgilmore> I really do not know
15:47:44 <dgilmore> I guess we should ask more questions in teh ticket
15:48:17 <tyll_> #action till ask about more infos in the ticket
15:49:54 * nirik notes apprentices don't have push to ansible. ;) but we can get it working.
15:50:10 * nirik has no idea on this ticket. ;)
15:50:13 <dgilmore> nirik: okay :)
15:50:33 <dgilmore> #topic #5934 GConf2-dbus getting added to f19 on s390
15:50:40 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5934
15:50:46 <dgilmore> sharkcz: so whats happening here?
15:51:02 <sharkcz> dgilmore: looks as a bug in syncing
15:51:36 <sharkcz> GConf2-dbus got removed from primary long time ago, but is being enabled for f19 on s390
15:51:47 <dgilmore> sharkcz: its not blocked on primary
15:51:53 <sharkcz> http://s390.koji.fedoraproject.org/koji/packageinfo?packageID=3120
15:52:26 <dgilmore> we cut off inheritance between f18 and f19
15:52:32 <dgilmore> its blocked in f18
15:52:36 <dgilmore> but not in f19
15:52:41 <dgilmore> bu there is no builds
15:52:59 <dgilmore> sharkcz: i suspect its a pkgdb bug
15:53:15 <sharkcz> yeah, but see f19 and "included" on s390 hub
15:53:30 <dgilmore> sharkcz: right thats pkgdb
15:53:36 <dgilmore> not a syncing issue
15:53:37 <tyll_> Can't we just block it in f19 on primary?
15:54:05 <dgilmore> tyll_: no. the pkgdb sync process will unblock it
15:54:18 <dgilmore> https://admin.fedoraproject.org/pkgdb/package/GConf2-dbus/ is weird
15:55:25 <pbrobinson> it always was but surely it's not that much of a special case in the pkgdb context?
15:56:42 * dgilmore will try some things in pkgdb to see if it can get removed properlly
15:57:10 <tyll_> #info < dgilmore> we cut off inheritance between f18 and f19
15:57:50 <tyll_> #info blocking it in f19 on primary will be undone by pkgdb sync process
15:58:03 <sharkcz> dgilmore: maybe I could just untag the GConf2-dbus-2.16.0-16.fc11 build
15:58:03 <tyll_> #info might be a pkgdb bug
15:58:29 <dgilmore> i took ownership and re retired
15:58:33 <dgilmore> lest see if that works
15:58:36 <dgilmore> lets
15:58:39 <sharkcz> ok
15:58:45 <dgilmore> if it doesnt we will have to file a pkgdb bug
15:59:21 <tyll_> don't we now also have to block it in f19?
15:59:36 <tyll_> Otherwise it is only blocked in f22 via the fedmsg blocker
16:00:37 <dgilmore> blocking it also
16:00:48 <dgilmore> lets see how we go
16:01:33 <dgilmore> #topic #5941 Requesting Koji user certificate for Koschei
16:01:38 <sharkcz> dgilmore: it might be related to the problem with removing all packages from f18 tag some time ago, by an error in the syncing, otherwise we shouldn't have the f19 tag there at all
16:01:59 <dgilmore> sharkcz: that happened when i cut the inheritance off
16:02:12 <dgilmore> so probably somewhat related
16:02:34 <sharkcz> yep, let's wait for the current results
16:02:36 * nirik has to head out, back later.
16:02:36 <dgilmore> whats peoples thought son the certificate issuance
16:02:45 <dgilmore> I am inclined to not issue one
16:02:59 <dgilmore> we would need to block the accountname in fas
16:03:32 <dgilmore> the certs we issue are good for 10 years
16:03:51 <bochecha> how does bodhi get a cert? does it also have a fas account?
16:04:00 <dgilmore> until its someythingw e officially run id rather the developers just use thier own certs
16:04:05 <pbrobinson> I thought the koji client certs were good for 6 months for users
16:04:14 <dgilmore> bochecha: i generated it and blocked the username in fas
16:04:21 <dgilmore> pbrobinson: users ones are
16:04:22 <pbrobinson> s/client/user
16:04:36 <tyll_> I guess they could start with a bot fas account (if it exists) and then if the service gets into Fedora infra use a 10 year certificate
16:04:36 <dgilmore> pbrobinson: the request is for a specially generated one
16:04:50 <dgilmore> tyll_: there is no such account
16:05:05 <bochecha> couldn't they start with a normal 6months one, then if it becomes a part of the infra we can make them a new 10 years one?
16:05:21 <dgilmore> bochecha: yes they are asking for a special one
16:05:27 <dgilmore> they do not want to use thier own
16:05:46 <bochecha> sure, I meant a 6 months one but for a dedicated user
16:05:56 <bochecha> that gets them halfway towards the final production setup
16:06:00 <dgilmore> bochecha: we cant generate one
16:06:19 <dgilmore> the non user code path only makes 10 year certs
16:06:47 <dgilmore> #action dgilmore to update the ticket
16:07:10 <dgilmore> #topic #5959 Enable keep-alive connections for koji (primary and secondaries)
16:07:15 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5959
16:07:22 <dgilmore> pbrobinson: did it break anything?
16:07:57 <tyll_> I meant to test whether this allows to not use MultiCall() but did not get to it
16:08:11 <pbrobinson> I've not seen any breakage
16:08:25 <pbrobinson> but I've not heard it's done what it's meant to
16:08:41 <dgilmore> I think we had it enabled in the past but that was distant past using mod_python
16:08:43 <pbrobinson> koji-shadow appears a little slow but I doubt it's to do with this :)
16:09:09 <dgilmore> pbrobinson: slower than usual?
16:09:52 <pbrobinson> well the F-21 mass rebuild seems to be taking a light year
16:10:16 <pbrobinson> but there's nothing to particular back that up other than a general feel....
16:10:27 <dgilmore> okay
16:10:32 <tyll_> #info keep-alive enabled on arm koji
16:10:39 <tyll_> #info no obvious problems noticed
16:11:06 <tyll_> #info no benchmarking multiple single calls versus multiCall() done yet
16:11:07 <sharkcz> pbrobinson: you could stop kojira for some time
16:11:19 <sharkcz> if you are waiting fo rnewRepos
16:11:29 <tyll_> #action till benchmark multiple single calls versus multiCall()
16:12:52 <dgilmore> okay lest move on here
16:12:56 <dgilmore> #topic #5981 add rel-eng git notifications to rel-eng mailing list
16:13:02 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5981
16:13:11 <dgilmore> we should just do this
16:13:42 <tyll_> I guess it needs fedorahosted rel-eng admin access or something like this
16:13:51 * tyll_ never managed any fedorahosted project
16:13:52 <dgilmore> #action dgilmore to update the hooks to send email to the list
16:14:12 <dgilmore> tyll_: its more an infra thing but i have the access and will do it
16:14:25 <tyll_> ok, I wasn't sure
16:14:31 <dgilmore> #topic #5982 make the rel-eng list git a copy of all ticket notifications
16:14:36 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5982
16:14:58 <tyll_> I guess is this similar, we agreed on this a while ago, but it was not implemented
16:15:45 <dgilmore> im not sure where in trac you set this
16:15:59 <tyll_> nirik knew it
16:16:29 <tyll_> I believe fedora-infra is doing the same
16:17:50 <dgilmore> found it
16:18:03 <dgilmore> #info dgilmore set the default cc to have the rel-eng list
16:18:26 <tyll_> #action dgilmore set the default cc to have the rel-eng list
16:19:27 <dgilmore> #topic #5983 generate signed RPM packages on kojipkgs on-demand
16:19:33 <dgilmore> https://fedorahosted.org/rel-eng/ticket/5983
16:20:12 <dgilmore> I believe you need to have admin perms to write out the signed rpms
16:20:47 <dgilmore> we could write a script to easily write it out, but I don't know that users could run it
16:21:00 <dgilmore> and we would still need a good way to do so
16:21:21 <dgilmore> as in knowing what rpms to sign
16:21:41 <dgilmore> tyll_: what exactly were you thinking?
16:22:37 <tyll_> I meant a web application that is available on kojipkgs
16:22:58 <tyll_> whenever one accesses a path like https://kojipkgs.fedoraproject.org/packages/libHX/3.18/3.fc22/data/signed/8e1431d5/armv7hl/libHX-3.18-3.fc22.armv7hl.rpm it runs through the application and creates the file if it does not exist already
16:23:13 <tyll_> if it exists, it is just returned, otherwise it is returned after it was created
16:23:40 <tyll_> so the script would look in https://kojipkgs.fedoraproject.org/packages/libHX/3.18/3.fc22/data/sigcache/ whether the signature exists
16:24:12 <tyll_> if the signature does not exist, a 404 is returned
16:25:09 <tyll_> I am not sure how signatures are added to RPMs, if they are external, maybe it can also be done without going through koji but just replicating the code, e.g. if it is just some appending of files
16:25:54 * masta is here
16:25:56 <masta> sry pediatrician appointment this morning.
16:25:56 <dgilmore> tyll_: rpm is used
16:26:30 <dgilmore> tyll_: not sure it will be easy toimplement
16:27:23 <tyll_> It would be just a re-write rule from the paths to the script
16:27:42 <bochecha> shouldn't be too hard, it's just identifying the build and the sigkey from the path, then from that getting the sigcache, then using the rpm api to make the signed rpm?
16:27:44 <tyll_> I could write it eventually, if it is considered to be useful
16:28:07 <dgilmore> you would need to have the cgi deal with some paths but not others
16:28:24 <dgilmore> you would need to check if there is a signature header or not
16:28:29 <dgilmore> its doable
16:29:02 <dgilmore> tyll_: when running mash for instance it doesnt use apache at all
16:29:18 <dgilmore> it hardlinks the rpms on the filesystem
16:30:21 <tyll_> ah, then it is not that usefule for this
16:30:23 <dgilmore> so mashes would still fail if the signed copy is missing
16:30:43 <dgilmore> tyll_: so i guess we need to understand better the use cases you're thinking of
16:31:53 <tyll_> I was thinking of mash, for builds that are signed but not written, e.g. because autosigning failed or manual signing was aborted before the RPMs were written
16:32:28 <dgilmore> okay.  that just won't work. we would need to teach mash to write them out
16:33:59 <tyll_> ok, then the other use case would only be for people who want to download signed RPMs from kojipkgs, I guess that are not that much, therefore the ticket can be closes wontfix imho
16:34:15 <dgilmore> okay
16:35:55 <tyll_> #info mash uses direct file system access, so a web application does not help here
16:36:01 <bochecha> tyll_, especially, if you need to know the full path before you can download them, it's not very useful
16:36:04 <tyll_> #action till close the ticket as wontfix
16:36:27 <tyll_> bochecha: koji download-build does it automatically afaik
16:36:36 <tyll_> bochecha: it tries to download from the right path
16:36:44 <bochecha> tyll_, true, I was more thinking of consuming them as a yum repo
16:38:17 <dgilmore> anything else here?
16:40:53 <dgilmore> we are 10 minutes over
16:41:03 <dgilmore> should we postpne the test for next week?
16:41:18 <sharkcz> dgilmore: GConf2-dbus seems to be fixed on s390 hub
16:41:38 <sharkcz> excluded in f19
16:42:28 * bochecha has to go very soon
16:42:37 <dgilmore> sharkcz: great
16:43:26 <tyll_> I am fine with anything
16:43:43 <dgilmore> lets wrap up.
16:44:34 <dgilmore> at least one of the remiaining tickets will probably be time consuming
16:46:23 <dgilmore> lets have a quick open floor
16:46:30 <dgilmore> #topic openfloor
16:47:44 <dgilmore> and if nothing lets close
16:47:59 <dgilmore> #endmeeting