19:32:55 <nirik> #startmeeting EPEL (2011-05-09)
19:32:55 <zodbot> Meeting started Mon May  9 19:32:55 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:32:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:32:55 <nirik> #meetingname epel
19:32:55 <zodbot> The meeting name has been set to 'epel'
19:32:55 <nirik> #topic init process/agenda
19:32:55 <nirik> #chair smooge tremble
19:32:55 <nirik> EPEL meeting ping abadger1999 rsc stahnma tremble dgilmore smooge nb maxamillion tremble Jeff_S
19:32:55 <zodbot> Current chairs: nirik smooge tremble
19:33:06 <abadger1999> yo
19:33:06 * derks is present
19:33:17 <Jeff_S> nirik: you are awesome
19:33:19 <Jeff_S> also, I'm here :)
19:33:20 * jness is here
19:33:34 <nirik> I didn't have much on agenda today. ;) Do other folks have items for us to discuss?
19:34:15 * tremble lurks
19:34:19 <derks> I saw the transcript from last week (sorry I missed the meeting)… where there was some talk about IUS
19:34:31 <nirik> I've failed to generate that list of packages in epel and rhel. (will try this week)
19:34:34 <derks> I'm all ears if we want to revisit that
19:34:42 <nirik> derks: yeah, we can discuss that again if you like...
19:35:01 <nirik> #topic IUS and EPEL
19:35:12 <dgilmore> hey
19:35:21 <Jeff_S> there is a tentative schedule up for centos 6 release:  http://qaweb.dev.centos.org/qa/calendar
19:35:39 * Jeff_S missed the IUS discussion as well
19:35:50 <nirik> so, there was some discussion on the list about again merging IUS into EPEL somehow. I guess the advantage is that EPEL is well known now? But the downside is that it would be a lot of work and it could confuse our userbase. ;)
19:35:54 <nirik> Jeff_S: cool.
19:36:28 <smooge> here
19:36:49 <derks> nirik, yeah… I feel that packages like that shouldn't be in EPEL proper
19:37:01 <derks> python26 is an exception… and its a side-by-side parallel install
19:37:12 <nirik> right. It's not really the same thing...
19:37:33 <tremble> I personally would prefer to see the IUS and EPEL stay seperate, even if we possibly allow the use of Fedora infrastructure to build IUS.
19:37:49 <derks> having IUS *next* to EPEL would be… convenient (for the few people who want to package that stuff)… a big under taking for the infrastructure
19:38:29 <tremble> Part of EPELs reputation is from the fact that we don't replace RHEL packages
19:38:35 <derks> true
19:38:46 <Jeff_S> yeah, IUS is intended to *upgrade/replace* certain RHEL packages; that's exactly what we don't want to do
19:39:12 <derks> definitely… its a completely different audience/need
19:39:50 * nirik nods.
19:40:09 <derks> keeping the IUS repo is tough… when it comes to things like building in koji….  you have to be very careful in how you setup a pkgXX… or yum gets confused
19:40:10 <nirik> I'm happy with them seperate... but then I am lazy too and it sounds like a lot of work to bring it into the same setup
19:40:23 <dgilmore> derks: koji side is simple
19:40:33 <nirik> derks: are you guys hurting for any resources? or doing ok?
19:40:58 * dgilmore thinks its a slipperly slope we dont have the resources to manage it
19:41:06 <derks> nirik, we are in the process or rolling out infrastructure….  had some hicups… but… not hurting
19:41:06 <nirik> yeah
19:41:42 <derks> something to note… from our side is…  the project was released by rackspace to serve, primarily, rackspace….  we have obvious concerns losing control of it
19:42:17 <derks> one example… we need to build for all EUS channels as well as base
19:42:26 <derks> which EPEL won't do already
19:42:43 <derks> (EUS -> Extended Updated Support from RHEL)
19:43:02 <nirik> yeah, so it sounds like it makes even more sense to keep seperate. ;)
19:44:13 <derks> Yeah… I mean, if EPEL was chomping at the bit to merge we're definitely open to talking about it … but based on infrastructure alone IUS would be just one more thing for the infra. guys
19:44:29 * nirik nods
19:45:09 <derks> here's a thought…. what if, hypothetically… one day… IUS supported authentication against FAS?
19:45:35 <nirik> well, that could lower barrier to entry for people wanting to contibute perhaps.
19:45:36 <dgilmore> derks: if you use koji its fairly easy to do
19:45:42 <derks> would be easier for packagers to contribute to both…
19:45:55 <derks> dgilmore, we don't…
19:46:09 <dgilmore> it would be a matter of my making you a ssl cert and doing it like a secondary arch
19:47:04 <derks> dgilmore, our app is built on turbogears though so using the repoze plugins would still be possible
19:47:52 <dgilmore> derks: not really
19:48:04 <dgilmore> derks: it could be possible to tie into fas
19:48:14 <dgilmore> but koji and building is not tied into fas
19:48:27 <dgilmore> fas uses passwds or yubikeys
19:48:29 <derks> dgilmore, right
19:48:31 <dgilmore> koji uses ssl certs
19:48:51 <tremble> I don't think we'd want to encourage Fedora passwords being handed to non-Fedora systems...
19:49:01 <dgilmore> if you wanted to get packagers participating you would want to use the same tools
19:49:13 <dgilmore> tremble: not at all
19:49:28 <derks> yeah, i agree
19:49:46 <tremble> derks: Honestly koji's not that hard to configure and once it's up it's easy to maintain.
19:49:55 <smooge> I am doing it today!
19:50:11 <derks> tremble, its not that really… its more that we [rackspace] have other needs for building
19:50:23 <derks> our first iteration of the app was strictly rpm
19:50:40 <abadger1999> <nod>
19:50:41 <derks> this new version was geared for supporting 'anything'… building via mock/rpm is just a plugin
19:50:44 <dgilmore> the harder bit would be making a wrapper around pyfedpkg to replace fedpkg
19:51:25 <dgilmore> derks: it honestly shouldnt be to hard to write some .deb support for koji
19:51:54 <dgilmore> derks: and you can use koji to do native maven builds and windows builds
19:52:50 <derks> dgilmore, I wasn't too entirely familiar with its capabilities outside of fedora
19:52:53 <dgilmore> anyway thats my 2c
19:53:21 <derks> last app I tried to customize was mirrormanager and found out real quick that it was made very much for fedora… outside of fedora use… it was really hard to make it work for my needs
19:53:51 <dgilmore> koji started life as a inside red hat tool
19:53:59 <dgilmore> and made its way outside the wall
19:54:19 <dgilmore> its extremely flexable and used by lots of people in lots of ways
19:54:38 <dgilmore> you should be able to build for any rpm based distro today
19:54:45 <derks> just to clarify, we didn't develop our own to compete with koji in anyway… we just started development on our own before koji was open sourced
19:54:59 <dgilmore> though using it on mandriva might be interesting with rpm5 used there
19:55:41 <dgilmore> derks: koji was opensourced a few years ago.
19:55:57 <nirik> so, sounds like we don't want to look at any kind of merging right now at least...
19:56:02 <dgilmore> derks: im just stating what its capable of
19:56:05 <nirik> anything else on this? or shall we move on?
19:56:07 <derks> dgilmore, our first iteration of the app was 4+ years ago
19:56:10 <Jeff_S> there was plague back before that, which was at least easier to install :)
19:56:25 <derks> dgilmore, but I will definitely give koji another look
19:56:31 <dgilmore> derks: :)
19:57:24 <nirik> #topic Broken deps
19:57:36 <nirik> so, the broken deps script is running along ok as far as I can tell.
19:57:43 <stahnma> I agree
19:57:51 <nirik> Not too many fixed over the last week, but perhaps with the bugging each week people will get with it.
19:58:13 <stahnma> I imagine when Centos 6 is out, much will get fixed
19:59:10 <nirik> hope so.
19:59:22 <nirik> #topic Open Floor
19:59:31 <nirik> anyone have any other topics ?
20:00:39 * rsc is there, too ;-)
20:00:40 <rsc> sorry.
20:01:12 <nirik> no worries.
20:02:41 <nirik> ok, will close on out in a minute if nothing else...
20:05:05 <nirik> thanks everyone!
20:05:09 <nirik> #endmeeting