21:00:59 <smooge> #startmeeting Fedora EPEL 2010-03-12
21:00:59 <zodbot> Meeting started Fri Mar 12 21:00:59 2010 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
21:01:16 <smooge> #topic HI all, hi back if you want
21:01:31 <tremble> hi smooge
21:02:07 * nirik is around.
21:02:19 <smooge> ok this will probably be a short short meeting.
21:02:33 <smooge> with most of the discussion on mailing list.
21:02:40 <smooge> #topic agenda
21:02:47 <smooge> Ok the things we will go over:
21:03:05 <smooge> 1) EPEL package issues with RHEL packages
21:03:15 <smooge> 2) EPEL block list for
21:03:45 <smooge> 3) EPEL repository redesign
21:03:51 <smooge> 4) Open Floor
21:04:01 <smooge> #topic EPEL package issues with RHEL packages
21:04:39 <smooge> Ok skvidal got me a script and I think I hacked it down to what I needed.. though it may have some bugs still.
21:05:08 <smooge> that generated a list of EPEL packages that effectively trump RHEL packages when required to be installed.
21:06:09 <smooge> Several of the packages seem to get pulled in because of 'leakage' of sublibraries in the EPEL package.
21:06:26 <nirik> yeah, I saw the post, but haven't had a chance to look at it more closely.
21:06:35 <nirik> whats the next step on this? file bugs on the issues?
21:06:40 <smooge> I will ask dgilmore if the %global items are workable for the EPEL build system to see if we can clean it up.
21:06:44 <smooge> and then file bugs
21:07:18 <tremble> FTR the atlas one, t does put liblapack onto the ldd search path
21:07:18 <smooge> I would say filing bugs is a good idea. We can close them later if it turns out that putting something into koji default fixes them
21:08:06 <smooge> for the case of something like qemu-img we need to figure out a way to change its provides somehow else
21:08:55 <smooge> tremble, yes.. I think its more about the fact that rpm says it provides it but the compares is not 'path-based'
21:09:48 <smooge> since we started discussion only today on what could be done.. I think this will be an open issue til next meeting. However, I would like to have closure by that meeting
21:10:00 <nirik> yeah.
21:10:00 <smooge> anything else?
21:10:22 * smooge trying to be a good moderator for the meeting and not running it all
21:10:24 <smooge> hi stahnma
21:10:27 <stahnma> hi
21:10:38 <stahnma> better late than never :)
21:10:55 <smooge> we are talking about the EPEL competition issue.
21:11:08 <stahnma> we have competition?
21:11:21 <smooge> where EPEL packages out-compete RHEL pacakges and thus get installed incorrectly
21:11:28 <stahnma> oh
21:11:47 <stahnma> I was trying to make sense of that email thread, but didn't spend much time on it
21:11:50 <smooge> the discussion is still going on in the list, so its going to be an open issue til next meeting. I am looking for any other input on it from members at the moment
21:12:27 <stahnma> ok
21:13:17 <smooge> #topic EPEL block list
21:14:00 <smooge> Ok I think I have an initial list for us to ask rel-eng to block in building for EPEL. Its time to pair it down and see what items we missed or put in over
21:14:18 <nirik> smooge: cool. Did that go to the list yet?
21:14:27 <smooge> it should have
21:14:41 * nirik is behind on his email for some reason.
21:15:07 <smooge> Packages where EPEL and redhat.com SRPMS conflict
21:15:10 <nirik> smooge: is that list against 5.4 ? or 5.5b?
21:15:20 <smooge> 5.4..
21:15:32 <smooge> its whats on ftp.redhat.com and 5.5b source isnt there.
21:15:42 <nirik> ok.
21:15:54 <smooge> I need to grab the 5.5 source RPMS and do it right again.
21:16:08 <smooge> I ran out of space and whacked the wrong isos
21:16:18 <nirik> I guess I would say we should ping maintainers of those, confirm that they don't have any objection to blocking them, then block them all, mark dead.package, etc.
21:17:24 <smooge> basically its just for i in *src.rpm ; do rpm -qf='%{NAME}\n' -qp $i; done > list ; sort -u list > src-list ; comm -1 -2 src-list epel-src-list
21:17:47 <smooge> for things that in both and -2 -3 for ones that are in rhel only
21:18:56 <smooge> nirik, yes. dgilmore had mentioned that there would be some packages that need to be non-dead but I forget which ones and wanted his input on that when we got to it
21:19:05 <nirik> sounds good.
21:19:12 <smooge> sorry for the delay but my stone-age DSL has made it slow to download
21:19:32 <smooge> should have it all wrapped up for a +1/-1 next meeting
21:19:40 <smooge> so we can close it out then
21:20:02 <nirik> so do we want to contact maintainers now? or wait and make sure of the list?
21:20:33 <smooge> I would say lets get dgilmore's input (it should be quick) and then contact maintainers
21:20:51 <smooge> then call Mar 26 flag day
21:20:57 <smooge> does that sound ok
21:21:14 <nirik> sounds good.
21:21:21 * tremble nods
21:21:23 <smooge> okie dokie... one last topic
21:21:37 <smooge> #topic EPEL repository redesign (brainstorming)
21:22:09 <smooge> ok this is a last minute thing that someone mentioned to me and I remembered just now
21:22:16 <smooge> it goes with the nirik slipstream idea
21:22:32 <nirik> oh, I have some news on that... sorta
21:22:37 <smooge> which in many ways could be a 'redesign'
21:22:42 <smooge> ok listening nirik
21:22:52 <nirik> I mailed the packaging list and asked for input on our incompatible upgrades woes.
21:23:01 <smooge> I saw that.
21:23:30 <nirik> no replies so far, but perhaps we will get some good ideas.
21:23:48 <nirik> http://lists.fedoraproject.org/pipermail/packaging/2010-March/006935.html
21:25:03 <nirik> so we will see.
21:25:08 <nirik> what brainstorming did you have smooge?
21:26:18 <smooge> ok what someone on #rhel pm'd me about was that stable gave the impression that stuff in it never changed
21:26:19 <jokajak> is the meeting still going on?
21:26:30 <smooge> or that they would be able to get all the old stuff
21:27:01 <smooge> it was something I had brought up once and I guess they read it and pm'd or just co-incidence
21:27:05 <stahnma> you'd basically have version a repo to get that
21:27:12 <stahnma> like, have a daily snapshot with a yum config
21:27:24 <stahnma> and then a client could subscribe to whatever version they desired
21:27:38 <stahnma> with rsync and hardlinks (link dest) this isn't all that undoable
21:27:55 <smooge> yeah.. I am not sure its something that dgilmore would want to do :).
21:28:09 <stahnma> I am not sure it is all that sane
21:28:11 <stahnma> but it is doable
21:28:27 <stahnma> it's something we're kind of working on at another place I work with
21:28:37 <smooge> they were wondering about something like recent upcoming eats-kittens
21:29:40 <smooge> and I thought, well I like this slipstream idea (which isn't a eats-kittens) so maybe it would be a good idea to bring them up together
21:30:10 <nirik> jokajak: yes
21:30:21 <smooge> oh wait I got the list wrong:
21:30:25 <nirik> well, stable means different things to different people.
21:31:08 <smooge> old, recent, upcoming, eats-kittens, and I would put slipstream as the 4th.
21:31:55 <smooge> nirik, I agree.. its a semantic issue, but one that seems to cause confusion to some people. And I realize it was bikeshedding but I wanted to bring it up once before it died
21:32:01 <smooge> or I forgot again
21:32:10 <nirik> well, there is no way we have resources to do all those. ;)
21:32:31 <smooge> well old is basically everything that was in recent but pushed out
21:32:39 <smooge> recent is 'stable' with a name change
21:32:51 <smooge> upcoming is testing with a name change
21:33:00 <smooge> eats-kittens is rawhide for epel
21:33:34 <smooge> and slipstream is where stuff that doesn't make the epel stability goes after upcoming.
21:33:51 <nirik> well, from a high level, cool... but I think it would take a lot of work to make that work with our infrastructure.
21:34:15 <nirik> I was envisioning only those 'problem children' packages in slipstream... not everything...
21:35:08 <smooge> yeah.. that was what I meant.. a package would flow from 'kittens -> upcoming then go either to slipstream or recent. Stuff afterwords would go to old.'
21:35:18 <stahnma> I think a lot of people would enjoy a raw-hide or something like it for epel
21:35:26 <stahnma> but difficulty level is high
21:35:32 <smooge> yeah.. I agree
21:35:57 * stahnma says as he tries to compile F13 sudo for EL4
21:35:58 <stahnma> :)
21:36:21 <smooge> do you guys think this is DOA ?
21:36:56 <nirik> well, I'm not even sure we could get buyin on a slipstream, much less more repos. ;(
21:36:59 <smooge> as in I am asking for a ponicorn not just your average pony
21:38:02 <smooge> ok I am going to ping dgilmore about what resources would be needed off hand for a slipstream and see if its feasible or something.
21:38:14 <smooge> planning is hard, lets go shopping.
21:38:15 <nirik> that might be the way to go...
21:38:31 <smooge> #topic Open Floor because thats all thats left.
21:38:39 <jokajak> was mod_wsgi discussed?
21:38:46 <smooge> no no it wasn't
21:38:50 <jokajak> excellent!
21:38:57 <smooge> #topic Open Floor mod_wsgi
21:39:05 <smooge> you have the floor
21:39:07 <jokajak> mod_wsgi cannot be run in the same apache instance as mod_python
21:39:23 <jokajak> EPEL currently ships an ancient version of mod_wsgi
21:40:08 <jokajak> i would like to update mod_wsgi to the most recent release (3.2), have mod_wsgi disabled by default, include a comment block in the mod_wsgi httpd configuration file describing the limitiations
21:40:34 <jokajak> and ship that in epel
21:41:03 <jokajak> users would then be able to install mod_wsgi and either disable mod_python and enable mod_wsgi, or use mod_wsgi in a mod_python compatible way
21:41:38 <jokajak> as it currently stands, if someone installs mod_wsgi and tries to use it apache segfaults
21:42:13 <nirik> jokajak: I personally think thats an acceptable plan.
21:42:14 <smooge> ok. what would happen to exisiting users
21:42:34 <nirik> good question.
21:42:39 <smooge> they should just get a rpmnew correct?
21:42:58 <smooge> or would it turn off mod_wsgi after an update
21:43:21 <smooge> jokajak, sorry for the last minute thought on my part
21:43:22 <jokajak> mod_wsgi would stay as it currently installed
21:43:35 <jokajak> the spec file has the configuration file as a config file, no replace
21:43:53 <jokajak> so any users that currently is using it would just get an upgrade in place
21:43:56 <nirik> right, and the new one is backward compatible on the config?
21:44:45 <jokajak> yes
21:45:00 * nirik sees no problem with the update then.
21:45:24 <jokajak> as far as i can find, mod_wsgi 3.1 is backwards compatible with 2.5
21:45:42 <smooge> ok
21:45:49 <smooge> no problem on my part either.
21:45:55 <smooge> stahnma, ?
21:49:31 <smooge> ok I think we have no problems so go for it.
21:49:48 <smooge> ok anything else?
21:50:01 <smooge> I think its just us 4.. so I can close in 1 minute
21:50:35 * nirik doesn't have anything.
21:51:02 <smooge> #endmeeting