16:01:09 #startmeeting EPEL 16:01:09 Meeting started Fri Sep 26 16:01:09 2014 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:09 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:01:14 #meetingname epel 16:01:14 The meeting name has been set to 'epel' 16:01:28 #topic Meats and Greets 16:01:29 * nirik is sort of here, but also trying to catch up on email flood. 16:01:34 hi all 16:01:39 morning 16:01:44 hello 16:01:45 I'm here for the most part 16:01:46 g'morning 16:02:11 hello all. I am also dealing with an email flood :/ 16:02:48 #topic Old Business? 16:03:01 #info EPEL trac is sort of operational 16:03:42 I got it installed and I thought working but it isn't sending email properly :/ 16:03:57 we can get it sorted. ;) 16:04:19 hopefully I will have that done soon but I would like people to look over what I have in the tickets so far and see what else we need added 16:05:04 The primary goal of the tickets are to track items that don't fit into bugzilla and need long term viewing and reminding 16:05:57 should we start pointing people at it for adding meeting items to the agenda? 16:06:07 yes please 16:06:37 because leaving it to my mind only gets the voices telling me to add redrum to the list 16:06:59 #info Items to be discussed at EpSCO should now be directed to Trac https://fedorahosted.org/epel/ 16:07:33 #chair bstinson Evolution nirik dgilmore 16:07:33 Current chairs: Evolution bstinson dgilmore nirik smooge 16:07:42 sorry forgot that in my agenda listing 16:07:50 #info Items to be discussed at EpSCO should now be directed to Trac https://fedorahosted.org/epel/ 16:07:55 in case it idnd't take the first time 16:08:15 does the bot need ops or do we care? 16:08:21 for topic and such 16:08:26 it needs the topic to be changeable 16:09:18 and I can't get Chanserv to do anything at the moment.. I don't have the right password for this channel or something 16:09:35 ok stop whining and get back to the meeting 16:09:40 I think we should just -t the channel 16:09:45 ie, anyone can change the topic. 16:10:29 nirik, that is what I was trying but I couldn't get it to do so 16:12:13 ok next topic 16:12:19 #topic New Business? 16:12:33 I want to thank bstinson for helping on list this weeks 16:13:14 that is my day in a nutshell.. try all kinds of ways to get ChanServ to op me... 16:13:33 well I will figure it out after this meeting 16:14:04 for new business, how are you doing the testing for version/package conflicts. 16:14:13 is there an existing toolset for this, or are you doing so locally? 16:14:23 ok what I am doing so far is the following: 16:14:34 1) set up a local mirror of centos and epel. 16:14:40 2) install mock on system. 16:15:08 3) work out what an 'everything install' is on CentOS choosing to not install packages which conflict with each other (samba vs samba4, etc) 16:15:08 okay. so there isn't an existing epel toolchain for this then 16:15:19 no I am trying to build one 16:15:37 4) enable epel repo in mock chroot and do a yum update. 16:15:53 5) see what tries to get updated in base package set. 16:15:53 we could potentially build this into the centos t_functional testing that we run at [root@cockpit cockpit]# rpm -q cockpit 16:15:56 cockpit-0.24-2.el7.centos.x86_64 16:15:59 er.. dammit. ci.dev 16:16:07 sorry, buffers are hard. 16:16:50 we have a jenkins instance going at ci.dev.centos.org where we could automate this to generate reports 16:17:04 would that be useful here? 16:17:12 yeah what I am trying to get is a dumbed down version of yum/rpm which only does the package installs to the database so I don't need ~30 GB per arch per distro to see what an install takes 16:18:44 or some sort of plugin to repoquery which can figure out if I have 2 repos what upgrades what in which repo, what conflicts with what in which repo (and if it conflicts does it have an explicite Conflicts tag or does it wait until it gets to file conflicts) 16:19:25 I need to look at your last posted list... for el6. 16:19:35 I think some of those are limited arch ones... but need to dig 16:19:46 then it could drop into a jenkins or a taskotron and we can do a weekly report and also tie it into "I want to put this package in EPEL.. NOPE can't do it until I add a conflicts or nope not at all' 16:20:14 nirik, they might be limited arch ones.. but I did it on an x86_64 box 16:20:44 right, we only can find that out by looking at if the packages are not in all arches on rhel. 16:20:59 smooge: is it possible to do that with some sort of yum transaction dry run? 16:22:18 maxamillion, most likely. I tried a dry run first time, but found that EL5 and EL6 core have a lot of conflicting packages 16:22:27 might be worth talking to fedora qa folks... I know they looked at some kind of conflicts test for taskotron, but I don't know how it's implemented. 16:22:32 so I was trying to figure out what ones I cared about and what ones I didn't 16:22:45 smooge: oh :/ 16:23:16 now that I have that.. yeah a dry-run may be what I can do 16:23:18 nirik: oh yeah, they might already have something like this in the AutoQA work they did 16:23:45 well, autoqa is going to get turned off real soon and taskotron in production 16:24:17 so I think that getting this working in both CentOS and Fedora environments is needed 16:24:46 nirik: oh ok, so it's going autoqa -> taskotron? 16:25:30 that way CentOS will have a method for their SIGS to deal with and we have a method tied into our 'business' logic to see if a package can get included in the EPEL review stages 16:26:43 that makes sense 16:27:16 +1 16:27:20 yep yep 16:27:30 ok cool. 16:27:52 #action work on getting conflicts methodology worked in Centos and EPEL for various needs. 16:28:05 or soemthing like that 16:28:29 #topic RHEL-5.11 16:28:34 * maxamillion runs 16:28:51 Evolution, do you know the status for CentOS-5.11? 16:29:32 smooge: it's built. we're getting the iso trees sorted currently. 16:29:42 should be out reasonably soon-ish. 16:30:20 cool 16:30:23 it was a minimal package changeset, and bash was the only stupidly-high-priority fix, so we didn't do cr this time. 16:30:29 Evolution: is it tested already? (also, is any of that QA data public?) 16:30:35 cr? 16:31:06 continuous release. it's an optional repository so folks can get security updates that might be part of a new release while we test isos. 16:31:14 ah got it 16:31:25 that way they're not delayed while we scream at isolinux or whatever. 16:32:16 maxamillion: for older releases it's not public. everything for 7 is either at buildlogs.centos. or on bugs.centos. 16:32:19 i must scream but isolinux # with apologies to harlan ellison and everyone else in channel 16:32:50 Evolution: ah, cool cool 16:33:04 ok thanks. I was mainly wanting to see if I had a bunch of packages we needed to x out 16:33:11 maxamillion: early on we had a number people who wanted to 'help test' simply to get early access. 16:33:25 Evolution: ah 16:33:53 ooooo ... mock.cfg, logs, and srpm ... *nice* 16:34:03 anyways... sorry, I'm completely off topic 16:35:00 no problem my coffee maker decided to pour out its sides for some reason.. 16:35:28 :( 16:36:32 nirik, dgilmore there was something I remember about us wanting to build lists of packages to be dead.package for EPEL so we didn't branch core overlaps versus just need for ppc 16:37:05 well, yeah, we should look at packages added in 5.11 and see if there's any in epel that need retiring 16:37:16 or am I misunderstanding the question? 16:37:33 yeah. that was my plan 16:37:55 I didn't know if it had been automated sometime in the past or if doing it manuallish was still the way. 16:38:30 if it wasn't automated I was going to volunteer to make a list and work on getting either packages removed, blocked or whatever was needed 16:39:42 and if it is manualish I would document the steps put them in a documentation area and then have it as a wrangler task for 6.6 and 7.1 16:39:55 it's not automated at all. 16:40:03 it's manual when someone does it ;) 16:41:16 usually new packages added is in the release notes... 16:41:20 is that a "file a bug" event or a "find a provenpackager to dead.package it" event? 16:41:24 okie dokie. I will put in a ticket and take it 16:41:59 bstinson, I don't know know... nirik ? 16:42:26 in the past we have filed bugs, waited for maintainers a bit, then just done it if they didn't do anything. 16:42:36 but we could just do it I guess. 16:43:46 nirik, how often have the maintainers done it themselves versus just needing to do it :)? 16:44:04 well, hit or miss I guess. 16:44:18 not that it really matters. I expect we will just say we are providing a new service for maintainers on channels they don't care about :) 16:45:15 bstinson Evolution, the next topic item was on the cloud-init convergence between the CentOS extras and the EPEL one.. do you know if anything has happened on this? 16:45:45 smooge: I don't think so. we have some patches that have been accepted upstream, but aren't in the epel version. 16:46:09 I need to diff the packages to see which they are, then submit a patch/bug to add then. 16:46:15 I think we need to get some of the centos maintainers commits on the epel version to get them in sync. 16:46:18 * nirik nods 16:46:55 we'll likely have another coming shortly from the rackspace/onmetal guys. 16:47:30 ok let me know if I can help on this any. 16:47:51 which leads me to 16:47:52 will do. it's finding free time currently. 16:47:57 #topic website cleanup 16:48:49 so I am going to start on this next week of going through each of the pages in https://fedoraproject.org/wiki/Category:EPEL 16:49:18 and seeing if we have stuff we need to pull, update list as OMG WHO WROTE THAT (OH RIGHT ME..) 16:49:21 etc 16:49:37 could we do this in 2 passes? first to mark pages as possibly deprecated and second to bring the deprecated ones up to date 16:49:48 oh it is going to take multi passes.. 16:49:57 being fairly new, i'm not sure where to start but i'm happy to ask questions and write some content 16:50:02 this compiler needs 8 passes before its ready :) 16:50:06 good luck and thanks. ;) 16:50:19 * nirik did the last revamp a few years ago... it was anoying and time consuming. 16:50:22 nirik, what was the page that you had to fight with a while back 16:50:37 nirik, I can say that the last revamp broke the EPEL committee :) 16:51:05 well, I reorganised things to have user and contributor and such path... and tried to answer everything on each page... so we did not need a FAQ page. 16:51:18 but other people kept reviving the faq and linking it back in. ;( 16:51:23 ok I thought it was the FAQ . 16:51:26 there's a bunch of old crap in the faq 16:51:35 and a bunch of things answered in other pages. 16:52:26 well ok so I would like to do the following: start with the FAQ, if it isanswered on a different page point in the FAQ to that other page. if it is old, make a page with the new stuff and point it to that. 16:52:41 sure, feel free. 16:53:18 I don't think we can get rid of the FAQ (it is the cockroach of EPEL I guess) but if we make it just includes to those pages versus being a seperate document.. it should make it a lot easier. 16:53:30 maybe 16:53:40 sure, thats a good approach. Just point to the maintainers page for maintainer questions, etc. 16:54:47 yeah.. also I would like to have a connection to COPR content for people who want packages but don't fit into current EPEL 16:55:03 which leads to the last topic 16:55:15 #topic EPEL.Next status 16:55:15 copr very seriously needs groups 16:55:49 I don't know enough about it to know what it needs or not. The page I found on the wiki about it was from over a year ago.. 16:56:13 Evolution: not sure if thats planned. Would be nice tho yeah. 16:56:24 you can grant acls to others already I think tho 16:57:09 So part of getting EPEL.fast or other items dealt with was to get the original house in order ( a trac, cleanup of current trees, documentation of methods used in those, setup of EpSCO to deal with problems, and a couple other items.) 16:57:55 So next week trac will be checked off, cleanup of current trees should be on its way, documentation of methods will go hand in hand, and EpSCO setup should be dealt with. 16:58:34 sure, but note this is all organizational stuff (very handy and good) but we need to get actual stuff done in the end too. ;) 16:58:59 so we might want to get things more progressed before focusing on more repos, etc. 16:59:29 correct. I figure there are things that need to be dealt with next 16:59:51 I have been in with the alligators for a while.. so I don't know what the next step is :) 17:00:15 nirik, so what do you think the next stuff needed before we get to repos and such 17:00:55 Evolution: I'll look into adding a patch to handle copr groups ... won't be this weekend, I have a wedding to go to but hopefully before long 17:01:00 Evolution: either groups or projects 17:01:09 dunno. I think at the very least we need to decide on what repos and how they work and write up a VERY VERY CLEAR expectations for people. 17:01:36 sorry for forgetting what we were going to do next.. but I got so transfixed on organization :) 17:01:37 smooge: I think the next step is mostly to just define what EPEL.next is going to be right? maybe we should get a wiki doc together and have interested parties add to it 17:01:39 updates@fedoraproject.org changed the Status on bug 1127540 from ON_QA --- to CLOSED ERRATA. 17:01:39 Bug https://bugzilla.redhat.com/show_bug.cgi?id=1127540 drupal6, medium, medium, ---, peter.borsa, CLOSED ERRATA, drupal6: drupal: denial of service issue (SA-CORE-2014-004) [epel-all] 17:01:57 https://fedoraproject.org/wiki/EPEL-faster-repo-ideas 17:02:10 updates@fedoraproject.org changed the Status on bug 1110726 from ON_QA --- to CLOSED ERRATA. 17:02:10 Bug https://bugzilla.redhat.com/show_bug.cgi?id=1110726 perl-Email-Address, low, low, ---, rob.myers, CLOSED ERRATA, CVE-2014-0477 perl-Email-Address: Denial-of-Service in Email::Address::parse [epel-6] 17:02:14 maxamillion, nirik yeah.. I think that is where we need to go. 17:02:30 updates@fedoraproject.org changed the Status on bug 1110725 from ON_QA --- to CLOSED ERRATA. 17:02:31 Bug https://bugzilla.redhat.com/show_bug.cgi?id=1110725 perl-Email-Address, low, low, ---, rob.myers, CLOSED ERRATA, CVE-2014-0477 perl-Email-Address: Denial-of-Service in Email::Address::parse [epel-5] 17:02:49 bstinson: yeah. 17:03:03 maybe this can take the whole meeting next time (unless there is really pressing administrivia) 17:04:06 bstinson, I agree. Could people go through https://fedoraproject.org/wiki/EPEL-faster-repo-ideas and either check if there is an existing ticket or put in a part of that the want to discuss in the upcoming meeting 17:04:20 smooge: +1 17:04:30 if there is an existing ticket just add a +1 and then I can use that to see what is on the agenda in what order 17:04:52 sounds good. 17:05:25 #action EVERYONE INTERESTED IN EPEL. Go through https://fedoraproject.org/wiki/EPEL-faster-repo-ideas and then open a ticket in https://fedorahosted.org/epel or +1 an existing ticket on items that will be discussed next meeting. 17:05:36 #topic Open Flood 17:05:44 OK any items for the general floor? 17:06:04 if not I can close in 1 minute 17:06:20 thank you all for coming and helping out. 17:06:49 thanks smooge! 17:06:53 I do appreciate all your time and putting up with my pauses due to 'a day, a week, a month' 17:06:59 thanks smooge 17:07:10 #endmeeting