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