19:30:48 #startmeeting EPEL (2010-10-11) 19:30:48 Meeting started Mon Oct 11 19:30:48 2010 UTC. The chair is tremble. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:31:00 #meetingname epel 19:31:00 The meeting name has been set to 'epel' 19:31:09 #chair nirik smooge 19:31:09 Current chairs: nirik smooge tremble 19:31:19 #topic init process / agenda 19:31:27 So current items... 19:31:27 * nirik waves 19:31:31 * stahnma hi 19:31:39 * tremble is here 19:31:49 * derks is here 19:32:07 here 19:33:16 * EPEL Bug numbers 19:33:16 * Broken dependencies in stable (stahnma) 19:33:16 * Conflicting Packages Policy (derks) 19:33:16 * Rubygem-rack Version 19:33:16 * Open floor 19:33:33 Anyone got anything else to add to the list before we begin? 19:33:34 sounds good. I have a update on lua as well if anyone cares. 19:33:44 I imagine somebody cares 19:33:47 * lua (nirik) 19:34:36 #topic EPEL Bug List 19:34:48 still under 200. ;) 19:35:04 Unfortunately they're going up again at the minute :( 19:35:24 * nirik notes 6 of them are clamav... 19:35:27 nirik, does that include package reviews? 19:35:34 derks: No 19:35:36 derks: nope. 19:35:37 very package reviews specifically for epel 19:35:40 no .. 19:35:41 if any... 19:35:41 eesh 19:35:47 hey. I have some 19:35:56 stahnma: There's a few parallel install ones 19:35:59 ok, back to my very few tatement :) 19:36:04 +s 19:36:34 At some point we need to get around to reviewing smooges packages since they kill off a few bugs. 19:36:45 true 19:36:58 I have a bug that will close with a stable push in a few days 19:37:06 I could try to do some reviews in the upcoming week. 19:37:08 and probably a few others I need to update/catch up on 19:37:41 I've a couple of bugs waiting on time in testing which should close in the next week or so. 19:37:48 also, I see 2 bugs that are filed against a busy coworker here, and I will see if he's ok with me just fixing them. 19:38:34 Some of them are just so old I wonder if people have forgotten to check for them 19:38:39 hopefully the lua ones will be closed before too long too. 19:38:53 A few saw motion just with the Whiteboarding prompting people. 19:39:06 sometimes that's what it takes 19:39:08 we agreed that things dropped in beta2 can just be branched normally now right? 19:39:08 just a reminder 19:39:16 nirik: yes 19:39:18 I think we did 19:39:27 so the perl-TK bug could be dealt with that way. 19:39:48 Yes, hence the branch request that went in just after your last run :) 19:40:31 yep. 19:41:06 There's another half dozen or so that're just going to have to wait for 6-GA when we know what shape the channels are going to be in. 19:41:29 But can then be closed off fairly quickly 19:41:39 yeah. 19:41:40 * stahnma wonders if we should try to triage/fix/close el4 nowish, as many may have little/no action/solution 19:42:07 tremble, any info on when 6-GA will drop? 19:42:17 derks: Nothing I can talk about. 19:42:27 right on 19:42:36 * schlobinux_ handles a beer to tremble :-) 19:42:50 15 bugs are el4 19:42:50 * tremble already has a beer :) 19:42:58 doing it right 19:43:27 I think we WONTFIX old bugs on EL4 when 6 hits GA 19:43:50 Unless the owner's making some form of movement... 19:44:08 Treat it like the Fedora cycles. 19:44:31 * SmootherFrOgZ just get in 19:44:31 well, except el4 is not end of life at all. 19:44:49 * nirik doesn't see any reason to wontfix them until support ends... 19:45:15 I think that we should keep fixing on EL4 19:45:21 Ok 19:45:23 I agree 19:45:41 even with 4.9 out some day A LOT OF PEOPLE use 4 19:45:46 unfortunately I'd have to agree with nirik ... being in an environment where customers are pissed off about el3 being eol... I think it'd be best to continue to fix until end of support 19:45:47 although, RH won't fix things on EL4 unless its security 19:45:47 more than I would guess 6 :) 19:46:11 hehehe. I got asked if I could fix EL-3 for some people on the side. 19:46:12 yeah, might be good to sometime poke those 15 bugs and see which are just not fesable to fix tho. 19:46:14 perhaps we should marry against the RHEL support lifecycle 19:46:38 stahnma: And WONTFIX the non-sec ones? 19:46:52 or at least the RFEs 19:47:25 tremble, yeah... RFE's should be a no-go for epel-4 in my opinion 19:47:31 https://access.redhat.com/support/policy/updates/errata/ 19:47:44 maybe we should do some homework and discuss next meeting 19:48:20 sounds reasonable. 19:48:54 * tremble nods 19:48:55 #info https://access.redhat.com/support/policy/updates/errata/ RHEL Lifecycle overview 19:49:06 nod sure if my info worked 19:49:12 stahnma: Fancy trying to put together a draft proposal ? 19:49:17 That will have worked. 19:49:27 would it be helpful at all to ping mdomsch and see how many uniques are checking in for epel-4 on mirrormanager... just to have an idea of usage? 19:49:27 It just doesn't give any output 19:49:44 tremble: I'll see if I get some time for that 19:49:55 tremble: I know the rhel support lifecycle pretty well, so probably 19:50:37 stahnma: Well there's no major rush about it yet. 19:51:02 derks: To be fair I know of far too many places still making heavy use of 4 19:51:27 * stahnma too 19:51:36 I just don't think we can do a ton with epel for it 19:51:46 derks: I suspect most places with a significant number of hosts will hide them behind private mirrors 19:51:53 specifically if you are on RHEL because up2date can't handle proxys and such 19:51:55 tremble, same here ... just curious of epel-4 ... personally we don't see a lot of usage of epel on rhel 4... but we have a ton of rhel 4 boxes 19:52:26 possibly in part due to epel coming out after el4 was released... so many people rolled their own stuff or made due without. 19:53:29 I dont' have any numbers off hand 19:53:35 ok 19:53:43 we could generate them I suspect 19:53:55 should we move on? Next week we can continue the discussion of support for EL4 after doing our homework 19:54:10 mdomsch, I was just throwing out the idea... i don't really think it would affect our decisions here 19:54:22 * nirik votes move on. 19:54:30 #topic Broken dependencies in stable (stahnma) 19:54:34 ++ 19:55:39 #info EL4 Numbers curtsey of dgilmore ... 1518 for i386 and 886 for x86_64 19:55:46 over what time? 19:56:16 #info el5 has 87023 x86_64 and 78071 i386, and 81 ppc 19:57:13 #info over 7 days 19:57:24 stahnma: want to take the lead on this topic? 19:58:34 yeah broken deps 19:59:48 just a sec 19:59:49 brb 19:59:52 dayjob 20:00:09 So we agreed last time we'd unpush the el5 (and el4?) STABLE packages with broken deps that weren't going to be easy to fix. Having already tidied the ones which just needed a rebuild... 20:00:48 ok back 20:00:49 tremble: yeah. 20:00:50 sorry 20:01:00 do we have a list? shall we just go over them one by one? or ? 20:01:00 tremble: yes 20:01:05 I sent a pastie 20:01:14 http://fpaste.org/ctkI/ 20:01:19 tremble did some updates 20:01:22 * nirik did a push this morning, worth re-running? 20:01:30 I was waiting for mirrors to populate 20:01:46 which seems to take a while 20:01:47 i can try 20:02:11 It's a lot better than it was, stahnma did a fair bit of work on the rubygem trees 20:02:17 ok. yeah. Thanks stahnma 20:02:28 I'd be happy to unpush things later today. 20:02:35 there are two ruby packages we need to unpush 20:02:43 and the rest can be fixed 20:03:02 and one might be able to be fixed, but will require a parallel install 20:03:09 pre-req 20:03:23 I haven't looked at 4 closely enough 20:04:02 probably easier to unpush them, then push them back out with their deps. 20:04:18 if that means they need a bump, then oh well. 20:04:33 yeah, and many of these have been around for ages. 20:04:33 ++ 20:04:53 yeah, the only things I really don't want pulled are rubygem-sinatra and rubygem-shotgun 20:04:57 I see 22 that have no comment or a note that they can't easily be fixed. 20:04:57 those are fixable still 20:05:07 yeah, the no comment ones I didn't get time to dig into 20:05:14 the ruby stack has been enough fun :) 20:05:40 rhnlib and xulrunner-devel should be left alone due to centos/el differences 20:06:31 rhnpush you mean? 20:06:39 possibly :) 20:06:47 yes 20:06:50 the dep on rhnlib 20:06:52 :) 20:07:19 * stahnma will turn in a rel-eng ticket for unpushes for EL5 20:07:30 should we go ahead and do everything broken in EL4 as well? 20:08:18 http://fpaste.org/T4Mq/ 20:08:47 I'd say lets perhaps look at el4 next week? 20:08:59 * tremble nods 20:09:03 ok 20:09:07 +1 for that 20:09:12 unpush fwsnort 20:09:37 I'll repush it with a dep fix and the dependency once I've built it. 20:09:41 ok. 20:09:58 They're doing a hard dep on a perl package (rather than the module) 20:10:14 http://fpaste.org/ktpx/ 20:10:42 +1 20:11:00 so, we want to look at the possibly ones more? or just do them too? 20:11:37 I'd vote to unpush the majority of them, but I don't know what they do 20:12:02 I vote for unpush, on the grounds that they're not installable. 20:12:08 +1 20:12:16 ok. Sounds reasonable to me. 20:12:21 if they get fixed, we put them back 20:12:24 it's that simple 20:12:29 * nirik can make with the clicking later today. 20:12:54 ok 20:12:54 ! 20:13:00 next item? 20:13:36 #topic Conflicting Packages Policy (derks) 20:13:36 gomix: you had something? 20:13:50 just heard something about fwsnort... and the pacakger 20:13:56 ? 20:13:59 did something wrong? 20:14:26 i mean im the packager 20:14:28 There's a package it depends on that's not in EL5 20:14:36 Well it will be in 2 weeks 20:15:24 Ok, i did not noticed that 20:15:28 you're also depending on the package rather than the perl(Module::Name) which is a minor faux pax 20:15:37 pas even 20:15:43 and builded it over koji 20:16:00 Yeah it's runtime rather than build time 20:16:03 They happen. 20:16:13 It's one of the things we're trying to clean up now. 20:16:18 kk 20:17:20 * gomix taking notes... enough for me... 20:17:27 nirik: Probably worth emailing $PKG-owner with the reason the package got unpushed too? 20:17:45 tremble: I am adding comments to the updates when unpushing. 20:17:51 * tremble nods 20:17:52 as far as conflicting package policy, I like the spirit of having them, as it allows more flexibility. I'm afraid it might be introducing a maint nightmare 20:18:18 derks: You wanted this brought up, anything specific you wanted to say? 20:18:25 we have very few maintainers who are really keeping up with everything in EPEL as it stands today. Allowing differences from the Fedora packaging guidelines might be difficult. 20:18:49 I really just wanted to get a definite decision on how to handle it 20:19:08 stahnma, so you are saying 'no' to the hard 'Conflicts' yeah? 20:19:16 derks: no, I am not 20:19:18 Was there a specific example ? 20:19:30 derks: I am saying it takes extra care 20:19:32 tremble, yes... python26-mod_python, and python26-mod_wsgi 20:19:40 and I'm not certain our maintainers currently have it 20:19:56 i've submitted reviews for both this week 20:20:08 Ah so we're talking about the parallel install packages that aren't going to be around for fedora anyway... 20:20:17 tremble, exactly 20:20:22 yeah, it makes sense 20:20:27 and I know people are doing it in-house anyway 20:20:42 just a note this is not installable in parallel 20:20:54 well, not all of the IUS packages I mean 20:20:59 to me, it is confusing to have a package installable... that won't function unless you know what your doing... rather than having a package *not* install because it conflicts with something else... but that is my opinion 20:21:03 ah 20:21:24 derks: I agree for the most part 20:21:34 schlobinux_, I know... currently I am using IfModule to check for the apache module and only load if it isn't loaded 20:21:39 I am not strongly opinionated on this either way. I just want quality packages ;) 20:21:42 Although in theory you could be running two apache instances... 20:22:14 tremble, that is a good point as well... in which case you could have both packages installed and not conflict 20:22:17 do we want to ask the FPC their thoughts on this? 20:22:19 yeah at which point you are not running from default 20:22:26 I know toshio chimed in a bit. 20:22:49 nirik: FPC at the very least probably have extra thoughts as to the pros and cons. 20:23:04 toshio mentioned that fedora has a no conflict policy, but that the epel use case might call for explicit conflicts 20:23:18 derks: my understanding is python26 is the first step, there is a lot more eventually coming in, like php52, php53, mysql51, etc.. 20:23:49 and this is going to be really useful, especially if RHEL6 release cycle is aslong as RHEL5 20:23:52 schlobinux_: Only if people have the time/inclination to maintain the extra package trees. 20:23:57 schlobinux_, I'm not aware of all that... I run the IUS community project and we have talked with EPEL (here) about merging efforts... and it always comes down to keeping them separate 20:24:20 derks: Which was the IUS project? 20:24:38 tremble, iuscommunity.org ... dl.iuscommunity.org 20:24:49 packages that explicitly replace those in rhel 20:24:55 php52, php53, mysql50, mysql51, etc 20:25:06 in IUS... we rely on hard conflicts 20:25:20 derks: things like php versions etc should eb paralell installable 20:25:21 I think many customers/users would love that 20:25:24 if it was available 20:25:39 parallel would be ideal.. 20:25:48 sure, but which one is used by default? 20:25:56 dgilmore, it could be... though some times requires a lot more maintainence over head/patching/etc 20:26:03 os default or setup alternatives 20:26:20 ? with parallele doesn't that mean both at the same time ? 20:26:28 nchauvet, yes 20:26:30 yep 20:26:34 dgilmore: Except you need to produce alternatives to Red Hat maintained packages. 20:26:48 nchauvet: Where possible. 20:27:01 so if you run a 'yum install python26-mod_python' it doesn't work until you manually tweak configs. which is kinda confusing. 20:27:06 the route that ius has taken, is similar to how redhat proper does... if anyone has looked at gcc44 and postgresql84 20:27:24 gcc44 is parallel... postgresql84 conflicts with postgresql, and provides it 20:27:29 this has produced weird results with dependencies on debian, specially with 'underlinked' librarie 20:27:31 to it replaces postgresql 20:27:31 tremble: its possible to do 20:27:42 doesn't it 20:28:08 dgilmore: True, would need cooperation from the RHEL maintainers though. 20:28:09 doesn't fedora has a guideline to prevent this most of the time ? 20:28:28 nchauvet: yes, conflicts are frowned upon. 20:28:32 nirik, the way python26-mod_python works now is... it *will* work out of the box... unless mod_python is installed, then it just silently doesn't load .. which is... confusing 20:28:33 nchauvet: yes, but EPEL is different due to the massively longer support cycle. 20:29:37 could someone generate a pros/cons and possible guidelines for this? I'm afraid I don't have the brains right at the moment to know where I stand on it. ;) 20:30:20 derks: Would you feel up to trying to do that? 20:30:59 tremble, I can. I more or less put all of my talking points in the thread on epel-devel 20:32:09 #action derks Get the conversation started on epel-devel... 20:32:09 * nirik re-reads 20:32:55 Since it's getting late let's move on... 20:32:56 $dayjob meeting 20:32:59 gotta go 20:33:02 byer 20:33:09 bye stahnma 20:33:25 #topic Rubygem-rack Version 20:34:20 * derks stepping away for a minute 20:34:23 stahnma wanted to talk about this, I can't remember the pros and cons, so unless there are objections shall we delay until next week and move on to open floor? 20:34:31 yeah 20:35:09 #topic Open floor 20:35:43 just FYI, I have unpushed all the for sure unpush ones. will work through the rest as time permits. 20:35:53 * tremble thanks nirik 20:38:04 * tremble will close the meeting in 1 minute 20:38:38 Since we're already running late and no-one as piped up. 20:39:31 #endmeeting