17:01:54 #startmeeting epel 17:01:54 Meeting started Fri Dec 19 17:01:54 2014 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:54 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:12 #chairs bstinson nirik dgilmore Evolution smooge 17:02:18 #meetingname epel 17:02:18 The meeting name has been set to 'epel' 17:02:24 * nirik is here, but slow typing 17:02:28 #topic Meats and Greets 17:02:44 Hi I am Stephen Smoogen, I am your lead chair today 17:03:27 People who said hi before I got this meeting started were: 17:03:35 gaurdro> \o/ 17:03:39 bstinson> woohoo! 17:03:44 Never saw so much excitement for a meeting ;) 17:03:51 kbsingh is also here today! 17:03:55 nirik is here, but slow typing 17:04:21 I am not sure about Evolution. I expect he started drinking straight egg-nog earlier (dropping the rum completely) 17:04:41 no. right now it's coffee with kahlua 17:04:43 I am sort of around, want to bring up something towards the end 17:04:49 rum+eggnog is for later 17:04:50 okie dokie 17:05:01 unfortunately I have to head out now, but I'll check the notes later. 17:05:14 Plus with kbsingh here it's too much excitement ;) 17:05:16 ok Jeff_S .. so I can nominate you for the board :) 17:05:23 haha FML 17:05:23 * bstinson is ready for rum - eggnog 17:05:34 #topic Agenda 17:05:47 I hope everyone enjoys their holidays (or non-holidays or whatever). ttyl 17:06:12 The agenda is light today... I am working on running this better in the new year so who ever takes over after elections has a steady thing 17:06:23 #info Bug Day Earlier in the month 17:06:32 smooge: I'm certain that once you hand it off to yourself it'll run more smoothly. 17:06:44 #info Orphan Removal Day 17:06:45 * Evolution campaigns for smooge2015 17:06:50 #info Repoclosure Day 17:07:15 #info 2014 End of the Year Slowdown 17:07:22 #info Elections 17:07:33 #info kbsingh's topic 17:07:43 #info Open Floor 17:07:54 #topic Bug Day on Dec 2 17:08:14 this was not a good thing. I got back from travel the day before and did not have things prepared. 17:08:38 * nirik was swamped that day and didn't get to doing much 17:08:41 when we do one in Jan/Feb I would like to make sure I schedule it in advance with what we need to do. 17:08:53 so that peopel aren't groping for something to do. 17:09:10 will work with QA on how they do their bug days and come up with a checklist for people. 17:09:18 thanks to bstinson for doing most of the work that day. 17:09:36 we had a couple of orphans adopted on that day...which is a couple more than i expected :) 17:09:37 any suggestions on how to help this in the future? 17:10:00 smooge: not schedule it so close to mass travel for key people? 17:10:17 with you, me, nirik, and dgilmore traveling it was a bit nuts. 17:10:21 Yep. 17:10:22 having a list of possible things to do might help... 17:10:32 just to point people in the right directions 17:11:00 yep. I am working on some blog posts on how to dothings.. hope to get them finished and have my November Blog-A-Thon in January 17:11:24 I expect I will have my Christmas presents ready in March at this rate 17:11:39 #topic Orphan Removal Day 17:11:55 I would like to thank tyll_ for doing all the work on this. 17:12:10 I believe we have no orphans who are older than 5 weeks at the moment in EPEL. 17:12:11 ++tyll_ 17:12:48 hurray! 17:12:58 and so far only one has been revived. 17:13:03 (that I know of) 17:13:19 I don't know if those packages are removed by releng from the ftp servers or if bodhi does it in our sleep 17:13:29 so the complaining may begin soon 17:13:34 or later 17:13:58 they should disappear on the next updates push 17:14:01 cool 17:14:20 which brings us to tyll's next act of awesomeness 17:14:27 #topic Repoclosure Day 17:14:41 That is scheduled for today, but tyll was working on it all day yesterday 17:15:05 so we should after the next update push also have repoclosure not reporting errors 17:15:13 note that we actually do have repoclosure for 5/6 running weekly 17:15:31 well I mean that it won't report "package X is missing Y" 17:15:37 and there's some false positives I don't think we can ever get rid of 17:16:10 so every package should be able to be installed without errors... which is actually all I really want 17:17:19 I guess I should have called it "No broken installs" or soemthing :) 17:17:30 well, for example, rhel doesn't ship python.i686 on rhel x86_64... and that assumption causes a number of packages to be shipping .i686 in x86_64 that could never ever work 17:17:46 we are not going to get to 100% clear without more work 17:18:01 ah ok 17:18:11 well was the first step ok then? or two steps back? 17:18:47 sure, we should clean up what we can, but we can't blindly just drop everything with problems. 17:18:54 sometimes they aren't the packages fault 17:19:37 I think I am not understanding something. Even if it isnt the packages fault.. we don't want those packages in the repo correct? Or do we want to ship a python.i686 17:20:13 we don't want them, but thats needing fixes in mash. 17:20:20 ah ok 17:20:32 just removing the package is not the solution, as it's otherwise just fine 17:20:50 and I need to look at mash anyway because it is where the epel symlink fix needs to go 17:21:35 and I didn't realize we shipped i686 in x86_64 epel. I thought we didn't do multilib 17:21:47 we do 17:22:01 we do the way fedora does... which is not the same way rhel does. ;( 17:22:07 ah ok 17:22:25 ok well then I have something to work on in January then 17:23:54 one thing, I told tyll to clean it up. So it may be overclean because of that problem (or it might not since tyll knows more about the build system than I do). If we overcleaned, I would like to say mea culpa and unretire any such package without a review 17:24:24 is that ok with bstinson Evolution and nirik (I can also do the reviews as punishment) 17:24:57 sure, I don't think tyll_ has done anything yet... hpefully will check before doing something 17:25:01 yeah. 17:25:37 alright I can go to the next step which is 17:25:45 +1 from me (i can take reviews too if needed) 17:25:48 #info 2014 End of the Year Slowdown 17:26:36 So it is the end of the year 2014 and Red Hat usually closes for the last weekish. During that time Red Hat employees (who make up most of the committee) may not be available in case of problems etc 17:27:01 I would like to also cancel the following meetings: 2014-12-26, 2014-01-02 17:27:01 I would say you should expect people to be gone next week and the next 17:27:12 +1 17:27:27 +1 17:27:38 s/2014-01-02/2015-01-02/ 17:27:54 Our next meeting would be 2015-01-09 17:28:06 +1 from me also 17:28:09 BAHUMBUG! 17:28:17 I mean, +1 17:28:34 #agreed 2014-12-26 2015-01-02 meetings canceled due to holidays. Next meeting 2015-01-09 17:29:01 Evolution, your bah humbug is noted. Ebenezeer Smooge will be giving you a lump of Oreo Coal 17:29:26 #topic Elections 17:30:04 so, perhaps I will sound like a despot here, but I am not really in favor of elections. 17:30:30 people who do the work or show up and help with the work should be welcome, but voting seems... strange 17:30:58 so an informal meritocracy then. 17:31:17 yeah, I mean, who is voting here? for who? 17:31:44 I am wanting to avoid the Fedora Packaging Committee Lifetime membership junta 17:31:46 well, I think we could get at least a 3/4 majority in favor of smooge doing work.... 17:32:35 smooge: well, the only way to avoid that is to make sure and get new people involved and doing things, so old people can wander off and do other things 17:33:21 having people be able to do differen things, while all of them allowing them to build karma, is a great goal 17:33:41 it does wonders to folks hanging around for the long term 17:33:51 s/to fol/for fol/ 17:33:51 * orionp didn't realize he was part of a junta 17:34:37 orionp: think of it as more of a militia 17:34:51 or a poker club 17:35:07 A VFW hall? ;) 17:35:09 at the very least i think we should designate (by vote or however) the EpSCO chair 17:35:16 smooge2015 17:35:25 orionp, technically you aren't part of the junta. The people on the steering committee are the junta. You just get to live under them 17:35:37 heh 17:35:48 indeed, smooge2015! 17:36:31 OK I have said my piece. If the people are happy, we stay with what we have. If not they can bring it up on the list and we can work it out later 17:36:33 I think it is beneficial to have one person with authority/veto powers at times. 17:36:41 sure. 17:38:11 hey all, sorry was afk 17:39:33 smooge: when was the "election" date that we put in the interim-EpSCO announcement? 17:39:46 6 months after the committee formed 17:40:06 basically I followed the How to Run a Junta published by the UN 17:40:41 promise elections after 6 months of rule to get things working 17:41:08 anyway I just wanted to bring it up in the meeting and move it to the mailing list. 17:41:40 #topic kbsingh's topic 17:41:46 kbsingh, you have the floor 17:42:01 .. waits for him to get back from changing a diaper or something .. 17:42:16 so, i wanted to bring up the EPEL and CentOS conversation and what we might be able to do around that 17:42:42 for now, folks doing builds in SIgs that need EPEL deps are just building in there locally, but it would be nice to have some sort of a relationship 17:43:05 I know Evolution was going to do something with an FAS account and use that to watch for package updates where we care - but that might not scale past a few rpms 17:43:32 just wondering how people felt about this overall in the epel side of things 17:44:50 kbsingh: one naive fix would be to simply enable epel by default in centos (or make doing so trivial) 17:46:12 rdieter: did that already. 17:46:26 rdieter: 'yum install epel-release' works out of the box. 17:46:45 we pulled that rpm into the -extras repo and re-signed it so that it works out of the box. 17:46:56 Evolution: sure, I was addressing the need for SIGs to rebuild things locally 17:47:16 my question is what do they need from us? 17:47:18 so these rebuilds are things in epel? or things not anywhere? 17:47:20 though "they" (the sigs) could just as well do that too (install epel-release) 17:48:14 nirik: things in epel (I assume) 17:48:48 yeah, so I wonder if we could get at least one person from each sig co-maintainer in epel for that package(s)? 17:48:56 we can do that - just enable it, but we need a way to sync packages and make sure people get equal opportunity to livewith or without updates 17:49:00 nirik: good idea 17:49:05 then they could just do epel builds where possible, and where not at least keep track of rht differences 17:49:54 nirik: I'd suggested something similar on the list, though a group instead of individuals. 17:50:14 kbsingh: I suppose you/centos could do the same as was done with epel-release, and cherry-pick packages (and resign them) as needed 17:50:27 there were loud angry voices about it on the epel-devel list. 17:50:52 rdieter: if we could find a way to communicate stuff across, we could/would be able to better work this i think 17:51:03 as a first cut, would it be possible to at least have a wiki page and track these? 17:51:13 kbsingh: i would like a way to have people contribute to epel through both CentOS and Fedora paths 17:51:29 that is likely quite a bit of work but I do think it is worth the effort 17:51:39 dgilmore: agreed, but there are a couple blockers. 17:51:40 could we form an epel-sponsors group? 17:52:02 dgilmore: yeah, i belive thats one of the big goals - but we might need smaller steps to get there 17:52:07 dgilmore: 1 being git layout. bstinson has a patch in for part of that to make centpkg work 17:52:14 kbsingh: how many packages are we talking about here? (potentially lots?) 17:52:20 bstinson: that was rpkg or something right? 17:52:24 what i was hoping to get somethoughts around in the short term was a way to stop the forking 17:52:32 rdieter: couple of hundred 17:52:36 yow 17:52:37 * smooge has a phone call. will be back in a few... someone can take over ? 17:52:39 Evolution: we're doing all of that logic in centpkg right now 17:52:39 that counts as lots 17:53:04 right, and in some cases, the problem is that there are dep chains that people want to protect 17:53:11 bstinson: ah. I hadn't kept up with that 17:53:20 short of using all of epel, some variant of dgilmore's idea is probably the best long term one 17:53:27 so getting a heads up on say cloud-init being updated, before its public in the user repo, would be good - and likely both ways 17:53:58 Evolution: not sure how that would matter, we would use the existing git 17:54:21 Evolution: but we would need a way to get acls etc across and setup trust for CentOS issues certs to work etc 17:54:33 kbsingh: notifications (espeically in the short term) could be solved with tooling that hooks into fedmsg 17:54:54 dgilmore: agreed. I'd like to see some level of federation through fas/ipa. 17:55:27 dgilmore: from that point groups should be somewhat easy to manage for contributions. 17:55:28 ok back 17:55:41 certs is another matter though. 17:55:43 Evolution: sure 17:56:00 Evolution: certs is not really that hard 17:56:31 and as much of this that can be abstracted away from the user, the better we are - and the more likely it will stick - even if we dont do build acl's - and the co-ordination is limited to sources, were winning 17:56:41 we could add the CentOS CA in the chain. we would need to have unique usernames across 17:57:28 kbsingh: making it completely transparent to the devs should be the goal 17:57:35 yup 17:58:34 happy to leave this question hanging for now, for folks to ponder over and revisit in the new year with some potential conversations in a wider forum 17:58:50 also, if needed, we can take time at Fosdem to sit and talk and look at code and look at repos 17:59:08 i suspect most of the EPEL crew are going to be at Fosdem ? 17:59:18 +1 for that 17:59:40 not i 17:59:48 dgilmore: will you be there this year? 18:00:01 nirik, and I will be in PHX2 playing with networks. 18:00:23 Evolution: I am trying to be there 18:00:28 I will be at devconf 18:00:51 ah, I'm not at that 18:01:53 I'll be at devconf as well but only for a day 18:02:10 but we can work that out, no point in spending meeting time on that 18:02:14 ok so kbsingh dgilmore etc will try to meet up in Europe and have a face to face 18:02:32 Will move rest of discussion to mailing list 18:02:36 #topic Open Flood 18:02:51 do we have any thing for open floor? 18:03:05 kbsingh, I will put this also on our Jan 9 th meeting 18:03:08 i had a question 18:03:27 was the kill-these-packages list built against binary rpms or did it also include buildreq's 18:04:07 only thing I wanted to bring up was golang 18:04:25 epel7 has golang shipped, but it's now in rhel -optional 18:04:39 I thought I remembered it being slated for retiring but couldn't recall 18:04:43 Evolution: then it will need to be pulled from epel 18:04:59 * nirik nods 18:05:20 Evolution: we are working on getting some things setup so that we know when packages get added to rhel so we can automate removing them 18:05:28 ah 18:05:48 we are also going to be taking extra steps to check if a package in in rhel 18:06:56 .wi16 18:07:04 fail :P 18:07:36 kbsingh: from memory its just binary rpms 18:08:41 dammit 18:08:42 yeah. 18:08:47 too many windows. 18:09:53 dgilmore: couple of people were bringing up that buildreq's were being removed as well ) golang bits were mentioned ( 18:09:55 im at about 60 or so 18:10:29 kbsingh: okay. happy to have a closer look at it 18:10:46 dgilmore: thanks 18:12:14 anything we can sort out today? 18:13:21 * nirik wanders off to get more coffee. will read back 18:13:35 btw, also - there is a communiy effort on to get centos7 on powerpc 18:13:49 kbsingh: cool :) 18:13:50 * bstinson heads to the next meeting 18:13:52 they were asking re: epel, but given they dont have the OS done yet, it might be a few months before that question is relevant 18:14:04 kbsingh: doing 32 bit? 18:14:33 kbsingh: epel7 is built for x86_64 and ppc64 18:15:09 kbsingh: there is no current plans to add ppc64le support 18:16:01 i guess right now it comes down to what exactly they are building 18:16:15 dgilmore: i believe this is for power7, and they wnt to do LE later ( based on the tyan build openpower dev boards ) 18:16:18 dgilmore: will check 18:16:39 ok I would like to close out this meeting 18:16:45 thank you kbsingh for the info 18:16:45 kbsingh: okay, well ppc64 is power7 optimised big endian 18:16:50 we build that already 18:17:00 and thanks to everyone else who helped out 18:17:12 I hope you all have a happy holidays and new year 18:17:14 thanks smooge 18:17:17 #endmeeting