15:41:03 #startmeeting RELENG (2014-09-08) 15:41:03 Meeting started Mon Sep 8 15:41:03 2014 UTC. The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:41:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:41:11 #meetingname releng 15:41:11 The meeting name has been set to 'releng' 15:41:17 #chair dgilmore nirik tyll sharkcz bochecha masta pbrobinson 15:41:17 Current chairs: bochecha dgilmore masta nirik pbrobinson sharkcz tyll 15:41:35 * nirik is here 15:41:44 * tyll too 15:41:48 * sharkcz IS HERE 15:41:51 * masta is here 15:41:52 * bochecha is here 15:41:57 * pingou 15:42:52 #topic init process 15:42:58 hey all 15:43:03 * pbrobinson waves 15:43:32 we have a ton of tickets to get through 15:44:10 I added a lot where it was unclear to me what the next action is or whether they are already done, if it is too much, we can skip some 15:44:11 #topic #1107 auto-cleanup rawhide trees 15:44:20 https://fedorahosted.org/rel-eng/ticket/1107 15:44:43 this needs a script written that will keep the last 14 trees 15:44:56 #info < dgilmore> this needs a script written that will keep the last 14 trees 15:45:13 which path needs to be cleaned on which system? 15:45:17 we could run it via cron or buildbranched/buildrawhide 15:45:32 #info < dgilmore> we could run it via cron or buildbranched/buildrawhide 15:45:35 though updates trees need cleaned up also as bodhi just leaves them there 15:45:48 #info < dgilmore> though updates trees need cleaned up also as bodhi just leaves them there 15:46:08 this one could be an easyfix 15:46:23 shouldnt take too long to write a script to do it 15:46:52 I do not think it needs to keep the meeting keyword 15:46:55 * nirik likes the idea of build* scripts cleaning up the old ones... 15:46:59 which path needs to be cleaned on which system? 15:47:02 we should update the ticket and remove the meeting keyword 15:47:19 hrm... yeah, looks easy. Keep N tree around. 15:47:22 /mnt/koji/mash and /mnt/koji/mash/updates 15:47:23 tyll: /mnt/fedora_koji/koji/mash/rawhide* and branched* 15:47:25 yes, this sounds good 15:47:42 * pingou notes: I'll have to go in ~25minutes, so if we to discuss the new-branch/pkg processes it should be before :) 15:47:45 nirik: dont forget updates 15:47:51 yeah, and updates/ 15:48:13 #info affected paths /mnt/koji/mash and /mnt/koji/mash/updates 15:48:17 what is the priority on that? 15:48:40 we low on space? 15:48:46 pingou: its not on the list of tickets so it wont be discussed unless it comes up in openfloor 15:49:06 masta: it is a very old ticket 15:49:10 masta: making sure we dont fill up the storage 15:49:26 dgilmore: cool, we can do an update in 3 weeks then 15:49:31 we have been cleaning them manually when we notice. 15:49:38 usually nirik or I clean it up when there is 3 or 4 months worth of composes 15:50:12 and same applies to secondary hubs, s automation is good idea 15:50:45 right 15:50:49 ok, I'll take the cleanup task. 15:50:56 so lets move on 15:51:04 #action masta I'll take the cleanup task. 15:51:08 #topic #1501 repomd.xml signing in bodhi 15:51:55 so i still do not think we can really do this 15:52:06 Is caching the sigul credentials still a no-go, considering that it also happens for the autosigner? 15:52:09 it would be a big pain. ;) more work, etc. 15:52:39 tyll: autosigner box is sperate with more limited access than the releng boxes 15:53:24 tyll: it would be a massive amount of work. and some of it depends on what would cache teh signature 15:53:54 I would be more willing to revisit with concrete proposal 15:54:03 not just we should do this 15:54:14 #info < dgilmore> I would be more willing to revisit with concrete proposal 15:54:20 i.e. how would we implements it 15:54:23 #info dgilmore> tyll: autosigner box is sperate with more limited access than the releng boxes 15:54:34 I'm not sure it gets us that much really either now that we have metalinks. 15:54:49 which systems are used to prepare updates? 15:55:00 releng04 and relepel01 15:56:00 pingou: i failed your ticket is next 15:56:12 ok, I guess we can defer this ticket then 15:56:27 #info releng04 and relepel01 used to prepare updates 15:56:36 * pingou is there for still 10min 15:57:21 lets nmove on 15:57:30 it seems to me that access restrictions are the same for these hosts and autosigner 15:57:52 tyll: I do not believe so 15:57:59 we would need to double check 15:58:01 sysadmin-releng allows access to both 15:58:22 tyll: yes. but afaik other groups have access to relepel01 and releng04 15:58:42 sysadmin-noc for instance 15:58:46 I see 16:00:15 #action someone come up witha concrete implementation plan and we can revisit 16:00:23 #topic #5931 [Proposal] Move new branch and unretire requests to pkgdb2 16:00:31 https://fedorahosted.org/rel-eng/ticket/5931 16:00:40 pingou: you're up 16:01:11 ok, so I started the discussion on devel about the new processes 16:01:23 based on it, I have 2 questions: 16:01:38 - Do we really want to populate the branch when we create them? 16:02:00 we could just create the epel8 branch and let the packager merge in whatever branch he thinks will work 16:02:31 It needs to be populated with something in GIT, because there needs to be a commit that is pointed to for a branch to exist 16:02:36 * nirik would be fine with letting them do it, we would need to announce/document it tho as it's different. 16:02:56 pingou: afaik its not possible to make a branch and have it be empty 16:03:15 the creation could just add the acls for the branch, then packagers create it where they want it? 16:03:25 if we can then it would be an option. but would need a lot of work 16:03:53 bochecha: many if not most maintainers wouldnt know how to 16:03:55 I can double-check if we actually can, but basically, we're in favor of this? 16:03:56 it could point to the first commit in master 16:04:05 pingou: im not opposed 16:04:12 i wouldnt say I am in favour 16:04:50 the point came up on devel@ so we can also continue the discussion there about if it's feasible/desirable 16:04:58 dgilmore, you mean, just using the usual « fedpkg switch-branch » and « fedpkg push » ? :-/ 16:05:12 bochecha: ? 16:05:16 I would be in favor of pointing it to the initial commit, which should be easy and avoids accidently creating the wrong branches 16:05:31 dgilmore, that's all it would take for a maintainer to create a new branch, if the acls already are open for it 16:05:41 tyll, that's a nice solution as well 16:05:51 bochecha: not really 16:05:59 tyll: mind bringing it up on devel@? 16:06:07 perhaps someone could do a proof of concept on stg? 16:06:39 it is afaik already what we do for initial packages 16:06:40 should be duable :) 16:07:05 the second question I have is: for new *fedora* branch, what do we need to check beside that the requester is a packager? 16:07:05 tyll: we init a bare repo then make the branches from master 16:07:43 http://paste.fedoraproject.org/131843/41019240 16:07:48 pingou: there was talk about us only allowing those from people with acls on the package 16:07:51 tyll: they could then do a git megre in the new one and it should just work 16:08:08 dgilmore: it is an empty .gitignore and sources file as initial commit 16:08:22 pingou: that the person is in the acls 16:09:03 dgilmore: nirik so nothing outside pkgdb? so if the person satisfies the conditions, we could just automatically grant *fedora* branch request, right? 16:09:05 pingou: and if its an epel package that the maintainer has opted out of epel and if not that they know and are okay with the other person making epel branches 16:09:21 pingou: in theory we could be completely hands off for new branches 16:09:26 * nirik nods 16:09:30 pingou: we just do not have the tooling to do it 16:10:01 * bochecha has to go 16:10:02 dgilmore: for epel branch I agree, that's why I'm here only speaking about new fedora branches 16:10:25 yeah, epel is more complex, but we could even automate it with some more work, IMHO 16:10:42 pingou: if the personal has commit access to an existing fedora branch and requests a new one then that could be done without intervention 16:10:52 pingou: epel could be automated also 16:10:55 dgilmore: cool, so I'll do that in pkgdb :) 16:11:02 it would just take some coding 16:11:13 we could have the fedora maintainer ack the epel branch 16:11:31 if we do one we should do both 16:11:39 I've started working on a pkgdb-admin CLI part of pkgdb-cli https://git.fedorahosted.org/cgit/packagedb-cli.git/tree/pkgdb2client/admin.py?h=pkgdb_admin 16:12:03 this way, admins can list pending action, process a specific action and update its status 16:12:21 okay 16:13:02 process being, grant a new branch <- we can add more checks there, create the new package or unretire a package <- doesn't do anything atm 16:13:42 * pingou has to go 16:13:51 but this is basically where I am at atm 16:13:56 code wise it's working on pkgdb 16:14:05 #info < pingou> - Do we really want to populate the branch when we create them? 16:14:09 okayt thanks for the update 16:14:20 we "just" need to define what we want to fully automate and what we still want to check "manually" 16:14:33 see you later/tomorrow people :) 16:14:35 info < pingou> the second question I have is: for new *fedora* branch, what do we need to check beside that the requester is a packager? 16:14:40 #info < pingou> the second question I have is: for new *fedora* branch, what do we need to check beside that the requester is a packager? 16:14:59 #info < pingou> we "just" need to define what we want to fully automate and what we still want to check "manually" 16:15:26 #info < pingou> I've started working on a pkgdb-admin CLI part of pkgdb-cli https://git.fedorahosted.org/cgit/packagedb-cli.git/tree/pkgdb2client/admin.py?h=pkgdb_admin 16:16:11 going to move on 16:16:16 #info for new branches, check whether the person is a packager and has commit ACLs for at least on Fedora branch 16:16:18 #topic #5967 Enable source repo generation 16:16:26 https://fedorahosted.org/rel-eng/ticket/5967 16:16:42 this comes at a massive cost 16:17:11 it's just another newrepo right? well, x buildroots 16:17:17 nirik: yep 16:17:29 #info < dgilmore> this comes at a massive cost 16:17:30 * nirik shrugs. I think we have pretty good capacity now... 16:17:39 every newRepo task will have an extra arch 16:18:26 we could try it and see if it causes too much load ? 16:18:44 it will be next to impoosible to turn off if we enable it 16:19:10 #info < dgilmore> it will be next to impoosible to turn off if we enable it 16:19:19 bummer. 16:19:28 I really do not understand what the perceived gain is either 16:19:35 in any case I wouldn't want to do it in freeze. 16:19:45 perhaps ask the reporter to come to the next meeting? 16:19:51 lets ask for some more info in the ticket 16:20:10 #action dgilmore ask for some more info in the ticket 16:20:27 #info < dgilmore> I really do not understand what the perceived gain is either 16:20:36 #info < nirik> in any case I wouldn't want to do it in freeze. 16:20:40 * nirik has a hard stop in about 10min, FYI. 16:21:18 the meeting is either going ot go way over or leave a lot of things untouched 16:21:35 we are not even a quarter into the tickets 16:21:47 * nirik nods 16:22:04 IMHO there are probably no time-critical tickets, so we can do them next meeting 16:23:03 with a few people dropping off lets end at the half hour 16:23:34 #topic #5959 Enable keep-alive connections for koji (primary and secondaries) 16:23:40 https://fedorahosted.org/rel-eng/ticket/5959 16:23:51 pbrobinson: did you enable this on arm.koji? 16:26:44 I'm on the hub, what does the config look like? 16:27:14 nothing jumps out as looking like a keep alive 16:27:37 KeepAlive On 16:28:05 ok, that is not present in the kojid.conf on the arm hub. 16:28:18 should be in the apache config 16:28:32 masta: its an apache config option 16:28:47 but it is not enabled according to curl 16:28:54 * nirik has to run, will read back on logs later. 16:29:00 $ curl -skI https://arm.koji.fedoraproject.org | grep Connection 16:29:01 Connection: close 16:29:07 ng to make sure nothing breaks 16:29:15 #action pbrobinson to enable and do testing to make sure nothing breaks 16:31:33 * pbrobinson is back and I'll do that this evening 16:31:44 if nothing else important lets wrap up 16:32:08 ok 16:33:10 #endmeeting