21:00:41 #startmeeting EPEL 21:00:42 Meeting started Fri Feb 26 21:00:41 2010 UTC. The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:44 Useful Commands: #action #agreed #halp #info #idea #link #topic. 21:00:52 hi guys 21:02:18 #topic roll call 21:02:21 I think I have a meeting at $DAYJOB 21:02:26 so I guess I am not really here :( 21:02:41 it is ok I didn't get an agenda together 21:02:42 * nirik is here. 21:02:52 but I am happy to see you able to say hi stahnma 21:03:37 #topic call for agenda 21:03:55 Hi guys this will be a short meeting. Do people have items they would like to talk about? 21:03:56 sorry i'm late 21:04:07 I have a couple of my own but should be pretty short 21:04:58 do we want to touch on the FESCo ban on direct stable pushes, or is that strictly a fedora thing? 21:05:03 I suppose we could touch again on the incompatible upgrades stuff, as I don't think we have reached a final conculsion on it. 21:05:29 derks: a) there has not been a ban. b) it doesn't apply to epel, as we already don't allow direct to stable in epel. ;) 21:05:58 fwiw, i thought i should let everyone know that i'm slowly working my way out of the pit that is Real Life. i'm trying to slowly work on my backlog of bugs and stuff... 21:06:06 right on. Personally I wouldn't ever push directly to stable anyhow... just saw it was a pretty hot thread on fedora devel 21:06:09 emphasis on "slowly" 21:06:11 hey silug. ;) 21:06:30 derks: there is talk about drafting a policy that will change this, but there is not even a draft yet. 21:06:30 no problem silug I am making 2 feet forward for every 1.5 back right now myself 21:07:08 nirik, gotcha 21:09:25 #topic RHEL/EPEL conflicts 21:09:49 ok seth got me a script to find provide conflicts that I am playing with 21:10:05 The first thing was I couldn't find the kvm-qemu-img that was listed in the email last night 21:10:14 I am trying to figure out what I missed in my copying 21:12:02 hehe yep. I missed the vt tree 21:12:26 that would do it. I should be able to have everything done soon so we can get a list of conflicts 21:12:32 it would be easier if rhel didn't randomly name packages different than fedora. :) 21:12:40 yes it would 21:12:48 however, not my department 21:14:12 good work on that smooge. Keep us posted on it. 21:15:50 it looks like we may have a couple of packages pulled in this release but not a lot. 21:16:43 I should have a complete list of things by the end of the weekend 21:17:07 next week we can start looking at dealing with conflicts a bit better and hopefully broken deps. 21:17:23 yeah. 21:17:30 #topic Broken upgrades 21:17:57 Ok I should also have a mediawiki spec file for people to look at next week 21:18:11 so where did we last leave this? 21:18:20 is that a mediawikiXY package? 21:18:24 allowing updated packages when they are fooN and don't conflict? 21:18:35 I am not sure where it left off nirik 21:18:42 yeah, me either. ;) 21:19:00 I am going to lead with one that basically says mediawiki -> mediawiki15, mediawiki19 will be the new one 21:19:07 I noticed on one of the epel list threads.... that postgresql84 was *added* in rhel 5.5 ... so, aren't they doing just this same thing? 21:19:19 sort of like how RH has done with samba3x and postgres84 packages 21:19:23 yeah, 21:19:29 me slow type 21:19:54 I'd still like to ping the packaging list and see if they want to provide any input before we commit to this route, but I gues I can do that and see what happens. 21:21:16 nirik please do 21:21:36 ok, can do 21:21:40 I figure I can at least have an alternative for people to look at 21:21:49 so its not a bunch of hand-waving 21:22:41 i really think the ability to introduce new(er) branches of packages will be a great improvement 21:22:51 what is the commannd to say "nirik said he will do this." 21:23:14 I would really like to see a database where I could select a specific application and get a listing of dependancies as well as the dependancies for all other dependancies. It would be very helpful for customizing a system for specific applications. 21:23:18 #action nirik will email packaging group for ideas on how to do this in the future. 21:23:33 right. But you're not #chair 21:23:43 I am not? 21:23:43 or are you? 21:23:47 he should be. 21:23:57 zodbot doesn't love me 21:24:13 Froolap: this is a Extra packages for enterprise linux (EPEL) meeting. ;) Not a general fedora meeting. 21:24:22 it just doesn't say anything. It did it. 21:24:39 #topic slipstream (or nirik gets a pony) 21:25:00 I think the slipstream idea basically died... 21:25:07 I seemed to be the only one who liked it. ;) 21:25:11 I liked it 21:25:11 slipstream? 21:25:28 rawhide for epel was my idea for slipstream 21:25:42 derks: instead of 'mediawiki15' and 'mediawiki18' in the main/normal repo, we have a 'slipstream' repo 21:25:43 but I might had misunderstood nirik 21:25:53 ooooh i did misunderstood 21:26:13 in that we can ship a newer one that breaks the base repo, because we tell users that it could and not to expect it to work from update to update. 21:26:37 so in that repo we only have problem children like mediawiki / moin/ etc. 21:26:43 ahh... so it'd be like a disabled by default, upgrade at your own risk repo 21:26:57 derks: yeah. 21:27:08 ah I was seeing it in my head as something different 21:27:11 but it would maintain the same package name 'mediawiki', 'moin' rather than 'moin19' etc? 21:27:14 but that means another 2 repos to deal with from rel-eng side of things. 21:27:24 right. 21:27:47 and if the current one was broken totally/no longer supported, it would just be removed from the base repo 21:28:28 nirik: I do not wish to distract. I would like to talk with you for a couple of minutes when this is done if possible. Thanks. 21:28:36 ok I was seeing slipstream as sort of our rawhide and we would freeze stuff in it to epel-testing and then epel-stable. It would mean also setting up updates trees like Fedora has so even more work 21:28:48 Froolap: sure, happy to. 21:29:05 smooge: ah... I see what you were thinking... 21:29:14 I was picturing it as a much smaller scale... 21:29:27 and only time things would move from it is major releases... 21:29:48 ie, we have mediawiki 1.8 in it now for epel5, then epel6 comes out, we could have that version in the base epel repo there. 21:30:42 let me write this all up again in my email to packaging... can cc epel-devel. 21:30:47 ok thansk 21:30:56 anything else on this for anyone 21:31:13 nirik, I like the idea... though being that a new rhel release comes around only every many of years... would it make more sense just to call it 'epel 6 beta'? 21:31:38 derks: well, that could be confusing since it's building against/usable in epel5. 21:31:58 nirik, right... that's true 21:33:00 perhaps we need another round on epel-devel before packaging... 21:33:21 yeah.. because I want to get a better idea 21:33:39 I have 2 more silly topics and then we can close 21:33:45 #topic PPC love 21:33:56 also, dgilmore as I recall didn't like the idea due to him doing all the rel-eng. ;) care to chime in denis? 21:34:17 sledge hammer?? 21:34:33 * nirik waits to hear what ppc love is here. ;) 21:34:47 Ok sorry you were talking so I wanted to wairt 21:35:01 Ok we have a tree that we don't know much about 21:35:09 has there been any community request for PPC builds? 21:35:10 does anyone here run/test PPC? 21:35:33 I have a ppc32 test box, but it's running f12 currently. 21:35:52 I haven't ever tested rhel on ppc as I don't have a license for it, and centos does not produce ppc. ;) 21:36:03 smooge, I have a dual 1.8 PPC mac pro that has been staring at me for over a year... so I suppose I do. 21:36:06 I know, that there are people out there using CentOS PPC (some development trees) and EPEL PPC - but for myself I don't use PPC. 21:36:15 I have an ibm p43. would be nice to get oracle running on. 21:36:25 nirik: CentOS would like and need help for PPC, at least I was told this 21:36:26 yeah.. centos has not seen a lot of community interest in it (well ok interest in the way of "we will do the work for you kbsingh") 21:36:40 rsc: yeah, understandable. I have ENOTIME for such tho. ;( 21:36:52 no, the problem at CentOS is, that their core team doesn't really accept contributions.... 21:37:28 well I know some of them do... 21:38:01 when I was there it was mostly people asking for finished builds and no-one saying they would do some themselves 21:38:08 but that is neither here nor there :) 21:38:40 in the end, we are doing some PPC EPEL builds and I was wondering if we had ideas on how to test/build them better. 21:38:47 well, I offered them already multiple times help for building packages etc. But there always was something like "no" but with other words :( 21:39:08 I don't know how many/if any consumers we have... 21:39:17 me either 21:39:28 perhaps we should ask for stats on how many ppc epel mm requests we get? 21:39:55 ok will ping mdomsch on that 21:40:22 It doesn't really cost us much to build for it now, except in confusion for our maintainers... but when f12 goes eol, fedora probibly won't have any more ppc builders, so we probibly should drop support then too. 21:41:11 that was my worry 21:41:27 we could also poll RHN hosted for a number of PPC subscribers 21:41:29 and also dealing with the fact that we haven't helped test stuff 21:41:34 It would be nice if it was well documented when and where support is dropped for those of us with legacy machines that might want to put them into service 10 years from now. 21:42:28 Froolap: yeah, a single page for that might be nice... a lookup table. 21:42:38 yes. I agree 21:43:00 I guess what I am wanting is my own desktop PPC with a power7 chip in it :) 21:43:20 I have exactly that problem currently with a 486 machine I was hoping to install linux on and get wireless networking going on. 21:43:24 I am sure they grow on vines in the promised land 21:44:06 ok, so gather stats, revisit at a later meeting? 21:44:15 nirik, the cost is in lack of testing, amounts of disk space, who is using it 21:44:20 nirik, yes I agree 21:44:35 well, and the confusion for maintainers, as there is no ppc desktop. 21:44:42 #action smooge will get stats from mdomsch. smooge will ping dgilmore on ppc builds after F12 21:44:49 rhel only provides server for rhel5 ppc. 21:45:03 so you have to exclude things that use/need packages only in desktop 21:45:26 nirik, yeah.. its things like that says "lets make Fedora Enterprise Linux just for PPC :)" 21:45:47 ok I have one other topic item for us to think about 21:46:06 #topic RHEL-4.9 (end of the line bub?) 21:46:42 Ok if I am understanding rumours and stories.. RHEL-4.9 will be the last RHEL 4 release with everything else being security/oh-shoot fixes 21:47:14 how does this affect things for us if at all? 21:47:18 should certainly lock epel4 for new packages 21:47:21 IMO 21:47:32 -1 21:47:38 really? 21:47:57 hey mdomsch you around? 21:47:58 I'm not sure it should change anything for us... I suppose we could consider locking out new packages, but I see both sides of that. 21:48:03 derks: well, I would like to see forward-compat packages added 21:48:08 smooge, yep 21:48:17 derks: something to help people getting away from RHEL 4 and up to RHEL 5. 21:48:21 rsc, ok... i see you there 21:48:40 mdomsch, we were wodnering what our MM numbers were for i386/x86_64/ppc so we could get an idea of usage 21:49:12 derks, I just came from a place where 60% of the computers were still RHEL-3 and I was having to rebuild EPEL-4 stuff for them 21:49:48 yeah, we have some clients still using 3 in places. ;( 21:50:21 I have no idea about absolute numbers, but I do know it was pretty common in server areas back at my other previous job places too 21:50:27 smooge, http://fedoraproject.org/maps/el5/ 21:50:32 (heck one was still using RHEL-2 for a lot of stuff.) 21:50:33 and /el4/ 21:50:46 smooge, yeah we have a lot of RHEL3 here as well. my stance is... start migrating customers/boxes before well before EOL time 21:50:51 shows 55.8k unique IPs for el5 i386, 48.3k unique for x86_64 21:50:57 smooge: you know that RHEL2.1 is still inofficially supported? ;-) 21:52:13 derks, sure.. but customers never see it that way. Many would prefer to pay more money for people to keep them at something they like than all this PROGRESS stuff 21:52:27 mdomsch, cool. thanks. is there a general number mapping too? 21:52:37 wow look at Europe. They use PPC there 21:53:00 ? 21:53:01 smooge... i hear that. up until a year or so ago we had a customer who refused to migrate off his redhat 7.3 box. really. 21:53:06 general number mapping ? 21:53:19 mdomsch, never mind. I didn't read what was on the pictures 21:53:20 Sometimes it's better to just have something that works, than to upgrade and find out what's broke. 21:53:26 mdomsch, I am stoooopid 21:53:50 derks, I was tentatively calling that RHEL-2.2 for some people. 21:53:52 Recent example. firefox decided to upgrade my browser, and now I can't play eucher on yahoo any more. 21:53:54 derks: I used to manage 6500 boxes, and my boss insisted that they stay on RH7.3 21:54:00 I know a lot of computers still on RHL-7.3 21:54:07 Good reason not to be on the bleeding edge of upgrades 21:54:09 LOL some times you have no choise... ig the have legacy hardware that you like & an't find support in the upgrades..... 21:54:20 ig if 21:54:37 I have to learn to type .. again\ 21:54:40 mdomsch, I didn't know we had ia64 builds or was that just someone rying 21:56:09 huh. is that germany with all the el5 ppc? 21:57:25 well ok I think we are nearing our end. Thanks mdomsch for the maps. It looks like PPC has less than 0.3% of all downloads 21:57:32 nirik, I think so 21:57:58 #topic Even More Open Floor 21:58:04 that meeting going to be releaced as mp3? 21:58:19 no the beat sucks 21:58:20 smooge, just trying; epel doesn't have ia64 21:58:26 both of those customers tried though 21:58:34 So... any talk about zStream (Extended Update Support) and EPEL? 21:58:39 ok.. I guess we need to explore something for them :) 21:58:54 derks, not really. we have never set up EPEL to deal with that 21:59:05 nor should we... 21:59:23 it would require a LOT of work as we would need to segregate our builds and stuff. I would do it if you paid us a million dollars (maybe) 21:59:29 no, i agree. just wondering if there ever was talks about it. seems like it would be a nightmare to attempt 21:59:52 I think we talked about it once.. laughed ourselves silly and then went back to the meeting :) 22:00:01 ha 22:00:02 conceptually, not hard to implement technically. Process-wise, given our contributors, I wouldn't think so. 22:00:21 mdomsch, yeah. I think it would definately be 'paying' work 22:00:29 z-stream is very much paying work 22:00:58 it's the part I love most about the paid-for open source support model: the more you pay me, the less changes I'll inflict upon you. 22:01:10 ha 22:01:11 yes 22:01:14 I had to do something like that for a while with RHEL-3.6. It was a long nightmare since mock etc wasnt available to me 22:01:34 some might call that protection money 22:01:50 yep... its worked for thousands of years 22:01:55 we are looking at making it available here, and I just can't seem to convince anyone how impossible it would be for me to do 22:02:01 or manage 22:02:47 derks, I was told to keep track of my hours to be billed... if I had been a consultant I would have been able to buy a jet 22:03:05 anyway. I think we have covered that. anything else for openfloor 22:03:22 if not we meet again in 2 weeks. same epel-channel. same epel-time 22:03:23 yes 22:03:47 smooge, thanks! 22:04:01 #endmeeting