19:30:34 <nirik> #startmeeting EPEL (2011-04-18)
19:30:34 <zodbot> Meeting started Mon Apr 18 19:30:34 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:34 <nirik> #meetingname epel
19:30:34 <zodbot> The meeting name has been set to 'epel'
19:30:34 <nirik> #topic init process/agenda
19:30:34 <nirik> #chair smooge tremble
19:30:34 <nirik> EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge nb maxamillion tremble Jeff_S
19:30:34 <zodbot> Current chairs: nirik smooge tremble
19:31:02 * rsc_ is around
19:31:06 * tremble lurks
19:31:43 <nirik> rsc_: care to discuss that package we were talking about the other day... see if anyone else has ideas?
19:31:49 * nirik didn't have much else for topics.
19:32:07 <rsc_> nirik: yeah...postfix26 AND glue-...-devel
19:32:20 <nirik> yeah, ok.
19:32:38 <nirik> #topic Replacing/parallel install packages in EPEL5
19:32:47 <nirik> so, care to describe some background here?
19:32:51 <nirik> or would you like me to?
19:32:52 <dgilmore> hi
19:33:40 <rsc_> I've packaged a newer version of postfix for several reasons for EPEL 5. The only issue is, it overlaps with the postfix package.
19:33:45 <smooge> here
19:33:54 <nirik> welcome smooge, dgilmore.
19:34:14 <rsc_> the question is now, how we're going to handle that in EPEL. Is it something like php vs. php53 in RHEL or do we need /etc/postfix26 /var/spool/postfix26 etc.
19:34:37 <rsc_> and do we allow, if we agree for replacements, for a general rule for EPEL?
19:34:38 <nirik> yeah, the waters got muddied by php53 and postgresql84 IMHO.
19:34:58 <nirik> both of those conflict with the base versions (but they are all in RHEL)
19:35:09 <rsc_> args, above sentence is broken. Do we think about a genreal rule for EPEL, if we agree about replacements.
19:35:50 <nirik> the other case is the cluster-glue-devel package... RHEL ships cluster-glue, but didn't ship the -devel subpackage. Is there any sane way for us to ship that?
19:35:52 <rsc_> right. But sometimes there are packages where it makes just less to no sense to have the old and the new version
19:36:15 <rsc_> right, but that's RHEL 6
19:36:28 <tremble> nirik: I assumed you posted an RFE for it to turn up in optional or something?
19:36:41 <nirik> tremble: yeah.
19:37:03 * dgilmore thinks we shouldnt be shipping things like a newer postfix
19:37:22 <dgilmore> if we did it would have to be completely parrallel
19:37:34 <dgilmore> not like what is in rhel with postgres84
19:37:38 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=692940
19:37:40 <dgilmore> where it conflicts
19:37:45 <rsc_> dgilmore: with which benefit exactly?
19:38:04 <dgilmore> rsc_: violating our goals and foundations if we do
19:38:10 <rsc_> dgilmore: that means we have to patch postfix to use other calls and to use other directories
19:38:20 <dgilmore> rsc_: yes
19:38:34 <dgilmore> it shouldnt be simple to replace bits as we choose
19:39:19 <rsc_> dgilmore: if we come to that in the end, I'll go CLOSED/NOTABUG or WONTIFX. The effort isn't worth that. And aside, postconf26 is not something, that admins want to type ;)
19:39:53 <rsc_> from the admin perspective, most serious postfix admins really even hate that old 2.3 thing in RHEL 5 ;)
19:40:14 <dgilmore> rsc_: its a dangerous slippery slope making it easy to replace bits of rhel, especially when we have always said that is something we will not do
19:41:07 <rsc_> dgilmore: and? If I remove the original postfix and use postfix26 with /etc/postfix26 - isn't that replacing bits of RHEL, too?
19:41:16 <rsc_> dgilmore: where exactly is the difference for you?
19:41:34 <dgilmore> rsc_: I dont think its a path we should go down period.
19:41:49 <dgilmore> but if we do then it needs to be completely parrallel
19:41:49 <rsc_> dgilmore: it's not a path, but all postfix binaries and paths.
19:41:59 <dgilmore> rsc_: your not getting me here
19:42:14 <dgilmore> rsc_: its a path your trying to push epel down
19:42:23 <dgilmore> one that we said was out of bounds
19:43:15 <rsc_> rules are there to be broken...that's what we do all the time in Fedora ;-)
19:43:36 <dgilmore> rsc_: rules are not menat to be broken
19:43:58 <dgilmore> rsc_: this is a change that i will very actively work against
19:44:18 <dgilmore> it violates what we have said epel will not do since day 1
19:44:21 * nirik has to go unfortunately.
19:44:27 <nirik> can someone else run things?
19:44:33 <dgilmore> I can almost say ok if its completely parrallel
19:44:34 <smooge> will take it
19:44:40 <smooge> as I have no horse in this contest
19:44:49 <smooge> can you chair me
19:44:51 <dgilmore> but if its not and it conflicts with base rhel then its not ok
19:44:53 <dgilmore> ever
19:44:55 <rsc_> do we still have a EPEL steering commitee?
19:44:59 <smooge> no
19:45:08 <rsc_> what a pity.
19:45:10 <smooge> nirik, can you chair me beofr you go
19:45:19 <nirik> #chair smooge
19:45:19 <zodbot> Current chairs: nirik smooge tremble
19:45:23 <smooge> basically the steering committee went about 2 years ago
19:45:57 <smooge> when you have 4 people on the Steering Committee and they are the only ones showing upo
19:46:47 <rsc_> okay, so this discussion is useless and wasted time then. We've "want it" and "dislike it", but nobody who's able to vote on it...
19:47:56 <smooge> sadly correct.
19:48:32 <rsc_> in the end, the EPEL project is broken, because we've rules but can't work on them.
19:48:59 <smooge> well how can we fix it
19:49:26 <rsc_> try to get a steering commitee again which will experience the same issues like years before?
19:49:46 <rsc_> (sorry, I'm realist not idealist)
19:50:36 <rsc_> as it's more or less a talking to myself...let's try to get the RHEL 6 issue done?
19:51:07 <smooge> ok what is the RHEL-6 issue
19:51:32 <rsc_> RHEL 6 is shipping the cluster-glue package like in Fedora, but they do not ship the cluster-glue-libs-devel subpackage which is required for building heartbeat.
19:51:50 <dgilmore> rsc_: that will be fixed with 6.1
19:51:59 <rsc_> dgilmore: for sure? Not 6.2?
19:52:07 <dgilmore> rsc_: i was told 6.1
19:52:20 <dgilmore> it was an accident that it did not gets hipped
19:52:21 <rsc_> dgilmore: and when will 6.1 show up? Because that prevents us from heartbeat in EPEL 6.
19:52:31 <dgilmore> rsc_: when it ships
19:52:37 <dgilmore> i dont have access to that
19:52:40 <smooge> so basically its dead til then.
19:52:41 <smooge> sigh
19:52:51 <tremble> rsc_: Given 6.1 is already in beta, I would guess a couple of months.
19:53:00 <dgilmore> i imagine it wont be too long since 6.1 is in beta
19:53:18 <rsc_> well, there are two options: Rebuild whole cluster-glue in EPEL with same ENVRA or build just the -devel package for EPEL 6, which isn't that hard
19:53:25 <rsc_> or wait...which isn't an option to me.
19:53:47 <rsc_> if there's also no solution to this, EPEL starts getting more and more useless to me, sorry.
19:56:19 <smooge> well I would say lets look at IUS... but its wiki seems untaken care of for quite some time
19:57:51 <smooge> ok so since this seems dead today. What else was on the agenda today?
19:58:17 <smooge> #topic Open Floor
19:58:36 <jokajak> oo, i've got a question
19:58:38 * nirik returns
19:58:41 <rsc_> [21:31:43] < nirik> rsc_: care to discuss that package we were talking about the other day... see if anyone else has ideas?
19:58:44 <rsc_> [21:31:49] * nirik didn't have much else for topics.
19:59:24 <smooge> jokajak, <=
20:00:16 <jokajak> i set up a local mirror of the epel and rhel packages in  koji and i noticed that there are several packages that are in both epel and rhel
20:00:51 <rsc_> packages that overlap with RHEL 5.6 the first time or older thing? I thought, somebody unpulled overlaps in RHEL < 5.6...
20:01:01 <tremble> jokajak: Some are only available in a few repos
20:01:08 <tremble> arches even
20:01:22 <jokajak> tremble: right, but many of them that i found were perl packages which are usually noarch
20:01:32 <smooge> jokajak, it can happen for some packages if they were in the distro at 5.n-2 and 5.n no longer has it
20:01:48 <jokajak> oh, and this is in RHEL6, sorry, forgot to mention that
20:01:54 <smooge> jokajak, a list and what channel they were in.. would be useful.
20:02:02 <jokajak> i've got a list, i'll have to work on the channel
20:02:08 <smooge> RHEL6 is a mess
20:02:16 <jokajak> smooge: no kidding :(
20:02:22 <tremble> jokajak: Yeah IIRC there might even be noarches only available in some arches.
20:02:23 <smooge> well I think all of RHEL's multi channels are a mess
20:02:31 <jokajak> is this something i should bring up on the list?
20:02:39 <nirik> jokajak: there are some we allowed in for i686... rhel only shipped them for 64bit
20:02:42 <nirik> please do.
20:03:04 <tremble> jokajak: probably simplest if you bring it up on the list if you don't have the list to hand.
20:03:20 <jokajak> like i said, i have the packages just not what channel they conflict with
20:03:29 <jokajak> http://fpaste.org/MGoP/ are the packages
20:04:18 * tremble recognises a lot of them as having fallen foul of being available in 1 arch only
20:04:54 <jokajak> so that means the noarch is only shipped in one of the arches?  man that is dumb
20:05:59 <nirik> they were only needed for the virt stack
20:06:05 <nirik> and it's only shipped on x86_64
20:06:20 <rsc_> the virtualization stack in RHEL 6 is just crazy...
20:07:27 <nirik> anything else? or should we close out?
20:07:42 <smooge> I am done
20:09:24 <nirik> ok, thanks for coming folks.
20:09:28 <nirik> #endmeeting