19:32:11 <smooge> #startmeeting EPEL
19:32:11 <zodbot> Meeting started Mon Oct 18 19:32:11 2010 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:32:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:32:23 <smooge> #chairs tremble
19:32:27 <smooge> #chair tremble
19:32:27 <zodbot> Current chairs: smooge tremble
19:32:36 <smooge> what is up this week?
19:33:17 <tremble> * Role Call
19:33:17 <tremble> * Bug list
19:33:17 <tremble> * Broken dependencies in stable
19:33:17 <tremble> * Conflicting Packages Policy  (derks)
19:33:17 <tremble> * EPEL support cycle
19:33:17 <tremble> * Rubygem-rack Version
19:33:52 * nirik has nothing else.
19:34:16 <smooge> ok we can call it then :)
19:34:32 * tremble is here
19:34:35 <smooge> Role Coal?
19:34:40 <smooge> here
19:34:43 * nirik is somewhat here
19:34:45 <smooge> stahnma, was here
19:34:49 <stahnma> and is
19:34:55 <smooge> cool.
19:35:01 <tremble> and will be to come?
19:35:11 <stahnma> until about 20 past the hour
19:35:53 <smooge> #topic Bug list
19:36:11 <tremble> It's dropping still !
19:36:17 <smooge> how does it stand right now? I need a bookmark
19:36:22 <tremble> 183
19:36:23 <stahnma> I closed a few last week
19:36:26 * nirik filed some more the other day tho. ;(
19:36:28 <stahnma> http://tr.im/epelbugs
19:36:46 <tremble> Down from about 230/240 a month ago
19:37:50 * stahnma has no other new information about bugs
19:37:56 <stahnma> other than I'm still working on some
19:38:24 <tremble> nirik: did you get chance to look into clamav?
19:39:51 <nirik> nope... sorry.
19:39:54 <tremble> Might be worth moving on to rubygem-rack and EPEL support cycle since stahnma needs to go early
19:40:01 <nirik> was hoping rsc would be able to. ;)
19:40:02 <smooge> cool
19:40:19 <smooge> I started looking at making a clamav096
19:40:25 <stahnma> just move the conflicting packages to last
19:40:28 <nirik> do we need to?
19:40:32 <stahnma> and then I can be there for the rest :)
19:40:39 <nirik> I am 99.9% sure it can upgrade fine from the current version.
19:41:02 <tremble> And TBH when it can't it won't be able to pickup updates.
19:41:27 <nirik> there was one update about 2 years ago that introduced an incompatibe change, but we are already long past that version.
19:41:31 <nirik> I think it just needs an update.
19:41:40 <tremble> I think clamav will just need to be an exception due to the changing formats for the clamav datafiles.
19:42:00 <nirik> I don't think it needs one... new version should work fine I am pretty sure.
19:42:06 * tremble nods
19:42:22 <smooge> the changes with llvm are pretty significant.
19:42:46 <smooge> I am not sure if its going to mean more embedded libraries or not.. still looking
19:43:09 <tremble> ergh that would be ugly
19:44:01 <nirik> I suppose I could try and look at clamav. I really dislike it's spec tho...
19:44:33 <smooge> nirik that was my main reason for clamav096
19:45:04 <nirik> understandable.
19:45:12 <nirik> I can try and bug rsc too.
19:45:16 <smooge> I found making mediawiki11X seperate from mediawiki clean
19:45:18 <tremble> just pinging rsc might work, it's worked with a few of the maintainers who'd just not spotted the BZ tickets.
19:47:46 <smooge> ok
19:47:51 <smooge> anything else on this?
19:48:15 <smooge> #topic Broken dependencies in stable
19:48:16 <tremble> That sounds suitably quiet :)
19:48:24 <smooge> stahnma, ping
19:48:29 <nirik> I can go and unpush some more stuff...
19:48:30 <stahnma> still here :)
19:48:32 <nirik> el5 is looking better.
19:48:34 <tremble> #info We've unpushed a whole load already
19:49:02 <stahnma> we need to unpush ruby-dbus and rubygem-rubigen for now
19:49:21 <nirik> ok.
19:49:32 <stahnma> I also need to see if I can easily exclude rhnpush and xulrunner-devel-unstable from the repoclosure
19:49:41 <stahnma> since those are centos vs rhel items
19:50:09 <nirik> qcairo-deve also
19:50:16 <stahnma> ok
19:50:19 <tremble> It's looking much better than it was.
19:50:27 <stahnma> I sure hope so
19:50:31 <smooge> cobbler needs to be unpushed from EL-6
19:50:35 <stahnma> we've been working on it for quite a while
19:50:40 <nirik> the dogtag stuff is known, should be fixed when 5.6 is out apparently.
19:51:03 <stahnma> smooge: is cobbler in rhel?
19:51:09 <tremble> yes
19:51:19 <stahnma> also, I thought we were not unpushing until el6 was finalized
19:51:27 <smooge> oh yeah never mind
19:51:35 <stahnma> I haven't run a signle repoclosure for 6 yet
19:51:40 <smooge> I have been so focused on that I forget
19:51:58 <stahnma> though maybe I should so we can see where we are starting from soon...
19:52:11 <stahnma> although the beta and the final may not be all that similar
19:52:22 <stahnma> EL4 broken deps?
19:52:36 <nirik> I haven't really looked at them...
19:52:38 <stahnma> I see none that look easy to fix
19:52:42 <smooge> I am looking through them
19:52:50 <stahnma> but I haven't done much digging
19:52:51 <tremble> EL-4 broken deps partly depends on what we're going to do on the branching policy...
19:53:22 <stahnma> tremble: true.  Branching/bugfix etc policy for EL4 needs more discussion.
19:53:26 <tremble> if we're dropping EL-4 to a "if you want it, you can branch it yourself" state, then we should probably just unpush things.
19:53:27 <nirik> I can unpush stuff there as well when we are ready.
19:53:37 <stahnma> I tried to start discussion on list
19:53:50 * nirik hasn't had a chance to reply to stahnma's email on list yet.
19:54:02 <stahnma> I remember python-twisted being quite painful to get into el4
19:54:09 <stahnma> the perl stuff I haven't looked at
19:54:21 <stahnma> the php stuff seems impossible at first glance
19:54:22 <nirik> I'd be fine waiting a week and seeing what the list thread consensus is
19:54:27 <smooge> mock is  broken in EL5
19:54:31 <smooge> mock is  broken in EL4 htat ois
19:54:36 <smooge> wow that is bad
19:54:36 <nirik> yeah, el4.
19:54:43 <tremble> Most of the perl stuff just needs things branching, but I'm not sure I want to branch them myself.
19:54:48 <stahnma> smooge: it has been for quite a while
19:55:07 <smooge> I think we will need to look at python26
19:55:28 <nirik> python26 for el4?
19:55:38 <tremble> or just going down the "sorry non-supported" line.
19:55:41 <stahnma> any action items on the topic of deps?
19:56:14 <tremble> I suppose it's possibly worth filling bugs with a deadline?
19:56:25 <nirik> I can unpush more stuff in el5.
19:56:31 <tremble> either get the deps branched or we unpush you.
19:56:32 <nirik> I can try and get rsc to update clamav.
19:56:51 <smooge> I think we will need to discuss on list (I will answer email) and see what is up
19:57:08 <stahnma> ok
19:57:10 <stahnma> next item?
19:57:33 <tremble> EPEL suport cycle?
19:57:45 <stahnma> sure.
19:57:48 <tremble> since it follows nicely on from the discussion?
19:57:48 <smooge> #topic EPEL support cycle
19:57:56 <stahnma> Again, I tried to start a discussion on this one
19:58:04 <smooge> ok 4.9 will be out sometime in the next year :)
19:58:15 <stahnma> Only one reply
19:58:18 <smooge> that will probably be hte last .9
19:58:28 <tremble> A rough outline of a possible EPEL policy ?
19:58:29 <smooge> I have been on so much travel sorry
19:58:44 <nirik> stahnma: yeah, but it was right this morning... I don't think it's fair to expect people to instantly answer. ;)
19:58:57 <stahnma> did everybody do the homework of reading>
19:59:16 <stahnma> nirik: yeah, I was thinking that it was an action item from the meeting, but we should ask everybody for input
19:59:23 * tremble was a good boy and did his homework ;)
19:59:26 <stahnma> also, I didn't see the minutes/log of last meeting posted
19:59:32 <nirik> yeah, I think 2 hours before meeting isn't enough time to gather input from the list. ;)
19:59:38 <stahnma> so i figured better late than never
19:59:40 <stahnma> nirik: agreed
19:59:41 <nirik> yeah.
19:59:44 <stahnma> https://access.redhat.com/support/policy/updates/errata/
20:00:00 <nirik> in principal I agree we should try and follow rhel's cycle/policies where it makes sense.
20:00:15 <tremble> Postpone discussion until next week to give people time to chime in on the list?
20:00:25 <stahnma> the one reply said they thought EPEL did this from the beginning.  I was around for EPEL in the beginning and I honest never remember this discussion
20:00:25 <tremble> My reading was if we follow EL...
20:00:35 <stahnma> other than saying we need to be able to support packages for 7 years
20:00:39 <tremble> 4 - Should be bugfixes only
20:00:51 <tremble> 5 - drops to no new packages when 6 arrives.
20:01:02 <tremble> 6 - should stablise on GA...
20:01:24 <stahnma> I'm not sure I'd want to close out 5 right when 6 hits, but shortly thereafter...
20:01:27 <nirik> yeah, the only part of that that could be trouble is the no new packages for 5... but not sure how many we get these days.
20:01:27 <stahnma> maybe
20:01:43 <nirik> I'd say lets address next week after more input.
20:01:44 <stahnma> almost every new package I put in, the main reason I do it is for EPEL and EL5
20:01:52 <stahnma> rawhide/fedora is just part of the process
20:02:02 <nirik> yeah, el5 is going to be the main release still for most people.
20:02:08 <schlobinux_> you never know what you will need, so I think I'm against a hard "no new packages" policy for 5
20:02:38 <stahnma> i'm not all that in favor of it...
20:02:53 <smooge> I think we have had enough conversations over the years on EPEL that any sort of conversation has happened and people will think we did it from the beginning
20:02:56 <stahnma> I'm worried about fragmenting our limited number of epel maintainers and resources even further than they already are
20:03:39 <tremble> Maybe we wait and see how fast 6 is adopted?  possibly go no-new 1 year after 6 GA?  (as a compromise)
20:03:56 <smooge> To be honest most RHEL installations I know of are still 4 and then 5.
20:04:42 <smooge> I doubt 6 will grow to the point that 5 will not need new packages
20:05:08 <traylenator> I certainly still want to add to 5 for another couple of years at least, today I still add to 4.
20:06:14 <stahnma> ok, I don't think we have a firm enough policy for any type of vote anyway
20:06:24 <stahnma> let's see what comes in on list and maybe the discussion will somewhere helpful
20:06:25 <tremble> Not by a long shot
20:06:51 <tremble> traylenator: if you have comments, then chiming in on the list would be useful.
20:06:58 <stahnma> maybe the policy should only apply to open bugs, we are then allowed to close them as WONTFIX :)
20:07:29 <tremble> that may be the better way
20:07:30 <stahnma> anything else on this topic for now?
20:07:47 <stahnma> I have one question.  Are we planning on keeping epel around during extended support cycle?
20:08:07 <nirik> good question.
20:08:22 <stahnma> I would probably vote no on that, or we just leave the repo around without change
20:08:23 <nirik> will there be regular security/etc updates for that?
20:08:32 <stahnma> looks like it
20:08:41 <stahnma> critical security
20:08:52 <tremble> I think EL-4 gets security fixes for the next couple of years IIRC
20:08:55 <stahnma> and it's an upcharge to the base RHEL subscription
20:09:09 <stahnma> tremble: until Fed 29 2012
20:09:13 * tremble nods
20:09:16 <nirik> stahnma: well, then I guess the question might be: do we get those so we can update koji? or not...
20:09:24 <stahnma> then we move into Extended Life until Feb 28, 2015
20:09:24 <nirik> if not, then we should just stop
20:09:31 * tremble nods
20:09:39 <stahnma> nirik: good question
20:09:57 <nirik> I guess we don't need to answer that now. ;)
20:10:01 <stahnma> not quite yet
20:10:04 <tremble> Indeed
20:10:09 <stahnma> next topic?
20:10:33 <tremble> #topic rubygem-rack
20:10:40 <stahnma> I think we briefly covered rubygem-rack in #epel last week, but here's the summary
20:10:53 <smooge> thanks. had phonecall
20:11:03 <stahnma> rack was put into epel at 0.4
20:11:08 <stahnma> but nothing depended on it
20:11:14 <stahnma> many things want rack 1.0 or higher
20:11:16 <stahnma> I'd like to move it
20:11:22 <stahnma> there is some small ABI breakage
20:11:39 <smooge> ok
20:11:42 <stahnma> but I know of nobody in their right mind using 0.4
20:11:45 <stahnma> for anything
20:11:46 <stahnma> ever
20:11:55 <tremble> How difficult would it be to put compat patches in?
20:11:58 <stahnma> and I keep up with ruby stuff pretty well
20:12:03 <stahnma> tremble: pretty difficult
20:12:07 <tremble> ok
20:12:20 <smooge> ugh patches like that are "pay me a lot of money, and i will think about it" level
20:12:28 <stahnma> ++
20:12:37 <stahnma> so, I'd like to move it to 1.1
20:12:44 <stahnma> and send something to the announce list about it
20:12:54 <stahnma> just in case anybody is using the 0.4 version for anything...
20:12:55 <smooge> sounds good
20:13:12 <stahnma> that will fix 3 more ruby dep issues in stable
20:13:13 * nirik nods. ok.
20:13:14 <tremble> To be honest whenever I went anywhere near the ruby stack in 4 things were just too out of date,
20:13:23 <stahnma> 5 isn't a ton better
20:13:34 <tremble> so improving that probably isn't a bad thing.
20:13:40 <stahnma> the railsrumble was this weekend and less than 2% of people used CentOS/Fedora :(
20:13:54 <stahnma> made me very sad
20:13:56 <tremble> What were they using?
20:14:00 <stahnma> ubuntu mostly
20:14:09 <stahnma> which I think also has a very messed up ruby stack
20:14:25 <tremble> probably a faster moving messed up stack?
20:14:28 <stahnma> but mostly ruby guys just install rubygems from a package manager and then gem install the rest
20:14:38 * tremble nods
20:14:40 <stahnma> or more howtos on digg ;)
20:15:00 <stahnma> ok, I will move rack and send announcement
20:15:05 <stahnma> you can mark that as an action
20:15:14 <tremble> That doesn't surprise me (just installing gems) reminds me of how I used to manage the perl stack on machines :)
20:15:36 <tremble> #action stahnma update rubygem-rack and mail the list
20:15:47 <tremble> ping derks
20:16:06 * stahnma packs up
20:16:07 <stahnma> bye
20:16:15 * tremble waves to stahnma
20:16:26 <tremble> #topic Conflicting Packages Policy  (derks)
20:17:02 <tremble> #info Derks was looking into trying to put together a conflicting packages policy for the "parallel" install packages.
20:17:21 <nirik> yeah, there was more discussion on list about this just right before the meeting.
20:17:25 <tremble> #info He emailed the list today
20:17:49 <tremble> I think we just postpone til next week and see what becomes of that thread?
20:17:56 <tremble> anyone opposed?
20:18:05 <nirik> not i
20:18:38 <tremble> #topic Open floor
20:18:54 <tremble> Ah derks
20:18:56 <derks> sorry I completely missed everything
20:19:03 <derks> had to give my father a ride somewhere
20:19:45 <tremble> Did you have anything much to add on the conflicting packages side of things, or should we just wait and see what comes from the thread on the list?
20:19:50 <derks> so, there wasn't much feedback on my email to the list until just now when i pinged it again today (regarding comflicting packages policy)
20:20:52 <derks> dmalcolm has a good point in that... there may be good reason for someone to want python26-mod_{python,wsgi} installable on the same box... even if it should not or can't run in the same process
20:21:07 <tremble> IIRC conflicts can be forced though ?
20:21:24 <nirik> forced?
20:21:27 <derks> tremble, definitely at the rpm level... not sure about the yum level
20:21:32 <derks> --force
20:21:50 * skvidal stabs
20:21:51 <tremble> Would be ugly when trying to pickup updates.
20:21:52 <nirik> oh god I hope not
20:22:03 <nirik> yum wouldn't let you do that kind of stupidity.
20:22:07 <nirik> rpm might
20:22:39 <tremble> I suppose one option with python26-mod.... might be alternatives if everything's in EPEL.
20:22:50 <tremble> Some of it's EL though IIRC?
20:22:52 <nirik> I think we should go with the 'no conflicts' thing based on dmalcolms input.
20:23:18 <derks> so, I think with the feedback we have so far, it would probably be best to no do explicit conflicts in epel
20:23:29 <nirik> yeah, thats what I am thinking.
20:23:43 <traylenator> For me the only reason to add a conflict is if installing it will break the first package.
20:23:52 <tremble> Does feel like the only easy option to allow what usecase.  With README.(fedora|epel) warning messages...
20:24:04 <traylenator> But that is something to avoid at all costs.
20:24:16 <smooge> yes
20:24:31 <tremble> Which is why Fedora has that policy
20:25:53 <derks> honestly, I don't forsee this subject popping up much outside of the pythonXY-xxxxx situation.
20:26:10 <traylenator> So for the mod_python26 case having the ! IFModule stuff stops mod_python26 breaking mod_python so there's no conflict.
20:26:19 <nirik> right.
20:26:26 <derks> concur
20:26:34 * tremble nods
20:26:59 <derks> python26-mod_wsgi has a double IfModule check for mod_python adn mod_wsgi
20:27:28 <derks> so it will only load if python_module and wsgi_module are not already loaded
20:27:50 <tremble> What happens if you load the other way around?
20:28:25 <derks> good point... if you have python26-mod_wsgi installed....  and working.... and then install mod_wsgi ... python26-mod_wsgi will cease to function
20:29:02 * derks watches the hole getting deeper
20:29:30 <tremble> We may just have to go with best efforts and a README.fedora
20:29:31 <smooge> I would go with the "ah fuck it.. packaging is hard. lets go to Ubuntu"
20:29:40 * tremble laughs
20:29:44 <derks> ha
20:30:18 <nirik> I think anyone likely to be installing python26-* would likely know how to configure it or look for a readme.
20:30:26 <nirik> they have to go out of their way to install python26
20:30:47 <smooge> nah.. htey just need to install something that needs python26
20:30:48 <tremble> Add something to the description?  "Please read the README.fedora" ?
20:30:58 <smooge> I would say add the README.fedora
20:30:59 <derks> nirik, I would agree.  I don't think there is anything wrong with assuming a higher level of competency in this or similar situations
20:31:07 <nirik> smooge: which would have 'python26' in the name. ;)
20:32:37 <smooge> I was thinking of more an application like plone or turbogears or something?
20:33:07 <smooge> or would any application needing pythong26 need its name?
20:33:30 <nirik> well, in general an application shouldn't need a python26 version
20:33:52 <abadger1999> well, plone and TG would both have python26 i nthe name as they're frameworks rather than apps, but I see your point.
20:34:01 <derks> smooge, not necessary... I'm looking to submit a package for 'cement' which is a cli application frame that needs python26... but its not just a library
20:34:07 <traylenator> If that was case we would not need/want python26.
20:34:25 <nirik> derks: doesn't run at all with default python?
20:34:41 <derks> nirik, in fedora yes.  epel 5 no
20:34:45 <abadger1999> smooge: But it'll drag python26 in... not python26-mod_python... so it shouldn't cause issues that I can see.
20:36:10 <derks> abadger1999 I assume you meant that plone ang tg would *not* have python26 in the name, yeah?
20:36:57 <tremble> with the frameworks possibly wrap the conf.d file in a ! IFModule  to make it obvious, that's the first place I'd look if things weren't working/
20:37:19 * nirik has to go work on work stuff.
20:37:35 <abadger1999> derks: Well.. I think the naming is a bit of a tangent to the initial question.
20:37:40 <traylenator> It maybe should have py26 in the name just case a madman ports it back to python2.4.
20:37:55 <smooge> well actually from what I can tell with pythons short life-times and applications sitting on it.. people will want apps/tools that won't work on 2.4 (heck tons of python stuff doesnt work with it anymore)
20:38:02 <tremble> Proposal, move this discussion onto the list (or #EPEL)
20:38:08 <smooge> I can see pressure for python27 in probably a year
20:38:12 <abadger1999> ie: just having python26 installed on the system won't cause issues for mod_python.  It's not until you have both mod_python and pyhton26-mod_python that you get problems.
20:38:36 <derks> tremble, agree
20:38:41 <abadger1999> derks: Err -- TG would definitely have python26 in the name.
20:38:45 * abadger1999 moves to #epel
20:38:59 <tremble> So Open Floor wise....
20:39:01 <smooge> agree
20:40:10 <tremble> EL-6 RC went to ISVs  http://press.redhat.com/2010/10/18/red-hat-enterprise-linux-6-release-candidate-available-to-partners/
20:40:36 <tremble> anything else people want to add?
20:41:05 <tremble> Closing in 1 minute...
20:42:03 <tremble> #endmeeting