22:12:26 #startmeeting EPEL (2012-05-23) 22:12:27 Meeting started Wed May 23 22:12:26 2012 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:12:27 Useful Commands: #action #agreed #halp #info #idea #link #topic. 22:12:27 #meetingname epel 22:12:27 #topic init process/agenda 22:12:27 #chair smooge tremble 22:12:27 EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge nb maxamillion tremble Jeff_S HackMan 22:12:27 The meeting name has been set to 'epel' 22:12:27 Current chairs: nirik smooge tremble 22:12:34 ok look, more meetings. 22:12:38 see how productive we are. ;) 22:12:43 hello goodbye. goodbye hello :-) 22:12:48 quite 22:12:52 o hai 22:12:54 gday 22:12:59 fancy seeing you all here 22:13:06 anyhow, as I was saying... I will get the script setup somewhere and anyone who cares to poke at it can do so. 22:13:30 ok, moving along. 22:13:35 #topic RHEL overlaps 22:14:11 ok, skvidal and smooge worked on coming up with a list of where we overlap with RHEL. 22:14:14 * stahnma strongly oppose pulling puppet+rubygems from EPEL 22:14:26 http://skvidal.fedorapeople.org/misc/epel-clashes/ 22:14:44 so, first the easy thing that I think we can all agree on: 22:14:50 (disclosure: I work at Puppet Labs) 22:14:51 we should fix the overlaps in os/optional. 22:15:11 and document the packages we are shipping due to arch needs. 22:15:11 * rbergeron pops in 22:15:33 hey smooge and rbergeron 22:15:40 sorry missed the transition.. was reading bjs's latest email 22:15:45 and not replying anymore 22:16:10 * dgilmore thinks that unless a layered product asks us to remove packages they ship they should remain in epel 22:16:12 yeah, so I was saying that we need to fix the overlaps in os/optional. Does anyone disagree with that? 22:16:26 nirik: no that needs fixed 22:16:28 no i think those should get pulled. 22:16:51 and we need to document the ones we are shipping for special arch needs that fit into that bucket. 22:16:51 +1 22:16:58 dgilmore, what steps would I need to put in something in various trees to help make sure it doesn't happen again 22:16:58 nirik: anything thats in the channels we use to populate the buildroots should not be replaced 22:17:00 that's been how it worked since EL6 shipped 22:17:03 +1 22:17:22 dgilmore: right. Unless we are allowing it because we need it for 32bit. 22:17:33 nirik: absolutly 22:17:35 eg something like branch glibc/el6 and put a dead.package in it? 22:18:09 for preventing, I think perhaps we could try and get RHEL folks to be better about letting us know when something is added? 22:18:13 so we can remove it... 22:18:22 it's not like it happens all the time, only at releases... 22:18:31 basically if there are steps needed to block builds I cand do so to take it off of someones list 22:18:31 smooge: ideally we have some kind of api we can query when making epel branches that can tell us if its in rhel or not 22:18:44 dgilmore, ah ok 22:18:50 dgilmore: that would be nice too. 22:18:53 smooge: then we can also periodically query it to see if things have been added we need to remove 22:19:30 smooge: base os in there checklists they have steps to check with epel and communicate to epel maintainers 22:19:49 but layered producst dont have the same things 22:20:12 im starting some discussions to make sure layered products consider epel in the work they do 22:20:28 so, I can try and work on the os/optional overlaps... does anyone else want to help out? if so, we might be able to make short work of it... 22:20:37 dgilmore: excellent. 22:20:39 dgilmore: that's great 22:20:59 well I have a list of the base os overlap already 22:21:06 we've been trying to get the RHEL developers to let us know when stuff changes since the inception of EPEL, and I think that's happened in very minimal ways only 22:21:24 the only communication I ever saw was when RHEL6 was close to shipping, and told us what to pull 22:21:26 smooge: yeah, skvidals list is good there, but we still have to check each one and see if we are shipping it for the 32bit 22:21:39 stahnma: with rhel6 they are supposed to do it, it is in the list of tasks when adding a package 22:21:55 well actually I was going to say.. just compare the overlap in i386 channels. If it overlaps there it is a problem. 22:22:01 dgilmore: cool. So the layered product are not that way? 22:22:11 smooge: yeah. 22:22:19 that is the list I had done. 22:22:32 smooge: do you have that list handy? 22:22:41 stahnma: no they are not 22:22:53 dgilmore: ok 22:22:57 stahnma: im starting on a path to fix that 22:23:16 I see 11 packages in base. 22:23:21 well, if we pulled things that some of the layered products use from EPEL, I would find EPEL infinitely less helpful 22:23:41 just to clarify: what are layered products? 22:24:01 I see 30ish some in optional, and most of those are perl packages. 22:24:01 nirik, http://fpaste.org/aMAM/ 22:25:25 right, ok. 22:25:31 NiveusLuna: layerd products are things that Red Hat ships that are add on things, Satellite is one for instance 22:25:33 we can work on nuking those and blocking them. 22:25:50 NiveusLuna: or directory server, iirc 22:25:56 nirik: i bet most/all of the perl ones are because they ship on x86_64 only 22:26:14 dgilmore: well, perhaps they once did, but they also overlap in 32bit too. 22:26:18 dgilmore, those perl ones are in the i386 channel now 22:26:18 now at least 22:26:44 NiveusLuna: https://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux#What.27s_the_difference_between_rebuilds_and_Red_Hat_Enterprise_Linux_.3F 22:26:50 NiveusLuna: stuff under: ftp.redhat.com:/pub/redhat/linux/enterprise/6Server/en 22:27:34 so, our current policy is: 22:27:46 " "EPEL6 will not ship any packages that have src.rpms on public mirrors under 6* directories with the following exception: If the binary rpm is only shipped in some arches in RHEL, EPEL may ship a package as close as possible to the RHEL version with a leading package Release of 0. (ie, libfoo-1.2-0.x) (note that EPEL maintainer must keep up exactly with the RHEL src.rpm where possible)." 22:28:27 so, how would people want to amend that? 22:28:38 if we don't amend it, it means removing a great deal of stuff from EPEL. 22:29:39 I'll note that we have overlapped with some of those channels for quite a while... and have heard not much feedback about it. 22:30:09 I would like to amend it to enterprise/6*/en/os/ 22:30:10 the discussion on the list started with glusterfs. 22:30:28 nirik: maybe add that if a package ships in a layered product we will removeit if asked to but otherwise its ok, ideally shipping with the same or a lower nvr than shipped in RHN 22:30:35 but it turns out the RHS channel glusterfs is in is pretty obscure... 22:30:43 and then I think z00dax said they would just move gluster into centos-plus or something? 22:31:01 what will happen is if EPEL pulls the software people want, another repo will put it in 22:31:09 making the EL world less fun to deal with all the way around 22:31:15 stahnma: agreed 22:31:23 stahnma: yup 22:31:40 well, ideally we want to not mess up anyone... 22:32:13 including: other oses that use epel and have no layered products and rhel customers who do use layered products 22:32:16 the easiest technical solution would be to have the RH layered products use same versions we ship in EPEL, but I realize that's a bit backwards for the flow 22:32:54 at the same time, the more that's in epel, the less people think they have to use repos that aren't up to our standards 22:32:55 and/or not charge for layered products; but I imagine that is combative with business goals somewhere 22:33:16 some of the channels seem very specific to me... and I am having trouble seeing where someone would enable epel on a appliance like thing that uses that specific channel. 22:33:30 nirik: nod 22:33:40 nirik: i dont think they would 22:33:44 and if they do, well they loaded the gun and aimed at their foot. 22:33:46 ie, if you are running a Red Hat storage appliance, why would you enable epel on it, it does one thing... 22:33:56 or a cloud controller node 22:33:57 there are also cases where tools are used to do setup, but not actually what Red Hat is saying is the value-prop 22:34:08 e.g. MRG using Puppet to set things up (if it still works that way) 22:34:09 but I could well be missing use cases. 22:34:59 if we pull nothing, will it encourage collaboration between RH product groups and EPEL maintainers? 22:35:09 I would expect that there are other projects that use puppet that would be adversely affected. 22:35:33 rbergeron: I would agree =) 22:35:46 on the upside, I would lose like 60 packages that I maintain 22:35:54 there are other things too that are popular... mogodb, etc. 22:36:07 yeah, mongo seems again seems somewhat general purpose 22:36:14 mmhmm 22:36:46 ruby-augeus would pull out all the other configuration management tools 22:36:59 so the most difficult one I see is the cloudforms channel. 22:37:13 as a loophole, I note they only ship 64bit. ;) 22:37:28 having split arch on that stuff isn't fun 22:37:36 esepcially since many of those packages are actually noarch 22:37:41 yep. 22:39:19 what stuff from cloudforms is in epel other than puppet? 22:39:31 it seems like a crock to have to remove it when aeolus isn't even in EPEL 22:39:39 proposal: EPEL6 will not ship any packages that have src.rpms under enterprise/6*/en/os/ with an exception for packages not shipped on one arch. Channels under enterprise/6/en/ may request EPEL remove any overlaping packages, and may be queried by EPEL about such overlaps from time to time. 22:39:41 unless it used to be and is now disappeared since a few days ago :) 22:39:54 http://skvidal.fedorapeople.org/misc/epel-clashes/epel-x86_64-clashes 22:40:10 looks at the rhel-x86_64-server-6-cf-ce-1 section 22:41:08 rbergeron, many of the items that puppet depends on to work are also used by other configuration management tools either directly or indirectly. Doing a loop of requires grows out to a LOT of packages 22:41:52 yeah, the rubygem stuff is more than half the reason I use EPEL (and maintain those packages) 22:42:22 perhaps before deciding anything we could try and open a dialog with those channel owners... 22:42:29 ask them what they want us to do... 22:42:58 because if the use case doesn't make sense for epel being enabled, they may well not care about overlaps on specific targeted channels. 22:43:07 true 22:43:30 nirik: i have started a dialog 22:43:38 * nirik is also not sure what makes a channel appear as a src.rpm download on ftp.redhat.com... 22:43:44 dgilmore: cool. thanks. 22:43:49 smooge: Errr --- wouldn't we start building with those layered products repos as part of our epel builder repos? 22:44:16 (If we don't decided to exclude layered products from our no-overlap policy by default) 22:44:44 abadger1999, we may not have access to them 22:44:47 abadger1999: we could I suppose. Note that some of them also overlap with base os I think in some places. 22:45:04 and our users wouldn't so if they could not download the repository would be broken for them 22:45:15 smooge: If we don't have access ot them, then it seems like a bo brainer that we can't do a no-conflicts policy with them. 22:45:21 *no brainer 22:45:46 I think we could enable them. I'd just rather not. 22:45:53 except their src.rpms are in the sub-trees we said we were going to not conflict with. 22:45:57 smooge: yeah, there is that other aspect too :-) 22:46:02 some of the layered products are designed to be standalone and you dont get support mixing and matching 22:46:12 those we should not worry about 22:46:24 so for example, we could drop mongodb because it overlaps, and add that channel so we could build against/use it, but that leaves all the epel consumers in the cold. 22:47:18 nirik: down the road we may have a different answer 22:47:28 not sure how much of it i can talk about 22:47:38 ok. 22:47:57 unless centos-plus pick it up or we decide to do a secondary repo ourselves... I don't know if centos-plus is intended to work with RHEL as well as with centos, though. 22:48:03 in the mean time I don't know how much we want to decide today. I think we might want to collect more data... 22:48:49 oh man, I just thought of something... 22:48:50 * abadger1999 is generally in favor of the proposal to restrict the products that we check for conflicts. 22:48:56 +1 22:49:18 abadger1999: to base os/optional? 22:49:30 that's what seems logical to me 22:50:00 nirik: that seems like a good semi-historical dividing line. don't know if there's other sane dividing lines as well. 22:50:11 or if we care to look for other possible lines :-) 22:50:21 nirik: sounds ok to me. what did you think of? 22:50:24 well, in rhel5, we used "advanced platform" which was more stuff/channels. 22:51:22 smooge: we also need to look at ppc64. ;) 22:51:34 I did.. very few overlaps 22:51:37 nirik: right but that doesnt exist in el6 22:51:48 smooge: xerces-c is one. 22:51:59 a lot of layered products dont support ppc64 22:52:01 it doesn't exist in rhel ppc64. 22:52:18 sure, I am talking baseos/optional. 22:52:52 right 22:53:21 ok, so back to the question, do we want to vote on/or agree we have consensus on only avoiding conflict with base os/optional? 22:53:34 or wait a week and get more feedback from channel owners, etc? 22:53:41 I like the proposal and will vote for it ;) 22:54:00 i think baseos/optional ha/lb that we build against are good lines in the sand 22:54:10 lets get some feedback 22:54:22 * nirik thinks there's at least one person on the list who will hate that, but hard to say. ;) 22:54:45 * nirik is fine with feedback for a week. 22:55:09 nirik: afaik no one on the list are channel owners 22:55:11 is this the time we're using from now on? 22:55:17 dgilmore, ha/lb? 22:55:22 I just note that our european friends probably hate this time... 22:55:26 dgilmore: yeah. 22:55:38 well, famsco apparently has the main meeting channel at this time. 22:55:45 smooge: high availablinty and load balancing i believe, they are what we use to populate the build roots 22:55:49 I'm open to other times... wed and friday are mostly non meeting days for me... 22:56:07 dgilmore, ah sorry was thinking half pound for some reason 22:56:09 * dgilmore would like to avoid fridays 22:56:18 arlight, discuss timing on list? 22:56:24 probably best 22:56:26 * stahnma has a hard stop at top of the hour 22:56:31 http://koji.fedoraproject.org/koji/taginfo?tagID=140 22:56:44 we can... I got crickets last time I tried, but we can try again. 22:56:51 #topic Open Floor 22:56:51 stahnma: ok, we should start to wrap up 22:57:00 any open floor items or shall we close out? 22:57:17 * dgilmore has nothing 22:57:20 has nothing. 22:57:23 * stahnma nothing 22:57:37 ok, thanks for coming everyone! 22:57:40 #endmeeting