21:00:17 <nirik> #startmeeting EPEL SIG (2010-01-15) 21:00:17 <zodbot> Meeting started Fri Jan 15 21:00:17 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:25 <nirik> #meetingname epel 21:00:25 <zodbot> The meeting name has been set to 'epel' 21:00:30 <nirik> #topic Init process 21:00:36 * stahnma is here 21:00:41 * maxamillion is here 21:02:22 <nirik> smooge ? 21:02:30 <smooge> here 21:02:31 <smooge> sorry 21:02:38 <maxamillion> oh hai :D 21:02:46 <smooge> hi guys.. welcome to TOTAL DRAMA REPO 21:02:56 <maxamillion> lol 21:03:01 * vpv is here as well 21:03:21 <smooge> tonight will inode0 or stahnma win when asked to eat a THOUSAND BUGS!!!! 21:03:39 <nirik> #topic Status update on action items 21:03:40 <smooge> will maxamillion or nirik be up to the challenge of REMOVE THAT PACKAGE OR ELSE 21:03:51 <smooge> and now I will sit down and be quiet 21:03:52 <maxamillion> roofles 21:03:52 <nirik> smooge: you have that list of packages we were going to block? whats the status on that? 21:03:56 <stahnma> I brought my llama! 21:04:09 <nirik> (these are the ones that are in 5.4 that we were going to now block in epel) 21:04:15 <nirik> (not anything to do with the channel discussion) 21:04:22 <smooge> nirik, which package set am I looking to block. Stuff that is in /os/ or other 21:04:42 <nirik> smooge: well, I suppose we could just wait and tie it into the later discussion. 21:04:45 <smooge> I have been tracking down other for a bit... so I need to get the first one back into head 21:04:53 <nirik> These were the ones in base os. 21:05:15 <smooge> Ok I had a list.. and I need to find it again. Wow that was pre-FUDcon wasn't it. 21:05:16 <smooge> sorry 21:05:23 <smooge> It should only take a bit 21:05:26 <maxamillion> I suppose we can cover the ones in the base os since at least that much appears to be agreed upon as $bad 21:05:34 <maxamillion> (for many values of $bad) 21:05:39 <nirik> ok, if dgilmore tells me which tag to block those in, I can just do it. 21:06:03 <nirik> so, we can do that out of band of this meeting/later. 21:06:32 <nirik> Next we have "Fuse for 5.4 status" which rayvd was poking at. 21:06:49 <nirik> I know we do now have some fuse packages branched and happy 21:07:12 <smooge> happy happy joy joy 21:07:16 <nirik> so, onward. 21:07:19 <maxamillion> I honestly didn't entirely understand that "Fuse for 5.4 status" ... what all is supposed to be covered there? 21:07:20 <nirik> #topic Moin - Any takers? 21:07:25 <maxamillion> oh jeebus 21:07:38 <vpv> I haven't heard from anyone... 21:07:41 <nirik> maxamillion: sorry, that was because fuse was in the 5.4 kernel... so now we can have fuse packages in epel. 21:07:50 <maxamillion> nirik: ahhh ok 21:07:54 <nirik> maxamillion: so, we were trying to proactively notify them to branch now. 21:08:03 <nirik> vpv: :( 21:08:15 <maxamillion> I *love* moin and wouldn't mind taking it, but I'm going to be the first to say that we should break it in favor of security 21:08:28 <maxamillion> "it" being the upgrade path 21:08:36 <maxamillion> nirik: very cool 21:08:44 <stahnma> according to our guidelines, I think that is ok 21:08:45 <nirik> maxamillion: do you know for sure that there are outstanding security issues in the current version that can't be backported? 21:08:59 <stahnma> of course we all know how awesome all the guidelines are :) 21:09:01 <maxamillion> nirik: unfortunately, the *one* package I want on a RHEL box running FUSE needs a newer version of FUSE 21:09:11 <maxamillion> nirik: no, that much I don't know 21:09:21 <vpv> maxamillion: I agree, but then someone should make sure that the data migration scripts work, which is my main consern 21:09:39 <maxamillion> nirik: but upstream no longer supports it so who ever is going to take it will essentially be maintaining a moin fork single handedly 21:09:40 <nirik> maxamillion: if you want to take moin, go for it. ;) 21:10:22 <smooge> ok the big issue is that the data-migration script when I ran it required you to stop moin, run the script, fix some other stuff, bring moin up. 21:10:24 * maxamillion doesn't have the web development know-how to handle something like that ... I could triage bugs and help upstream and maybe offer a patch for things in the parser, but web programming is out of my scope of knowledge 21:10:24 <nirik> if you can find outstanding security issues that cannot be backported, you can under our current rules ship the newer one. (after notifying epel-announce, etc) 21:10:48 <maxamillion> smooge: I thought the migration script was very "hit or miss" 21:10:55 <smooge> maxamillion, it is 21:11:01 <smooge> we spent a week cleaning up by hand stuff 21:11:07 <maxamillion> smooge: ah ... ouch 21:11:40 <smooge> nirik, there are security fixes but should a person have to show that it affects the old stuff (which it might but you may need to rewrite the exploit to find it etc) 21:12:05 <smooge> personally I hate webapss with a passion now 21:12:06 <nirik> well, not sure how much we need to go into it... just a 'very likely affects' I would think or something. 21:12:15 <maxamillion> smooge: +1 21:12:22 <maxamillion> fat clients FTW 21:12:36 <nirik> anyhow, unless we get someone willing to deal with it, shall we give it another week and then stop shipping the current one at all? 21:12:41 <smooge> I should orphan mediawiki 21:12:50 <vpv> when I was looking at the security issues, I had the problem that I wasn't sure if a new fix really concerned the 1.5 branch or not. And upstream wasn 21:13:03 <vpv> wasn't really interested in helping with an abandoned branch 21:13:06 <smooge> vpv assume that it will 21:13:14 <smooge> most of the time they do 21:13:22 <maxamillion> nirik: that's a possibility I suppose ... but we might also want to look into getting some pen testing done against it with some common tools and see if there is even anything outstanding that will make us need to nuke it 21:13:43 <maxamillion> I might be able to con our security officer to run a nessus scan across it or something 21:14:03 <nirik> I doubt such tools are geared for finding the kind of vulnerabilities that it has. 21:14:07 <maxamillion> "our security officer" = CSO at $dayjob 21:14:24 <nirik> "you're running moin 1.5. Give up now!" 21:14:59 <nirik> We don't want to keep shipping it if it has no maintainer. 21:15:08 <nirik> even if it was not vulnerable. 21:15:10 <smooge> No if it has no maintainer it should go 21:15:13 <smooge> or be updated 21:15:51 <nirik> ok, shall we move on to the fun discussion? 21:16:07 <smooge> personally I think with webapps we are going to have to come up with a policy of "its in this repo, it gets updated when RHEL sends out a new update. Updates may kill kittens." 21:16:09 <maxamillion> nirik: right, but if there isn't a big outstanding vulnerability I don't mind maintaining it ... I just can't promise I could pull off a patch for it if there was a security issue to arise 21:16:48 <maxamillion> smooge: wait, what? ... how does RHEL updates coordinate with EPEL updates? 21:17:02 <smooge> maxamillion, they don't. 21:17:26 <vpv> maxamillion: someone should go through all the security issues Moin has annouced and try to find out if they need to be fixed in 1.5. I just didn't get it done... 21:17:33 <smooge> maxamillion, If I was the proverbial ShadowMan who can tell people what to do .. we would schedule big updates at that time 21:17:35 <maxamillion> smooge: right but you said "it gets updated when RHEL sends out a new update" ... how does RHEL send an update to an EPEL package? 21:17:43 * dgilmore is here now 21:17:58 <smooge> maxamillion, I meant 5.3 -> 5.4 ->5.5 ->5.6 21:17:59 <maxamillion> smooge: I think I misunderstood you or missed something somewhere 21:18:04 <smooge> or 6.0 -> 6.1 -> 6.2 21:18:11 <smooge> I think I missed a word 21:18:14 <maxamillion> smooge: ah ... but how would that fix Moin? 21:18:25 * maxamillion is really lost :/ 21:18:34 <smooge> maxamillion, when RHEL-5.5 came out you could update moin to 1.maintainable 21:18:48 <smooge> versus keeping a stale branch around. 21:19:00 <smooge> does that make it any better. 21:19:32 <chrismcc> I like the update when RHEL X.Y+1 with the "may kill kittens" approach 21:19:35 <nirik> smooge: I think I agree with that idea, but we should still not do that just because we feel like it on those boundrys... it should be a real need (not maintained upstream anymore, etc). 21:19:43 <maxamillion> smooge: ah, ok 21:19:51 <smooge> nirik, yes I agree 21:19:55 <nirik> also it would be well to be communicated as much as possible. 21:20:04 <smooge> in most cases its not supported upstream anymore with most webapps 21:20:18 <stahnma> do most people jump on RHEL x.y+1 as soon as it is released? 21:20:20 <stahnma> I know we don't 21:20:24 <maxamillion> we do 21:20:27 <maxamillion> well 21:20:31 <maxamillion> we do and don't 21:20:39 <smooge> "Oh its friday? I don't look at anything from earlier than monday... too far in the past..." 21:20:55 <nirik> we do with our centos boxes (as soon as they release it). We sometimes wait more on rhel ones if requested. 21:20:58 <maxamillion> all new builds (we are adding servers like mad) get the new version and all the rest are updated during our quarterly downtime 21:21:04 <smooge> stahnma, where I worked previously.. there is a cron job that does a yum update at 4am every night. 21:21:19 <stahnma> smooge: that's awesome and makes update really easy 21:21:27 <stahnma> and puts a lot of trust in RH 21:21:30 <stahnma> and my ISVs 21:21:38 <stahnma> which I don't quite have 21:21:40 <nirik> stahnma: right, so if people don't they would be confused by this... or broken by it. 21:21:52 <stahnma> yeah 21:21:57 <stahnma> like my boxes are in a 5.3 frozen channel 21:22:01 <nirik> anyhow, should we move on to the channel talk? or continue talking incompatible upgrades? 21:22:11 <stahnma> but maybe grab epel from newer stuff...which is dumb now that I write it down 21:22:14 * nirik wants to change the topic as we aren't really talking about moin anymore 21:22:18 <stahnma> ok 21:22:42 <smooge> yeah.... lets say it was better than dealing with "oh wait we need to update stuff?" and finding a 3.0 box that had never been updated running IRCd for something even lower than efnet 21:22:51 <smooge> but oracle would have a cow 21:23:07 <stahnma> yeah, asm/rac falls over 21:23:21 <stahnma> (It's not all that unbreakable) :) 21:23:24 <nirik> #topic EPEL swimming in the RHEL channels 21:23:36 <nirik> so, this has been the hot topic on the list... 21:23:40 <smooge> stahnma, dgilmore I would love to have some way we could do frozen 'channels' for releases.. but well I am not sure that would be feasible disk wise 21:23:44 <stahnma> I tried to discuss on list the best I could 21:23:47 <nirik> when is an EPEL package conflicting with a RHEL package. 21:23:53 <smooge> ok topic near and dear to my ulcer 21:24:12 <nirik> Can we all agree we shouldn't ship something thats in os/ 21:24:21 * maxamillion honestly didn't think the inquery about nagios would turn into this 21:24:21 <stahnma> +1 21:24:22 <nirik> for workstation/server 21:24:24 <chrismcc> +1 21:24:26 <maxamillion> nirik: +1 21:24:29 <smooge> stahnma, I understood and liked your questions.. sorry if I was 'snippy' in my reply. I should have waited a while before SEND 21:24:39 <stahnma> smooge: I didn't read it yet 21:24:49 * stahnma goes to fuel the fire! 21:24:50 <dgilmore> smooge: its not pratical or feasable 21:24:55 <smooge> +1 nothing in /os/ or CentOS base. 21:24:58 <dgilmore> smooge: not unless we get alot more help 21:24:59 <smooge> dgilmore, I didn't think so 21:25:13 <dgilmore> smooge: it requires extra cvs branches 21:25:15 <smooge> dgilmore, its my pony wish for the week 21:25:15 <dgilmore> koji tags 21:25:25 <dgilmore> banging head on desk 21:25:39 <smooge> dgilmore, would it be any easier when we go to git.. probably not. 21:25:47 <nirik> ok, next then is: should we never conflict with any channels we have srpms for on the mirror? ie, enterprise/ 21:26:01 <dgilmore> smooge: or do you mean we make a snaphot of the epel tree when 5.5 comes out 21:26:03 <smooge> dgilmore, no problem.. I wanted to just see feasibility. Dont hurt your head 21:26:24 <smooge> dgilmore, we make a snapshot of the epel-tree when 5.5 came out. 21:26:26 <dgilmore> smooge: we could somewhat easily keep the tree as it was 21:26:32 <smooge> epel becomes no frozen rawhide 21:26:38 <dgilmore> smooge: but it owuld never get update 21:26:39 <dgilmore> s 21:26:41 <dgilmore> ever 21:26:41 <inode0> is the intermediate step of "doesn't conflict with AP" worth thinking about short of conflict with anything? 21:26:49 <smooge> oh nm 21:27:00 <nirik> inode0: can you explain whats in AP? 21:27:08 <maxamillion> nirik: that is apparently a not as "cut and dry" situation to deal with ... in an ideal world I think we should not ship anything that RH makes openly available and we are able to verify that they ship, this will keep us 100% (to the best of our knowledge) a non-conflicting repository 21:27:27 <stahnma> AP == RHEL + Clustering stuff and Virtualization stuff 21:27:27 <inode0> RHEL basic things plus cluster suite and gfs 21:27:27 <stahnma> I think 21:27:31 <stahnma> and it's a rhel5 only 21:27:36 <maxamillion> nirik: buuuuut, in the real world where people want tools like git without paying for a channel, we're in a bit of a bind I suppose 21:28:12 <smooge> inode0, it is basicially "What CentOS ships" with a lot more support. 21:28:14 <inode0> it *is* the supported enterprise class flavor or RHEL 21:28:28 <nirik> does Centos ship those things? 21:28:43 <inode0> yes, CentOS does rebuild cluster suite and gfs 21:28:51 <stahnma> yes, but I don't rmember if it's in core or extras or addons or whatever 21:28:56 <nirik> and includes them in Base? 21:29:06 <inode0> no idea where they have it 21:29:15 <smooge> nirik, yes. Its all the stuff that comes on the main DVD so it gets rebuilt and plugged in. kbsighn didn't want to do a channel thing because it seemed a nightmare 21:29:32 * smooge puts on old CentOS QA hat. 21:29:38 <stahnma> kbsighn was right :) 21:29:41 <nirik> ok. 21:29:45 * smooge takes off CentOS qa hat and puts on Red Hat employee hat. 21:29:55 <nirik> so, with that I am +1 to not conflicting with AP. 21:30:33 <maxamillion> I am +1 with not conflicting AP as well 21:30:36 <smooge> ok I will just look at the SRPMs for those then to see what would be conflicting/pulled 21:31:05 <nirik> sure, more data is cool. 21:31:05 <smooge> and will put that as the list to block against. 21:31:06 * inode0 thinks the rest has to come in and be accommodated somehow 21:32:05 <nirik> the next step would be any of the things we have srpms for: 21:32:14 <nirik> JBEAP JBWFK RHCERT RHDOCS RHEMRG RHNSAT JBEWS RHDirServ RHEIPA RHNPROXY RHWAS 21:32:51 <nirik> (and here's where it gets sticky of course) 21:33:01 <dgilmore> smooge: srpms can be a red herring. we could use the same srpm name but ship different rpms. say we shipped ppc java and java plugin for i386 x86_64 21:33:03 <maxamillion> I'd really like to not ship anything in any of those, but I know that's not going to happen because it would make EPEL far less useful 21:33:13 <stahnma> on my "i want pony wish list" it would be easiest if RH just put all that content in EPEL, and if you want support, buy it 21:33:13 <dgilmore> i dont think we have any of that but its possible 21:34:00 <smooge> dgilmore, would it be useful to use them as a starting point? or is something better 21:34:21 <nirik> I would like to propose: we don't automatically confict if something is in this list, but we can remove things on a case by case basis if asked by RHEL. We can also try and ask our maintainers to try and communicate with any rhel version maintainrs in those channels to reduce problems. 21:34:22 <maxamillion> stahnma: that'd be fun ... or we could just rebuild their RPMs 21:34:29 <maxamillion> SRPMs* 21:34:45 <chrismcc> If RH put those in EPEL, then most likely RH would still always be behind. e.g. puppet would get updated in EPEL, but RH would (probably) still be shipping an older version. 21:35:00 <smooge> chrismcc, correct. 21:35:10 <stahnma> what if the RH maintainer == EPEL maintainer 21:35:25 <stahnma> then he/she could move it when ready 21:35:26 <nirik> stahnma: they talk to themselves and come to an accomodation? 21:35:30 <smooge> or in the case of 389 or cobbler.. the developers know the people using it are RHEL people and not Fedora people. 21:35:50 <smooge> so they push the newer versions there so that people can test/use/etc 21:36:23 <smooge> its also what the spacewalk+dogtag etc people want. An avenue to talk to users who are wanting new things 21:36:48 <smooge> but can't or aren't able to use Fedora to do so 21:37:09 <smooge> EPEL looked like for them the place to do it... and in many ways some of us encouraged it 21:37:25 * inode0 thinks that is a good mission/purpose for EPEL 21:37:43 <smooge> I think 1) We need to take down all the EPEL pages from the wiki and rewrite them to be nice and simple. 21:37:58 <smooge> 2) Put out a bunch of policies of what EPEL's mission is. 21:38:05 * stickster is reading back buffer -- also just saw stahnma's message from earlier today 21:38:09 <maxamillion> smooge: I agree, but we need to know what to put on them first 21:38:20 <smooge> 3) Declare that we don't like to kill kittens but are known to kill small frogs every now and then 21:38:32 <maxamillion> stickster: welcome to the suck, population us 21:38:34 <smooge> 4) skvidal eats orphans 21:38:40 <skvidal> mmm mm orphans 21:39:01 <stickster> I'd like to help by getting some visibility on this internally. We did this once before but apparently we're not catching all these channels properly 21:39:02 <smooge> fava beans do not go well with them 21:39:20 <smooge> stickster, it has been multiple times. 21:39:25 <stickster> *nod 21:39:49 <inode0> stickster: I pinged acathrow when I bumped into him about this, he went off to think some 21:40:04 <stickster> inode0: Great, I'll make sure to loop him in then 21:40:31 * nirik wonders if anyone liked his proposal or has another one. 21:40:51 <stickster> AIUI the upshot is that EPEL folks can't see all the RHN channels, so you guys can't ensure that there's no conflicts across the board. 21:41:12 <smooge> stickster, actually it goes a bit more than that 21:41:13 <stickster> And at the same time, no one's come to you to say, "here's what's in those channels" in a way that lets you make an informed decision about what to carry where 21:41:25 <stahnma> and if we have conflicts, we're not sure how to handle them 21:41:29 <smooge> there are conflicts and those conflicts would impact certain teams getting their product to testers 21:41:32 <stahnma> like, should we remove puppet and nagios from EPEL? 21:41:38 <stahnma> if we do, EPEL now sucks a whole lot more 21:41:45 <chrismcc> +1 21:41:54 <stahnma> and I need to find another enterprise linux repo 21:41:58 <stickster> Right, because on one hand, RHEL users using EPEL could be in for ping-pong updates; and on the other, if EPEL just drops stuff, it gets a lot less useful 21:42:11 <stahnma> that's the upshot 21:42:25 <smooge> eg 389, spacewalk, and ipa would have to be pulled because not of name conflicts in main rpms but conflicts in under packages (python-my-mom-dresses-me-funny or something) 21:42:43 <inode0> won't ping pong much, more likely just replace what Red Hat ships with whatever consequences flow from it 21:43:00 <stahnma> and could cause support contract issues if you buy RHDS 21:43:04 <stahnma> then yum update 21:43:11 <stahnma> and get parts of 389 from EPEL 21:43:37 <stahnma> (I am in that boat, and maintain 389 in EPEL. Sometimes, I jus do this junk to myself......) 21:43:58 <maxamillion> nirik: which proposal? 21:43:59 <inode0> I am pretty comfortable with the following compromise 21:44:00 <smooge> well I think the best thing we can do for that is advertise how to set up your own mirror and subchannel mirrors (ok I mirror epel locally, and then copy over XYZ packages to a sub-repo and my clients go from that sub-repo versus epel directly) 21:44:08 <maxamillion> nirik: I might have missed it in the calamity 21:44:08 <nirik> I would like to propose: we don't automatically confict if something is in this list, but we can remove things on a case by case basis if asked by RHEL. We can also try and ask our maintainers to try and communicate with any rhel version maintainrs in those channels to reduce problems. 21:44:15 <inode0> (1) Don't conflict with AP for those users wanting a conflict free world 21:44:53 <inode0> (2) Let anything go with layered products to support both users who want more and developers who find EPEL useful for feedback 21:45:13 * stickster is going to retread because he hasn't read the whole ML thread 21:45:27 <maxamillion> nirik: I like that I suppose, but I don't know how feasible that is since we are (as I keep hearing) considered upstream to RHEL 21:45:59 <nirik> inode0: can you clarify your 2) there? let go how? 21:46:07 <nirik> maxamillion: how would it not be feasable? 21:46:25 <inode0> allow conflicts with layered products since doing so supports 2 good use cases for EPEL 21:47:16 * nirik nods. Agrees with inode0 21:47:23 <maxamillion> nirik: we don't know the work flow of those RH counter parts for our packages ... what are those packages to do where the Hatter isn't able to work with the non-Hatter? 21:47:29 <chrismcc> and maybe ask RH maintainers to communicate with EPEL maintainers. It should not be a one way street in the communication process. 21:47:45 <maxamillion> chrismcc: right, that's more or less where I was going with this 21:47:48 <nirik> maxamillion: we ignore them and go on our way, we can't force them to talk to us. 21:48:09 <stickster> Under inode0's proposal, would it be possible to have some sort of EPEL yum plugin that retrieved a current list of conflicts and then made sure EPEL users aren't overriding RHN material with EPEL material? 21:48:12 <stickster> chrismcc: +1 21:48:13 <maxamillion> nirik: right, but that would (at least in my mind) ruin the work flow and potentially bring us back to this sort of topic again in the future 21:48:20 <nirik> I'm just saying we should be open to dropping things or modifying our packages when another channel/repo asks us politely to do so. 21:48:32 <maxamillion> nirik: ah, ok 21:48:36 * maxamillion misunderstood 21:48:45 <nirik> maxamillion: if they don't ask us, we do the best we can. 21:48:54 <maxamillion> fair enough 21:49:00 <nirik> stickster: not sure if any such plugin would work with rhn plugin. 21:49:09 <stickster> hrmph 21:49:20 <nirik> stickster: and rhel4/epel4 would be out of luck. 21:49:43 <stahnma> stickster: and if you don't use RHN but a local yum repo, I guess that wouldn't work 21:49:51 <stahnma> but if you use a local yum repo, you should konw what you are doing 21:49:54 <chrismcc> does the rhn plugin support the yum exclude tag? 21:50:00 <inode0> stickster: under my plan users who use RHEL layered products need to be careful using EPEL, that is all 21:50:10 <smooge> I think the only way I could see it working is someone maintain epel-bare-naked-repo with all the conflicts manually taken out 21:50:30 <stickster> nirik: *: So did someone already suggest an epel-base, epel-ds, ... repo? 21:50:40 <nirik> inode0: yeah, and I would hope that many of the users of those specific channels would have special purpose machines using them for that purpose. 21:50:41 <inode0> which they need to be now because those conflicts currently exist 21:50:48 <nirik> stickster: yes, nightmare. 21:50:53 <maxamillion> smooge: or break into epel and epel-conflict repos 21:50:59 <maxamillion> smooge: but that gets icky either way 21:51:03 <smooge> inode0, I think that is doable. Its like any mixing of repos. If you turn on all the layered channels for a system from RH you are going to end up with a world of hurt anyway 21:51:24 <stickster> nirik: Where epel-base = "known OK", epel-X = "known to conflict with RHN X", epel-Y = "known to conflict with RHN Y" ? 21:51:47 * stickster apologizes for wasting any time with this. 21:51:52 <nirik> I wish we had a way to communicate to people using those other channels something simple like: "be carefull using EPEL, you should check for conflicts and use includepkgs" 21:52:20 <stahnma> it's kind of difficult though too, because like the MRG channel ships puppet, IIRC. People buying MRG are not doing so to get puppet (AFAIK) 21:52:20 <stahnma> they are doing it for MRG, which happens to use puppet for some stuff 21:52:21 <nirik> stickster: the complexity goes way up. We don't have the infrastructure for it, IMHO. 21:52:26 <stahnma> should puppet be in a conflicting channel? 21:52:31 <stickster> nirik: Where do people go to enable EPEL now? Don't they have to end up at some point on the "fp.o/wiki/EPEL" site or some such? 21:52:44 <maxamillion> nirik: in the epel-release package can there be a way to check for those repos being enabled and print a simple message if one of those channels is found? 21:52:58 <smooge> stickster that was an idea.. the issue was complexity.. and manhours of dealing with it. dgilmore only have so much go juice 21:52:59 <maxamillion> s/repos/channels 21:53:01 <nirik> stickster: possibly. They just install epel-release... there is a how to use epel landing page on the wiki, but they might have just gotten the epel-release link before. 21:53:16 <nirik> maxamillion: that would take a yum plugin likely... 21:53:25 <maxamillion> nirik: bugger 21:53:28 <stickster> nirik: Thanks 21:53:43 <stickster> maxamillion: nirik: Yeah, but *that* yum plugin is probably neither RHN conflicting, nor really difficult 21:53:44 <smooge> nirik, I think we could do a README in the epel-release package which mirrors a page on the wiki 21:53:54 <maxamillion> stickster: think so? 21:53:58 <smooge> It probably won't be seen but its about as good as I think 21:54:15 <stickster> If all you want to do is print a message... 21:54:37 <inode0> I don't think we need to coddle people running RHDS or a Satellite 21:54:45 <stahnma> print everytime yum is ran? 21:54:52 <inode0> Just document this in the EPEL FAQ accurately :) 21:54:55 <nirik> That message could be anoying. 21:55:08 <maxamillion> stickster: well, I suppose th checking for the other repositories would be as simple as a grep of the /etc/yum.repos.d/ contents 21:55:09 <stickster> nirik: Could be, but then make it up to the user to disable with a switch. 21:55:20 <stickster> That way they're taking their lumps at that point 21:55:37 * stickster is not saying any of this is a substitute for better communication, mind you all 21:56:02 <nirik> well, would it also warn on atrpms/rpmforge/dries? 21:56:07 * stickster gets out of the rathole of yum plugins, summary: warning might be do-able. 21:56:35 <maxamillion> or we could put some sort of a flag in there such that they have to read the instrcutions properly or epel just doesn't work for them 21:56:45 * chrismcc would suggest adding some text to the /etc/yum.repos.d/epel... file 21:56:50 <Jeff_S> am I hours late for this yet? :) sorry! 21:56:52 * nirik gets a phone call 21:57:17 <stickster> maxamillion: chrismcc: Let's put the details aside for now and move on with the conversation, I'm sure this is a thread on its own 21:57:22 <stickster> :-) 21:57:38 <stahnma> sadly no solution seems all that complete nor simple 21:57:42 <maxamillion> stickster: heh ... you're probably right come to think of it 21:57:53 * maxamillion didn't even realize how big of a tangent that turned into 21:58:18 <stahnma> wait, I know, what if we use REPOTAGS!?!?!? 21:58:21 * stahnma ducks 21:58:30 <Jeff_S> let's vote ;) 21:58:42 <Jeff_S> I see I got here just in time 21:59:12 <stickster> So I'll be raising this topic in our program meeting internally, thanks for taking the time to enlighten me guys. 21:59:30 <stahnma> thanks stickster 22:00:06 <maxamillion> stahnma: lets revisit that .... I got another hour to kill ;) 22:00:32 <maxamillion> stickster: thanks for taking the time to listen to us bicker 22:00:34 <maxamillion> :) 22:00:50 <stickster> I'm just sorry this is continuing to be a problem, I want to do what I can to help solve it 22:00:59 <dgilmore> + 22:01:53 <inode0> I just think it is growing pains, nothing really bad is happening as far as I know 22:02:05 <nirik> ok, we are out of time anyhow... 22:02:11 <inode0> who has complained about a problem caused by nagios? or puppet? 22:02:19 <chrismcc> inode0: -1 22:02:44 <maxamillion> yeah, same here ... I have yet to see anyone come running in and complaining to #epel, #rhel, or #centos complaining that EPEL broke their system (which I hear a lot of about rpmforge) 22:02:57 <maxamillion> inode0: nobody I know of 22:03:17 <stahnma> most complaints I hear are just "I want newer version of package X" 22:03:19 <smooge> stahnma, you are right. repotags would fix this... I don't know why I didn't see this before in my life. :) 22:03:25 <nirik> so, some action items then: 22:03:28 <stahnma> smooge: :) 22:03:43 <nirik> #action smooge will generate a list of packages that are not following our new current policy. 22:03:50 <maxamillion> nirik: action item 1: stahnma has volunteered to take on adding repotags 22:03:55 <maxamillion> >.> 22:04:12 <nirik> #action dgilmore or nirik will block them. 22:05:26 <smooge> working on downloading stuff right now (I ran out of disk space on my slicehost so have to start over again) 22:05:40 * dgilmore slaps stahnma 22:06:01 <nirik> #topic Open Floor 22:06:12 <stahnma> II am glad my joke got so much reaction :) 22:06:30 <nirik> Anything for open floor 22:06:37 <maxamillion> neg 22:07:06 <stahnma> eventually we'll need to decide a rhel 6 policy 22:07:15 <stahnma> like do we branch everythign that's branched for EL-5 22:07:25 <stahnma> or try to get more packages 22:07:26 <stahnma> and stff 22:07:32 <stahnma> that can wait for another day 22:07:33 <maxamillion> discussion topic for next week maybe? 22:07:47 <derks> any eta on rhel6? 22:07:48 <chrismcc> how long until RHEL6 beta? 22:07:49 <dgilmore> stahnma: i talked about it at fudcon with some people 22:07:54 <maxamillion> derks: none that is public, no 22:07:56 <dgilmore> when its done 22:08:01 <stahnma> sure, if we have time 22:08:08 <stahnma> 18-24 months after rhel 5 22:08:10 <stahnma> wait...... 22:08:36 <chrismcc> How much work to get a koji buildsystem once rhel6beta is releasaed? 22:08:37 <smooge> el6 doesn't everyone have it already? did my time travel come out at the wrong time 22:08:38 <maxamillion> stahnma: shhh, don't bring historical statistic trending into this 22:08:44 <dgilmore> stahnma: my plan for EL-6 branching is this 22:09:04 <dgilmore> stahnma: branch everything in EL-5 giving a period of time for people to opt out 22:09:19 <dgilmore> i know some packages i have in EL-5 are not needed in EL-6 22:09:35 <dgilmore> python modules for koji that will be in EL-6's python 22:10:13 <dgilmore> chrismcc: we need to sync a rhel6 tree to build against then go to town building 22:10:40 <dgilmore> once there is a public beta id like to get things started 22:13:21 <maxamillion> that'd be awesome 22:13:40 <nirik> shall we close out the meeting? 22:13:53 <chrismcc> +1 22:14:29 <maxamillion> +1 22:16:04 <nirik> thanks everyone! 22:16:12 <nirik> #endmeeting