20:30:40 <tremble> #startmeeting EPEL
20:30:40 <zodbot> Meeting started Mon Dec  6 20:30:40 2010 UTC.  The chair is tremble. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:30:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:30:50 <tremble> #chair smooge nirik
20:30:50 <zodbot> Current chairs: nirik smooge tremble
20:30:59 <tremble> #topic rollcall
20:31:06 * tremble is here.
20:31:11 * schlobinux_ is here
20:31:48 * Jeff_S is here, there, and everywhere
20:32:35 <smooge> sort of here... dealing with breakage
20:32:45 * stahnma here
20:33:09 <tremble> nirik's about somewhere...
20:33:30 * nirik gets back from getting coffee. here.
20:33:45 <tremble> #topic Agenda
20:34:08 <tremble> #item EPEL6 "release" date
20:34:19 <nirik> yeah.
20:34:33 <tremble> #item RHEL/EPEL Channels
20:35:06 <tremble> Anyone got anything else?
20:35:19 * nirik ponders for a sec.
20:35:34 <nirik> broken deps?
20:35:40 <tremble> #item broken deps
20:35:44 <stahnma> I can provide an update
20:36:01 <nirik> stahnma: that would be great.
20:36:30 <tremble> In that case I suggest we start with stahnma's update...
20:36:35 <nirik> ok.
20:36:41 <stahnma> there isn't too much of one.
20:36:42 <tremble> #topic Broken Deps in EPEL
20:36:47 <stahnma> For 4-5 I have some scripts
20:37:04 <stahnma> they are running on my linode, but I should/could probably move them to fedora infr and get them in cron
20:37:23 <nirik> yeah, I was just going to say, I spent time cleaning up infra tickets this weekend and ran into:
20:37:29 <stahnma> they need to be a bit smarter (still) and 1. not send out an email if nothing's wrong, and 2. email the maintainers directly.
20:37:30 <nirik> .ticket 2343
20:37:31 <zodbot> nirik: #2343 (EPEL Dep Checker) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/2343
20:37:52 <stahnma> nirik: yeah, that's the one.  I wrote the stuff, but then deployed on my stuff, don't remember why though
20:38:13 <stahnma> on 6, we need to figure out what to do.  Once centos is out, I can run against that
20:38:16 <nirik> if we can deploy in infrastructure, we could use the real rhel bits, so we should be able to do 6 as well.
20:38:29 <stahnma> until then, I guess if I move to Fedora Infr, I can use the rhel buildroots
20:38:30 * tremble nods
20:38:33 <stahnma> which is likely better
20:38:36 <nirik> yeah.
20:38:52 <stahnma> sadly, I've had almost no time to look at those scripts recently
20:38:57 * stahnma just changes jobs again
20:39:02 <stahnma> err changed
20:39:40 <stahnma> so it's either a matter of patience or volunteers to get this done currently
20:39:53 * nirik is already overcommited on time I fear. ;(
20:40:07 <nirik> I'd be happy to help anyone interested in moving this forward to get the right acces, etc.
20:40:38 * tremble has been knackered in the evenings of late, and is working this weekend.
20:41:49 <nirik> stahnma: so, whenever you can get to it, or when we can find someone else to drive it...
20:42:01 <tremble> #info The scripts have mostly been written, someone needs to do the last mile and get them up and running in the Fedora Infrastructure and tidy stuff up.
20:42:33 <stahnma> i have some time off at the end of the year, so I would hope I could make some progress then
20:42:51 <tremble> That would be good
20:43:04 <nirik> cool. I should be around over the holidays if I can help with anything.
20:43:09 <stahnma> that's all I have for that topic
20:43:15 <tremble> Hopefully shouldn't need more than a day or so of work...
20:43:30 <tremble> What state were the dep trees in last time the scripts were run?
20:43:44 <nirik> 5 was pretty good I think.
20:43:47 <nirik> 4 less so.
20:44:12 <tremble> Was that just live or live+testing?
20:44:27 <stahnma> 5 was clean in stable, I need to run them again.  I'll kick that off in a few minutes.
20:44:30 <stahnma> 4 needs some work in stable
20:44:38 <stahnma> 6 is unknown more or less
20:44:41 <nirik> yeah, I slacked on that. I can try again after the next run.
20:45:06 <nirik> stahnma: can you find someone with a rhel6 box to run them for us? or are they hard to setup? should just be repoclosure?
20:45:24 <tremble> #info 5 was clean in stable, 4 needs some work in stable, 6 is unknown (more or less)
20:45:27 * nirik is quite curious to see how bad it is.
20:45:38 <stahnma> nirik: it's basically repoclosure, but I don't think repoclosure works on an rhn repo :(
20:45:47 <stahnma> I could be wrong on that though
20:45:52 <skvidal> stahnma: it should be able to
20:45:54 <Jeff_S> as Orion mentioned on the email list, we really should be running this before we make epel 6 public
20:45:55 <stahnma> I know you can't use them in mock (or couldn't)
20:45:57 <skvidal> stahnma: it's just using it as a repo
20:45:57 <tremble> It's just using the yum code isn't it?
20:46:38 <stahnma> client side yes, server side there's some weird entitlement stuff in satellite/rhn that normally makes me angry
20:46:39 * nirik would be happy to run it here, but I only have a rhel6b2 box...
20:46:56 <stahnma> I have a rhel6 sandbox somewhere here.  I'll see if I can do something with it
20:47:02 <tremble> stahnma: If you forward the scripts on to me I'll see if I can find an hour or so to at least get a single run off.
20:47:23 <stahnma> tremble: ok
20:47:37 <stahnma> my scripts are incredibly simple :)
20:47:44 * tremble has plenty of RHEL6 boxes including VMs
20:48:00 <tremble> And this laptop for that matter.
20:48:25 <tremble> And Jeff_S's comment leads us nicely on to...
20:48:36 <tremble> #topic EPEL6 release...
20:49:12 <tremble> So my memory of things is that if possible we're not going to specifically wait for CentOS-6.
20:49:26 <nirik> I think it would be good to set a date.
20:49:35 <nirik> because it would help some maintainers in planning...
20:49:43 <tremble> You suggested sometime this weekend?
20:49:45 <nirik> ie, can they wait and get a newer foo in? or do they need to ship the current foo
20:50:09 <nirik> I suggested 2010-12-13
20:50:16 <nirik> but I'm open to other thoughts.
20:50:29 <tremble> To be fair if we set a deadline I'll sit down and get my packages in order...
20:51:04 <tremble> When was RHEL6 released?
20:51:04 <nirik> see! ;)
20:51:06 <stahnma> my main issue is that december is a whirlwind for many people.  If they wanted to bump a version of a package before finalizing epel6, december might be a burden
20:51:19 <nirik> we could wait for jan
20:51:35 <stahnma> I know I have about 100 packages I need to review and see if I can move forward
20:51:44 <stahnma> 7 years is a long time to try to stay on a version
20:51:49 <tremble> Yeah
20:52:04 <tremble> Although we did talk about relaxing it slightly for point releases...
20:52:10 <stahnma> rushing into it may lead to bad outcomes.
20:52:21 <stahnma> I could possibly be convinced that was a good idea :)
20:52:41 <Jeff_S> if we're going to wait for January, I'd argue we should just wait for CentOS
20:53:09 <tremble> Do we have developers who are being held up by the lack of test env?
20:53:12 <nirik> well, I think it's important to set a date.
20:53:20 <stahnma> do we have any type of data on what packages we had in rhel5+epel vs rhel6+epel ?
20:53:26 <stahnma> are we missing hundreds?  thousands?
20:53:28 <nirik> because if we just say 'whenever centos 6 comes out' people won't scramble until it's out.
20:53:39 <tremble> There's about 1200 that haven't been built.
20:53:41 <nirik> tremble: possibly...
20:54:13 * nirik wonders what happened to the 'give entitlements to epel developers' thing went. No where I suspect. ;)
20:54:18 <Jeff_S> nirik: true, likely because most packagers are only building/testing on centos
20:54:44 <nirik> Jeff_S: well, rhel6b2 is available, thats what I have been using... but yes, not ideal.
20:55:55 <nirik> ok, so what would folks think of 2011-01-04 or 2011-01-11 ?
20:56:15 <stahnma> I'd vote for 2011-01-11, but I can understand if others think that is too far away.
20:56:17 <Jeff_S> I'm just curious if we're seeing very slow uptake of people to build on el6, is setting a date really going to help?  (I think some, but not a whole lot)
20:56:30 <stahnma> Jeff_S: a valid concern
20:56:39 <nirik> sure, it's no magic bullet.
20:56:45 <tremble> If we're waiting for end of Dec I'd say give people the extra days post holiday and go with 11-1-11
20:57:13 <tremble> But then I just like the number
20:57:17 <nirik> ha.
20:57:31 * nirik is fine with that.
20:57:37 <nirik> at least as a tenative.
20:57:44 <tremble> And it's not like "you missed the date your package won't go into EPEL ever"
20:57:56 <stahnma> let's put it to the list and see if people grumble or are ok with it
20:58:03 <nirik> right. it gives the holidays for people to work on things...
20:58:05 <Jeff_S> so... if we're just picking a random date to motivate people, why not do sooner than later?  if we're doing it in hopes that we get X percent of packages built, then I'd still prefer to wait for centos
20:58:23 <Jeff_S> cause I don't think people will do much if anything over the holidays
20:58:45 <Jeff_S> forgive me if I sound too pessimistic :)
20:58:51 <tremble> Which is why I said the week after the holidays.
20:58:54 <nirik> well, hard to say, but I think lots of people have time during the holidays for non work stuff.
20:59:20 <stahnma> but much where non-work == family-time
21:00:17 <nirik> well, let me reiterate why I think we should pick a date:
21:00:25 <tremble> How about.  We set 11-1-11 as a tentative date, would we be able to go for 1 week in testing rather than 2?
21:00:37 <nirik> * we need to have some time so maintainers know what to plan for.
21:00:44 <stahnma> agreed
21:00:47 <nirik> I know abadger1999 has been pondering newer turbogears.
21:01:11 * stahnma has been debating what rails to put in
21:01:11 <nirik> * marketing/build some press/etc.
21:01:56 <tremble> If people don't have time be
21:02:01 <nirik> I don't think this is so much for packages that havent been built yet, but for maintainers who want to know when they need to get fooX in by easily.
21:02:24 <tremble> between now and then then they shouldn't complain if we start letting people co-maintain...
21:02:58 <nirik> on the haven't been built, perhaps one more round of nagging, with us saying: hey, if you don't want to maintain this we will let someone else do it.
21:03:13 * tremble nods
21:03:17 <Jeff_S> nirik: ok, in that case I'm fine with picking some random date.  1-11-11 sounds fine to me
21:03:51 <nirik> possibly by then centos will be done too.
21:03:59 <Jeff_S> maybe...
21:04:09 <tremble> I finally managed to get my script to run again, just need to word the email and test to see if the mail servers are going to complain when I send a couple of hundred mails...
21:04:33 <nirik> tremble: happy to proofread.
21:04:52 * tremble nods.  I'll probably mail you tomorrow.
21:05:25 <nirik> cool.
21:05:33 <nirik> 2011-01-11 sounds ok to me.
21:05:38 <tremble> #info Tremble will try to actually get a nag script run out again to remind people to build their packages.
21:06:21 <tremble> There's been a fair amount of "When's EPEL6 going to be out" so being able to give firm dates would be good.
21:06:59 <nirik> yeah.
21:07:21 <tremble> #info General agreement to go with 2011-01-11 as our target date.
21:07:34 <Jeff_S> anyone against that date?
21:07:43 * Jeff_S didn't notice anyone
21:07:50 <tremble> Do we want to set a go/no-go date the week before?
21:08:01 <abadger1999> One thing -- I'm more concerned with getting information about what packages I have in EPEL6 that aren't at the version as rawhide than what I have in EL-5 that isn't in EL-6.
21:08:31 <stahnma> abadger1999: good point
21:08:38 <nirik> tremble: a sound idea. Also time to fire up marketing, etc.
21:08:58 <Jeff_S> tremble: depends... what will happen that would cause a no go?
21:09:03 <abadger1999> I can always add packags to EL-6 later but I may not be able to update the version
21:09:10 <tremble> abadger1999: I have a script I've been using to compare revisions.
21:09:27 <tremble> Jeff_S: That would be my other question what is our criteria...
21:09:45 <abadger1999> tremble: Excellent.  that wowuld be great to run.
21:10:27 <Jeff_S> I think we can just pick a date and stick to it.  if stuff breaks that'll be more motivation for packagers to do something IMO.
21:10:34 <Jeff_S> am I extra grumpy today?  must be Monday :)
21:10:35 * tremble nods
21:10:35 <schlobinux_> something like what's at http://perl.rsrchboy.net/ would be quite nice, but a script would fill the need too
21:11:27 <tremble> Pulling the info out of koji's a doddle.
21:11:37 <Jeff_S> tremble: what's a doddle?
21:11:49 <nirik> Jeff_S: we could delay due to excessive broken deps, or a maintainer saying they needed more time to update a stack?
21:11:50 <tremble> Comparing version numbers
21:13:08 <Jeff_S> tremble: just never heard that word before
21:13:40 * Jeff_S = stupid american
21:13:55 <Jeff_S> nirik: isn't the date intended to keep people from asking for more time?
21:14:21 <nirik> perhaps.
21:15:54 <tremble> Well let's go with that date, and consider pulling if the dep trees look insane or "enough" people ask for more time on the mailing lists.
21:16:03 <tremble> How's that?
21:16:09 <nirik> I don't see it being a big deal in practice if we have a date.
21:16:15 <nirik> we should be able to clean up things before then
21:16:19 <Jeff_S> yeah
21:16:21 <tremble> Exactly
21:16:43 * nirik just got some input on #rhel asking for a sooner date. ;0)
21:16:52 <abadger1999> In my case (TurboGears) I would just pull the stack from the initial EL-6 non-beta rather than asking for more time.... Seems more fair to everyone else.
21:16:52 * tremble isn't surprised
21:17:31 <nirik> abadger1999: yeah, thats what was done with trac.
21:17:39 <nirik> yanked until the new version can land.
21:18:30 <tremble> It does at least take us out of this limbo.
21:18:46 <nirik> anyhow, shall we move on?
21:18:56 * tremble was just typing to suggest that
21:19:08 <tremble> #topic RHEL6 channels.
21:19:20 <nirik> yeah, so I have no idea what we do here.
21:19:27 <nirik> rhel6 is differently setup on the mirrors.
21:19:38 <nirik> I don't know if there is a "Advanced platform" anymore.
21:19:46 <tremble> I don't think so.
21:19:57 <tremble> but I don't need to worry about it any more.
21:20:29 <nirik> a particular case that came up that I was asked about:
21:20:37 <nirik> pacemaker (cluster software)
21:20:49 <nirik> it's in Server/HighAvailability channel.
21:21:08 <nirik> but it's -docs and other subpackages are in Server/optional which we build against.
21:21:18 <nirik> so it's src.rpm is in server/optional on the mirrors.
21:21:25 <nirik> but it's not shipped except in that channel.
21:22:29 <nirik> so, should we say:
21:23:03 <nirik> if the binary package is shipped in server/server-optional/workstation/workstation-optional we don't allow it in epel.
21:23:16 <stahnma> we should really formally suggest that red hat fixes stuff like that
21:23:18 <nirik> if the src.rpm is on the mirrors for server/server-optional/workstation/workstation-optional we don't allow it in epel.
21:23:47 <nirik> yes.
21:23:55 <stahnma> nirik: that's looks good for now as a baseline
21:23:57 <nirik> it's crazy. I see why they wish to reduce support, but it makes it a mess.
21:24:08 <nirik> stahnma: which?
21:24:17 <stahnma> the main problem I have, is that I don't have enough exposure to rhel6 yet to make good decisions on this stuff
21:24:29 <stahnma> the server/opt/workstation/opt srpm theory
21:24:43 <nirik> also, we need the "unless the binary rpm is only shipped in some arches, in which case we can built that rhel src.rpm in epel"
21:25:01 <stahnma> which again, is basically a bug
21:25:10 <nirik> no, it's intended.
21:25:13 <tremble> Well it's not a bug
21:25:18 <nirik> the virt stack is x86_64 only.
21:25:23 <stahnma> ok, a poor design decision ;)
21:25:28 <tremble> There's no desktop stack on PPC64
21:25:28 <nirik> so, all virt stuff and it's deps are not in 32bit repo
21:25:35 <nirik> and that
21:25:44 <stahnma> either way it's painful
21:25:47 <stahnma> variables lead to complexity
21:25:52 <stahnma> which leads to downtime
21:25:54 <nirik> yes.
21:25:55 <tremble> That's where most of the nastyness came from.
21:25:56 <stahnma> which leads me to less money
21:25:58 <stahnma> which hurts
21:26:14 <stahnma> since Red Hat is supposedly all about the simple
21:26:54 <stahnma> but my rants aside, nirik's plan is as good as any
21:26:55 <tremble> When I first saw the second beta I could see this coming.
21:27:03 <nirik> so: 'if the src.rpm appears under 6* on mirrors we will not allow it in epel, with the exception of packages that are only shipped on a subset of available arches. Those are allowed provided they track the exact version in rhel6"
21:27:05 <stahnma> me too, I complained then
21:27:25 <nirik> so that means, no pacemaker for me. ;(
21:27:41 <stahnma> nirik: it would be nice to create some form of auto-tracker to autobuild the stuff that fit that second case
21:27:46 <stahnma> maybe not so simple then
21:27:54 <stahnma> nirik: why not pacemaker?
21:28:01 <stahnma> isn't it in HA?
21:28:09 <stahnma> or is that in server-optional?
21:28:13 <tremble> HA
21:28:16 * stahnma is getting more confused
21:28:25 <nirik> it's in server/HighAvailability channel.
21:28:37 <tremble> The question is could we build against it?
21:28:45 <nirik> except for it's -docs and one other subpackage that are in server/optional.
21:28:51 <stahnma> so that can be in EPEL because it's not in server/opt/workstation/opt right?
21:28:58 <nirik> it is.
21:29:07 <stahnma> arg
21:29:15 <nirik> enterprise/6Server/en/os/SRPMS/pacemaker-1.1.2-7.el6.src.rpm
21:29:16 <stahnma> ah so HA is under server
21:29:24 <stahnma> /cry
21:29:33 <tremble> Except I thought we generally avoided building the bolt-on channels too...
21:29:39 <nirik> because the pacemaker-docs and pacemaker-cts subpackages are in server optional.
21:29:54 <nirik> tremble: yes, but in 5, we had a clear set of srpms available.
21:29:59 <tremble> Ah
21:30:06 <nirik> in 6 the src.rpms for optional channels are not shipped anywhere I can see.
21:30:08 <stahnma> we still built things like 389
21:30:12 <stahnma> but not rhds
21:30:16 <stahnma> it's a fuzzy line
21:30:46 <nirik> I see no 389 src.rpms in final.
21:30:55 <nirik> I suspect it's in Server/Confuseusall channel
21:31:04 <Jeff_S> :)
21:31:16 <stahnma> right but there is a layered product called rhds, so it's like building on the bolt-on channels
21:31:18 <stahnma> only ont
21:31:19 <stahnma> not
21:31:21 <stahnma> I guess
21:31:27 <stahnma> we need more discussion on this
21:31:32 <stahnma> and a clear map
21:31:34 * nirik has no idea how to come up with a sane guideline on this mess. ;)
21:31:36 <stahnma> of how it actually works
21:32:23 <stahnma> I wonder if we could get a meeting with a RH SE on how this stuff is sold/packaged/bundled/channeled/supported/planned
21:32:31 <tremble> nirik: 389/RHDS isn't ready for RHEL6 yet.
21:32:36 <nirik> ok, we can defer, but someday we will need to figure it out. ;)
21:32:56 <tremble> SE?
21:33:09 <stahnma> Sales engineer?
21:33:13 <stahnma> technical consultant?
21:33:18 <stahnma> solutions architect
21:33:23 <stahnma> you know, the technical sales dude
21:33:27 <stahnma> (or lady)
21:33:39 <tremble> Ah, yes I know several of them.
21:34:01 <nirik> yes, a guest speaker would be great if we could get one. ;)
21:34:09 <stahnma> as upstream makes this more difficult to work with, the more people will do something else
21:34:16 <stahnma> and they need to know this
21:34:16 * tremble nods
21:34:24 <stahnma> maybe even a RHEL product mgr
21:34:26 <Jeff_S> you're seeming to assume that somebody actually understands all that stuff :)
21:34:37 <stahnma> right, if they don't, how do they expect me to?
21:35:05 <stahnma> i know whenever our rhel agreement is up, it's a big PITA to get it renewed and re-priced
21:35:15 * tremble nods
21:35:17 <stahnma> because stuff like this changes a lot
21:35:36 <Jeff_S> ok, so we're gonna try to get some advice/input from RH on the channel stuff and we'll defer until then on a guideline
21:35:40 <Jeff_S> right?
21:35:43 <stahnma> +1
21:35:46 <Jeff_S> seems good to me
21:35:49 * tremble nods
21:36:15 <Jeff_S> who is going to tackle this?
21:36:40 * tremble only knows EMEA people and wouldn't feel happy asking them to appear online this late.
21:37:07 <Jeff_S> I don't think it needs to be in an actual EPEL meeting... could be offline for all I care as long as we can get some valid information
21:37:24 * stahnma can ask my RH sales tech guy, but I am not sure that's the right approach
21:37:30 <stahnma> I can start there
21:37:36 <stahnma> and maybe ask some internal RH folks
21:37:39 <nirik> I think we are past out of time today,
21:37:41 <tremble> It is the right place
21:37:48 <nirik> but if we could arrage something next week or something.
21:37:49 <Jeff_S> if there are some RH folks that could make an EPEL intro that would also be good
21:38:04 <Jeff_S> yeah, anything else quickly before we end today?  I've gotta run
21:38:13 <stahnma> me too
21:38:14 <stahnma> thanks all
21:38:23 <tremble> Anyone got a burning desire to bring anything else up?
21:38:28 <tremble> #topic Open Floor
21:38:39 <nirik> nothing else here.
21:38:43 <nirik> thanks for running things tremble
21:39:01 <tremble> closing in 1 minute...
21:39:05 <Jeff_S> ok, thanks.  bye :)
21:40:22 <tremble> #endmeeting