From fedora at leemhuis.info Sun Jul 1 13:15:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Jul 2007 15:15:47 +0200 Subject: Log from this weeks EPEL Sig meeting (20070627) Message-ID: <4687A903.1060803@leemhuis.info> 00:00 < knurd> | Meeting ping dgilmore, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00 < knurd> | Hi everybody; who's around? 00:00 < quaid> | hey knurd 00:00 * | mmcgrath pong 00:00 * | mmcgrath is here 00:00 * | nirik is here. 00:00 * | Jeff_S here, but if I stop responding for a while it is because my connection has dropped out :( 00:01 --> | notting (Bill Nottingham) has joined #fedora-meeting 00:01 --> | ixs (Andreas) has joined #fedora-meeting 00:01 --> | ixs (Andreas) has joined #fedora-meeting 00:01 --> | ixs (Andreas) has joined #fedora-meeting 00:01 < knurd> | no dgilmore, no stahnma 00:01 < knurd> | well, let's start 00:01 --- | knurd has changed the topic to: EPEL Meeting -- bodhi/testing repo/final repo layout -- nirik/lmacken 00:02 < knurd> | sorry, I still haven't replied to mmcgrath's last mail 00:02 < nirik> | seems it will be a while before we can figure out koji which means it will be a while for bodhi 00:02 < knurd> | looks like it 00:02 < mmcgrath> | All a matter of manpower 00:02 < knurd> | I'm all for announcing EPEL with plague and teh old scripts 00:03 < nirik> | I'm not sure if the -stable and -testing targets will work. It might. 00:03 < knurd> | I can ping dgilmore and mschwendt about it 00:03 < nirik> | I'd sure like to have -testing before announcing... 00:03 < knurd> | nirik, +1 00:03 < Jeff_S> | I agree w/ mmcgrath's email -- let's get going with plague and we'll move to koji/bodhi (ie. testing/) as soon as we can 00:03 < nirik> | could we have it so everything goes to testing and have admins manually move packages to stable? 00:04 < knurd> | nirik, should work as well afaik 00:04 < knurd> | nirik, just a bit more overhead 00:04 < nirik> | that would be more overhead, but then maintainers wouldn't need to remember two steps, no recompile, and admins could check and make sure something should go to stable 00:04 < _blah_> | i don't want to announce until broken deps are resolved. 00:04 < knurd> | _blah_, +1 00:04 < nirik> | not sure if that ability exists tho. dgilmore would know how things are setup. 00:05 < nirik> | _blah_: yeah, +1 00:05 < knurd> | _blah_, that's why there is a "make sure repo is in good shape" on the schedule 00:05 < mmcgrath> | I started to look at the spam-o-matic script. 00:05 < Jeff_S> | blah, I'm trying to get epel mirrored locally so I can check out deps, etc. although I'm having lots of fun trying to find a "current" mirror to rsync from :) 00:05 < _blah_> | knurd: maybe i should look closely at the schedule :) 00:05 < mmcgrath> | http://git.fedoraproject.org/?p=hosted/mash;a=blob_plain;f=utils/spam-o-matic;hb=HEAD <-- script 00:05 < ixs> | knurd: just for the record. epel should work fine with plague... we're doing exactly that internally right now. 00:05 < knurd> | mmcgrath, shall I add this to the schedule to make sure we don#t forget it? 00:05 < nirik> | _blah_: are you the one who posted the borken deps to the list? how did you generate? centos? rhel? 00:05 < mmcgrath> | Jeff_S: yeah thats a little strange the issues you've had. 00:06 < mmcgrath> | knurd: spam-o-matic? yeah 00:06 < _blah_> | jeff: i'm using mirrorservice.uk, but who knows what the lag is there. 00:06 < knurd> | ixs, sure, the push scripts are the problem 00:06 < knurd> | mmcgrath, k 00:06 < ixs> | knurd: sure. but that#s not the build issue, it#s a deployment issue. 00:06 < _blah_> | nirik: rhel5+all channels+epel 00:06 < knurd> | ixs, sure, but without the scripts pushing is hard and a lot of work 00:06 < knurd> | I know that from another repo ;-) 00:06 < Jeff_S> | mmcgrath: sorry, I'll bring that up in #epel later :) 00:06 < nirik> | cool. I could run centos4/centos5 repoclosure here pretty easily too... could check against your output. 00:07 < knurd> | so, what about "leaving room for a kind of "rolling epel" repo? 00:08 < knurd> | I got the impreission some contributors would like that 00:08 < quaid> | epelhide 00:08 < knurd> | :-) 00:08 < nirik> | I think it might be something we could look at down the road, but we shouldn't try and do everything at once. 00:08 < knurd> | nirik, of course 00:08 < knurd> | nirik, but we could leave room for that in the repo layout 00:08 < _blah_> | nirik: that would be helpful, it is a convoluted process for me to generate that list, so please report any errors or validations. also long term, it would be nice if this information could be generated on the build servers or somewhere similar. 00:08 < knurd> | nirik, that's all I want for now 00:09 < Jeff_S> | knurd: I feel like that is trying to do too much. We've defined EPEL as being stable, ie. not a ton of updates. So, if we're to have a "rolling" repo, then we'd have to branch every package for that and maintain separately... 00:09 < knurd> | Jeff_S, I don#t want rolling now 00:09 < knurd> | I just want to be able to do it later if we later want 00:09 < Jeff_S> | knurd: just the possibility of it down the road? 00:09 < knurd> | Jeff_S, yes 00:09 < mmcgrath> | perhaps we should label it 'experimental' 00:09 < quaid> | 'explosive' 00:09 < knurd> | zod 00:09 < _blah_> | why not add those directories in the future, then? 00:09 < knurd> | epelzod 00:10 < knurd> | _blah_, we can do that only if we put the current repo in a subdirectory 00:10 < Jeff_S> | knurd: seems reasonable, although I don't see why we can't cross that bridge when we come to it. We can always push out an updated .repo package later... 00:10 < knurd> | that's what I want 00:10 < nirik> | _blah_: yeah, thats the spam-o-matic script that mmcgrath was looking at... would mail maintainers. ;) 00:10 < nirik> | I have no problem with moving epel/* to epel/stable/ now, I don't think we shoudl create other dirs tho until we are ready to use them 00:11 < knurd> | nirik, +1 00:11 < knurd> | nirik, that's exaclty what I wanted 00:11 < mmcgrath> | _blah_: http://git.fedoraproject.org/?p=hosted/mash;a=blob_plain;f=utils/spam-o-matic;hb=HEAD <-- code 00:11 < nirik> | we do have mirrors now tho, so not sure how mad they would be getting everything again. 00:11 < _blah_> | mmcgrath: thanks, that's what i used to generated my list, but i can't install it on the buildsystem. :) 00:11 < nirik> | we could make stable and hardlink things and then remove after a few days... 00:11 < knurd> | nirik, we could hardlink that for a week or two 00:12 < knurd> | nirik, then it should not be that much new stuff 00:12 < Jeff_S> | Why not epel/{4,5}, epel/testing/{4,5}, epel/rolling/{4,5}? 00:12 < knurd> | Jeff_S, confusing 00:12 < Jeff_S> | or whatever you want to call "rolling" 00:12 < knurd> | epel rolling might have a testing as well 00:12 < mmcgrath> | _blah_: I can though :) email me after the meeting if you had to make any changes to that script to get it working. 00:12 < mmcgrath> | I don't think most sysadmins will know what rolling means. 00:12 * | knurd would really like to moving epel/* to epel/stable/ now 00:12 < mmcgrath> | I'd prefer experimental 00:13 < knurd> | mmcgrath, we don't need to define the name now 00:13 < _blah_> | mmcgrath: no changes required other than createing the repository to run it on. thanks for looking at that! 00:13 < quaid> | to start epel/stable/{4,5} alone seems sensible 00:13 < quaid> | room to grow without committing to any type of growth now 00:13 < nirik> | quaid: +1 00:13 < knurd> | mmcgrath, we just move the current stuff down a level and decide later if we want to have a rolling epel in addition 00:13 < knurd> | quaid, +1 00:13 < mmcgrath> | knurd: sounds good to me. 00:13 < _blah_> | quaid: +1 00:13 < Jeff_S> | so just hardlink in the meantime? 00:14 < knurd> | Jeff_S, yes, for a week or two 00:14 < Jeff_S> | works for me 00:14 < nirik> | who can take that action? dgilmore ? mmcgrath ? 00:14 < knurd> | the push scripts would need to be adjusted 00:14 < knurd> | and a new epel-release would be needed 00:15 < knurd> | dgilmore might be the best one for that job 00:15 < Jeff_S> | knurd: well, if you are wanting to push to -testing, then we'd need to update them anyway... 00:15 < knurd> | well, what do we want to do with testing now? 00:15 < knurd> | create it and hand-move packages over? 00:15 < knurd> | (when needed) 00:16 < _blah_> | knurd: are there other options? 00:16 < knurd> | _blah_, differnt targes in plague (see mailing list) 00:16 < Jeff_S> | knurd: I think it may be best to get people used to having things pushed to testing. Although we'd need a procedure in place for requesting the push to stable 00:16 < knurd> | but handmoving over stuff might be fine for now 00:16 < knurd> | Jeff_S, wiki? 00:17 < knurd> | we'll find something 00:17 < Jeff_S> | knurd: I can't think of anything better ATM ;) 00:17 < knurd> | afaics most of us want a testing 00:17 < knurd> | or am I wrong with that? 00:17 < nirik> | our release plan of only promoting things on N.y releases depends on testing. 00:18 < knurd> | all new stuff could (and should) go to the stable repo as well 00:18 < knurd> | and testing becomes stable on N.y releases 00:18 < knurd> | and security stuff gets build for testing, and moved over after a day or two 00:18 < nirik> | new stuff? new packages? 00:18 < knurd> | yes, new packages 00:19 < knurd> | for now 00:19 < knurd> | until EPEL is a bit bigger 00:19 < nirik> | new -> stable , update -> testing (wait until next .y release) -> stable... yeah... 00:19 < knurd> | fine for the others as well? 00:20 * | knurd waits if somebody yells 00:20 < rdieter> | using bodhi? 00:20 < nirik> | I like the idea of a rel team checking things before moving to stable tho... no broken deps, etc. 00:20 < knurd> | rdieter, in the long term: sure 00:20 < nirik> | rdieter: we can't use bodhi yet. We will when we can. 00:20 < knurd> | rdieter, but we need koji for that, and that requires manpower we don#t have 00:21 < rdieter> | so you want to implement testing repo before bodhi? 00:21 < knurd> | rdieter, kind of, yes 00:21 < rdieter> | ok 00:21 < knurd> | anything else regarding this topic? 00:21 < knurd> | otherwise I'll move on 00:21 --- | knurd has changed the topic to: EPEL Meeting -- finish the wiki docs and remove the warnings by end of may -- quaid 00:21 < knurd> | quaid seems to be working on it today 00:22 < knurd> | thx for that 00:22 < mmcgrath> | hurray for quaid :) 00:22 < knurd> | quaid anything to say reg. this? otherwise I'll move on 00:22 < quaid> | nope 00:22 < quaid> | just doing it now so it gets finally done :) 00:22 --- | knurd has changed the topic to: EPEL Meeting -- unresolved deps / packages missing in owners.epel.list 00:22 < knurd> | we talked about that in parts already 00:22 < knurd> | anything else to say regarding this? 00:23 < nirik> | I think all the missing packages should be fixed. 00:23 < knurd> | nirik, k, will remove that 00:23 < nirik> | need to see if dgilmore cleaned up tdma... I can do that if not. 00:23 < knurd> | maybe we should try to bug c4chris, so he runs his package status script for epel as well 00:23 < nirik> | we need to get the broken deps fixed tho. 00:24 < knurd> | yeah, but I got the impression you guys work on that 00:24 < mmcgrath> | I'll try to get the script installed in the next day or two 00:24 < knurd> | and the script 00:24 < knurd> | mmcgrath, great 00:24 < nirik> | I can poke people on fixing things too... 00:24 < knurd> | nirik, that would be great 00:24 < nirik> | some of them look to be that some dependent packages need to be branched for epel. 00:25 < knurd> | nirik, we likely should bug the fedora maintainers if needed and ask them if they want to participate in EPEL 00:25 < knurd> | if they don#t want -> send a list of packages to the list 00:25 < knurd> | I'm sure a maintainer will show up sooner or later 00:26 < knurd> | anything else? 00:26 --- | knurd has changed the topic to: EPEL Meeting -- vacant seat in the steering committee 00:26 < knurd> | smoog didn#t want to afaics from the last weeks log 00:27 < knurd> | so Jeff_S self-nominated 00:27 < knurd> | I#d say we should give others a chance to self-nominate as well 00:27 * | mmcgrath likes Jeff_S 00:27 < knurd> | and finally decide next week 00:27 < Jeff_S> | mmcgrath: well thank you :) 00:27 < nirik> | did we have any other people interested? 00:27 < knurd> | mmcgrath, agreed, but we should give others a chance to self-nominate as well 00:27 < knurd> | nirik, don#t know, we did not ask 00:28 < knurd> | and I think it's best to ask once in public 00:28 * | knurd should have done that two weeks ago 00:28 < knurd> | sorry Jeff_S 00:28 < nirik> | I think we did ask... 00:28 < nirik> | at least I remember comment about it on the list. 00:28 < nirik> | oh yeah, on the 20th, Jeff_S throwing a hat into the ring. 00:28 < nirik> | no other reponses. 00:29 < knurd> | okay 00:29 < knurd> | then +1 for Jeff_S 00:29 < nirik> | yeah, +1 for Jeff_S here. 00:29 < _blah_> | +1 for jeff_s 00:29 < knurd> | mmcgrath, quaid ? 00:29 < mmcgrath> | +1 00:30 < quaid> | Jeff_S++ 00:30 < knurd> | k, settled 00:30 < quaid> | yay! 00:30 < knurd> | welcome Jeff_S 00:30 < Jeff_S> | thanks 00:30 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:30 < knurd> | anything else? 00:31 * | mmcgrath wanted to mention that I regularly bump into EPEL users. 00:31 < mmcgrath> | I found 3 of them in #puppet the other day :) 00:31 < knurd> | hehe, and we didn't even annouce yet :) 00:31 < nirik> | really? wow.... 00:31 < Jeff_S> | that's nice 00:32 < _blah_> | i've requested a few packages from fedora maintainers that have not gotten back to me... what is the next step in getting those packages into epel? 00:32 < quaid> | I bet the uptake will be pretty good 00:32 < nirik> | we are getting a good sized collection of packages now. 00:32 * | f13 sits in the peanut gallary 00:32 < notting> | do we want a separate excludearch tracker for epel, or piggyback on the fedora one? 00:32 * | quaid sends the peanut gal around with a fresh bag of hot 'nuts for fab__ 00:32 < knurd> | _blah_, good question 00:32 < quaid> | argh s/fab__/f13/ 00:32 < nirik> | _blah_: how long since you pinged them? Might wait a bit, and then post the list to the epel-devel list and see if anyone is interested in them? 00:32 < knurd> | _blah_, if they don#t react I'd say just request the branch via bugzilla; CC the fedora maintainer 00:33 < knurd> | (if you want to maintain them) 00:33 < _blah_> | nirik: 2 weeks+ time elapsed. i'm willing to maintain all of em for epel purposes. 00:33 < nirik> | notting: not sure. Either way would be fine as long as the arch people know to watch the epel one too. 00:33 < notting> | nirik: admittedly, this is an odd case 00:33 < knurd> | _blah_, we likely should ask FESCo for their opinion 00:34 < knurd> | I'll do that and get back to you 00:34 < notting> | nirik: excludearched b/c a rhel package is horribly broken 00:34 --> | wwoods (Will Woods) has joined #fedora-meeting 00:34 < _blah_> | knurd: ok, that would be cool. 00:34 < nirik> | notting: lovely... and since it's RHEL it's unlikely to get fixed anytime soon, eh? 00:34 * | knurd is wondering if we really need a a EPEL excludearch tracker 00:34 < notting> | nirik: well, i can *ask*. doubtful unless we find an actual customer that cares about rhel4 guile x86_64 00:35 < Jeff_S> | I think http://fedoraproject.org/wiki/EPEL/Schedule could use some updating... 00:35 < knurd> | Jeff_S, it's a wiki, feel free to do so 00:35 < knurd> | Jeff_S, but it's on my todo list as well for the next days 00:36 * | Jeff_S back again 00:36 < Jeff_S> | weee 00:36 < Jeff_S> | knurd: ok, I'll try to work on it a bit as well 00:36 < knurd> | Jeff_S, thx 00:36 < knurd> | notting, maybe ask on the list for opinions if we need a EPEL exclude arch tracker 00:37 < knurd> | I'd tend to say we don't need one, but I'm fine with having one if others want one 00:37 < nirik> | yeah, thinking about it, I think we could just use the fedora ones... 00:37 < knurd> | nirik, it might confuse people... 00:37 < notting> | ok, i'll ask on the list 00:37 < knurd> | notting, thx 00:38 < knurd> | anything else? 00:38 < nirik> | true, but the only people who look at those are arch folks, they likely wouldn't be too confused (by that at least. ;) 00:38 < notting> | well, i pointed some people on a mailing list to epel. didn't mean to jump the gun, sorry about that 00:39 < nirik> | no problem. I have been using epel on client machines here already, as well as centos virtuals of mine. 00:40 * | nirik doesn't have any other discussion items right now. 00:40 < f13> | has there been any progress on the RHX issue? 00:40 * | knurd will close the meeting in 30 00:40 < knurd> | f13, could you mail about it to the list 00:40 < knurd> | f13, I still try to understand it 00:40 < f13> | I'm not on the list as of yet. 00:40 < f13> | quaid: was supposed to do some looking into it IIRC 00:40 < knurd> | well, I'd like to see it discussed on the list 00:41 < f13> | that's fine, I'm just an "outsider" looking for an update 00:41 < knurd> | one IMHO should write up the background of such complicate topics first and send it to the list 00:41 < knurd> | f13, k, :-) I'll bug quaid about it then 00:41 * | knurd has to leave soon 00:41 * | knurd will close the meeting in 20 00:42 * | knurd will close the meeting in 10 00:42 < knurd> | -- MARK -- Meeting end 00:42 --- | knurd has changed the topic to: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting 00:42 < dgilmore> | shit sorry i missed it guys 00:42 < knurd> | thx everybody 00:42 < knurd> | hi dgilmore 00:42 * | knurd has to leave now 00:42 < knurd> | np dgilmore 00:42 < knurd> | cu 00:42 --- | You're now known as knurd_afk 00:43 < mmcgrath> | laterz From fedora at leemhuis.info Sun Jul 1 15:15:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Jul 2007 17:15:24 +0200 Subject: EPEL report week 26, 2007 Message-ID: <4687C50C.8040902@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week26 = Weekly EPEL Summary = Week 26/2007 == Most important happenings == * Jeff Sheltren is new Steering Committee member (he replaces Axel Thimm, who left some weeks ago). Welcome Jeff! * wiki docs will be ready and reviewed soon; @everyone: everything fine with the docs? anything missing? * things that need do be done before EPEL announcement: fix broken deps, final repo layout, check if everything is okay == EPEL SIG Meeting == === Attending === >From the Steering Committee: * Jeff_S (Jeff Sheltren) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * quiad (KarstenWade) Missing from the Steering Committee: * dgilmore (DennisGilmore) * stahnma (MichaelStahnke) Others that participated the meeting: notting, rdieter, f13, _blah_ === Summary === * bodhi/testing repo/final repo layout ? nirik/lmacken * the plan is to move on using plague and the extras push scripts for the near future; koji plus bodhi later (hopefully soon; needs koji improvements that need to be written) * we move the current repo down one level (hardlinking the files, to make mirrors happy) into a subdirectory "stable" to leave room on the server for other EPEL in the future (that might happen or not). * we freeze the current repo and make the testing repo the default target for now and hand-move packages over to the stable repo when needed manually (information flow: via wiki) ? e.g. new packages that were in testing for some days as well as important bugfixes (security, hard crashers, ...) * finish the wiki docs and remove the warnings by end of may ? quaid * quaid and Jess_S are working on it; seems to be in the final stages * unresolved deps / packages missing in owners.epel.list * we should solve the broken deps soon (needed before announcement); * nirik will poke maintainers (help from SIG members would likely be appreciated); * mmcgrath will try to set up the broken deps checker script somewhere that spmas maintainers and the list in case of broken deps * should we try to bug c4chris, so he runs his package status script for epel as well? * vacant seat in the steering committee * Jeff_S was elected by the Steering Committee members to fill Axel's seat * Free discussion around EPEL * _blah_> "i've requested a few packages from fedora maintainers that have not gotten back to me... what is the next step in getting those packages into epel?"; knurd mailed the Fedora list about this; see https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02614.html; revisit next week * notting> "do we want a separate excludearch tracker for epel, or piggyback on the fedora one?" -> moved to the list, revisit next week * f13> "has there been any progress on the RHX issue?" - quaid is supposed to do some looking into it IIRC === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00000.html == Stats == === General === Number of EPEL Contributors 101 We welcome 3 new contributors: mcepl_AT_redhat.com, qspencer_AT_ieee.org, skvidal_AT_linux.duke.edu === EPEL 5 === Number of source packages: 405 Number of binary packages: 736 There are 12 new Packages: * bzr | Friendly distributed version control system * cvs2svn | CVS to Subversion Repository Converter * glpk | GNU Linear Programming Kit * itcl | Object oriented extensions to Tcl and Tk * python-dateutil | Powerful extensions to the standard datetime module * python-feedparser | Parse RSS and Atom feeds in Python * python-matplotlib | Python plotting library * python-memcached | A Python memcached client library * python-paramiko | A SSH2 protocol library for python * pytz | World Timezone Definitions for Python * re2c | Tool for generating C-based recognizers from regular expressions * yum-utils | Utilities based around the yum package manager === EPEL 4 === Number of source packages: 252 Number of binary packages: 529 There are 4 new Packages: * cvs2svn | CVS to Subversion Repository Converter * itcl | Object oriented extensions to Tcl and Tk * python-feedparser | Parse RSS and Atom feeds in Python * re2c | Tool for generating C-based recognizers from regular expressions ---- ["CategoryEPELReports"] From fedora at leemhuis.info Sun Jul 1 15:29:43 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 01 Jul 2007 17:29:43 +0200 Subject: RFC: EPEL branching if Fedora maintainer does not react Message-ID: <4687C867.8060400@leemhuis.info> >From this weeks report: * _blah_> "i've requested a few packages from fedora maintainers that have not gotten back to me... what is the next step in getting those packages into epel?"; knurd mailed the Fedora list about this; Find the mail attached. Is that fine for everyone? If yes I'd say we make this policy in this weeks meeting. CU thl -------------- next part -------------- An embedded message was scrubbed... From: Thorsten Leemhuis Subject: EPEL branching if Fedora maintainer does not react (was: Re: Plan for tomorrows (20070628) FESCO meeting) Date: Thu, 28 Jun 2007 07:12:15 +0200 Size: 3083 URL: From jamatos at fc.up.pt Sun Jul 1 17:52:58 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Sun, 1 Jul 2007 18:52:58 +0100 Subject: EPEL5 dependency report In-Reply-To: <80d7e4090706281218mc27d04bq79ccf4e218c58607@mail.gmail.com> References: <1182792111.4065.70.camel@rxm-581b.stl.gtri.gatech.edu> <4683FACC.40700@leemhuis.info> <80d7e4090706281218mc27d04bq79ccf4e218c58607@mail.gmail.com> Message-ID: <200707011852.58494.jamatos@fc.up.pt> On Thursday 28 June 2007 20:18:31 Stephen John Smoogen wrote: > I am seeing this one is missing on the break tree for some reason: > > --> Processing Dependency: python-imaging = 1.1.6-3.el5 for package: > python-imaging-tk > --> Processing Dependency: python-imaging for package: plone > --> Finished Dependency Resolution > --> Populating transaction set with selected packages. Please wait. > ---> Package kernel.i686 0:2.6.18-8.1.4.el5 set to be erased > --> Running transaction check > --> Processing Dependency: python-imaging = 1.1.6-3.el5 for package: > python-imaging-tk > --> Processing Dependency: python-imaging for package: plone > --> Finished Dependency Resolution > Error: Missing Dependency: python-imaging = 1.1.6-3.el5 is needed by > package python-imaging-tk Why should this fail? I am the maintainer of python-imaging, and I don't see what can be wrong, thus I am asking. :-) > -- > Stephen J Smoogen. -- CSIRT/Linux System Administrator > How far that little candle throws his beams! So shines a good deed > in a naughty world. = Shakespeare. "The Merchant of Venice" -- Jos? Ab?lio From buildsys at fedoraproject.org Mon Jul 2 13:13:37 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 2 Jul 2007 09:13:37 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-02 Message-ID: <20070702131337.D1317152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 2 NEW JSDoc-1.10.2-3.el5 : Produces javadoc-style documentation from JavaScript sourcefiles NEW libcgi-1.0-5.el5 : CGI easy as C Packages built and released for Fedora EPEL 4: 2 NEW JSDoc-1.10.2-3.el4 : Produces javadoc-style documentation from JavaScript sourcefiles NEW libcgi-1.0-5.el4.1 : CGI easy as C Changes in Fedora EPEL 5: JSDoc-1.10.2-3.el5 ------------------ * Sat Jun 23 2007 Matej Cepl - 1.10.2-3 - Added GPL text as new source - documentation files (*.tmpl, *.css) shouldn't be executable. - limited ownership of perl_vendorlib direcotries. libcgi-1.0-5.el5 ---------------- * Tue Jun 26 2007 Jose Pedro Oliveira - 1.0-5 - make install: override LIBDIR in order to support /usr/lib64. * Tue Jun 26 2007 Jose Pedro Oliveira - 1.0-4 - Install the header files in %{_includedir}/%{name}. Changes in Fedora EPEL 4: JSDoc-1.10.2-3.el4 ------------------ * Sat Jun 23 2007 Matej Cepl - 1.10.2-3 - Added GPL text as new source - documentation files (*.tmpl, *.css) shouldn't be executable. - limited ownership of perl_vendorlib direcotries. libcgi-1.0-5.el4.1 ------------------ * Sun Jul 01 2007 Jose Pedro Oliveira - 1.0-5.1 - RHEL4: find doesn't support the -delete option (-delete => -exec rm {} ';'). * Tue Jun 26 2007 Jose Pedro Oliveira - 1.0-5 - make install: override LIBDIR in order to support /usr/lib64. * Tue Jun 26 2007 Jose Pedro Oliveira - 1.0-4 - Install the header files in %{_includedir}/%{name}. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From tla at rasmil.dk Mon Jul 2 17:26:26 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Mon, 02 Jul 2007 19:26:26 +0200 Subject: Fedora EPEL Package Build Report 2007-06-30 In-Reply-To: <20070630165812.EC4E5152131@buildsys.fedoraproject.org> References: <20070630165812.EC4E5152131@buildsys.fedoraproject.org> Message-ID: <46893542.6010105@rasmil.dk> buildsys at fedoraproject.org wrote: > NEW yum-utils-1.0.3-1.el5 : Utilities based around the yum package manager > ???? How pushed this one into EPEL5, I maintain it upstream and make the releases in fedora too. I have no problems with yum-util in EPEL5, i have just not gotten to push it my self. Tim From bojan at rexursive.com Tue Jul 3 02:27:01 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 03 Jul 2007 12:27:01 +1000 Subject: viewvc package In-Reply-To: <1182494305.2937.27.camel@shrek.rexursive.com> References: <1182493149.2937.23.camel@shrek.rexursive.com> <467B6CF9.5010902@symetrix.com> <1182494305.2937.27.camel@shrek.rexursive.com> Message-ID: <1183429621.11410.6.camel@shrek.rexursive.com> On Fri, 2007-06-22 at 16:38 +1000, Bojan Smojver wrote: > I'm on EL5, so I'll focus on that for now. Enscript is there, but > cvsgraph isn't. I'll see if Fedora packages build on EL5 and report > back. I'll also check other build/runtime dependencies. cvsgraph-1.6.1-3.fc6 (a.k.a. the current F7 thingy) builds just fine on EL5, with no modification. -- Bojan From buildsys at fedoraproject.org Tue Jul 3 02:41:06 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 2 Jul 2007 22:41:06 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-02 Message-ID: <20070703024106.6A0A4152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 16 NEW alsamixergui-0.9.0-0.3.rc1.el5 : GUI mixer for ALSA sound devices NEW artwiz-aleczapka-fonts-1.3-5.el5 : Set of (improved) artwiz fonts babel-0.8.1-1.el5 NEW c-ares-1.4.0-1.el5 : A library that performs asynchronous DNS operations ebtables-2.0.8-1.el5 NEW evolution-bogofilter-0.2.0-5.el5.1 : A plugin for bogofilter support in evolution NEW ftplib-3.1-2.el5 : Library of FTP routines php-pear-Benchmark-1.2.7-1.el5 php-pear-Date-Holidays-0.17.1-2.el5 php-pear-HTML-Common-1.2.4-1.el5 php-pear-HTML-QuickForm-3.2.9-1.el5 php-pear-Image-Canvas-0.3.1-1.el5 php-pear-Net-URL-1.0.15-1.el5 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.10-1.el5 python-genshi-0.4.2-1.el5 NEW python-isprelink-0.1.2-2.el5 : Python module to determine if a file has been prelinked Packages built and released for Fedora EPEL 4: 6 NEW alsamixergui-0.9.0-0.2.rc1.el4 : GUI mixer for ALSA sound devices NEW artwiz-aleczapka-fonts-1.3-3.el4 : Set of (improved) artwiz fonts NEW c-ares-1.4.0-1.el4 : A library that performs asynchronous DNS operations ebtables-2.0.8-1.el4 NEW ftplib-3.1-2.el4 : Library of FTP routines NEW python-isprelink-0.1.2-2.el4 : Python module to determine if a file has been prelinked Changes in Fedora EPEL 5: alsamixergui-0.9.0-0.3.rc1.el5 ------------------------------ * Sun Sep 10 2006 Tom "spot" Callaway 0.9.0-0.3.rc1 - bump for fc6 artwiz-aleczapka-fonts-1.3-5.el5 -------------------------------- * Sat Sep 23 2006 Tom "spot" Callaway 1.3-5 - Rebuilt for FC6 babel-0.8.1-1.el5 ----------------- * Mon Jul 02 2007 Jeffrey C. Ollie - 0.8.1-1 - Update to 0.8.1 - Remove upstreamed patch. c-ares-1.4.0-1.el5 ------------------ * Wed Jun 27 2007 Tom "spot" Callaway 1.4.0-1 - bump to 1.4.0 (resolves bugzilla 243591) - get rid of static library (.a) ebtables-2.0.8-1.el5 -------------------- * Mon Jul 02 2007 Tom "spot" Callaway 2.0.8-1 - final 2.0.8 release evolution-bogofilter-0.2.0-5.el5.1 ---------------------------------- * Mon Jul 02 2007 Tom "spot" Callaway 0.2.0-5.1 - evo doesn't exist for RHEL-5 ppc ftplib-3.1-2.el5 ---------------- * Mon Jun 04 2007 Tom "spot" Callaway - 3.1-2 - fix licensing (libs LGPL, qftp GPL) * Mon Jun 04 2007 Tom "spot" Callaway - 3.1-1 - initial build for Fedora php-pear-Benchmark-1.2.7-1.el5 ------------------------------ * Mon Jul 02 2007 Christopher Stone 1.2.7-1 - Upstream Sync php-pear-Date-Holidays-0.17.1-2.el5 ----------------------------------- * Mon Jul 02 2007 Christopher Stone 0.17.1-2 - Add files to %{_bindir} * Mon Jul 02 2007 Christopher Stone 0.17.1-1 - Upstream Sync - Update license file php-pear-HTML-Common-1.2.4-1.el5 -------------------------------- * Mon Jul 02 2007 Christopher Stone 1.2.4-1 - Upstream sync - Update license file php-pear-HTML-QuickForm-3.2.9-1.el5 ----------------------------------- * Mon Jul 02 2007 Christopher Stone 3.2.9-1 - Upstream sync - Update license file php-pear-Image-Canvas-0.3.1-1.el5 --------------------------------- * Mon Jul 02 2007 Christopher Stone 0.3.1-1 - Upstream Sync php-pear-Net-URL-1.0.15-1.el5 ----------------------------- * Mon Jul 02 2007 Christopher Stone 1.0.15-1 - Upstream sync php-pear-Structures-DataGrid-DataSource-MDB2-0.1.10-1.el5 --------------------------------------------------------- * Mon Jul 02 2007 Christopher Stone 0.1.10-1 - Upstream sync python-genshi-0.4.2-1.el5 ------------------------- * Thu Jun 21 2007 Jeffrey C. Ollie - 0.4.2-1 - Update to 0.4.2 python-isprelink-0.1.2-2.el5 ---------------------------- * Fri Jun 29 2007 Jeffrey C. Ollie - 0.1.2-2 - Upstream tarball is different from what I was using, adapt. * Tue Jun 26 2007 Jeffrey C. Ollie - 0.1.2-1 - First version for Fedora Changes in Fedora EPEL 4: alsamixergui-0.9.0-0.2.rc1.el4 ------------------------------ * Mon Jan 16 2006 Tom "spot" Callaway 0.9.0-0.2.rc1 - add desktop entry artwiz-aleczapka-fonts-1.3-3.el4 -------------------------------- * Sat Dec 31 2005 Andreas Bierfert 1.3-3 - apply fixes from Dawid Gajownik - add documentation c-ares-1.4.0-1.el4 ------------------ * Wed Jun 27 2007 Tom "spot" Callaway 1.4.0-1 - bump to 1.4.0 (resolves bugzilla 243591) - get rid of static library (.a) ebtables-2.0.8-1.el4 -------------------- * Mon Jul 02 2007 Tom "spot" Callaway 2.0.8-1 - final 2.0.8 release ftplib-3.1-2.el4 ---------------- * Mon Jun 04 2007 Tom "spot" Callaway - 3.1-2 - fix licensing (libs LGPL, qftp GPL) * Mon Jun 04 2007 Tom "spot" Callaway - 3.1-1 - initial build for Fedora python-isprelink-0.1.2-2.el4 ---------------------------- * Fri Jun 29 2007 Jeffrey C. Ollie - 0.1.2-2 - Upstream tarball is different from what I was using, adapt. * Tue Jun 26 2007 Jeffrey C. Ollie - 0.1.2-1 - First version for Fedora For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From bojan at rexursive.com Tue Jul 3 03:51:58 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 03 Jul 2007 13:51:58 +1000 Subject: viewvc package In-Reply-To: <1183429621.11410.6.camel@shrek.rexursive.com> References: <1182493149.2937.23.camel@shrek.rexursive.com> <467B6CF9.5010902@symetrix.com> <1182494305.2937.27.camel@shrek.rexursive.com> <1183429621.11410.6.camel@shrek.rexursive.com> Message-ID: <1183434718.11410.9.camel@shrek.rexursive.com> On Tue, 2007-07-03 at 12:27 +1000, Bojan Smojver wrote: > cvsgraph-1.6.1-3.fc6 (a.k.a. the current F7 thingy) builds just fine on > EL5, with no modification. And, if cvsgraph does make into EPEL5, I was thinking of something like the attached for the spec file. Unfortunately, we'd probably have to bring back the -selinux package for EPEL... The patch is against Fedora development spec. -- Bojan -------------- next part -------------- A non-text attachment was scrubbed... Name: viewvc-epel.patch Type: text/x-patch Size: 2593 bytes Desc: not available URL: From fedora at leemhuis.info Wed Jul 4 04:51:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Jul 2007 06:51:31 +0200 Subject: Plan for todays (20070704) EPEL SIG meeting Message-ID: <468B2753.1070906@leemhuis.info> Hi all, find below the list of topics that are likely to come up in the next EPEL SIG meeting that's scheduled for tomorrow, Wednesday at 17:00 UTC in #fedora-extras on irc.freenode.org. Note: I added some new stuff and worked a bit on the Schedule page in the wiki http://fedoraproject.org/wiki/EPEL/Schedule I put some names behind some of the new tasks -- that's not binding for now and will be discussed in the meeting. /topic EPEL Meeting ? broken deps ? nirik /topic EPEL Meeting ? spam o magic script ? mmcgrath /topic EPEL Meeting ? signers group ? dgilmore /topic EPEL Meeting ? move epel dirs on servers down below stable ? knurd /topic EPEL Meeting ? branch for EPEL if Fedora maintainer does not react ? knurd, _blah_ /topic EPEL Meeting ? finish the wiki docs and remove the warnings by end of may ? quaid /topic EPEL Meeting ? new meeting time? ? all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) /topic EPEL Meeting ? Communication plan for enterprise customers/ISVs/IHVs ? stahnma, quaid /topic EPEL Meeting ? ExcludeArch TrackerBugs for EPEL ? notting/knurd /topic EPEL Meeting ? RHX and EPEL ? quaid You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics at the end of the meeting itself. If your name/nick is on above list please give a update. That way all the interested parties know what up ahead of the meeting; that will avoid long delays and "status update monologues in the meeting. Thanks! CU thl From dennis at ausil.us Wed Jul 4 05:29:56 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 4 Jul 2007 00:29:56 -0500 Subject: Plan for todays (20070704) EPEL SIG meeting In-Reply-To: <468B2753.1070906@leemhuis.info> References: <468B2753.1070906@leemhuis.info> Message-ID: <200707040029.57048.dennis@ausil.us> Once upon a time Tuesday 03 July 2007, Thorsten Leemhuis wrote: > Hi all, > > find below the list of topics that are likely to come up in the next > EPEL SIG meeting that's scheduled for tomorrow, Wednesday at 17:00 UTC > in #fedora-extras on irc.freenode.org. > > Note: I added some new stuff and worked a bit on the Schedule page in > the wiki http://fedoraproject.org/wiki/EPEL/Schedule > I put some names behind some of the new tasks -- that's not binding for > now and will be discussed in the meeting. > > /topic EPEL Meeting ? broken deps ? nirik > /topic EPEL Meeting ? spam o magic script ? mmcgrath > /topic EPEL Meeting ? signers group ? dgilmore > /topic EPEL Meeting ? move epel dirs on servers down below stable ? knurd > /topic EPEL Meeting ? branch for EPEL if Fedora maintainer does not > react ? knurd, _blah_ > /topic EPEL Meeting ? finish the wiki docs and remove the warnings by > end of may ? quaid > /topic EPEL Meeting ? new meeting time? ? all (see also > http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) > /topic EPEL Meeting ? Communication plan for enterprise > customers/ISVs/IHVs ? stahnma, quaid > /topic EPEL Meeting ? ExcludeArch TrackerBugs for EPEL ? notting/knurd > /topic EPEL Meeting ? RHX and EPEL ? quaid > > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics at the end of the meeting itself. > > If your name/nick is on above list please give a update. That way all > the interested parties know what up ahead of the meeting; that will > avoid long delays and "status update monologues in the meeting. Since its a public holiday in the states im unlikely to be available. not sure if the other us based people will be either. Dennis From fedora at leemhuis.info Wed Jul 4 05:53:16 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Jul 2007 07:53:16 +0200 Subject: Plan for todays (20070704) EPEL SIG meeting In-Reply-To: <200707040029.57048.dennis@ausil.us> References: <468B2753.1070906@leemhuis.info> <200707040029.57048.dennis@ausil.us> Message-ID: <468B35CC.8060009@leemhuis.info> On 04.07.2007 07:29, Dennis Gilmore wrote: > Once upon a time Tuesday 03 July 2007, Thorsten Leemhuis wrote: >> Hi all, >> >> find below the list of topics that are likely to come up in the next >> EPEL SIG meeting that's scheduled for tomorrow, Wednesday at 17:00 UTC >> in #fedora-extras on irc.freenode.org. >>[...] > Since its a public holiday in the states im unlikely to be available. not > sure if the other us based people will be either. Uhhhps -- I should have thought of this. Well, we'll see who's around and cancel the meeting if we are to few (with looks likely...). CU thl From pertusus at free.fr Wed Jul 4 07:48:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Jul 2007 09:48:11 +0200 Subject: Plan for todays (20070704) EPEL SIG meeting In-Reply-To: <468B2753.1070906@leemhuis.info> References: <468B2753.1070906@leemhuis.info> Message-ID: <20070704074811.GA10397@free.fr> On Wed, Jul 04, 2007 at 06:51:31AM +0200, Thorsten Leemhuis wrote: > Hi all, > > find below the list of topics that are likely to come up in the next > EPEL SIG meeting that's scheduled for tomorrow, Wednesday at 17:00 UTC > in #fedora-extras on irc.freenode.org. > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics at the end of the meeting itself. I sent a mail about how to havev some infos about RHEL packages some time ago and didn't received any response, so (even though it is not completly obvious that it is in EPEL role), I add it here. Maybe it is relevant for EPEL anyway, if the silence reflects an issue in EPEL/RHEL relationship. I am checking which package I'd like to put in EPEL and it appears that some informations are lacking, that I can find easily with rpmfind (for example), but I cannot for RHEL. Here is a list of things I would like to do, from a non Centos/RHEL box, or from another Centos/RHEL version, of course. Do you have guidance on how to do it? Keep in mind that I would like something easy, (like what rpmfind provides, for example) not something complicated (like download all the srpms and work out from the spec files): * find whether a package is in RHEL or not * find whether a file is in RHEL or not, and in which package * find whether a provides is in RHEL or not, and provided by which package * find the list of files and provides of a package in RHEL I'd like to add that, if there is to be a cooperation with other repos, it would be nice to have a place in the wiki for other repo representant to put this information (and also more information, like web site, contact people, download link, version control system link if any). -- Pat From fedora at leemhuis.info Wed Jul 4 08:05:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Jul 2007 10:05:03 +0200 Subject: Plan for todays (20070704) EPEL SIG meeting In-Reply-To: <20070704074811.GA10397@free.fr> References: <468B2753.1070906@leemhuis.info> <20070704074811.GA10397@free.fr> Message-ID: <468B54AF.1090600@leemhuis.info> On 04.07.2007 09:48, Patrice Dumas wrote: > [...] > I am checking which package I'd like to put in EPEL and it appears that > some informations are lacking, that I can find easily with rpmfind (for > example), but I cannot for RHEL. Here is a list of things I would like > to do, from a non Centos/RHEL box, or from another Centos/RHEL version, > of course. Do you have guidance on how to do it? mock + chroot? Or install CentOS in a VM? > Keep in mind that I would > like something easy, (like what rpmfind provides, for example) not something > complicated (like download all the srpms and work out from the spec > files): > > * find whether a package is in RHEL or not Simply look at the CentOS dir like? http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/5/os/x86_64/CentOS/ > * find whether a file is in RHEL or not, and in which package > * find whether a provides is in RHEL or not, and provided by which > package > * find the list of files and provides of a package in RHEL I've never used rpmfind, but if it can serve you this information for Fedora it might be able to serve it for CentOS as well (which "aims to be 100% binary compatible"). CU thl From pertusus at free.fr Wed Jul 4 09:02:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 4 Jul 2007 11:02:11 +0200 Subject: Plan for todays (20070704) EPEL SIG meeting In-Reply-To: <468B54AF.1090600@leemhuis.info> References: <468B2753.1070906@leemhuis.info> <20070704074811.GA10397@free.fr> <468B54AF.1090600@leemhuis.info> Message-ID: <20070704090211.GB10397@free.fr> On Wed, Jul 04, 2007 at 10:05:03AM +0200, Thorsten Leemhuis wrote: > On 04.07.2007 09:48, Patrice Dumas wrote: > > [...] > > I am checking which package I'd like to put in EPEL and it appears that > > some informations are lacking, that I can find easily with rpmfind (for > > example), but I cannot for RHEL. Here is a list of things I would like > > to do, from a non Centos/RHEL box, or from another Centos/RHEL version, > > of course. Do you have guidance on how to do it? > > mock + chroot? Or install CentOS in a VM? Indeed mock and chroot may be very usefull for testing package functionnality and build, but it is not exactly what I am looking for. As a side note I cannot find a mock config for centos to be used for mock builds of epel, looking through the wiki (although they are reference to such a thing existing, for example http://fedoraproject.org/wiki/EPEL/FAQ#head-f9e8c36dc22934ebff5e9c6ec537f7673e8b7a38 and I remember seeing a reference to those files on a list). > > Keep in mind that I would > > like something easy, (like what rpmfind provides, for example) not something > > complicated (like download all the srpms and work out from the spec > > files): > > > > * find whether a package is in RHEL or not > > Simply look at the CentOS dir like? > > http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/5/os/x86_64/CentOS/ It is really the same than: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/ with all the subdirectories? (well is http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/4/os/ the same ?) > > * find whether a file is in RHEL or not, and in which package > > * find whether a provides is in RHEL or not, and provided by which > > package > > * find the list of files and provides of a package in RHEL > > I've never used rpmfind, but if it can serve you this information for > Fedora it might be able to serve it for CentOS as well (which "aims to > be 100% binary compatible"). Ok, this clarifies things a lot. I hadn't understood that Centos was interchangeable for RHEL for EPEL. -- Pat From fedora at leemhuis.info Wed Jul 4 09:22:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 04 Jul 2007 11:22:00 +0200 Subject: Plan for todays (20070704) EPEL SIG meeting In-Reply-To: <20070704090211.GB10397@free.fr> References: <468B2753.1070906@leemhuis.info> <20070704074811.GA10397@free.fr> <468B54AF.1090600@leemhuis.info> <20070704090211.GB10397@free.fr> Message-ID: <468B66B8.8060101@leemhuis.info> On 04.07.2007 11:02, Patrice Dumas wrote: > On Wed, Jul 04, 2007 at 10:05:03AM +0200, Thorsten Leemhuis wrote: >> On 04.07.2007 09:48, Patrice Dumas wrote: >>> [...] > [...] > As a side note I cannot find a mock config for centos to be used > for mock builds of epel, [...] $ repoquery --whatprovide /etc/mock/fedora-5-i386-epel.cfg /etc/mock/fedora-5-i386-epel.cfg [...] mock-0:0.7.2-1.fc7.x86_64 mock-0:0.7.2-1.fc7.x86_64 This is on F7 -- the EPEL files where added around two weeks ago iirc. Maybe it would be good to add them to the wiki as well; can't hurt. >>> Keep in mind that I would >>> like something easy, (like what rpmfind provides, for example) not something >>> complicated (like download all the srpms and work out from the spec >>> files): >>> >>> * find whether a package is in RHEL or not >> Simply look at the CentOS dir like? >> http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/5/os/x86_64/CentOS/ > It is really the same than: > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/ > with all the subdirectories? > (well is > http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/4/os/ > the same ?) CentOS (round about) takes the SRPMs, strips/replaces some stuff that is protected (trademarks for example) and rebuilds the SRPMs. Thus the package names and the content should be the same (especially as they are afaik aiming for compatibility in this regard). There are some small differences; CentOS has everything in one repo while in RHEL there are some packages only part of the Client or the Server (for RHEL5 for example; it's similar in RHEL4 afaik). The bottom part of this section http://fedoraproject.org/wiki/EPEL/FAQ#head-f1c2fc524be33cdc730200379a3814c3d80c0203 lists some of those differences. But they are not that important in most cases. HTH CU thl From rob.myers at gtri.gatech.edu Wed Jul 4 13:52:54 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Wed, 04 Jul 2007 09:52:54 -0400 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <4687C867.8060400@leemhuis.info> References: <4687C867.8060400@leemhuis.info> Message-ID: <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> On Sun, 2007-07-01 at 17:29 +0200, Thorsten Leemhuis wrote: > >From this weeks report: > > * _blah_> "i've requested a few packages from fedora maintainers that > have not gotten back to me... what is the next step in getting those > packages into epel?"; knurd mailed the Fedora list about this; > > Find the mail attached. Is that fine for everyone? If yes I'd say we > make this policy in this weeks meeting. it looks good to me. i massaged the wording a bit, below. thanks for putting this together; it is needed. rob. If an EPEL maintainer wants to get a Fedora package into EPEL he should first check the ContributorStatus document, located in the wiki at http://fedoraproject.org/wiki/EPEL/ContributorStatus . If the Fedora maintainer of the package has indicated a desire not to participate in EPEL then the EPEL maintainer can request the branch directly via the standard procedures (e.g. via bugzilla currently). The EPEL maintainer should CC the Fedora maintainer on the branch request, so the Fedora maintainer knows that the package is maintained in EPEL as well. If it's unclear if the Fedora maintainer of the package participates in EPEL then the EPEL maintainer should mail the Fedora maintainer and ask about their plans for EPEL in general and the package at hand. If there is no answer within seven days the EPEL maintainer is free to request the EPEL branch (CC the Fedora maintainer here as well). If the Fedora maintainer later wants to participate in EPEL, then the EPEL maintainer of the package should hand primary per release maintainership back to the Fedora maintainer (and become comaintainer, if interested). From mailing-lists at hughesjr.com Wed Jul 4 13:56:28 2007 From: mailing-lists at hughesjr.com (Johnny Hughes) Date: Wed, 04 Jul 2007 08:56:28 -0500 Subject: Plan for todays (20070704) EPEL SIG meeting In-Reply-To: <468B66B8.8060101@leemhuis.info> References: <468B2753.1070906@leemhuis.info> <20070704074811.GA10397@free.fr> <468B54AF.1090600@leemhuis.info> <20070704090211.GB10397@free.fr> <468B66B8.8060101@leemhuis.info> Message-ID: <468BA70C.2020303@hughesjr.com> Thorsten Leemhuis wrote: > On 04.07.2007 11:02, Patrice Dumas wrote: >> On Wed, Jul 04, 2007 at 10:05:03AM +0200, Thorsten Leemhuis wrote: >>> On 04.07.2007 09:48, Patrice Dumas wrote: > CentOS (round about) takes the SRPMs, strips/replaces some stuff that is > protected (trademarks for example) and rebuilds the SRPMs. Thus the > package names and the content should be the same (especially as they are > afaik aiming for compatibility in this regard). > > There are some small differences; CentOS has everything in one repo > while in RHEL there are some packages only part of the Client or the > Server (for RHEL5 for example; it's similar in RHEL4 afaik). > Also, there are a couple differences (in CentOS-5 we have stripped out the rhn* RPMS that do RHN things to/for yum / purit) ... and redhat-release is named centos-release. Any files that are edited by CentOS for content are ".el5.centos" in the name ... whereas all the files that are built unmodified are labeled exactly as they are in RHEL. For CentOS-3 and CentOS-4 ... files modified by CentOS may have .c3, .c4, .centos3, .centos4, .el3.centos, or .el4.centos. In any event they will have .c3., .c4., or .centos in the name. > The bottom part of this section > http://fedoraproject.org/wiki/EPEL/FAQ#head-f1c2fc524be33cdc730200379a3814c3d80c0203 > lists some of those differences. But they are not that important in most > cases. > > Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From buildsys at fedoraproject.org Wed Jul 4 14:03:14 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 4 Jul 2007 10:03:14 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-04 Message-ID: <20070704140314.E7FF8152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 7 NEW cobbler-0.4.8-1.el5 : Boot server configurator NEW koan-0.4.0-1.el5 : Network provisioning tool for Xen and Bare Metal Machines NEW perl-version-0.7203-1.el5 : Perl extension for Version Objects NEW php-pear-Phlickr-0.2.7-2.el5 : Phlickr is a PHP5 based api kit used with the Flickr API NEW php-spyc-0.2.5-1.el5 : A simple php yaml class NEW R-2.5.1-1.el5.1 : A language for data analysis and graphics NEW uread-0-0.19981218.el5 : Utilities for unformatted fortran files Packages built and released for Fedora EPEL 4: 6 NEW cobbler-0.4.8-1.el4 : Boot server configurator NEW koan-0.4.0-1.el4 : Network provisioning tool for Xen and Bare Metal Machines NEW perl-version-0.7203-1.el4.1 : Perl extension for Version Objects NEW php-spyc-0.2.5-1.el4 : A simple php yaml class NEW R-2.5.1-1.el4.1 : A language for data analysis and graphics NEW uread-0-0.19981218.el4 : Utilities for unformatted fortran files Changes in Fedora EPEL 5: cobbler-0.4.8-1.el5 ------------------- * Thu Apr 26 2007 Michael DeHaan - 0.4.8-1 - Upstream changes (see CHANGELOG) - Fix defattr in spec file koan-0.4.0-1.el5 ---------------- * Thu May 31 2007 Michael DeHaan - 0.4.0-1 - Upstream changes (see CHANGELOG) perl-version-0.7203-1.el5 ------------------------- * Tue Jul 03 2007 Tom "spot" Callaway 1:0.7203-1 - i love perl versioning. bumping to 0.7203 php-pear-Phlickr-0.2.7-2.el5 ---------------------------- * Sat Jun 30 2007 Michael Stahnke - 0.2.7-2 - Upstream URL changed - Sourceforge has project directory lowercased - Bug # 245694 * Tue Jun 26 2007 Michael Stahnke - 0.2.7-1 - Initial Package php-spyc-0.2.5-1.el5 -------------------- * Wed Jun 20 2007 Michael Stahnke - 0.2.5-1 - Initial packaging R-2.5.1-1.el5.1 --------------- * Tue Jul 03 2007 Tom "spot" Callaway 2.5.1-1.1 - fix BR for EL-5 * Mon Jul 02 2007 Tom "spot" Callaway 2.5.1-1 - drop patch, upstream fixed - bump to 2.5.1 uread-0-0.19981218.el5 ---------------------- * Tue Jun 26 2007 Patrice Dumas 0-0.19981218 - use 0 as version and put the timestamp in the release Changes in Fedora EPEL 4: cobbler-0.4.8-1.el4 ------------------- * Thu Apr 26 2007 Michael DeHaan - 0.4.8-1 - Upstream changes (see CHANGELOG) - Fix defattr in spec file koan-0.4.0-1.el4 ---------------- * Thu May 31 2007 Michael DeHaan - 0.4.0-1 - Upstream changes (see CHANGELOG) perl-version-0.7203-1.el4.1 --------------------------- * Tue Jul 03 2007 Tom "spot" Callaway 1:0.7203-1.1 - EL-4 doesn't have M::B... :( * Tue Jul 03 2007 Tom "spot" Callaway 1:0.7203-1 - i love perl versioning. bumping to 0.7203 php-spyc-0.2.5-1.el4 -------------------- * Wed Jun 20 2007 Michael Stahnke - 0.2.5-1 - Initial packaging R-2.5.1-1.el4.1 --------------- * Tue Jul 03 2007 Tom "spot" Callaway 2.5.1-1.1 - fix ppc on EL-4 * Mon Jul 02 2007 Tom "spot" Callaway 2.5.1-1 - drop patch, upstream fixed - bump to 2.5.1 uread-0-0.19981218.el4 ---------------------- * Tue Jun 26 2007 Patrice Dumas 0-0.19981218 - use 0 as version and put the timestamp in the release For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Thu Jul 5 16:55:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 05 Jul 2007 18:55:33 +0200 Subject: Log from yesterdays (20070705) EPEL SIG meeting Message-ID: <468D2285.4070405@leemhuis.info> 00:00:02 < knurd> | Meeting ping dgilmore, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00:02 < knurd> | Hi everybody; who's around? 00:00:02 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00:02 * | knurd likes to remind people that the schedule and the topic list for todays meeting can be found on http://fedoraproject.org/wiki/EPEL/Schedule 00:00:28 * | dgilmore is kinda here 00:00:28 --- | knurd has changed the topic to: EPEL Meeting ? broken deps ? nirik 00:00:37 < knurd> | any process in that area? 00:00:39 --> | stahnma (Michael Stahnke) has joined #fedora-meeting 00:00:48 < Jeff_S> | knurd: can you add my name to your 'ping' so my client beeps at me when I'm not paying attention? :) 00:01:08 < nirik> | knurd: I posted a EL-4 broken deps report... haven't done much else. ;( 00:01:25 < knurd> | Jeff_S, you can add yourself :) see http://fedoraproject.org/wiki/EPEL/Schedule 00:01:40 < nirik> | I think we need to spam maintainers... then I would be happy to try and bug personally people who still have broken deps after a while... 00:01:52 < Jeff_S> | I've meant to run repoclosure or something to verify nirik's results on my EPEL mirror, but somehow haven't got to it yet 00:02:40 < knurd> | well, someone needs to poke maintainers 00:02:43 < nirik> | I finally have local kvm centos4/centos5 virtuals on my laptop, so I should be able to test things and run repoclosure anytime someone wants. 00:02:55 < knurd> | seems otherwise stuff won't get fixed afaics 00:03:05 < knurd> | any volunteers? 00:03:17 < Jeff_S> | yes, I don't have any access to RHEL, but I can run it against CentOS 00:03:38 < knurd> | Jeff_S, that should be enough for the start afaics 00:03:46 * | mmcgrath is looking at spam-o-matic right now actually. 00:04:02 < knurd> | Jeff_S, I'll asign that job to you then? it was nirik's until now 00:04:02 < nirik> | I think most people don't realize they have broken deps... spamming them should help a lot. 00:04:14 --- | knurd has changed the topic to: EPEL Meeting ? spam o magic script ? mmcgrath 00:04:18 < Jeff_S> | knurd: either way 00:04:20 < knurd> | mmcgrath, any progress? 00:04:31 * | mmcgrath is looking at it right now actually. I'll commit to having this done by the next meeting. 00:04:43 < knurd> | mmcgrath, k, thx 00:04:46 < nirik> | I'd be happy to help, but have been very very busy of late... so might be better if Jeff_S takes charge of it and I can help? 00:04:54 < Jeff_S> | nirik: OK 00:04:57 < knurd> | nirik, Jeff_S, some manual poking will probably thee best 00:05:11 < knurd> | nirik, k, I#ll note that on the schedule 00:05:17 < nirik> | sure, but if we can spam and wait a week I think we will have a LOT less of them... 00:05:24 < knurd> | anything else regarding this? 00:05:26 < knurd> | nirik, +1 00:05:45 < Jeff_S> | I agree, spam, spam, spam, eggs and spam 00:06:01 < knurd> | :-) 00:06:06 < nirik> | could we start running a repoclosure before push and not push anything with new broken deps? 00:06:25 < nirik> | I realize that makes it take longer, but we don't want to add to the problem. 00:06:27 < knurd> | nirik, we'd need to modify the push script to do that 00:06:28 < dgilmore> | nirik: no 00:06:50 < dgilmore> | nirik: the scripts are not very smart 00:06:59 < knurd> | nirik, and it takes some time to run, so it would likely take to long 00:07:12 < nirik> | ok, bummer. ;( 00:07:17 < dgilmore> | each time you find a problem they need to be re ran 00:08:08 < knurd> | I'd assume most problems currently happended due to new packages hitting the repo with missing deps 00:08:14 < knurd> | bodhi should help in the long run 00:08:20 < dgilmore> | seems to be the case 00:08:29 < knurd> | I#d say we wait and see for now and watch it closely 00:08:30 < nirik> | yeah, likely so... missing epel versions of packages that are needed by that package 00:08:31 < knurd> | that okay? 00:08:41 < Jeff_S> | knurd: yes, at the very least it'll let us catch things while still in testing/ 00:08:48 < knurd> | Jeff_S, yes 00:08:53 --- | knurd has changed the topic to: EPEL Meeting ? move epel dirs on servers down below stable ? knurd 00:09:00 < knurd> | dgilmore didn't like that 00:09:08 < dgilmore> | ------------------------------------------------------------100000000000000 00:09:16 < quaid> | wow, that's quite negative 00:09:17 < knurd> | see discussion in #epel from some hours ago 00:09:22 * | knurd still wants it 00:09:26 < stahnma> | it's so negative, it's like positive 00:09:29 < Jeff_S> | dgilmore just outvoted all of us I think 00:09:43 * | knurd still wants to have room on the server for other stuff in EPEL, whatever we might do in the long run 00:09:48 < nirik> | we can always do it later can't we? 00:09:54 < dgilmore> | we can do that 00:09:57 < knurd> | nirik, no, I#d say either now or never 00:10:07 < dgilmore> | we should not diverge from what fedora has done forever 00:10:08 < knurd> | such a move after annoucing EPEL would be confusing 00:10:11 < mmcgrath> | :) 00:10:17 < quaid> | well, in this caes, dgilmore actually should have more weight 00:10:36 < knurd> | where would we diverge from what fedora ? 00:10:39 < knurd> | I can't see that 00:10:47 < nirik> | knurd: true, but if we announce a 'rolling' version or something weird we can just call it 'epel-rolling' or something... 00:10:51 * | quaid was not making a "big guy to another big guy" joke 00:11:01 < knurd> | nirik, and it would be a mess on the servers 00:11:27 < nirik> | personally I like the plan we came up with for updates, but then that fits the use case I have. I don't think epel can be all things for all people, we just don't have enough resources to meet all needs. 00:11:40 < dgilmore> | knurd: fedora has never put anything into a stable/ dir stable has always been the main dir 00:11:58 < knurd> | dgilmore, I'm fine with giving it another name 00:12:13 < knurd> | dgilmore, and extras was below some others dirs as well 00:12:15 < mmcgrath> | nirik: very true 00:12:21 < knurd> | that just what I want 00:12:29 < knurd> | mmcgrath, I just want to leave path open 00:12:41 < knurd> | for whatever we want to do 00:12:47 < knurd> | in the future 00:13:04 < knurd> | it a easiy move now 00:13:13 < knurd> | and we can't do it later anymore without big trouble 00:13:17 < dgilmore> | nirik: extras was the product as is epel 00:13:24 < dgilmore> | knurd: ^^ 00:13:41 < knurd> | knurd, yeah, but extras was a product of epel 00:13:50 < knurd> | we are noe epel the repo from epel the sig 00:13:58 < knurd> | so epel/epel/ would be fine as well 00:14:07 < dgilmore> | knurd: no 00:14:14 < dgilmore> | knurd: epel is a product 00:14:19 < dgilmore> | extras was a product 00:14:31 < knurd> | I still want this subdir 00:14:34 < nirik> | knurd: what sort of thing are you seeing that might happen later? totally diffrent branches/repo with rolling release? 00:14:36 < dgilmore> | /epel/ is stable 00:14:43 < knurd> | nirik, yes 00:14:48 < dgilmore> | /epel/testing/ 00:14:57 < nirik> | couldn't that be under /epel/5-rolling/ or whatever? 00:14:58 < knurd> | nirik, some contrinutors indicated that they might want that 00:15:22 < knurd> | nirik, we could, but I'd prefer a more cleaner directory structure 00:15:29 < knurd> | and I'm gettign more and more frustrated 00:15:37 < nirik> | or /epel/rolling/5/ /epel/rolling/4/ etc. 00:15:52 < knurd> | nirik, yes, and /epel/stable/5 00:15:55 * | mmcgrath thinks anything with the word 'rolling' in it will confuse the heck out of a sysadmin that doesn't contribute to fedora. 00:16:05 < nirik> | don't get frustrated... just trying to figure out what you are trying to do... :) 00:16:06 < knurd> | mmcgrath, rolling is just a example 00:16:36 * | mmcgrath likes /epel/ 00:16:38 < knurd> | nirik, just "mkdir stable; mv * stable/" 00:16:40 < dgilmore> | /epel/5/ is stable 00:16:57 < knurd> | or /epel/epel/ 00:16:57 < dgilmore> | mmcgrath: thats how it should be 00:17:08 < knurd> | some subdirectory 00:17:18 < knurd> | so we can do other stuff later 00:17:20 < knurd> | if we want to 00:17:22 < dgilmore> | mmcgrath: that is consistent with the rest of fedora. it is where people will expect it 00:17:34 < knurd> | it does not hurt if we don't want to do other stuff alter 00:17:47 < knurd> | dgilmore, then it should be under fedora/ 00:18:07 < knurd> | but we only have this epel directory 00:18:20 < knurd> | we need that for everything we might want to do sooner or later 00:18:25 < knurd> | whatever that is 00:18:32 < dgilmore> | knurd: we a are fedora product regardless of where its located on the tree 00:18:50 < dgilmore> | knurd: you are over complicating this 00:18:55 < knurd> | dgilmore, you are 00:00:01 < knurd> | the move is a easy thing now 00:00:03 < knurd> | later it's not 00:00:15 < nirik> | knurd: would rolling (or whatever) also depend on stable? or be totally different? 00:00:17 < dgilmore> | by keeping things the same as fedora as users will expect 00:00:24 < knurd> | nirik, not sure 00:00:34 * | mmcgrath wonders how centos does it? 00:00:50 < nirik> | if it depends on stable, then I think it would make sense to have epel/rolling/ like epel/testing/ 00:00:56 < nirik> | and leave the current dirs. 00:01:00 < dgilmore> | mmcgrath: they work like fedora extras did AKAIK 00:01:04 < mmcgrath> | 00:01:16 < nirik> | but if it's seperate, then knurd's moving things would make sense... 00:01:32 < knurd> | nirik, I#d say it could be both at the same time 00:01:35 < nirik> | it's hard to plan for something like this if we don't know what it's going to be. 00:01:43 < knurd> | as I said; we don#t know what we'll do in one or two years from now 00:01:52 < knurd> | a subdir leaves room for other things 00:01:56 < knurd> | whatever they look like 00:21:04 < knurd> | and I#d like to leave that path open 00:21:12 < mmcgrath> | why does leaving a subdir out mean we can't do things? 00:21:27 < knurd> | mmcgrath, it looks confusing on the server 00:21:40 < dgilmore> | knurd: no it doesnt 00:22:03 < knurd> | I thin kit will 00:22:09 < nirik> | I think epel/epel/ would confuse people... epel/stable/ might not be too bad, but would as dgilmore says be different. 00:22:33 < quaid> | knurd: I'll point out that the EPEL guidelines are to be "just like Fedora" unless there is a good reason not to, then we document it, etc. 00:22:50 < dgilmore> | nirik: /epel/ for stable is the sanest approach 00:22:52 < quaid> | so this is adding more than just directory difference, it has to be recorded, taught, etc. 00:23:00 < knurd> | quaid, what has that to do with the guidlines and the directory on the server? 00:23:18 < dgilmore> | knurd: you are wanting to diverge for no good reason 00:23:21 < quaid> | knurd: it sounds like you are asking for something different than the way it is in the rest of Fedora, right? 00:23:25 < quaid> | dgilmore: well ... 00:23:28 < knurd> | quaid, no 00:23:28 < quaid> | dgilmore: he has a good reason 00:23:31 < dgilmore> | we can do what you want without diverging 00:23:34 < quaid> | dgilmore: but he needs to convince others :) 00:23:47 < dgilmore> | quaid: we can do what he wants without changing 00:23:54 < quaid> | ok 00:24:05 < knurd> | quaid, all I want is foo in the url http://download.fedora.redhat.com/pub/epel/foo/5/ 00:24:18 < quaid> | dgilmore: then what are you arguing against? If it's not changing from Fedora ... 00:24:20 < knurd> | so we can do bar, baz, or whatever later 00:24:38 < knurd> | in one, two or fiver years from now 00:24:38 < mmcgrath> | knurd: why couldn't we do bar and baz later without foo? 00:24:48 < dgilmore> | quaid: moving stable elsewhere is diverging 00:25:02 < dgilmore> | there is no reason to do that 00:25:03 < mmcgrath> | even next week I don't see why /epel couldn't contain 4, 5, and testing/ 00:25:23 < knurd> | mmcgrath, if epele does foo, bar and baz, then you would expect them in different dirs 00:25:33 < mmcgrath> | and they are. 00:25:48 < knurd> | mmcgrath, it's like putting extras/ below core/ 00:25:53 < mmcgrath> | /epel/4 /epel/5 /epel/testing/4 /epel/testing/5 /epel/baz/4 /epel/baz/5 00:25:58 < knurd> | mmcgrath, that would be confusing, wound't it? 00:26:19 < quaid> | knurd: why not leave stable in epel/ and if we need a bar version later, do epel/bar/ ? 00:26:23 < knurd> | mmcgrath, it's like putting extras/ below core/ that would be confusing, wounld't it? 00:26:37 < knurd> | quaid, it's like putting extras/ below core/ that would be confusing, wounld't it? 00:26:39 < mmcgrath> | knurd: not to me but whatever. 00:26:47 < quaid> | not me either 00:27:01 < quaid> | I think it's all convention and habit more than anything 00:27:24 < mmcgrath> | knurd: look at this - http://fedora.mirror.iweb.ca/core/ 00:27:29 < dgilmore> | Lets move on because this is not going to get resolved. 00:27:39 < mmcgrath> | knurd: explain how that is confusing? 00:27:46 * | quaid suggests we take the contention to the list where it belongs :) 00:27:48 < dgilmore> | I will not make the proposed changes so someone else would have to do it and take over pushing 00:28:02 < knurd> | mmcgrath, imagine extras would be at http://fedora.mirror.iweb.ca/core/extras 00:28:23 < mmcgrath> | knurd: I'm not talking about extras or any other thing, core was a product, with versions. Epel is a product with versions. 00:28:37 < mmcgrath> | how is http://fedora.mirror.iweb.ca/core/ confusing to you? 00:28:37 < Jeff_S> | quaid: +1 00:28:37 --> | has joined #fedora-meeting 00:28:49 < knurd> | mmcgrath, but foo or bar just like core and extras might be differnet things ,standing for their ow 00:29:01 < knurd> | mising them in one dire would confuse people 00:29:09 < mmcgrath> | if its a different product, then it's not epel. 00:29:37 < nirik> | epel-hide! New packages every day. ;) 00:29:37 < knurd> | why do you guys suddenly don#t want to leave room for the future? 00:29:47 < knurd> | last week you wanted it 00:29:49 < mmcgrath> | http://fedora.mirror.iweb.ca/core/ 00:29:50 < mmcgrath> | http://fedora.mirror.iweb.ca/core/ 00:29:51 < mmcgrath> | http://fedora.mirror.iweb.ca/core/ 00:29:56 < mmcgrath> | Look at it there, seriously 00:30:02 < mmcgrath> | why couldn't epel look exactly like that? 00:30:02 < knurd> | mmcgrath, s 00:30:52 < mmcgrath> | its got development, test, updates. 00:30:57 < mmcgrath> | it could also have other things if it wanted. 00:31:06 < knurd> | mmcgrath, for me epel is like fedora; and core and extras get different dirs in fedora; epel stable and rolling get differnet dirs 00:31:15 < knurd> | mmcgrath, http://fedora.mirror.iweb.ca/extras/ 00:31:18 < knurd> | it's seperate 00:31:21 < mmcgrath> | for me epel is like core or extras. 00:31:41 < mmcgrath> | a fedora product. 00:32:10 --> | rastaman (purple) has joined #fedora-meeting 00:32:21 < rastaman> | irie bredas 00:32:37 < dgilmore> | mmcgrath: +1 00:32:38 < knurd> | k, so let's forget about it 00:32:45 * | knurd is very very disappointed 00:33:09 < knurd> | just one subdir to leave room for other things 00:33:15 < knurd> | what's so complicated about it? 00:33:20 < mmcgrath> | other things like testing, development and updates? 00:33:26 < knurd> | it doesn#t hurt anyone 00:33:36 < rastaman> | hi, this is rastaman 00:33:39 < mmcgrath> | lets move on. 00:33:45 --- | knurd has changed the topic to: EPEL Meeting ? signers group ? dgilmore 00:33:51 < rastaman> | how are u doing? 00:34:09 < mmcgrath> | rastaman: we're having an EPEL meeting right now, feel free to participate if you are interested in EPEL. 00:34:09 < knurd> | rastaman, this is a EPEL meeting, not a random chat channel ;-) 00:34:21 < knurd> | dgilmore ? 00:34:24 < rastaman> | ok 00:34:31 < rastaman> | sorry,, see u later 00:34:35 < knurd> | rastaman, np 00:34:39 < knurd> | rastaman, tanks 00:34:46 < rastaman> | yourwellcome 00:34:55 <-- | rastaman has left #fedora-meeting ( ) 00:35:21 * | knurd sometime wonders if this channel should be named fedora-groupmeetings or something 00:35:41 < knurd> | seem dgilmore left 00:35:43 < nirik> | doubt it would matter. ;) 00:35:46 * | knurd moves on 00:35:55 --- | knurd has changed the topic to: EPEL Meeting ? branch for EPEL if Fedora maintainer does not react ? knurd, _blah_ 00:36:09 < knurd> | _blah_ saind in EPEL that he supports the idea 00:36:13 < knurd> | no other reasction 00:36:17 < knurd> | is the current proposal fine? 00:36:26 < mmcgrath> | seems to have had support 00:36:26 < knurd> | +1 for the current proposal 00:36:41 < dgilmore> | sorry wife came home 00:36:50 < knurd> | dgilmore, np, we can go back to that soon 00:36:59 < nirik> | looks ok to me... +1 here... 00:37:01 < knurd> | other +1 / -1 0 for this? 00:37:20 < knurd> | come on 00:37:23 < mmcgrath> | +1 00:37:25 < knurd> | I#d like to see 4 +1 please 00:37:42 < dgilmore> | im ok with it +1 00:37:48 < knurd> | k, settled then 00:37:48 * | nirik had to go read the last version. ;) 00:37:56 --- | knurd has changed the topic to: EPEL Meeting ? signers group ? dgilmore 00:38:05 < knurd> | dgilmore? 00:38:15 < knurd> | we had that on the list months ago, but it got forgotten 00:38:25 < knurd> | dgilmore, you are the only one with access to the keys atm? 00:38:32 * | mmcgrath notes notting and jesse are creating a whole signing server solution 00:38:42 < mmcgrath> | but it won't be ready for a while me thinks. 00:38:45 < knurd> | knurd, it#s not only signing, also pushing 00:38:52 < dgilmore> | knurd: mmcgrath has access 00:38:54 < mmcgrath> | ahh. 00:39:22 * | mmcgrath has access but hasn't actually pushed yet :) 00:39:24 < knurd> | dgilmore, well, is that enough or do we want/need more pushsigners 00:39:29 < knurd> | ? 00:39:35 < dgilmore> | knurd: right now its enough i think 00:39:37 * | nirik would be happy to help if someone described the procedure. 00:39:42 < knurd> | dgilmore, k 00:39:44 < mmcgrath> | dgilmore: how was extras done? Just with a few people or did we have a fedora account group? 00:39:57 < dgilmore> | mmcgrath: extras_signers group 00:40:06 < dgilmore> | mmcgrath: we have epel_signers 00:40:24 < mmcgrath> | got'cha 00:40:28 < dgilmore> | there is only 4 people that do extras i think 00:40:29 < mmcgrath> | its all coming back to me now :) 00:41:11 < knurd> | I#d remove it from the schedule then? 00:41:21 < knurd> | I remove this topic from the schedule then? 00:41:39 * | knurd takes silence as support 00:41:42 --- | knurd has changed the topic to: EPEL Meeting ? finish the wiki docs and remove the warnings by end of may ? quaid 00:41:50 < knurd> | quaid, everything ready? 00:42:36 < quaid> | well 00:42:41 < quaid> | probably, but I'll still make changes to some stuff 00:42:47 * | quaid looks to see if all the warnings are removed 00:42:54 < quaid> | heh, the top page one ... 00:43:03 < knurd> | leave the top page one until we annouce 00:43:08 < knurd> | but remove the others 00:43:26 < knurd> | or what do the others think about it? 00:43:28 < quaid> | sure, I was actually working the guidelines as the last one last night, so I'll remove it by the end of this meeting 00:43:51 < nirik> | knurd: +1. sounds good to me. 00:43:55 < stahnma> | yup 00:44:22 < knurd> | regarding annouce: 00:44:36 < knurd> | quaid, can you write a press relase and/or a announce mail? 00:44:41 < quaid> | hmm, ok 00:45:03 < quaid> | I'll float a draft by the list, ok/ 00:45:04 < quaid> | ? 00:45:09 < knurd> | quaid, yes, thanks 00:45:11 < knurd> | btw 00:45:24 < knurd> | I set "July 24" as date for the announcement 00:45:32 < mmcgrath> | sounds good to me 00:45:38 < knurd> | other opinions? 00:45:39 < quaid> | ok 00:45:50 < knurd> | do you guys think we are ready by then? 00:45:56 < knurd> | deps soleved, wiki ready? 00:46:01 * | mmcgrath thinks so 00:46:07 < nirik> | sounds ok, I wish we had koji/bodhi, but oh well, we will make due with what we have. 00:46:09 < stahnma> | I am worried about lack of actual packages 00:46:18 < quaid> | how about ... 00:46:25 < stahnma> | in my daily work, I still download and build a LOTS of srpms from extras 00:46:26 < quaid> | an early internal announcement 00:46:27 < stahnma> | for RHEL 00:46:40 < knurd> | stahnma, well, we need to poke maintainers 00:46:49 <-- | Jeff_S has quit (Read error: 113 (No route to host)) 00:46:50 < knurd> | especially those with lots of packages 00:46:54 < nirik> | stahnma: yeah, I think there are some people who are waiting for offical open, or don't know about it. 00:46:57 < quaid> | we can do an announcement on 10 July 00:46:57 < stahnma> | can we do that for while before you officially open? 00:47:02 < nirik> | we are getting close to 1000 packages. 00:47:04 < quaid> | saying we're opening the doors on 24 July 00:47:13 * | stahnma would like all perl modules plz :) 00:47:30 < quaid> | the 10 July would go to maintainers, devel-announce 00:47:41 < knurd> | 10 July? 00:47:58 < knurd> | ohh, sorry, missed that line 00:48:17 < knurd> | quaid, yeah, sounds fine 00:48:35 < nirik> | that sounds ok, but will mean we will need to really get working on fixing broken deps... 00:48:39 < knurd> | we likely should adjust the push target to testing before 24 July 00:48:46 < quaid> | 07 July - early announce draft to epel-devel-l 00:48:46 < quaid> | 10 July - early announce to maintainers 00:48:46 < quaid> | 14 July - first draft of real announcement to e-d-l 00:48:46 < quaid> | 20 July - real announcement complete 00:48:47 < quaid> | 24 July - announcement 00:48:47 < knurd> | so the new stuff lands in testing 00:48:55 < quaid> | use that as a skel 00:48:57 < knurd> | quaid, +1 00:49:01 < quaid> | for when to fix stuff by 00:49:11 < stahnma> | +1 00:49:33 < dgilmore> | quaid: id like to announce on Jul 19 00:49:58 * | knurd is fine with that as well 00:50:17 < knurd> | dgilmore, just wondering: why? 00:50:56 < dgilmore> | knurd: its a thursday whihc matches fedora release policy and i think the 26th is too long 00:51:36 < knurd> | dgilmore, I thought Fedora only announces Tuesdays to Thursdays? 00:51:38 * | nirik doesn't much care, as long as we have a clean repo ready. :) 00:51:48 < knurd> | and hta maily due to mirrors be able to sync? 00:51:53 < knurd> | which is not important for us 00:52:35 < dgilmore> | knurd: only Thursdays 00:53:25 < dgilmore> | tuesday freeze for a release the following thursday 00:53:31 < dgilmore> | its cosmetic 00:53:40 < knurd> | dgilmore, FC6 was a tuesday 00:53:47 < quaid> | rockin', np 00:53:48 < knurd> | 20061024 00:53:55 < knurd> | btu whatever 00:54:00 * | quaid recalls there was a reason for that one 00:54:01 < knurd> | I'm fine with Thursday 00:54:04 < dgilmore> | knurd: yes but its been refined since then 00:54:05 < quaid> | but I don't remembe what :) 00:54:47 < knurd> | quaid, is 19 July fine for you as well? 00:55:15 < knurd> | quaid, I'd like to offload the annouce mail and press relase to you because you are a native english speaker 00:55:51 < quaid> | knurd: 19 July is fine, I just adjusted the dates 00:55:56 < knurd> | quaid, k 00:55:57 < quaid> | that means I'll send drafts this weekend to th elist 00:56:02 < quaid> | as for press release... 00:56:11 < quaid> | we really don't have that as part of Fedora stuff 00:56:26 < quaid> | that is, we don't have a way to e.g. release something on Business Wire 00:56:43 < knurd> | some kind of document somewhere would be neough I#d say 00:56:52 < quaid> | just curious if we wanted that level of attention 00:56:59 < knurd> | good question 00:57:00 < quaid> | and I don't think we can get it easily :) 00:57:24 < quaid> | one thing that we can do is write the announcement using the 'press-release' module, so it can easily be translated. 00:57:39 < quaid> | ok, I'm good from here, just being semantic :) 00:57:47 < knurd> | wk 00:57:48 < knurd> | k 00:57:57 <-- | No5251 has quit (Read error: 104 (Connection reset by peer)) 00:58:02 --- | knurd has changed the topic to: EPEL Meeting ? RHX and EPEL ? quaid 00:58:13 < knurd> | quaid, f13 said you know about that stuff? 00:58:25 * | knurd sill does not fully understand RHX 00:58:54 < mmcgrath> | knurd: I'm not sure anyone fully understands it yet :) 00:58:59 < knurd> | :-) 00:59:17 < mmcgrath> | knurd: I think the point is trying to get those RHX applications that could be in EPEL space, in EPEL space. 00:59:22 < knurd> | but I tend to say tha apps that are in RHX should be able to be in EPEL as well 00:59:23 < dgilmore> | knurd: its a place for people to make there software available for rhel with paid support 00:59:38 < quaid> | sorry, back 00:59:38 < knurd> | mmcgrath, +1 00:59:52 < quaid> | ok, here's the status ... 00:59:56 < mmcgrath> | Its mostly just that some of those groups will want to release software somehow and we already have systems in place to do it. 01:00:02 < dgilmore> | we should try to work it so that Free and open source software in RHX is available in EPEL with community support 01:00:14 * | quaid reads opinions 01:00:20 < nirik> | dgilmore: +1 01:00:29 < stahnma> | +1 01:00:35 < knurd> | dgilmore, +1 01:00:42 < quaid> | I doubt we'll have any problem with that idea 01:01:00 < quaid> | I think the RHX folks feel the same; they have no need to duplicate what we do for no reason, and lose the gain of the community 01:01:16 < quaid> | it's going to be a few weeks until we can get a formal set of guidelines between the two groups 01:01:48 < quaid> | mainly it's about the messaging, making sure that it's easy to know the difference between a package from EPEL and one from RHX 01:02:06 < quaid> | I made the point that ISVs can control that best if the ... actually own the package in Fedora :) 01:02:13 < knurd> | :-) 01:02:15 < quaid> | so, I think it's all mainly details 01:02:20 < knurd> | quaid, I just leave it on the schedule 01:02:27 < quaid> | cool 01:02:31 < knurd> | quaid, should we discuss it on the list? 01:02:35 < knurd> | or was this discussion enough? 01:02:46 * | mmcgrath thinks the list would be good so we have something to point isv's at when they come around. 01:02:50 < quaid> | I'll update next week, but it will be a few until we have guidelines 01:02:51 < knurd> | mmcgrath, +1 01:02:52 < mmcgrath> | some might be around now and just not speaking up :) 01:03:05 < quaid> | ok, I can send an update to the list at some point soon 01:03:09 < knurd> | quaid, thx 01:03:18 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 01:03:22 < mmcgrath> | quaid: are you in a position where you could contact the RHX ISV's and ask them to join th eepel list? 01:03:24 < knurd> | it's getting late 01:03:36 < knurd> | anything else that can't wait till next week? 01:03:46 * | stahnma needs to leave 01:03:48 * | mmcgrath has nothing 01:03:49 < quaid> | mmcgrath: that's for Huff to do, ultimately 01:03:58 * | dgilmore has to travel for work July 16-26 any probably wont be available much during that time 01:04:04 < quaid> | mmcgrath: but also, I am going to hook up with the ISV partner marketing people, so we are hitting them from all angles 01:04:20 < quaid> | I expect actual ISV communication to be slow and trickly 01:04:29 < quaid> | we might want to make a wishlist of who to talk to first 01:04:33 < mmcgrath> | cool 01:04:34 < quaid> | I know dgilmore wants Zimbra :) 01:04:40 < dgilmore> | quaid: zimbra :) 01:04:56 < mmcgrath> | heh 01:04:56 --> | llaumgui (LLaumgui) has joined #fedora-meeting 01:04:57 * | quaid has Alfresco on his wishlist 01:05:14 * | knurd will close the meeting in 30 01:05:29 * | knurd will close the meeting in 15 01:05:44 < knurd> | -- MARK -- Meeting end From buildsys at fedoraproject.org Fri Jul 6 13:13:51 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 6 Jul 2007 09:13:51 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-06 Message-ID: <20070706131351.44DD2152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 18 NEW blacs-1.1-24.el5.1 : Basic Linear Algebra Communication Subprograms NEW cronolog-1.6.2-5.el5 : Web log rotation program for Apache NEW dar-2.3.4-1.el5 : Software for making/restoring incremental CD/DVD backups NEW dx-4.4.4-3.el5 : Open source version of IBM's Visualization Data Explorer NEW eclipse-subclipse-1.2.2-2.el5 : Subversion Eclipse plugin NEW gxemul-0.4.6-1.el5 : Instruction-level machine emulator NEW itk-3.3-0.4.RC1.el5 : Object oriented extensions to Tk NEW iwidgets-4.0.1-4.el5 : A set of useful widgets based on itcl and itk NEW jam-2.5-4.el5 : Program construction tool, similar to make NEW lapack-3.1.1-1.el5 : The LAPACK libraries for numerical linear algebra. NEW perl-Lingua-EN-Inflect-1.89-4.el5 : Convert singular to plural, select "a" or "an" NEW perl-Lingua-EN-Inflect-Number-1.1-5.el5 : Force number of words to singular or plural NEW planet-2.0-3.el5 : Flexible RDF/RSS/Atom feed aggregator NEW R-hdf5-1.6.6-1.el5 : Interface to the NCSA HDF5 library NEW R-RScaLAPACK-0.5.1-9.el5 : An interface to perform parallel computation on linear algebra problems using ScaLAPACK NEW scalapack-1.7.5-1.el5 : A subset of LAPACK routines redesigned for heterogenous computing NEW trac-git-plugin-0.0.1-3.20070705svn1536.el5 : GIT version control plugin for Trac NEW trac-mercurial-plugin-0.10.0.2-3.20070705svn5798.el5 : Mercurial plugin for Trac Packages built and released for Fedora EPEL 4: 6 NEW gxemul-0.4.6-1.el4 : Instruction-level machine emulator NEW jam-2.5-4.el4 : Program construction tool, similar to make NEW perl-Lingua-EN-Inflect-1.89-3.el4 : Convert singular to plural, select "a" or "an" NEW perl-Lingua-EN-Inflect-Number-1.1-4.el4 : Force number of words to singular or plural NEW trac-git-plugin-0.0.1-3.20070705svn1536.el4 : GIT version control plugin for Trac NEW trac-mercurial-plugin-0.10.0.2-3.20070705svn5798.el4 : Mercurial plugin for Trac Changes in Fedora EPEL 5: blacs-1.1-24.el5.1 ------------------ * Wed Dec 20 2006 Tom "spot" Callaway 1.1-24.1 - updated bmake files to include new lam-devel header path cronolog-1.6.2-5.el5 -------------------- * Thu Jul 05 2007 Sean Reifschneider 1.6.2-5 - Included patch for LARGEFILE support, fix provided by Arenas Belon, Carlo Marcelo. dar-2.3.4-1.el5 --------------- * Tue Jul 03 2007 Chris Petersen 2.3.4-1 - Update to 2.3.4 dx-4.4.4-3.el5 -------------- * Wed Jul 04 2007 Dominik Mierzejewski 4.4.4-3 - fix menu icon transparency (#207841) - drop redundant BRs - fix some rpmlint warnings - build against openmotif for EL-5 eclipse-subclipse-1.2.2-2.el5 ----------------------------- * Wed Jun 20 2007 Robert Marcano 1.2.2-2 - Update to upstream 1.2.2 - Dependency changed from javasvn to svnkit - Patch to support EPEL5 sent by Rob Myers gxemul-0.4.6-1.el5 ------------------ * Thu Jul 05 2007 Tom "spot" Callaway 0.4.6-1 - bump to 0.4.6 itk-3.3-0.4.RC1.el5 ------------------- * Mon Aug 28 2006 Wart - 3.3-0.4.RC1 - Rebuild for Fedora Extras iwidgets-4.0.1-4.el5 -------------------- * Mon Aug 28 2006 Wart - 4.0.1-4 - Rebuild for Fedora Extras jam-2.5-4.el5 ------------- * Mon Sep 11 2006 Tom "spot" Callaway 2.5-4 - fix minimal BR from bison to byacc - rebuild for FC-6 lapack-3.1.1-1.el5 ------------------ * Fri May 25 2007 Tom "spot" Callaway 3.1.1-1 - bump to 3.1.1 perl-Lingua-EN-Inflect-1.89-4.el5 --------------------------------- * Fri Sep 15 2006 Tom "spot" Callaway 1.89-4 - bump for fc6 perl-Lingua-EN-Inflect-Number-1.1-5.el5 --------------------------------------- * Fri Sep 15 2006 Tom "spot" Callaway 1.1-5 - bump for fc6 planet-2.0-3.el5 ---------------- * Mon Dec 11 2006 Richard Dawe - 2.0-3 - Bugfix: "BuildRequires: python-devel" is needed for python 2.5 update. - Include dist tag in release. R-hdf5-1.6.6-1.el5 ------------------ * Thu Jul 05 2007 Tom "spot" Callaway 1.6.6-1 - bump to 1.6.6 R-RScaLAPACK-0.5.1-9.el5 ------------------------ * Fri Mar 30 2007 Tom "spot" Callaway 0.5.1-9 - include bitsize specific lam include directory scalapack-1.7.5-1.el5 --------------------- * Thu Jan 18 2007 Tom "spot" Callaway 1.7.5-1 - bump to 1.7.5 trac-git-plugin-0.0.1-3.20070705svn1536.el5 ------------------------------------------- * Thu Jul 05 2007 Jesse Keating - 0.0.1-3.20070705svn1536 - Require trac and python-setuptools as well * Thu Jul 05 2007 Jesse Keating - 0.0.1-2.20070705svn1536 - Require git-core * Thu Jul 05 2007 Jesse Keating - 0.0.1-1.20070705svn1536 - Initial build trac-mercurial-plugin-0.10.0.2-3.20070705svn5798.el5 ---------------------------------------------------- * Thu Jul 05 2007 Jesse Keating - 0.10.0.2-3.20070705svn5798 - Require trac, python-setuptools as well * Thu Jul 05 2007 Jesse Keating - 0.10.0.2-2.20070705svn5798 - Require mercurial * Thu Jul 05 2007 Jesse Keating - 0.10.0.2-1.20070705svn5798 - Initial build Changes in Fedora EPEL 4: gxemul-0.4.6-1.el4 ------------------ * Thu Jul 05 2007 Tom "spot" Callaway 0.4.6-1 - bump to 0.4.6 jam-2.5-4.el4 ------------- * Mon Sep 11 2006 Tom "spot" Callaway 2.5-4 - fix minimal BR from bison to byacc - rebuild for FC-6 perl-Lingua-EN-Inflect-1.89-3.el4 --------------------------------- * Fri Jul 29 2005 Tom "spot" Callaway 1.89-3 - chmod -x files that don't need to be executable (hooray upstream) - own Lingua directory correctly perl-Lingua-EN-Inflect-Number-1.1-4.el4 --------------------------------------- * Mon Apr 24 2006 Tom "spot" Callaway 1.1-4 - confirmed license with upstream author trac-git-plugin-0.0.1-3.20070705svn1536.el4 ------------------------------------------- * Thu Jul 05 2007 Jesse Keating - 0.0.1-3.20070705svn1536 - Require trac and python-setuptools as well * Thu Jul 05 2007 Jesse Keating - 0.0.1-2.20070705svn1536 - Require git-core * Thu Jul 05 2007 Jesse Keating - 0.0.1-1.20070705svn1536 - Initial build trac-mercurial-plugin-0.10.0.2-3.20070705svn5798.el4 ---------------------------------------------------- * Thu Jul 05 2007 Jesse Keating - 0.10.0.2-3.20070705svn5798 - Require trac, python-setuptools as well * Thu Jul 05 2007 Jesse Keating - 0.10.0.2-2.20070705svn5798 - Require mercurial * Thu Jul 05 2007 Jesse Keating - 0.10.0.2-1.20070705svn5798 - Initial build For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Jul 7 00:19:33 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 6 Jul 2007 20:19:33 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-06 Message-ID: <20070707001933.DA053152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 4 NEW php-pear-Mail-Mime-1.4.0-1.el5 : Classes to create and decode mime messages (!) planet-2.0-3.el5 : INVALID rebuild, not published! R-2.5.1-2.el5 ushare-1.0-1.el5 Packages built and released for Fedora EPEL 4: 2 R-2.5.1-2.el4 ushare-1.0-1.el4 Changes in Fedora EPEL 5: php-pear-Mail-Mime-1.4.0-1.el5 ------------------------------ * Wed May 16 2007 Brandon Holbrook 1.4.0-1 - Upgraded to 1.4.0 planet-2.0-3.el5 ---------------- * Mon Dec 11 2006 Richard Dawe - 2.0-3 - Bugfix: "BuildRequires: python-devel" is needed for python 2.5 update. - Include dist tag in release. R-2.5.1-2.el5 ------------- * Thu Jul 05 2007 Tom "spot" Callaway 2.5.1-2 - add rpm helper macros, script ushare-1.0-1.el5 ---------------- * Fri Jul 06 2007 Eric Tanguy - 1.0-1 - Update to 1.0 * Tue Jun 26 2007 Eric Tanguy - 0.9.10-4 - Rebuild Changes in Fedora EPEL 4: R-2.5.1-2.el4 ------------- * Thu Jul 05 2007 Tom "spot" Callaway 2.5.1-2 - add rpm helper macros, script ushare-1.0-1.el4 ---------------- * Fri Jul 06 2007 Eric Tanguy - 1.0-1 - Update to 1.0 * Tue Jun 26 2007 Eric Tanguy - 0.9.10-4 - Rebuild For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From sheltren at cs.ucsb.edu Sat Jul 7 13:11:17 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 7 Jul 2007 09:11:17 -0400 Subject: EPEL 4 Dependency Report Message-ID: Here's a list of broken deps in EPEL-4 i386 and x86_64. If you own a package which has broken deps, please see about having the Fedora maintainer for the dependency build it for EPEL, or if they are not interested you could also become a co-maintainer of the needed package (s). If you notice any errors in the dep checking, please let me know. Thanks, Jeff Broken deps in EPEL-4 i386 (looking at CentOS-4 base/updates and EPEL-4) -------------------- package: JSDoc - 1.10.2-3.el4.noarch from epel4-i386 unresolved deps: perl(HTML::Template) package: SDL_mixer - 1.2.6-8.el4.i386 from epel4-i386 unresolved deps: timidity++ package: bcfg2 - 0.9.4-2.el4.noarch from epel4-i386 unresolved deps: python-lxml package: bugzilla - 2.22.2-1.el4.noarch from epel4-i386 unresolved deps: perl(Date::Parse) perl(MIME::Parser) perl(Date::Format) perl(Template::Stash) graphviz package: bugzilla-contrib - 2.22.2-1.el4.noarch from epel4-i386 unresolved deps: perl(MIME::Parser) package: cobbler - 0.4.8-1.el4.noarch from epel4-i386 unresolved deps: python-cheetah yum-utils package: ctapi-cyberjack - 3.0.0-3.el4.i386 from epel4-i386 unresolved deps: /usr/lib/ctapi package: fail2ban - 0.6.2-3.el4.noarch from epel4-i386 unresolved deps: shorewall package: git-arch - 1.5.2.1-2.el4.i386 from epel4-i386 unresolved deps: tla package: git-cvs - 1.5.2.1-2.el4.i386 from epel4-i386 unresolved deps: cvsps package: mimedefang - 2.62-2.el4.i386 from epel4-i386 unresolved deps: perl(MIME::Tools) >= 0:5.410 perl(MIME::Base64) >= 0:3.03 perl(MIME::Parser) perl(MIME::Words) package: mock - 0.7.2-1.el4.i386 from epel4-i386 unresolved deps: yum >= 0:3.0 package: nagios-plugins-fping - 1.4.6-3.el4.i386 from epel4-i386 unresolved deps: /usr/sbin/fping package: nagios-plugins-game - 1.4.6-3.el4.i386 from epel4-i386 unresolved deps: qstat package: nagios-plugins-ifoperstatus - 1.4.6-3.el4.i386 from epel4-i386 unresolved deps: perl(Net::SNMP) package: nagios-plugins-ifstatus - 1.4.6-3.el4.i386 from epel4-i386 unresolved deps: perl(Net::SNMP) package: otrs - 2.1.5-2.el4.noarch from epel4-i386 unresolved deps: perl(MIME::Entity) perl(Compress::Zlib) perl(Date::Pcalc) perl-GDGraph perl(MIME::Parser) perl(MIME::Words) package: perl-MailTools - 1.77-1.el4.noarch from epel4-i386 unresolved deps: perl(Date::Parse) perl(Date::Format) package: perl-Net-Server - 0.96-1.el4.noarch from epel4-i386 unresolved deps: perl(IO::Multiplex) package: perl-SOAP-Lite - 0.68-5.el4.noarch from epel4-i386 unresolved deps: perl(MIME::Lite) package: perl-libwhisker2 - 2.4-3.el4.noarch from epel4-i386 unresolved deps: perl(Net::SSLeay) perl(MD5) package: postgresql-dbi-link - 2.0.0-3.el4.noarch from epel4-i386 unresolved deps: perl-DBI >= 0:1.52 package: postgresql-pgpoolAdmin - 1.0.0-6.el4.noarch from epel4-i386 unresolved deps: php >= 0:4.4.2 php-pgsql >= 0:4.4.2 package: python-Coherence - 0.2.1-3.el4.noarch from epel4-i386 unresolved deps: SOAPpy python-configobj python-twisted-core python-nevow python-twisted-web package: python-psycopg2-zope - 2.0.6-1.el4.i386 from epel4-i386 unresolved deps: zope package: qucs - 0.0.12-2.el4.i386 from epel4-i386 unresolved deps: iverilog package: redet - 8.22-4.el4.noarch from epel4-i386 unresolved deps: iwidgets package: specto - 0.2.0-4.el4.noarch from epel4-i386 unresolved deps: notify-python package: sqlgrey - 1.7.5-1.el4.noarch from epel4-i386 unresolved deps: perl(DBD::SQLite) package: zabbix - 1.1.7-1.el4.i386 from epel4-i386 unresolved deps: fping Broken deps in EPEL-4 x86_64 (looking at CentOS-4 base/updates and EPEL-4) -------------------- package: JSDoc - 1.10.2-3.el4.noarch from epel4-x86_64 unresolved deps: perl(HTML::Template) package: SDL_mixer - 1.2.6-8.el4.i386 from epel4-x86_64 unresolved deps: timidity++ package: SDL_mixer - 1.2.6-8.el4.x86_64 from epel4-x86_64 unresolved deps: timidity++ package: bcfg2 - 0.9.4-2.el4.noarch from epel4-x86_64 unresolved deps: python-lxml package: bugzilla - 2.22.2-1.el4.noarch from epel4-x86_64 unresolved deps: perl(Date::Parse) perl(MIME::Parser) perl(Date::Format) perl(Template::Stash) graphviz package: bugzilla-contrib - 2.22.2-1.el4.noarch from epel4-x86_64 unresolved deps: perl(MIME::Parser) package: cobbler - 0.4.8-1.el4.noarch from epel4-x86_64 unresolved deps: python-cheetah yum-utils package: ctapi-cyberjack - 3.0.0-3.el4.i386 from epel4-x86_64 unresolved deps: /usr/lib/ctapi package: ctapi-cyberjack - 3.0.0-3.el4.x86_64 from epel4-x86_64 unresolved deps: /usr/lib64/ctapi package: fail2ban - 0.6.2-3.el4.noarch from epel4-x86_64 unresolved deps: shorewall package: ghex - 2.8.2-4.el4.i386 from epel4-x86_64 unresolved deps: libbonoboui-2.so.0 libgnomeui-2.so.0 package: git-arch - 1.5.2.1-2.el4.x86_64 from epel4-x86_64 unresolved deps: tla package: git-cvs - 1.5.2.1-2.el4.x86_64 from epel4-x86_64 unresolved deps: cvsps package: libgnomeuimm26 - 2.8.0-1.el4.i386 from epel4-x86_64 unresolved deps: libbonoboui-2.so.0 libgnomeui-2.so.0 package: mimedefang - 2.62-2.el4.x86_64 from epel4-x86_64 unresolved deps: perl(MIME::Tools) >= 0:5.410 perl(MIME::Base64) >= 0:3.03 perl(MIME::Parser) perl(MIME::Words) package: mock - 0.7.2-1.el4.x86_64 from epel4-x86_64 unresolved deps: yum >= 0:3.0 package: nagios - 2.9-1.el4.i386 from epel4-x86_64 unresolved deps: libperl.so package: nagios-plugins-fping - 1.4.6-3.el4.x86_64 from epel4-x86_64 unresolved deps: /usr/sbin/fping package: nagios-plugins-game - 1.4.6-3.el4.x86_64 from epel4-x86_64 unresolved deps: qstat package: nagios-plugins-ifoperstatus - 1.4.6-3.el4.x86_64 from epel4- x86_64 unresolved deps: perl(Net::SNMP) package: nagios-plugins-ifstatus - 1.4.6-3.el4.x86_64 from epel4-x86_64 unresolved deps: perl(Net::SNMP) package: openoffice.org2-pyuno - 1:2.0.4-5.7.0.i386 from el4update- x86_64 unresolved deps: libpython2.3.so.1.0 package: otrs - 2.1.5-2.el4.noarch from epel4-x86_64 unresolved deps: perl(MIME::Entity) perl(Compress::Zlib) perl(Date::Pcalc) perl-GDGraph perl(MIME::Parser) perl(MIME::Words) package: perl-MailTools - 1.77-1.el4.noarch from epel4-x86_64 unresolved deps: perl(Date::Parse) perl(Date::Format) package: perl-Net-Server - 0.96-1.el4.noarch from epel4-x86_64 unresolved deps: perl(IO::Multiplex) package: perl-SOAP-Lite - 0.68-5.el4.noarch from epel4-x86_64 unresolved deps: perl(MIME::Lite) package: perl-libwhisker2 - 2.4-3.el4.noarch from epel4-x86_64 unresolved deps: perl(Net::SSLeay) perl(MD5) package: postgresql-dbi-link - 2.0.0-3.el4.noarch from epel4-x86_64 unresolved deps: perl-DBI >= 0:1.52 package: postgresql-pgpoolAdmin - 1.0.0-6.el4.noarch from epel4-x86_64 unresolved deps: php >= 0:4.4.2 php-pgsql >= 0:4.4.2 package: python-Coherence - 0.2.1-3.el4.noarch from epel4-x86_64 unresolved deps: SOAPpy python-configobj python-twisted-core python-nevow python-twisted-web package: python-psycopg2-zope - 2.0.6-1.el4.x86_64 from epel4-x86_64 unresolved deps: zope package: qucs - 0.0.12-2.el4.x86_64 from epel4-x86_64 unresolved deps: iverilog package: redet - 8.22-4.el4.noarch from epel4-x86_64 unresolved deps: iwidgets package: specto - 0.2.0-4.el4.noarch from epel4-x86_64 unresolved deps: notify-python package: sqlgrey - 1.7.5-1.el4.noarch from epel4-x86_64 unresolved deps: perl(DBD::SQLite) package: zabbix - 1.1.7-1.el4.x86_64 from epel4-x86_64 unresolved deps: fping From sheltren at cs.ucsb.edu Sat Jul 7 13:15:06 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 7 Jul 2007 09:15:06 -0400 Subject: EPEL 5 Dependency Report Message-ID: <52A25C5E-12C6-48A1-AE15-C360719E6942@cs.ucsb.edu> Here's a list of broken deps in EPEL-4 i386 and x86_64. If you own a package which has broken deps, please see about having the Fedora maintainer for the dependency build it for EPEL, or if they are not interested you could also become a co-maintainer of the needed package (s). If you notice any errors in the dep checking, please let me know. Thanks, Jeff Broken deps in EPEL-5 i386 (looking at CentOS-5 base/updates and EPEL-5) -------------------- package: JSDoc - 1.10.2-3.el5.noarch from epel5-i386 unresolved deps: perl(HTML::Template) package: SDL_mixer - 1.2.7-2.el5.i386 from epel5-i386 unresolved deps: timidity++ package: bcfg2 - 0.9.4-2.el5.noarch from epel5-i386 unresolved deps: python-lxml package: bugzilla - 3.0-2.el5.noarch from epel5-i386 unresolved deps: perl(Email::Send) perl(Email::Reply) perl-Template-Toolkit perl-Email-Reply perl-Email-MIME-Modifier perl-Email-MIME-Attachment-Stripper perl-Email-MIME perl(Email::MIME::Attachment::Stripper) perl-Email-Address perl-Email-Send perl(Email::MIME) perl(Template::Config) perl(Template::Stash) perl(Email::MIME::Modifier) perl-Email-Simple perl(Email::Address) package: ctapi-cyberjack - 3.0.0-2.el5.i386 from epel5-i386 unresolved deps: /usr/lib/ctapi package: eggdrop - 1.6.18-7.el5.i386 from epel5-i386 unresolved deps: libdns.so.21 package: evolution-bogofilter - 0.2.0-5.el5.1.i386 from epel5-i386 unresolved deps: bogofilter package: fail2ban - 0.6.2-3.el5.noarch from epel5-i386 unresolved deps: shorewall package: git-arch - 1.5.2.1-2.el5.i386 from epel5-i386 unresolved deps: tla package: git-cvs - 1.5.2.1-2.el5.i386 from epel5-i386 unresolved deps: cvsps package: nagios-plugins-fping - 1.4.6-3.el5.i386 from epel5-i386 unresolved deps: /usr/sbin/fping package: nagios-plugins-game - 1.4.6-3.el5.i386 from epel5-i386 unresolved deps: qstat package: nagios-plugins-ifoperstatus - 1.4.6-3.el5.i386 from epel5-i386 unresolved deps: perl(Net::SNMP) package: nagios-plugins-ifstatus - 1.4.6-3.el5.i386 from epel5-i386 unresolved deps: perl(Net::SNMP) package: ntfs-config - 1.0-0.4.rc5.el5.noarch from epel5-i386 unresolved deps: ntfs-3g package: perl-Module-Build - 0.2807-1.el5.noarch from epel5-i386 unresolved deps: perl(Pod::Readme) >= 0:0.04 package: perl-Net-Pcap - 0.14-2.el5.i386 from epel5-i386 unresolved deps: perl(IO::Interface) package: perl-SOAP-Lite - 0.68-4.el5.noarch from epel5-i386 unresolved deps: perl(MQSeries::QueueManager) perl(MQSeries::Queue) perl(MQSeries::Message) perl(MQClient::MQSeries) perl(MQSeries) package: perl-Test-Base - 0.53-1.el5.noarch from epel5-i386 unresolved deps: perl(Module::Install::Base) package: perl-libwhisker2 - 2.4-3.el5.noarch from epel5-i386 unresolved deps: perl(MD5) package: php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch from epel5-i386 unresolved deps: php-mcrypt php-mhash package: phpdoc - 1.3.2-1.el5.noarch from epel5-i386 unresolved deps: php-pear(PhpDocumentor) = 0:1.3.2-1.el5 package: python-Coherence - 0.2.1-3.el5.noarch from epel5-i386 unresolved deps: SOAPpy python-twisted-core python-nevow python-twisted-web package: qucs - 0.0.12-2.el5.i386 from epel5-i386 unresolved deps: iverilog package: redet - 8.22-4.el5.noarch from epel5-i386 unresolved deps: iwidgets package: translate-toolkit - 0.10.1-1.el5.noarch from epel5-i386 unresolved deps: python-enchant package: zabbix - 1.1.7-1.el5.i386 from epel5-i386 unresolved deps: fping Broken deps in EPEL-5 x86_64 (looking at CentOS-5 base/updates and EPEL-5) -------------------- package: JSDoc - 1.10.2-3.el5.noarch from epel5-x86_64 unresolved deps: perl(HTML::Template) package: SDL_mixer - 1.2.7-2.el5.i386 from epel5-x86_64 unresolved deps: timidity++ package: SDL_mixer - 1.2.7-2.el5.x86_64 from epel5-x86_64 unresolved deps: timidity++ package: bcfg2 - 0.9.4-2.el5.noarch from epel5-x86_64 unresolved deps: python-lxml package: bugzilla - 3.0-2.el5.noarch from epel5-x86_64 unresolved deps: perl(Email::Send) perl(Email::Reply) perl-Template-Toolkit perl-Email-Reply perl-Email-MIME-Modifier perl-Email-MIME-Attachment-Stripper perl-Email-MIME perl(Email::MIME::Attachment::Stripper) perl-Email-Address perl-Email-Send perl(Email::MIME) perl(Template::Config) perl(Template::Stash) perl(Email::MIME::Modifier) perl-Email-Simple perl(Email::Address) package: ctapi-cyberjack - 3.0.0-2.el5.i386 from epel5-x86_64 unresolved deps: /usr/lib/ctapi package: ctapi-cyberjack - 3.0.0-2.el5.x86_64 from epel5-x86_64 unresolved deps: /usr/lib64/ctapi package: eggdrop - 1.6.18-7.el5.x86_64 from epel5-x86_64 unresolved deps: libdns.so.21()(64bit) package: evolution-bogofilter - 0.2.0-5.el5.1.x86_64 from epel5-x86_64 unresolved deps: bogofilter package: fail2ban - 0.6.2-3.el5.noarch from epel5-x86_64 unresolved deps: shorewall package: git-arch - 1.5.2.1-2.el5.x86_64 from epel5-x86_64 unresolved deps: tla package: git-cvs - 1.5.2.1-2.el5.x86_64 from epel5-x86_64 unresolved deps: cvsps package: nagios-plugins-fping - 1.4.6-3.el5.x86_64 from epel5-x86_64 unresolved deps: /usr/sbin/fping package: nagios-plugins-game - 1.4.6-3.el5.x86_64 from epel5-x86_64 unresolved deps: qstat package: nagios-plugins-ifoperstatus - 1.4.6-3.el5.x86_64 from epel5- x86_64 unresolved deps: perl(Net::SNMP) package: nagios-plugins-ifstatus - 1.4.6-3.el5.x86_64 from epel5-x86_64 unresolved deps: perl(Net::SNMP) package: ntfs-config - 1.0-0.4.rc5.el5.noarch from epel5-x86_64 unresolved deps: ntfs-3g package: perl-Module-Build - 0.2807-1.el5.noarch from epel5-x86_64 unresolved deps: perl(Pod::Readme) >= 0:0.04 package: perl-Net-Pcap - 0.14-2.el5.x86_64 from epel5-x86_64 unresolved deps: perl(IO::Interface) package: perl-SOAP-Lite - 0.68-4.el5.noarch from epel5-x86_64 unresolved deps: perl(MQSeries::QueueManager) perl(MQSeries::Queue) perl(MQSeries::Message) perl(MQClient::MQSeries) perl(MQSeries) package: perl-Test-Base - 0.53-1.el5.noarch from epel5-x86_64 unresolved deps: perl(Module::Install::Base) package: perl-libwhisker2 - 2.4-3.el5.noarch from epel5-x86_64 unresolved deps: perl(MD5) package: php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch from epel5-x86_64 unresolved deps: php-mcrypt php-mhash package: phpdoc - 1.3.2-1.el5.noarch from epel5-x86_64 unresolved deps: php-pear(PhpDocumentor) = 0:1.3.2-1.el5 package: python-Coherence - 0.2.1-3.el5.noarch from epel5-x86_64 unresolved deps: SOAPpy python-twisted-core python-nevow python-twisted-web package: qucs - 0.0.12-2.el5.x86_64 from epel5-x86_64 unresolved deps: iverilog package: redet - 8.22-4.el5.noarch from epel5-x86_64 unresolved deps: iwidgets package: translate-toolkit - 0.10.1-1.el5.noarch from epel5-x86_64 unresolved deps: python-enchant package: zabbix - 1.1.7-1.el5.x86_64 from epel5-x86_64 unresolved deps: fping From sheltren at cs.ucsb.edu Sat Jul 7 13:16:18 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 7 Jul 2007 09:16:18 -0400 Subject: EPEL 5 Dependency Report In-Reply-To: <52A25C5E-12C6-48A1-AE15-C360719E6942@cs.ucsb.edu> References: <52A25C5E-12C6-48A1-AE15-C360719E6942@cs.ucsb.edu> Message-ID: <17010848-728A-4E41-9B0D-53937877B5CD@cs.ucsb.edu> On Jul 7, 2007, at 9:15 AM, Jeff Sheltren wrote: > Here's a list of broken deps in EPEL-4 i386 and x86_64 As the subject indicates, this is really for EPEL-5. Please forgive my lazy copy/pasting :) -Jeff From pertusus at free.fr Sat Jul 7 14:00:41 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Jul 2007 16:00:41 +0200 Subject: packages that conflict with centos? Message-ID: <20070707140041.GF3144@free.fr> Hello, There isn't many of them, but yum and related packages are in Centos and not in RHEL-4 (unless I am wrong). Should they be packaged in EPEL or not? And in the general, what to do in such cases? -- Pat From sheltren at cs.ucsb.edu Sat Jul 7 14:15:39 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 7 Jul 2007 10:15:39 -0400 Subject: packages that conflict with centos? In-Reply-To: <20070707140041.GF3144@free.fr> References: <20070707140041.GF3144@free.fr> Message-ID: On Jul 7, 2007, at 10:00 AM, Patrice Dumas wrote: > Hello, > > There isn't many of them, but yum and related packages are in > Centos and > not in RHEL-4 (unless I am wrong). According to the CentOS release notes, you are correct: http://mirror.centos.org/centos/4/os/i386/RELEASE-NOTES-en.html It lists the following as packages which are in CentOS-4 and not in RHEL-4: createrepo centos-yumconf sqlite sqlite-devel python-elementtree python-sqlite python-urlgrabber yum 'centos-yumconf' is probably safe to ignore as it is only yum repo configs. We should discuss how to deal with the other packages. -Jeff From wolfy at nobugconsulting.ro Sat Jul 7 14:32:04 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 07 Jul 2007 17:32:04 +0300 Subject: packages that conflict with centos? In-Reply-To: References: <20070707140041.GF3144@free.fr> Message-ID: <468FA3E4.7080204@nobugconsulting.ro> On 07/07/2007 05:15 PM, Jeff Sheltren wrote: > On Jul 7, 2007, at 10:00 AM, Patrice Dumas wrote: > >> Hello, >> >> There isn't many of them, but yum and related packages are in Centos and >> not in RHEL-4 (unless I am wrong). > > According to the CentOS release notes, you are correct: > http://mirror.centos.org/centos/4/os/i386/RELEASE-NOTES-en.html > > It lists the following as packages which are in CentOS-4 and not in > RHEL-4: > createrepo > centos-yumconf > sqlite > sqlite-devel > python-elementtree > python-sqlite > python-urlgrabber > yum > > 'centos-yumconf' is probably safe to ignore as it is only yum repo > configs. We should discuss how to deal with the other packages. I for one am 100% in favor of including them in EPEL. At least because RH5 uses yum. From tcallawa at redhat.com Sat Jul 7 17:51:48 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 07 Jul 2007 12:51:48 -0500 Subject: EPEL 5 Dependency Report In-Reply-To: <52A25C5E-12C6-48A1-AE15-C360719E6942@cs.ucsb.edu> References: <52A25C5E-12C6-48A1-AE15-C360719E6942@cs.ucsb.edu> Message-ID: <1183830708.3489.40.camel@localhost.localdomain> On Sat, 2007-07-07 at 09:15 -0400, Jeff Sheltren wrote: > Here's a list of broken deps in EPEL-4 i386 and x86_64. If you own a > package which has broken deps, please see about having the Fedora > maintainer for the dependency build it for EPEL, or if they are not > interested you could also become a co-maintainer of the needed package > (s). > > If you notice any errors in the dep checking, please let me know. I'm in the process of building all of my Fedora packages for EPEL (where relevant). This will clear up a rather significant portion of these broken deps. (I'm also in the middle of moving cross-country, so please be patient with me) ~spot From mastahnke at gmail.com Sat Jul 7 19:56:37 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sat, 7 Jul 2007 14:56:37 -0500 Subject: packages that conflict with centos? In-Reply-To: <468FA3E4.7080204@nobugconsulting.ro> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> Message-ID: <7874d9dd0707071256t73df3fe5pb2171de0e71fe90e@mail.gmail.com> On 7/7/07, Manuel Wolfshant wrote: > On 07/07/2007 05:15 PM, Jeff Sheltren wrote: > > On Jul 7, 2007, at 10:00 AM, Patrice Dumas wrote: > > > >> Hello, > >> > >> There isn't many of them, but yum and related packages are in Centos and > >> not in RHEL-4 (unless I am wrong). > > > > According to the CentOS release notes, you are correct: > > http://mirror.centos.org/centos/4/os/i386/RELEASE-NOTES-en.html > > > > It lists the following as packages which are in CentOS-4 and not in > > RHEL-4: > > createrepo > > centos-yumconf > > sqlite > > sqlite-devel > > python-elementtree > > python-sqlite > > python-urlgrabber > > yum > > > > 'centos-yumconf' is probably safe to ignore as it is only yum repo > > configs. We should discuss how to deal with the other packages. > I for one am 100% in favor of including them in EPEL. At least because > RH5 uses yum. > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > I thought we have had this conversation before and said that native tools woudl be used. (I.E on RHEL 4, you get to have all the fun of up2date (shudder)) . I am not saying I am for or against, but we have had the conversation. stahnma From sheltren at cs.ucsb.edu Sat Jul 7 20:41:31 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 7 Jul 2007 16:41:31 -0400 Subject: EPEL 5 Dependency Report In-Reply-To: <1183830708.3489.40.camel@localhost.localdomain> References: <52A25C5E-12C6-48A1-AE15-C360719E6942@cs.ucsb.edu> <1183830708.3489.40.camel@localhost.localdomain> Message-ID: <5FCD7CB2-BC10-4379-AE63-899D954D4A44@cs.ucsb.edu> On Jul 7, 2007, at 1:51 PM, Tom spot Callaway wrote: > On Sat, 2007-07-07 at 09:15 -0400, Jeff Sheltren wrote: >> Here's a list of broken deps in EPEL-4 i386 and x86_64. If you own a >> package which has broken deps, please see about having the Fedora >> maintainer for the dependency build it for EPEL, or if they are not >> interested you could also become a co-maintainer of the needed >> package >> (s). >> >> If you notice any errors in the dep checking, please let me know. > > I'm in the process of building all of my Fedora packages for EPEL > (where > relevant). This will clear up a rather significant portion of these > broken deps. > > (I'm also in the middle of moving cross-country, so please be patient > with me) > Great, thanks! Good luck with the move :) -Jeff From sheltren at cs.ucsb.edu Sat Jul 7 20:43:54 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 7 Jul 2007 16:43:54 -0400 Subject: packages that conflict with centos? In-Reply-To: <7874d9dd0707071256t73df3fe5pb2171de0e71fe90e@mail.gmail.com> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <7874d9dd0707071256t73df3fe5pb2171de0e71fe90e@mail.gmail.com> Message-ID: <16081984-EF79-4FC1-BAFF-825263459911@cs.ucsb.edu> On Jul 7, 2007, at 3:56 PM, Michael Stahnke wrote: >> > I thought we have had this conversation before and said that native > tools woudl be used. (I.E on RHEL 4, you get to have all the fun of > up2date (shudder)) . I am not saying I am for or against, but we have > had the conversation. > > stahnma > Did the question of what to do when someone wants, for example, sqlite (or needs it for a dependency)? Sorry, I must have missed this before :) -Jeff From pertusus at free.fr Sat Jul 7 20:47:25 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Jul 2007 22:47:25 +0200 Subject: packages that conflict with centos? In-Reply-To: <468FA3E4.7080204@nobugconsulting.ro> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> Message-ID: <20070707204725.GG3144@free.fr> On Sat, Jul 07, 2007 at 05:32:04PM +0300, Manuel Wolfshant wrote: > I for one am 100% in favor of including them in EPEL. At least because RH5 > uses yum. But then EPEL conflicts with Centos. -- Pat From pertusus at free.fr Sat Jul 7 20:48:42 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 7 Jul 2007 22:48:42 +0200 Subject: packages that conflict with centos? In-Reply-To: <16081984-EF79-4FC1-BAFF-825263459911@cs.ucsb.edu> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <7874d9dd0707071256t73df3fe5pb2171de0e71fe90e@mail.gmail.com> <16081984-EF79-4FC1-BAFF-825263459911@cs.ucsb.edu> Message-ID: <20070707204842.GH3144@free.fr> On Sat, Jul 07, 2007 at 04:43:54PM -0400, Jeff Sheltren wrote: > > Did the question of what to do when someone wants, for example, sqlite (or > needs it for a dependency)? That's why I raised the issue, because I saw yum needed as a dependency. -- Pat From steve at silug.org Sat Jul 7 20:58:44 2007 From: steve at silug.org (Steven Pritchard) Date: Sat, 7 Jul 2007 15:58:44 -0500 Subject: packages that conflict with centos? In-Reply-To: <20070707204725.GG3144@free.fr> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <20070707204725.GG3144@free.fr> Message-ID: <20070707205844.GA21696@osiris.silug.org> On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote: > But then EPEL conflicts with Centos. Why not just track their package with a lower Release? Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From fedora at leemhuis.info Sun Jul 8 13:01:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Jul 2007 15:01:26 +0200 Subject: EPEL report week 27, 2007 Message-ID: <4690E026.7010906@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week27 = Weekly EPEL Summary = Week 27/2007 == Most important happenings == * Policy for "Branching for EPEL if Fedora maintainer does not react" was approved * target date for for official EPEL announcement: July 19; we need to fix all broken deps beforehand (and make sure any new ones hit the repo) == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * Jeff_S (Jeff Sheltren) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * quiad (KarstenWade) * stahnma (MichaelStahnke) === Summary === * EPEL Meeting ? broken deps ? nirik: * Jeff_S will be responsible for this topic; nirik will try to help * we need to poke people; they likely don't even know that there are broken dep * running a repoclosure before push would be ideal, but not easy; we should get that with bodhi sooner or later, so we don't look deeper into this issue * spam o magic script (broken deps) ? mmcgrath * mmcgrath is looking at it; he committed to have it ready by the next meeting * Move epel dirs on servers down below stable ? knurd * last week decided, this week reverted. * Branch for EPEL if Fedora maintainer does not react ? knurd, _blah_ * https://www.redhat.com/archives/epel-devel-list/2007-July/msg00016.html got approved, knurd added it to the wiki. We likely need to adjust a small detail; see https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00332.html * signers group ? dgilmore * dgilmore and mmcgrath can push and sign; that is considered enough for now * finish the wiki docs and remove the warnings by end of may ? quaid * round about ready; quaid has some changes pending, but nothing major * warning on the top EPEL-page in the wiki will get removed shortly before announcement * EPEL announcement -- quaid * early announce draft to epel-devel-l soon; shortly after that early announce to f-maintainers ; followed by first draft of real announcement to e-d-l ; finally announce on Jul 19 * RHX and EPEL ? quaid * seems some people still don't really know that RHX actually is * general agreement to "we should try to work it so that Free and open source software in RHX is available in EPEL with community support"; quaid> "I doubt we'll have any problem with that idea . I think the RHX folks feel the same; they have no need to duplicate what we do for no reason, and lose the gain of the community . It's going to be a few weeks until we can get a formal set of guidelines between the two groups . Mainly it's about the messaging, making sure that it's easy to know the difference between a package from EPEL and one from RHX . I made the point that ISVs can control that best if the ... actually own the package in Fedora :) " === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00019.html == Stats == === General === Number of EPEL Contributors 107 We welcome 6 new contributors: gemi_AT_bluewin.ch, ghenry_AT_suretecsystems.com, mdehaan_AT_redhat.com, mszpak_AT_wp.pl, rich_AT_phekda.gotadsl.co.uk, rpm_AT_greysector.net === EPEL 5 === Number of source packages: 439 Number of binary packages: 799 There are 34 new Packages: * alsamixergui | GUI mixer for ALSA sound devices * artwiz-aleczapka-fonts | Set of (improved) artwiz fonts * blacs | Basic Linear Algebra Communication Subprograms * c-ares | A library that performs asynchronous DNS operations * cobbler | Boot server configurator * cronolog | Web log rotation program for Apache * dar | Software for making/restoring incremental CD/DVD backups * dx | Open source version of IBM's Visualization Data Explorer * eclipse-subclipse | Subversion Eclipse plugin * evolution-bogofilter | A plugin for bogofilter support in evolution * ftplib | Library of FTP routines * gxemul | Instruction-level machine emulator * itk | Object oriented extensions to Tk * jam | Program construction tool, similar to make * JSDoc | Produces javadoc-style documentation from JavaScript sourcefiles * koan | Network provisioning tool for Xen and Bare Metal Machines * lapack | The LAPACK libraries for numerical linear algebra. * libcgi | CGI easy as C * perl-Lingua-EN-Inflect | Convert singular to plural, select "a" or "an" * perl-Lingua-EN-Inflect-Number | Force number of words to singular or plural * perl-version | Perl extension for Version Objects * php-pear-Phlickr | Phlickr is a PHP5 based api kit used with the Flickr API * php-spyc | A simple php yaml class * planet | Flexible RDF/RSS/Atom feed aggregator * python-isprelink | Python module to determine if a file has been prelinked * R | A language for data analysis and graphics * R-RScaLAPACK | An interface to perform parallel computation on linear algebra problems using ScaLAPACK * scalapack | A subset of LAPACK routines redesigned for heterogenous computing * uread | Utilities for unformatted fortran files === EPEL 4 === Number of source packages: 271 Number of binary packages: 560 There are 19 new Packages: * alsamixergui | GUI mixer for ALSA sound devices * artwiz-aleczapka-fonts | Set of (improved) artwiz fonts * c-ares | A library that performs asynchronous DNS operations * cobbler | Boot server configurator * ftplib | Library of FTP routines * gxemul | Instruction-level machine emulator * jam | Program construction tool, similar to make * JSDoc | Produces javadoc-style documentation from JavaScript sourcefiles * koan | Network provisioning tool for Xen and Bare Metal Machines * libcgi | CGI easy as C * perl-Lingua-EN-Inflect | Convert singular to plural, select "a" or "an" * perl-Lingua-EN-Inflect-Number | Force number of words to singular or plural * perl-version | Perl extension for Version Objects * php-spyc | A simple php yaml class * python-isprelink | Python module to determine if a file has been prelinked * R | A language for data analysis and graphics * uread | Utilities for unformatted fortran files ---- ["CategoryEPELReports"] From fedora at leemhuis.info Sun Jul 8 13:16:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Jul 2007 15:16:24 +0200 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> References: <4687C867.8060400@leemhuis.info> <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <4690E3A8.2040906@leemhuis.info> Hi! On 04.07.2007 15:52, rob myers wrote: > On Sun, 2007-07-01 at 17:29 +0200, Thorsten Leemhuis wrote: > [...] > If an EPEL maintainer wants to get a Fedora package into EPEL he should > first check the ContributorStatus document, located in the wiki at > http://fedoraproject.org/wiki/EPEL/ContributorStatus . > > If the Fedora maintainer of the package has indicated a desire not to > participate in EPEL then the EPEL maintainer can request the branch > directly via the standard procedures (e.g. via bugzilla currently). The > EPEL maintainer should CC the Fedora maintainer on the branch request, > so the Fedora maintainer knows that the package is maintained in EPEL as > well. > > If it's unclear if the Fedora maintainer of the package participates in > EPEL then the EPEL maintainer should mail the Fedora maintainer and ask > about their plans for EPEL in general and the package at hand. If there > is no answer within seven days the EPEL maintainer is free to request > the EPEL branch (CC the Fedora maintainer here as well). If the Fedora > maintainer later wants to participate in EPEL, then the EPEL maintainer > of the package should hand primary per release maintainership back to > the Fedora maintainer (and become comaintainer, if interested). We approved this in this weeks meeting and I added it to the wiki. But on fedora-devel a problem with the last part was raised; see https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00332.html https://www.redhat.com/archives/fedora-devel-list/2007-July/msg00334.html Therefor I'd like to change the last sentence of the policy to this: If the Fedora maintainer within less then 1 month wants to participate in EPEL, then the EPEL maintainer of the package must hand primary per release maintainership back to the Fedora maintainer (and become comaintainer, if interested), if he's interested. If the Fedora maintainer at a later point in time wants to participate in EPEL and get his package back then the EPEL maintainer should strongly consider doing so, but doesn't has to. How does this sound? CU thl From fedora at leemhuis.info Sun Jul 8 13:23:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 08 Jul 2007 15:23:52 +0200 Subject: packages that conflict with centos? In-Reply-To: <468FA3E4.7080204@nobugconsulting.ro> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> Message-ID: <4690E568.50006@leemhuis.info> On 07.07.2007 16:32, Manuel Wolfshant wrote: > On 07/07/2007 05:15 PM, Jeff Sheltren wrote: >> On Jul 7, 2007, at 10:00 AM, Patrice Dumas wrote: >>> There isn't many of them, but yum and related packages are in Centos and >>> not in RHEL-4 (unless I am wrong). >> According to the CentOS release notes, you are correct: >> http://mirror.centos.org/centos/4/os/i386/RELEASE-NOTES-en.html >> >> It lists the following as packages which are in CentOS-4 and not in >> RHEL-4: >> createrepo >> centos-yumconf >> sqlite >> sqlite-devel >> python-elementtree >> python-sqlite >> python-urlgrabber >> yum >> >> 'centos-yumconf' is probably safe to ignore as it is only yum repo >> configs. We should discuss how to deal with the other packages. > I for one am 100% in favor of including them in EPEL. At least because > RH5 uses yum. +1 (except centos-yumconf of course) But we should not create trouble for CentOS, so I'm in favor of this, what was said somewhere else in this thread: On 07.07.2007 22:58, Steven Pritchard wrote: > On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote: >> But then EPEL conflicts with Centos. > Why not just track their package with a lower Release? CU thl From sundaram at fedoraproject.org Sun Jul 8 14:16:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 08 Jul 2007 19:46:24 +0530 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <4690E3A8.2040906@leemhuis.info> References: <4687C867.8060400@leemhuis.info> <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> <4690E3A8.2040906@leemhuis.info> Message-ID: <4690F1B8.1@fedoraproject.org> Thorsten Leemhuis wrote: > If the Fedora maintainer within less then 1 month wants to participate > in EPEL, then the EPEL maintainer of the package must hand primary per > release maintainership back to the Fedora maintainer (and become > comaintainer, if interested), if he's interested. If the Fedora > maintainer at a later point in time wants to participate in EPEL and get > his package back then the EPEL maintainer should strongly consider doing > so, but doesn't has to. > > How does this sound? Good but I would remove the gender specific language. Rahul From ville.skytta at iki.fi Sun Jul 8 14:21:11 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 8 Jul 2007 17:21:11 +0300 Subject: Getting involved Message-ID: <200707081721.11459.ville.skytta@iki.fi> Hello, I'm gradually getting more involved with EPEL, have already built a couple of packages yesterday and will ask branches of some others soon. However, my interest is almost exclusively limited to EL-5 at this time. While I'm not going to make any gratuitous changes to packages that would cause them to not work on EL-4 and will test at least to some extent with it, I probably won't be requesting any EL-4 branches nor really promise to actively maintain packages for it. So, if you want some packages for which I'm listed as the sole EPEL maintainer to appear for EL-4 and volunteer to co-maintain them (for EL-4 only or for later releases too), that's welcome, let me know. One such example is cvsps - it was listed in EPEL 4 broken deps report, required by git-cvs. For EL-5 it has been branched and built and will probably appear in a push soon, but I have no plans to maintain it for EL-4. From buildsys at fedoraproject.org Sun Jul 8 14:54:06 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 8 Jul 2007 10:54:06 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-08 Message-ID: <20070708145406.4B75C152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 3 NEW colordiff-1.0.6a-2.el5 : Color terminal highlighter for diff files NEW cvsps-2.1-4.el5 : Patchset tool for CVS NEW roundcubemail-0.1-0.6rc1.1.el5 : Round Cube Webmail is a browser-based multilingual IMAP client Packages built and released for Fedora EPEL 4: 1 (!) perl-IO-stringy-2.110-5.el4 : INVALID rebuild, not published! Changes in Fedora EPEL 5: colordiff-1.0.6a-2.el5 ---------------------- * Sat Jul 07 2007 Ville Skytt? - 1.0.6a-2 - Convert docs to UTF-8. cvsps-2.1-4.el5 --------------- * Tue Aug 29 2006 Ville Skytt? - 2.1-4 - Rebuild. roundcubemail-0.1-0.6rc1.1.el5 ------------------------------ * Tue Jul 03 2007 Jon Ciesla = 0.1-0.6rc1.1 - New upstream release, all GPL, all current languages included. Changes in Fedora EPEL 4: perl-IO-stringy-2.110-5.el4 --------------------------- * Wed Apr 18 2007 Paul Howarth 2.110-5 - buildrequire perl(ExtUtils::MakeMaker) For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Tue Jul 10 02:28:28 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 9 Jul 2007 22:28:28 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-09 Message-ID: <20070710022828.E7000152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 5 NEW gshutdown-0.2-1.el5 : GShutDown is an advanced shut down utility for GNOME NEW libpaper-1.1.21-1.el5.1 : Library and tools for handling papersize NEW ntfsprogs-1.13.1-5.el5 : NTFS filesystem libraries and utilities python-genshi-0.4.2-2.el5 NEW scrub-1.9-1.el5 : Disk scrubbing program Packages built and released for Fedora EPEL 4: 3 NEW libpaper-1.1.21-1.el4.1 : Library and tools for handling papersize mock-0.7.2-1.el4.1 NEW scrub-1.9-1.el4 : Disk scrubbing program Changes in Fedora EPEL 5: gshutdown-0.2-1.el5 ------------------- * Mon Jul 09 2007 Xavier Lamien - 0.2-1 - Updated Release. libpaper-1.1.21-1.el5.1 ----------------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.1.21-1.1 - BR: libtool * Mon Jul 09 2007 Tom "spot" Callaway 1.1.21-1 - bump to 1.1.21 - fix automake bug (bz 247458) ntfsprogs-1.13.1-5.el5 ---------------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.13.1-5 - don't package items which say they should never be installed (resolves bz 247398) * Wed Jun 27 2007 Tom "spot" Callaway 1.13.1-4 - fix packaging mistake (resolve bz 245329) python-genshi-0.4.2-2.el5 ------------------------- * Mon Jul 09 2007 Jeffrey C. Ollie - 0.4.2-2 - BR python-setuptools so that egg-info files get installed. Fixes #247430. scrub-1.9-1.el5 --------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.9-1 - bump to 1.9 Changes in Fedora EPEL 4: libpaper-1.1.21-1.el4.1 ----------------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.1.21-1.1 - BR: libtool * Mon Jul 09 2007 Tom "spot" Callaway 1.1.21-1 - bump to 1.1.21 - fix automake bug (bz 247458) mock-0.7.2-1.el4.1 ------------------ * Mon Jul 09 2007 Michael Brown - 0.7.1-1.el4.1 - back out yum>3 require scrub-1.9-1.el4 --------------- * Mon Jul 09 2007 Tom "spot" Callaway 1.9-1 - bump to 1.9 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Tue Jul 10 13:17:46 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Jul 2007 08:17:46 -0500 Subject: fftw advice... Message-ID: I was going to get to work on building fftw2/fftw3 for epel, and have a small quandry. Fedora names these fftw2/fftw. rpmforge currently names them fftw/fftw3. They feel strongly about it, and users were angered previously at my initial attempts at implementing an Obsoletes/Provides migration path to fftw2/fftw. So, I was leaning toward following rpmforge's fftw/fftw3 naming scheme, but... these modules are currently named fftw2 and fftw in cvs. I'm unaware of any strict rules, but figured it would be at least uncool to create packages whose %{name} != cvs_module. So, to move forward here should I: 1. be uncool and just do it. or 2. request a new package review for 'fftw3' ?? If 2 is the correct answer here, I'm not sure I'm willing to subject myself to the further pain/effort of a review (unless someone chimes in quickly to offer to review it). -- Rex From jamatos at fc.up.pt Tue Jul 10 13:40:33 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Tue, 10 Jul 2007 14:40:33 +0100 Subject: fftw advice... In-Reply-To: References: Message-ID: <200707101440.33981.jamatos@fc.up.pt> On Tuesday 10 July 2007 14:17:46 Rex Dieter wrote: > I was going to get to work on building fftw2/fftw3 for epel, and have a > small quandry. > > Fedora names these fftw2/fftw. > rpmforge currently names them fftw/fftw3. They feel strongly about it, and > users were angered previously at my initial attempts at implementing an > Obsoletes/Provides migration path to fftw2/fftw. What is so special about fftw to name the version that is not further developed as fftw as opposed to the version that is developed? Don't we trust upstream to decide which is the package's name? OTHO version 2 and 3 are different libraries (different API) that target more or less the same problem space, so there is not such a thing as an upgrade path in this case. If they had different names then there would not be such a problem. :-) > > -- Rex -- Jos? Ab?lio From pertusus at free.fr Tue Jul 10 15:59:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 10 Jul 2007 17:59:10 +0200 Subject: fftw advice... In-Reply-To: References: Message-ID: <20070710155910.GA6039@free.fr> On Tue, Jul 10, 2007 at 08:17:46AM -0500, Rex Dieter wrote: > > So, I was leaning toward following rpmforge's fftw/fftw3 naming scheme, Although naming fftw3 the newer version seems acceptable to me, especially if upstream breaks api now and then, naming the old version fftw seems wrong to me. Would rpmforge people accept to rename fftw to fftw2, and leave the latest at fftw3? > If 2 is the correct answer here, I'm not sure I'm willing to subject myself > to the further pain/effort of a review (unless someone chimes in quickly to > offer to review it). I could do that (if needed), after all it is just a rename. -- Pat From fedora at leemhuis.info Tue Jul 10 16:24:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 10 Jul 2007 18:24:12 +0200 Subject: fftw advice... In-Reply-To: <20070710155910.GA6039@free.fr> References: <20070710155910.GA6039@free.fr> Message-ID: <4693B2AC.90702@leemhuis.info> On 10.07.2007 17:59, Patrice Dumas wrote: > On Tue, Jul 10, 2007 at 08:17:46AM -0500, Rex Dieter wrote: >> So, I was leaning toward following rpmforge's fftw/fftw3 naming scheme, > Although naming fftw3 the newer version seems acceptable to me, > especially if upstream breaks api now and then, naming the old version > fftw seems wrong to me. [...] >From looking at it at this point of time I tend to agree. Normally I'd say that the latest version of "foo" should always be foo as long as upstream calls it foo (IOW: fftw3 in this case is confusing as upstream calls it fftw). If we ship foo (major-1) I'd expect we'd call it compat-foo or foo(major-1) (e.f. fftw2 in this case). Calling the older one simply foo (fftw) would IMHO be to confusing, as a lot of people that simply want to install "foo" will expect the latest version when they run "yum install foo". CU thl From fedora at leemhuis.info Tue Jul 10 16:48:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 10 Jul 2007 18:48:05 +0200 Subject: Plan for tomorrows (20070701) EPEL SIG meeting Message-ID: <4693B845.4040505@leemhuis.info> Hi all, find below the list of topics that are likely to come up in the next EPEL SIG meeting that's scheduled for tomorrow, Wednesday at 17:00 UTC in #fedora-extras on irc.freenode.org. /topic EPEL Meeting ? broken deps ? Jeff_S /topic EPEL Meeting ? spam o magic script ? mmcgrath /topic EPEL Meeting ? branch for EPEL if Fedora maintainer does not react ? knurd /topic EPEL Meeting ? push new packages to testing after EPEL annoucement ? dgilmore /topic EPEL Meeting ? EPEL annoucement ? quaid /topic EPEL Meeting ? new meeting time? ? all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) /topic EPEL Meeting ? Communication plan for enterprise customers/ISVs/IHVs ? stahnma, quaid /topic EPEL Meeting ? ExcludeArch TrackerBugs for EPEL ? notting/knurd /topic EPEL Meeting ? RHX and EPEL ? quaid You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics at the end of the meeting itself. If your name/nick is on above list please give a update. That way all the interested parties know what up ahead of the meeting; that will avoid long delays and "status update monologues in the meeting. Thanks! CU thl From fedora at leemhuis.info Tue Jul 10 16:49:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 10 Jul 2007 18:49:36 +0200 Subject: Plan for tomorrows (20070711) EPEL SIG meeting (was: Re: Plan for tomorrows (20070701) EPEL SIG meeting) In-Reply-To: <4693B845.4040505@leemhuis.info> References: <4693B845.4040505@leemhuis.info> Message-ID: <4693B8A0.1030402@leemhuis.info> Sorry for the typo in the subject, tomorrow is of course 20070711 Cu thl On 10.07.2007 18:48, Thorsten Leemhuis wrote: > Hi all, > > find below the list of topics that are likely to come up in the next > EPEL SIG meeting that's scheduled for tomorrow, Wednesday at 17:00 UTC > in #fedora-extras on irc.freenode.org. > > /topic EPEL Meeting ? broken deps ? Jeff_S > /topic EPEL Meeting ? spam o magic script ? mmcgrath > /topic EPEL Meeting ? branch for EPEL if Fedora maintainer does not > react ? knurd > /topic EPEL Meeting ? push new packages to testing after EPEL > annoucement ? dgilmore > /topic EPEL Meeting ? EPEL annoucement ? quaid > /topic EPEL Meeting ? new meeting time? ? all (see also > http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) > /topic EPEL Meeting ? Communication plan for enterprise > customers/ISVs/IHVs ? stahnma, quaid > /topic EPEL Meeting ? ExcludeArch TrackerBugs for EPEL ? notting/knurd > /topic EPEL Meeting ? RHX and EPEL ? quaid > > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule (I can't promise we will get > to it tomorrow, but we'll most likely will if we don't run out of time). > You can also propose topics at the end of the meeting itself. > > If your name/nick is on above list please give a update. That way all > the interested parties know what up ahead of the meeting; that will > avoid long delays and "status update monologues in the meeting. > > Thanks! > > CU > thl > > > From smooge at gmail.com Tue Jul 10 17:09:59 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 10 Jul 2007 11:09:59 -0600 Subject: fftw advice... In-Reply-To: <4693B2AC.90702@leemhuis.info> References: <20070710155910.GA6039@free.fr> <4693B2AC.90702@leemhuis.info> Message-ID: <80d7e4090707101009m3fda2a3en11c91657810e6c5f@mail.gmail.com> On 7/10/07, Thorsten Leemhuis wrote: > On 10.07.2007 17:59, Patrice Dumas wrote: > > On Tue, Jul 10, 2007 at 08:17:46AM -0500, Rex Dieter wrote: > >> So, I was leaning toward following rpmforge's fftw/fftw3 naming scheme, > > Although naming fftw3 the newer version seems acceptable to me, > > especially if upstream breaks api now and then, naming the old version > > fftw seems wrong to me. [...] > > >From looking at it at this point of time I tend to agree. > > Normally I'd say that the latest version of "foo" should always be foo > as long as upstream calls it foo (IOW: fftw3 in this case is confusing > as upstream calls it fftw). If we ship foo (major-1) I'd expect we'd > call it compat-foo or foo(major-1) (e.f. fftw2 in this case). Calling > the older one simply foo (fftw) would IMHO be to confusing, as a lot of > people that simply want to install "foo" will expect the latest version > when they run "yum install foo". > Isnt there something about dropping the compat naming scheme and going to something else? Or am I confused about a different email thread. Here are my best attempts at Solomon The first question I would ask is what are your customers wanting? What packages need a Fast Fourier Transform and what do a majority of customers running on EL want it to be? If the scientific community is using lots of fftw2 versus fftw3 then that might be a good reason to keep to older name schemes. The second question is what is the new packaging name scheme? If the name scheme is still compat-- I would go with that.. if it isnt then I would go with something like: fftw_22 fftw_3x as the name schemes Third I would go for an open and documented reasoning document from both forge and you on why the names are different and how a user would be able to deal with this issue. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From rdieter at math.unl.edu Tue Jul 10 18:19:00 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Jul 2007 13:19:00 -0500 Subject: fftw advice... References: <20070710155910.GA6039@free.fr> <4693B2AC.90702@leemhuis.info> <80d7e4090707101009m3fda2a3en11c91657810e6c5f@mail.gmail.com> Message-ID: Stephen John Smoogen wrote: > Isnt there something about dropping the compat naming scheme and going > to something else? Or am I confused about a different email thread. The guidelines were (will soon be?) updated to relax the rules, to leave this more at the discretion of maintainers. > The first question I would ask is what are your customers wanting? > What packages need a Fast Fourier Transform and what do a majority of > customers running on EL want it to be? If the scientific community is > using lots of fftw2 versus fftw3 then that might be a good reason to > keep to older name schemes. dunno. Mostly, all I've heard is one *very* vocal rpmforge user. >From scrounging upstream, fftw (3) clearly is the hear and now, fftw2 is all legacy. > The second question is what is the new packaging name scheme? If the > name scheme is still compat-- I would go with > that.. if it isnt then I would go with something like: fftw_22 fftw_3x > as the name schemes match rpmforge: fftw (v2.x) and fftw3 > Third I would go for an open and documented reasoning document from > both forge and you on why the names are different and how a user would > be able to deal with this issue. Easier to simply match, than to diverge + document I think. A bonus is that it's easier to change our minds later (ie, easier to migrate fftw/fftw3 -> fftw2/fftw than the other way around). -- Rex From rdieter at math.unl.edu Tue Jul 10 18:47:45 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 10 Jul 2007 13:47:45 -0500 Subject: fftw advice... References: <20070710155910.GA6039@free.fr> <4693B2AC.90702@leemhuis.info> <80d7e4090707101009m3fda2a3en11c91657810e6c5f@mail.gmail.com> Message-ID: Rex Dieter wrote: >> The second question is what is the new packaging name scheme? If the >> name scheme is still compat-- I would go with >> that.. if it isnt then I would go with something like: fftw_22 fftw_3x >> as the name schemes > > match rpmforge: fftw (v2.x) and fftw3 > >> Third I would go for an open and documented reasoning document from >> both forge and you on why the names are different and how a user would >> be able to deal with this issue. > > Easier to simply match, than to diverge + document I think. > > A bonus is that it's easier to change our minds later (ie, easier to > migrate fftw/fftw3 -> fftw2/fftw than the other way around). OK, I'm going to forge ahead (following a suggestion from pjones): keeping (main) Name: fftw ,so srpm matches cvs module, and make (binary) packages named fftw3. clear as mud? hopefully, no one will yell. -- Rex From Fedora at FamilleCollet.com Tue Jul 10 20:13:30 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Tue, 10 Jul 2007 22:13:30 +0200 Subject: [Fwd: Broken dependencies: php-pear-Net-Ping] Message-ID: <4693E86A.1030203@FamilleCollet.com> Can someone explain me this mail ? I really don't understand where is the broken dep. Remi. P.S. i receive such a mail for each of my RPM in EPEL... -------- Message original -------- Sujet: Broken dependencies: php-pear-Net-Ping Date: Tue, 10 Jul 2007 12:59:43 -0700 De: root Pour :: remi at fedoraproject.org php-pear-Net-Ping has broken dependencies in the development tree: On ppc: php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /usr/bin/pear php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/sh php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/ping On x86_64: php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /usr/bin/pear php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/sh php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/ping On i386: php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /usr/bin/pear php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/sh php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/ping Please resolve this as soon as possible. From jima at beer.tclug.org Tue Jul 10 20:15:37 2007 From: jima at beer.tclug.org (Jima) Date: Tue, 10 Jul 2007 15:15:37 -0500 (CDT) Subject: [Fwd: Broken dependencies: php-pear-Net-Ping] In-Reply-To: <4693E86A.1030203@FamilleCollet.com> References: <4693E86A.1030203@FamilleCollet.com> Message-ID: On Tue, 10 Jul 2007, Remi Collet wrote: > Can someone explain me this mail ? > > I really don't understand where is the broken dep. Ignore it (this time around). It was an administrative mishap. :-) Jima From paul at city-fan.org Tue Jul 10 20:19:26 2007 From: paul at city-fan.org (Paul Howarth) Date: Tue, 10 Jul 2007 21:19:26 +0100 Subject: [Fwd: Broken dependencies: php-pear-Net-Ping] In-Reply-To: <4693E86A.1030203@FamilleCollet.com> References: <4693E86A.1030203@FamilleCollet.com> Message-ID: <1184098766.13101.3.camel@metropolis.intra.city-fan.org> On Tue, 2007-07-10 at 22:13 +0200, Remi Collet wrote: > Can someone explain me this mail ? > > I really don't understand where is the broken dep. In most cases there isn't one. > Remi. > > P.S. i receive such a mail for each of my RPM in EPEL... Me too. > -------- Message original -------- > Sujet: Broken dependencies: php-pear-Net-Ping > Date: Tue, 10 Jul 2007 12:59:43 -0700 > De: root > Pour :: remi at fedoraproject.org > > > > php-pear-Net-Ping has broken dependencies in the development tree: > On ppc: > php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /usr/bin/pear > php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/sh > php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/ping > On x86_64: > php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /usr/bin/pear > php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/sh > php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/ping > On i386: > php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /usr/bin/pear > php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/sh > php-pear-Net-Ping - 2.4.1-2.el5.noarch requires /bin/ping > Please resolve this as soon as possible. Please resolve the dependency resolution problems in this script as soon as possible. An apparently missing dep on /bin/sh is a good indicator that something is seriously wrong with the script, and I think it might be a good idea if the script exited as soon as it saw that in future. Paul. From pertusus at free.fr Tue Jul 10 20:24:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 10 Jul 2007 22:24:45 +0200 Subject: fftw advice... In-Reply-To: References: <20070710155910.GA6039@free.fr> <4693B2AC.90702@leemhuis.info> <80d7e4090707101009m3fda2a3en11c91657810e6c5f@mail.gmail.com> Message-ID: <20070710202003.GA6876@free.fr> On Tue, Jul 10, 2007 at 01:47:45PM -0500, Rex Dieter wrote: > > OK, I'm going to forge ahead (following a suggestion from pjones): > keeping (main) Name: fftw ,so srpm matches cvs module, and make (binary) > packages named fftw3. clear as mud? hopefully, no one will yell. This may be wrong, but what about a simple Provides: fftw3 -- Pat From dennis at ausil.us Tue Jul 10 20:39:09 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 10 Jul 2007 15:39:09 -0500 Subject: spam-o-matic Message-ID: <200707101539.10087.dennis@ausil.us> Hey All, when testing the spam-o-matic script that sends out notifications for broken dependencies it was accidentally run without the --nomail flag in addition to not being pointed at a RHEL tree. which resulted in messages sent that should not have been. We are terribly sorry for the noise and will try to never ever do it again. Thank you for your patience and understanding Dennis From buildsys at fedoraproject.org Wed Jul 11 03:43:49 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 10 Jul 2007 23:43:49 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-10 Message-ID: <20070711034349.CAA9F152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 9 NEW fwrestart-1.04-2.el5 : A way to more safely re-load firewall rules remotely NEW geomview-1.9.3-1.el5 : Interactive 3D viewing program NEW glibmm24-2.12.10-1.el5 : C++ interface for GTK2 (a GUI library for X) NEW libsigc++20-2.0.17-3.el5 : Typesafe signal framework for C++ NEW mussh-0.7-1.el5 : Multihost SSH wrapper phpPgAdmin-4.1.3-1.el5 NEW pylibacl-0.2.1-6.el5 : POSIX.1e ACLs library wrapper for python NEW pyxattr-0.2.1-4.el5 : Extended attributes library wrapper for Python reciteword-0.8.3-5.el5 Packages built and released for Fedora EPEL 4: 6 NEW geomview-1.9.3-1.el4.1 : Interactive 3D viewing program NEW itk-3.3-0.7.RC1.el4 : Object oriented extensions to Tk NEW iwidgets-4.0.1-4.el4 : A set of useful widgets based on itcl and itk phpPgAdmin-4.1.3-1.el4 NEW pylibacl-0.2.1-6.el4 : POSIX.1e ACLs library wrapper for python NEW pyxattr-0.2.1-4.el4 : Extended attributes library wrapper for Python Changes in Fedora EPEL 5: fwrestart-1.04-2.el5 -------------------- * Sun Aug 27 2006 Kevin Fenzi - 1.04-2 - Rebuild for fc6 geomview-1.9.3-1.el5 -------------------- * Thu Jun 21 2007 Rex Dieter 1.9.3-1 - geomview-1.9.3 * Sat Jun 16 2007 Rex Dieter 1.9.2-1 - geomview-1.9.2 glibmm24-2.12.10-1.el5 ---------------------- * Tue Jul 10 2007 Denis Leroy - 2.12.10-1 - Update to 2.12.10 - Put documentation under datadir/gtk-doc/html libsigc++20-2.0.17-3.el5 ------------------------ * Tue Jul 10 2007 Denis Leroy - 2.0.17-3 - Added dist tag mussh-0.7-1.el5 --------------- * Tue Dec 26 2006 Kevin Fenzi 0.7-1 - Update to 0.7 phpPgAdmin-4.1.3-1.el5 ---------------------- * Tue Jul 10 2007 Devrim Gunduz 4.1.3-1 - Update to 4.1.3 pylibacl-0.2.1-6.el5 -------------------- * Wed Apr 25 2007 Marcin Zajaczkowski - 0.2.1-6 - added Provides/Obsoletes tags pyxattr-0.2.1-4.el5 ------------------- * Wed Apr 25 2007 Marcin Zajaczkowski - 0.2.1-4 - added Provides/Obsoletes tags reciteword-0.8.3-5.el5 ---------------------- * Wed Jun 27 2007 Hu Zheng - 0.8.3-4 - Fix no .mo file problem. Changes in Fedora EPEL 4: geomview-1.9.3-1.el4.1 ---------------------- * Thu Jun 21 2007 Rex Dieter 1.9.3-1 - geomview-1.9.3 * Sat Jun 16 2007 Rex Dieter 1.9.2-1 - geomview-1.9.2 itk-3.3-0.7.RC1.el4 ------------------- * Tue Jul 10 2007 Wart - 3.3-0.7.RC1 - Add explicit BR: tcl-devel (This should be added by tk-devel. see BZ #182190) iwidgets-4.0.1-4.el4 -------------------- * Mon Aug 28 2006 Wart - 4.0.1-4 - Rebuild for Fedora Extras phpPgAdmin-4.1.3-1.el4 ---------------------- * Tue Jul 10 2007 Devrim Gunduz 4.1.3-1 - Update to 4.1.3 pylibacl-0.2.1-6.el4 -------------------- * Wed Apr 25 2007 Marcin Zajaczkowski - 0.2.1-6 - added Provides/Obsoletes tags pyxattr-0.2.1-4.el4 ------------------- * Wed Apr 25 2007 Marcin Zajaczkowski - 0.2.1-4 - added Provides/Obsoletes tags For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Wed Jul 11 12:39:03 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Jul 2007 07:39:03 -0500 Subject: fftw advice... References: <20070710155910.GA6039@free.fr> <4693B2AC.90702@leemhuis.info> <80d7e4090707101009m3fda2a3en11c91657810e6c5f@mail.gmail.com> <20070710202003.GA6876@free.fr> Message-ID: Patrice Dumas wrote: > On Tue, Jul 10, 2007 at 01:47:45PM -0500, Rex Dieter wrote: >> >> OK, I'm going to forge ahead (following a suggestion from pjones): >> keeping (main) Name: fftw ,so srpm matches cvs module, and make (binary) >> packages named fftw3. clear as mud? hopefully, no one will yell. > > This may be wrong, but what about a simple > Provides: fftw3 It already contained that before (as well as an Obsoletes), but that (a package rename fftw3 -> fftw) was unacceptable to rpmforge folks. -- Rex From rdieter at math.unl.edu Thu Jul 12 15:33:30 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Jul 2007 10:33:30 -0500 Subject: fftw advice... References: <20070710155910.GA6039@free.fr> <4693B2AC.90702@leemhuis.info> <80d7e4090707101009m3fda2a3en11c91657810e6c5f@mail.gmail.com> Message-ID: Rex Dieter wrote: > OK, I'm going to forge ahead (following a suggestion from pjones): > keeping (main) Name: fftw ,so srpm matches cvs module, and make (binary) > packages named fftw3. clear as mud? hopefully, no one will yell. FYI, builds queue'd. Please test for sanity: EL-4: http://buildsys.fedoraproject.org/build-status/job.psp?uid=34938 EL-5: http://buildsys.fedoraproject.org/build-status/job.psp?uid=34937 "fftw: epel branch/builds, rpmforge compatible": http://bugzilla.redhat.com/246004 -- Rex From fedora at leemhuis.info Thu Jul 12 16:35:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Jul 2007 18:35:01 +0200 Subject: EPEL announcement planed for 20070726 Message-ID: <46965835.9030705@leemhuis.info> Hi, just a heads up; the current plan is to officially announce EPEL on Thursday, 26th 2007. Yes, that's one week later that estimated last week, as we need a bit more time to fix all broken deps before the announcement. While at it: Note that new and updated packages for EPEL will go to into EPEL-testing repo after the announcement (?) and get moved to the proper repo at a later point of time. The plan is to do the move from testing to the proper repo in parallel with the "quarterly" EL-releases like RHEL 5.1. CU knurd (?) -- except security updates and critical bugfixes of course From icon at fedoraproject.org Thu Jul 12 18:06:44 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 12 Jul 2007 14:06:44 -0400 Subject: EPEL, RHEL-5Server and RHEL-5Client Message-ID: So, here's a fun situation: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246444 In brief: * python-imaging in EPEL conflicts with python-imaging in RHEL-5Client * upstream (RHEL5) requests to remove python-imaging because EPEL is not supposed to override upstream * removing python-imaging will break dependencies in RHEL-5Server How do we deal with the fact that there is RHEL-5Server and RHEL-5Client and that they have different sets of packages? -- Konstantin Ryabitsev Montr?al, Qu?bec From rdieter at math.unl.edu Thu Jul 12 18:08:38 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 12 Jul 2007 13:08:38 -0500 Subject: EPEL, RHEL-5Server and RHEL-5Client References: Message-ID: Konstantin Ryabitsev wrote: > So, here's a fun situation: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246444 > > In brief: > > * python-imaging in EPEL conflicts with python-imaging in RHEL-5Client > * upstream (RHEL5) requests to remove python-imaging because EPEL is > not supposed to override upstream > * removing python-imaging will break dependencies in RHEL-5Server remove it from epel, and RHEL-5Server folks will probably have to live with broken deps. -- Rex From fedora at leemhuis.info Thu Jul 12 18:24:20 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 12 Jul 2007 20:24:20 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: References: Message-ID: <469671D4.4020509@leemhuis.info> On 12.07.2007 20:08, Rex Dieter wrote: > Konstantin Ryabitsev wrote: > >> So, here's a fun situation: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246444 >> >> In brief: >> >> * python-imaging in EPEL conflicts with python-imaging in RHEL-5Client >> * upstream (RHEL5) requests to remove python-imaging because EPEL is >> not supposed to override upstream >> * removing python-imaging will break dependencies in RHEL-5Server > > remove it from epel, and RHEL-5Server folks will probably have to live with > broken deps. +1 A real long term solution might be to have a kind of dynamic exclude list (done by a yum-plugin with pre-generated lists maybe? no idea, just thinking loud) that would exclude all packages depending on python-imaging on EL5Server. CU thl From Michael_E_Brown at dell.com Thu Jul 12 18:26:06 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 12 Jul 2007 13:26:06 -0500 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: References: Message-ID: <20070712182605.GA28549@humbolt.us.dell.com> On Thu, Jul 12, 2007 at 02:06:44PM -0400, Konstantin Ryabitsev wrote: > So, here's a fun situation: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246444 > > In brief: > > * python-imaging in EPEL conflicts with python-imaging in RHEL-5Client > * upstream (RHEL5) requests to remove python-imaging because EPEL is > not supposed to override upstream > * removing python-imaging will break dependencies in RHEL-5Server > > How do we deal with the fact that there is RHEL-5Server and > RHEL-5Client and that they have different sets of packages? A) File a bug against RHEL-5Server and ask them to include python-imaging. or B) ignore upstream in this instance because they aren't playing nice with downstream. or C) let 5Server guys live with broken deps. Apparently nobody with a Server license would ever want to use this anyways, so they should never run into it. (yeah, right). Personally, I would say to try (A), and then fall back to (B) if they dont do (A). -- Michael From Michael_E_Brown at dell.com Thu Jul 12 18:27:26 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 12 Jul 2007 13:27:26 -0500 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: <469671D4.4020509@leemhuis.info> References: <469671D4.4020509@leemhuis.info> Message-ID: <20070712182725.GB28549@humbolt.us.dell.com> On Thu, Jul 12, 2007 at 08:24:20PM +0200, Thorsten Leemhuis wrote: > > > On 12.07.2007 20:08, Rex Dieter wrote: > > Konstantin Ryabitsev wrote: > > > >> So, here's a fun situation: > >> > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246444 > >> > >> In brief: > >> > >> * python-imaging in EPEL conflicts with python-imaging in RHEL-5Client > >> * upstream (RHEL5) requests to remove python-imaging because EPEL is > >> not supposed to override upstream > >> * removing python-imaging will break dependencies in RHEL-5Server > > > > remove it from epel, and RHEL-5Server folks will probably have to live with > > broken deps. > > +1 > > A real long term solution might be to have a kind of dynamic exclude > list (done by a yum-plugin with pre-generated lists maybe? no idea, just > thinking loud) that would exclude all packages depending on > python-imaging on EL5Server. Sounds like: 1) a lot of work. and 2) really cool way to really confuse our users. (why can't I install foo? it is in the repo?) -- Michael From smooge at gmail.com Thu Jul 12 18:27:52 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 12 Jul 2007 12:27:52 -0600 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: <469671D4.4020509@leemhuis.info> References: <469671D4.4020509@leemhuis.info> Message-ID: <80d7e4090707121127m21304697rc78782196563d640@mail.gmail.com> On 7/12/07, Thorsten Leemhuis wrote: > > > On 12.07.2007 20:08, Rex Dieter wrote: > > Konstantin Ryabitsev wrote: > > > >> So, here's a fun situation: > >> > >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246444 > >> > >> In brief: > >> > >> * python-imaging in EPEL conflicts with python-imaging in RHEL-5Client > >> * upstream (RHEL5) requests to remove python-imaging because EPEL is > >> not supposed to override upstream > >> * removing python-imaging will break dependencies in RHEL-5Server > > > > remove it from epel, and RHEL-5Server folks will probably have to live with > > broken deps. > > +1 > > A real long term solution might be to have a kind of dynamic exclude > list (done by a yum-plugin with pre-generated lists maybe? no idea, just > thinking loud) that would exclude all packages depending on > python-imaging on EL5Server. > I wont be able to install plone or anything pythonish because of this on server but I can on client? Proposal: Compile a version of python-imaging that matches what is in the base OS. The EPEL version is 1.0.6 and the supplied version is 1.0.5. That sounds the most reasonable. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From sundaram at fedoraproject.org Thu Jul 12 18:32:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Jul 2007 00:02:47 +0530 Subject: EPEL announcement planed for 20070726 In-Reply-To: <46965835.9030705@leemhuis.info> References: <46965835.9030705@leemhuis.info> Message-ID: <469673CF.1090408@fedoraproject.org> Thorsten Leemhuis wrote: > Hi, > > just a heads up; the current plan is to officially announce EPEL on > Thursday, 26th 2007. Yes, that's one week later that estimated last > week, as we need a bit more time to fix all broken deps before the > announcement. > > While at it: Note that new and updated packages for EPEL will go to into > EPEL-testing repo after the announcement (?) and get moved to the proper > repo at a later point of time. The plan is to do the move from testing > to the proper repo in parallel with the "quarterly" EL-releases like > RHEL 5.1. > Have you folks decided where and how the announcements should be send? Fedora announce list RHEL 4 and 5 lists and announce lists Red Hat press release Other news sites This might be a useful reference: http://fedoraproject.org/wiki/Marketing/SpreadingNews Rahul From mailing-lists at hughesjr.com Thu Jul 12 19:11:05 2007 From: mailing-lists at hughesjr.com (Johnny Hughes) Date: Thu, 12 Jul 2007 14:11:05 -0500 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: References: Message-ID: <46967CC9.7040306@hughesjr.com> Konstantin Ryabitsev wrote: > So, here's a fun situation: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246444 > > In brief: > > * python-imaging in EPEL conflicts with python-imaging in RHEL-5Client > * upstream (RHEL5) requests to remove python-imaging because EPEL is > not supposed to override upstream > * removing python-imaging will break dependencies in RHEL-5Server > > How do we deal with the fact that there is RHEL-5Server and > RHEL-5Client and that they have different sets of packages? > How about just tell them to use yum-priorities? Then, the server guys do not get it and the client guys do. You can also have another repo that is Client-only ... and the only thing that goes there are deps that do not exist in rhel-server??? You are also going to have things that are in 5 and not 4 (and vice versa). You will need to handle all these somehow. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From icon at fedoraproject.org Thu Jul 12 19:14:38 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 12 Jul 2007 15:14:38 -0400 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: <469671D4.4020509@leemhuis.info> References: <469671D4.4020509@leemhuis.info> Message-ID: On 7/12/07, Thorsten Leemhuis wrote: > A real long term solution might be to have a kind of dynamic exclude > list (done by a yum-plugin with pre-generated lists maybe? no idea, just > thinking loud) that would exclude all packages depending on > python-imaging on EL5Server. What would happen if, say, in the future RH rolls out RHEL-5YourMom that includes a bunch of packages currently available in EPEL? Will that mean that those of us who are reliant on those packages coming from EPEL would suddenly lose them? This is not a very good policy. Actually, this is awful, since it means that unless I purchase subscriptions to ALL RHEL channels, I will likely find that some package is unable to install in Server due to missing dependencies. We need a much better solution if EPEL is to remain useful and reliable. -- Konstantin Ryabitsev Montr?al, Qu?bec From mastahnke at gmail.com Thu Jul 12 19:15:15 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 12 Jul 2007 14:15:15 -0500 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: <46967CC9.7040306@hughesjr.com> References: <46967CC9.7040306@hughesjr.com> Message-ID: <7874d9dd0707121215hc5a2f89m1336ccb0b046f7ee@mail.gmail.com> On 7/12/07, Johnny Hughes wrote: > Konstantin Ryabitsev wrote: > > So, here's a fun situation: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246444 > > > > In brief: > > > > * python-imaging in EPEL conflicts with python-imaging in RHEL-5Client > > * upstream (RHEL5) requests to remove python-imaging because EPEL is > > not supposed to override upstream > > * removing python-imaging will break dependencies in RHEL-5Server > > > > How do we deal with the fact that there is RHEL-5Server and > > RHEL-5Client and that they have different sets of packages? > > > > How about just tell them to use yum-priorities? Then, the server guys > do not get it and the client guys do. > > You can also have another repo that is Client-only ... and the only > thing that goes there are deps that do not exist in rhel-server??? > > You are also going to have things that are in 5 and not 4 (and vice versa). > 5 vs 4 is handled. The policy is to provide what is NOT provided by upstream (RHEL in this case). So if RHEL 4 doesn't include something, EPEL can. If RHEL 5 includes it, EPEL will not. The client vs server issues on RHEL 5 have been brought up before, but still with no good solution offered...thus far. stahnma > You will need to handle all these somehow. > > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > From rayvd at bludgeon.org Thu Jul 12 19:23:46 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 12 Jul 2007 12:23:46 -0700 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: References: <469671D4.4020509@leemhuis.info> Message-ID: <20070712192346.GB30911@bludgeon.org> On Thu, Jul 12, 2007 at 03:14:38PM -0400, Konstantin Ryabitsev wrote: > On 7/12/07, Thorsten Leemhuis wrote: > > A real long term solution might be to have a kind of dynamic exclude > > list (done by a yum-plugin with pre-generated lists maybe? no idea, just > > thinking loud) that would exclude all packages depending on > > python-imaging on EL5Server. > > What would happen if, say, in the future RH rolls out RHEL-5YourMom > that includes a bunch of packages currently available in EPEL? Will > that mean that those of us who are reliant on those packages coming > from EPEL would suddenly lose them? > > This is not a very good policy. > > Actually, this is awful, since it means that unless I purchase > subscriptions to ALL RHEL channels, I will likely find that some > package is unable to install in Server due to missing dependencies. > > We need a much better solution if EPEL is to remain useful and reliable. Would there be any problem with just replacing the EPEL version in the EPEL repo with the upstream version if upstream decides to include a conflicting package all of the sudden? If the two packages were different enough, upstream could perhaps be persuaded to include necessary changes to avoid breaking EPEL dependancies? Ray From icon at fedoraproject.org Thu Jul 12 19:34:04 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 12 Jul 2007 15:34:04 -0400 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: <20070712192346.GB30911@bludgeon.org> References: <469671D4.4020509@leemhuis.info> <20070712192346.GB30911@bludgeon.org> Message-ID: On 7/12/07, Ray Van Dolson wrote: > Would there be any problem with just replacing the EPEL version in the > EPEL repo with the upstream version if upstream decides to include a > conflicting package all of the sudden? Well, how about we ask upstream to use EPEL repositories, just like RH does with Fedora? Huh? Huh? -- Konstantin Ryabitsev Montr?al, Qu?bec From rayvd at bludgeon.org Thu Jul 12 19:37:13 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 12 Jul 2007 12:37:13 -0700 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: References: <469671D4.4020509@leemhuis.info> <20070712192346.GB30911@bludgeon.org> Message-ID: <20070712193713.GB31338@bludgeon.org> On Thu, Jul 12, 2007 at 03:34:04PM -0400, Konstantin Ryabitsev wrote: > On 7/12/07, Ray Van Dolson wrote: > > Would there be any problem with just replacing the EPEL version in the > > EPEL repo with the upstream version if upstream decides to include a > > conflicting package all of the sudden? > > Well, how about we ask upstream to use EPEL repositories, just like RH > does with Fedora? Huh? Huh? +1 I imagine there'd still be cases where they went off and decided to do their own thing though, so maybe we should still decide how to handle that. Ray From rtlm10 at gmail.com Thu Jul 12 20:38:56 2007 From: rtlm10 at gmail.com (Russell Harrison) Date: Thu, 12 Jul 2007 16:38:56 -0400 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: <20070712193713.GB31338@bludgeon.org> References: <469671D4.4020509@leemhuis.info> <20070712192346.GB30911@bludgeon.org> <20070712193713.GB31338@bludgeon.org> Message-ID: <1ed4a0130707121338g38f22ae8r67591d11599e8514@mail.gmail.com> On 7/12/07, Ray Van Dolson wrote: > On Thu, Jul 12, 2007 at 03:34:04PM -0400, Konstantin Ryabitsev wrote: > > On 7/12/07, Ray Van Dolson wrote: > > > Would there be any problem with just replacing the EPEL version in the > > > EPEL repo with the upstream version if upstream decides to include a > > > conflicting package all of the sudden? > > > > Well, how about we ask upstream to use EPEL repositories, just like RH > > does with Fedora? Huh? Huh? > > +1 > > I imagine there'd still be cases where they went off and decided to do > their own thing though, so maybe we should still decide how to handle > that. Does it make things any easier to have Client / Server repos that packages get moved to only when this sort of thing happens? By default all packages go into the current "common" repo and when problems like this arise the move to the specific repo. At least in that case it isn't necessary to duplicate everything in both repos. Only the one offs. Its messy no matter how you do it. :-/ ---- Russell Harrison Systems Administrator -- Linux Desktops Cisco Systems, Inc. From smooge at gmail.com Thu Jul 12 21:18:46 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 12 Jul 2007 15:18:46 -0600 Subject: EPEL, RHEL-5Server and RHEL-5Client In-Reply-To: <1ed4a0130707121338g38f22ae8r67591d11599e8514@mail.gmail.com> References: <469671D4.4020509@leemhuis.info> <20070712192346.GB30911@bludgeon.org> <20070712193713.GB31338@bludgeon.org> <1ed4a0130707121338g38f22ae8r67591d11599e8514@mail.gmail.com> Message-ID: <80d7e4090707121418h1b61babal18779bafcb53ee0e@mail.gmail.com> On 7/12/07, Russell Harrison wrote: > On 7/12/07, Ray Van Dolson wrote: > > On Thu, Jul 12, 2007 at 03:34:04PM -0400, Konstantin Ryabitsev wrote: > > > On 7/12/07, Ray Van Dolson wrote: > > > > Would there be any problem with just replacing the EPEL version in the > > > > EPEL repo with the upstream version if upstream decides to include a > > > > conflicting package all of the sudden? > > > > > > Well, how about we ask upstream to use EPEL repositories, just like RH > > > does with Fedora? Huh? Huh? > > > > +1 > > > > I imagine there'd still be cases where they went off and decided to do > > their own thing though, so maybe we should still decide how to handle > > that. > > Does it make things any easier to have Client / Server repos that > packages get moved to only when this sort of thing happens? By > default all packages go into the current "common" repo and when > problems like this arise the move to the specific repo. At least in > that case it isn't necessary to duplicate everything in both repos. > Only the one offs. > > Its messy no matter how you do it. :-/ Trying to build against the way 5 is set up is very hard.. I just have been using CentOS and then dealing with unavailabel packages by adding in the CentOS items. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From bojan at rexursive.com Thu Jul 12 22:28:58 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 13 Jul 2007 08:28:58 +1000 Subject: EPEL announcement planed for 20070726 In-Reply-To: <46965835.9030705@leemhuis.info> References: <46965835.9030705@leemhuis.info> Message-ID: <1184279338.9972.2.camel@shrek.rexursive.com> On Thu, 2007-07-12 at 18:35 +0200, Thorsten Leemhuis wrote: > Thursday, 26th 2007. July, I'm guessing... -- Bojan From sundaram at fedoraproject.org Thu Jul 12 23:32:40 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 13 Jul 2007 05:02:40 +0530 Subject: EPEL announcement planed for 20070726 In-Reply-To: <1184279338.9972.2.camel@shrek.rexursive.com> References: <46965835.9030705@leemhuis.info> <1184279338.9972.2.camel@shrek.rexursive.com> Message-ID: <4696BA18.4060305@fedoraproject.org> Bojan Smojver wrote: > On Thu, 2007-07-12 at 18:35 +0200, Thorsten Leemhuis wrote: > >> Thursday, 26th 2007. > > July, I'm guessing... It's in the subject. Rahul From buildsys at fedoraproject.org Fri Jul 13 13:34:21 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 13 Jul 2007 09:34:21 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-13 Message-ID: <20070713133421.B0D6A152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 13 NEW archivemail-0.7.0-6.el5 : A tool for archiving and compressing old email in mailboxes (!) cgdb-0.6.4-1.el5 : INVALID rebuild, not published! eclipse-cdt-3.1.2-5.el5 NEW fftw-3.1.2-5.el5 : Fast Fourier Transform library (!) gmrun-0.9.2-7.el5 : INVALID rebuild, not published! NEW limph-1.9.4-7.el5 : A PHP5-compatible network host/service poller with web interface NEW mod_evasive-1.10.1-3.el5 : Denial of Service evasion module for Apache NEW mysql-proxy-0.5.1-1.el5 : A proxy for the MySQL Client/Server protocol ntfsprogs-1.13.1-6.el5 NEW perl-MogileFS-Client-1.07-2.el5 : Client library for the MogileFS distributed file system phpPgAdmin-4.1.3-2.el5 NEW R-mvtnorm-0.7-2.el5 : Multivariate normal and T distribution R Package NEW tiquit-2.4-4.el5 : A PHP5-compatible help desk incident tracking/knowledgebase system Packages built and released for Fedora EPEL 4: 6 NEW archivemail-0.7.0-6.el4 : A tool for archiving and compressing old email in mailboxes NEW fftw-3.1.2-5.el4 : Fast Fourier Transform library NEW limph-1.9.4-7.el4 : A PHP5-compatible network host/service poller with web interface NEW perl-MogileFS-Client-1.07-2.el4.1 : Client library for the MogileFS distributed file system phpPgAdmin-4.1.3-2.el4 NEW tiquit-2.4-4.el4 : A PHP5-compatible help desk incident tracking/knowledgebase system Changes in Fedora EPEL 5: archivemail-0.7.0-6.el5 ----------------------- * Tue Jun 12 2007 Jon Ciesla 0.7.0-6 - Patch to fix imap handling, BZ 243846. cgdb-0.6.4-1.el5 ---------------- * Wed May 16 2007 - 0.6.4-1 - 0.6.4 - Fix broken info installation. - Enable SMP build. - Preserve the source time-stamp. - Replace install with %{__install}. eclipse-cdt-3.1.2-5.el5 ----------------------- * Wed Jul 11 2007 Jeff Johnston 3.1.2-5 - Resolves #247518, #246153, #246783, #246134, #245820 - Resolves #245611, #243184, #241782, #241612, #239620 - Resolves #238173. #239886 - Rebase autotools to 0.0.9. - Multiple fixes to automake editor - Multiple fixes to autoconf editor - Autotools editor preferences added fftw-3.1.2-5.el5 ---------------- * Thu Jul 12 2007 Rex Dieter 3.1.2-5 - fftw3(-devel): Provides: fftw(-devel) = %version ... - cleanup, +%check section (disabled by default) * Tue Jul 10 2007 Rex Dieter 3.1.2-4 - (re)name -> fftw3 (epel-only, for rpmforge compatibility, #246004) gmrun-0.9.2-7.el5 ----------------- * Sat Feb 10 2007 - 0.9.2-7 - Preserve the source time-stamp. limph-1.9.4-7.el5 ----------------- * Tue Jan 16 2007 Jon Ciesla - 1.9.4-7 - Added style.css to limph files mod_evasive-1.10.1-3.el5 ------------------------ * Tue Apr 10 2007 Konstantin Ryabitsev - 1.10.1-3 - Modify the URL and finally import into extras. mysql-proxy-0.5.1-1.el5 ----------------------- * Tue Jul 10 2007 Ruben Kerkhof 0.5.1-1 - Upstream released new version - Included examples * Sun Jul 01 2007 Ruben Kerkhof 0.5.0-1 - First version ntfsprogs-1.13.1-6.el5 ---------------------- * Wed Jul 11 2007 Tom "spot" Callaway 1.13.1-6 - build and install "extra" binaries by default (I was accidentally installing the scripts, not the binaries) This better resolves bz 247398 (thanks to Martin Riarte) perl-MogileFS-Client-1.07-2.el5 ------------------------------- * Wed Jun 20 2007 Ruben Kerkhof 1.07-2 - Incorporate suggestions from tibbs in review #240699: - Remove test which does nothing without a mogilefs server - Change URL to cpan site phpPgAdmin-4.1.3-2.el5 ---------------------- * Wed Jul 11 2007 Devrim Gunduz 4.1.3-2 - Added temporary patch #2 , per sf.net bug #1751614 R-mvtnorm-0.7-2.el5 ------------------- * Wed Jul 11 2007 Orion Poplawski - 0.7-2 - Comply with R packaging guidelines tiquit-2.4-4.el5 ---------------- * Mon May 07 2007 Jon Ciesla - 2.4-4 - Removed duplicate slash in symlink creation. Changes in Fedora EPEL 4: archivemail-0.7.0-6.el4 ----------------------- * Tue Jun 12 2007 Jon Ciesla 0.7.0-6 - Patch to fix imap handling, BZ 243846. fftw-3.1.2-5.el4 ---------------- * Thu Jul 12 2007 Rex Dieter 3.1.2-5 - fftw3(-devel): Provides: fftw(-devel) = %version ... - cleanup, +%check section (disabled by default) * Tue Jul 10 2007 Rex Dieter 3.1.2-4 - (re)name -> fftw3 (epel-only, for rpmforge compatibility, #246004) limph-1.9.4-7.el4 ----------------- * Tue Jan 16 2007 Jon Ciesla - 1.9.4-7 - Added style.css to limph files perl-MogileFS-Client-1.07-2.el4.1 --------------------------------- * Fri Jul 13 2007 Ruben Kerkhof 1.07-2.1 - Add missing BuildRequires * Wed Jun 20 2007 Ruben Kerkhof 1.07-2 - Incorporate suggestions from tibbs in review #240699: - Remove test which does nothing without a mogilefs server - Change URL to cpan site phpPgAdmin-4.1.3-2.el4 ---------------------- * Wed Jul 11 2007 Devrim Gunduz 4.1.3-2 - Added temporary patch #2 , per sf.net bug #1751614 tiquit-2.4-4.el4 ---------------- * Mon May 07 2007 Jon Ciesla - 2.4-4 - Removed duplicate slash in symlink creation. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dennis at ausil.us Fri Jul 13 13:36:25 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 13 Jul 2007 08:36:25 -0500 Subject: Fedora EPEL Package Build Report 2007-07-13 In-Reply-To: <20070713133421.B0D6A152131@buildsys.fedoraproject.org> References: <20070713133421.B0D6A152131@buildsys.fedoraproject.org> Message-ID: <200707130836.25733.dennis@ausil.us> Once upon a time Friday 13 July 2007, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora EPEL 5: 13 Just a quick note python-imaging was removed with this push. that is because it is in RHEL5-client and CentOS5 Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mastahnke at gmail.com Fri Jul 13 14:39:51 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Fri, 13 Jul 2007 09:39:51 -0500 Subject: Fedora EPEL Package Build Report 2007-07-13 In-Reply-To: <200707130836.25733.dennis@ausil.us> References: <20070713133421.B0D6A152131@buildsys.fedoraproject.org> <200707130836.25733.dennis@ausil.us> Message-ID: <7874d9dd0707130739u53242707w811f27c09066780b@mail.gmail.com> On 7/13/07, Dennis Gilmore wrote: > Once upon a time Friday 13 July 2007, buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora EPEL 5: 13 > > Just a quick note python-imaging was removed with this push. that is because > it is in RHEL5-client and CentOS5 > Is there a solution for those running RH 5 server? Maybe a topic for next weeks' EPEL meeting? stahnma > Dennis > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > From smooge at gmail.com Fri Jul 13 20:13:28 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 13 Jul 2007 14:13:28 -0600 Subject: Fedora EPEL Package Build Report 2007-07-13 In-Reply-To: <7874d9dd0707130739u53242707w811f27c09066780b@mail.gmail.com> References: <20070713133421.B0D6A152131@buildsys.fedoraproject.org> <200707130836.25733.dennis@ausil.us> <7874d9dd0707130739u53242707w811f27c09066780b@mail.gmail.com> Message-ID: <80d7e4090707131313j6d903319qae09a6c05d8fdb7b@mail.gmail.com> On 7/13/07, Michael Stahnke wrote: > On 7/13/07, Dennis Gilmore wrote: > > Once upon a time Friday 13 July 2007, buildsys at fedoraproject.org wrote: > > > Packages built and released for Fedora EPEL 5: 13 > > > > Just a quick note python-imaging was removed with this push. that is because > > it is in RHEL5-client and CentOS5 > > > Is there a solution for those running RH 5 server? Maybe a topic for > next weeks' EPEL meeting? > It should be as there will always be issues where people have Server/Desktop/etc but need something that is only included in one of the channels. The simplest solution would be to 'rebuild' the packages to match what is missing (or borrow them from Sci/CentOS). That might not be politically tastey.. but seems to be the best solution. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From rob.myers at gtri.gatech.edu Fri Jul 13 22:10:35 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Fri, 13 Jul 2007 18:10:35 -0400 Subject: EPEL 5 Dependency Report - 20070713 Message-ID: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> here are the broken dependencies in EPEL 5 as they appear in my tree from yesterday. let me know if anything looks wrong, or if you would rather i didn't post this report, or if you think notting saw into the future when he named the spam-o-matic script, or if mmcgrath is part of a conspiracy to make it seem like notting can see into the future. :) rob. Broken deps for i386 - EPEL 5 ---------------------------------------------------------- JSDoc - 1.10.2-3.el5.noarch requires perl(HTML::Template) SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ bcfg2 - 0.9.4-2.el5.noarch requires python-lxml bugzilla - 3.0-2.el5.noarch requires perl-Email-Send bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier bugzilla - 3.0-2.el5.noarch requires perl-Email-Address ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi dar - 2.3.4-1.el5.i386 requires par2cmdline evolution-bogofilter - 0.2.0-5.el5.1.i386 requires bogofilter fail2ban - 0.6.2-3.el5.noarch requires shorewall git-arch - 1.5.2.1-2.el5.i386 requires tla gmrun - 0.9.2-7.el5.i386 requires xterm nagios-plugins-fping - 1.4.6-3.el5.i386 requires /usr/sbin/fping nagios-plugins-game - 1.4.6-3.el5.i386 requires qstat nagios-plugins-ifoperstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) nagios-plugins-ifstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) ntfs-config - 1.0-0.4.rc5.el5.noarch requires ntfs-3g perl-Net-Pcap - 0.14-2.el5.i386 requires perl(IO::Interface) perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core python-Coherence - 0.2.1-3.el5.noarch requires python-nevow python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy qucs - 0.0.12-2.el5.i386 requires iverilog translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant zabbix - 1.1.7-1.el5.1.i386 requires fping Broken deps for x86_64 - EPEL 5 ---------------------------------------------------------- JSDoc - 1.10.2-3.el5.noarch requires perl(HTML::Template) SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ SDL_mixer - 1.2.7-2.el5.x86_64 requires timidity++ bcfg2 - 0.9.4-2.el5.noarch requires python-lxml bugzilla - 3.0-2.el5.noarch requires perl-Email-Send bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier bugzilla - 3.0-2.el5.noarch requires perl-Email-Address ctapi-cyberjack - 3.0.0-2.el5.x86_64 requires /usr/lib64/ctapi ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi dar - 2.3.4-1.el5.x86_64 requires par2cmdline evolution-bogofilter - 0.2.0-5.el5.1.x86_64 requires bogofilter fail2ban - 0.6.2-3.el5.noarch requires shorewall git-arch - 1.5.2.1-2.el5.x86_64 requires tla gmrun - 0.9.2-7.el5.x86_64 requires xterm nagios-plugins-fping - 1.4.6-3.el5.x86_64 requires /usr/sbin/fping nagios-plugins-game - 1.4.6-3.el5.x86_64 requires qstat nagios-plugins-ifoperstatus - 1.4.6-3.el5.x86_64 requires perl(Net::SNMP) nagios-plugins-ifstatus - 1.4.6-3.el5.x86_64 requires perl(Net::SNMP) ntfs-config - 1.0-0.4.rc5.el5.noarch requires ntfs-3g perl-Net-Pcap - 0.14-2.el5.x86_64 requires perl(IO::Interface) perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core python-Coherence - 0.2.1-3.el5.noarch requires python-nevow python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy qucs - 0.0.12-2.el5.x86_64 requires iverilog translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant zabbix - 1.1.7-1.el5.1.x86_64 requires fping From buildsys at fedoraproject.org Sat Jul 14 19:40:53 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 14 Jul 2007 15:40:53 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-14 Message-ID: <20070714194053.CF65B152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 3 NEW dx-samples-4.4.0-3.el5 : OpenDX Examples mksh-29g-1.el5 NEW sub2srt-0.5.3-2.el5 : Convert files in .sub format to .srt Packages built and released for Fedora EPEL 4: 2 mksh-29g-1.el4 NEW sub2srt-0.5.3-2.el4 : Convert files in .sub format to .srt Changes in Fedora EPEL 5: dx-samples-4.4.0-3.el5 ---------------------- * Wed Sep 20 2006 Dominik Mierzejewski 4.4.0-3 - fixed BuildRequires: mksh-29g-1.el5 -------------- * Sat Jul 14 2007 Robert Scheck 29g-1 - Upgrade to 29g sub2srt-0.5.3-2.el5 ------------------- * Sat Jul 14 2007 Marek Mahut - 0.5.3-2 - Rebuild * Fri Jun 29 2007 Marek Mahut - 0.5.3-1 - First build Changes in Fedora EPEL 4: mksh-29g-1.el4 -------------- * Sat Jul 14 2007 Robert Scheck 29g-1 - Upgrade to 29g sub2srt-0.5.3-2.el4 ------------------- * Sat Jul 14 2007 Marek Mahut - 0.5.3-2 - Rebuild * Fri Jun 29 2007 Marek Mahut - 0.5.3-1 - First build For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Sun Jul 15 13:00:14 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Jul 2007 15:00:14 +0200 Subject: Meetings (was: Re: Fedora EPEL Package Build Report 2007-07-13) In-Reply-To: <80d7e4090707131313j6d903319qae09a6c05d8fdb7b@mail.gmail.com> References: <20070713133421.B0D6A152131@buildsys.fedoraproject.org> <200707130836.25733.dennis@ausil.us> <7874d9dd0707130739u53242707w811f27c09066780b@mail.gmail.com> <80d7e4090707131313j6d903319qae09a6c05d8fdb7b@mail.gmail.com> Message-ID: <469A1A5E.7060101@leemhuis.info> On 13.07.2007 22:13, Stephen John Smoogen wrote: > On 7/13/07, Michael Stahnke wrote: >> On 7/13/07, Dennis Gilmore wrote: >>> Once upon a time Friday 13 July 2007, buildsys at fedoraproject.org wrote: >>>> Packages built and released for Fedora EPEL 5: 13 >>> Just a quick note python-imaging was removed with this push. that is because >>> it is in RHEL5-client and CentOS5 >> Is there a solution for those running RH 5 server? Maybe a topic for >> next weeks' EPEL meeting? > It should be I just added it to the schedule. While at it I'd like to use the chance to say something else (especially in the direction of the Steering Committee Members): The meetings are *IMHO* not there to work out all the details how to solve this or other problems -- that what we should use the mailing lists is for, as that the where people can easily participate even if they can't make the meeting due to more important issues or just because they live in another timzone. The meetings IMHO mainly should focus on decisions only (and even those should in an ideal world IMHO be found on the list) -- either accept a proposal that has been worked out and discussed on the lists or give a statement in which direction the Steering Committee would like to see a issue solved. Further: I'd really like it if people that own a task on the schedule would reply to the "topics for tomorrows meeting mails" and give a status update before the meeting. Then we avoid stuff like this: chair> ping foo; what's the status of bar foo> off, sorry, I just did baz foo> okay, here is the status: blahh blub and blib blib while blop blop As that's time consuming and likely annoying for everyone. Comments? CU knurd From fedora at leemhuis.info Sun Jul 15 13:05:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Jul 2007 15:05:41 +0200 Subject: python-imaging (was: Re: Fedora EPEL Package Build Report 2007-07-13) In-Reply-To: <80d7e4090707131313j6d903319qae09a6c05d8fdb7b@mail.gmail.com> References: <20070713133421.B0D6A152131@buildsys.fedoraproject.org> <200707130836.25733.dennis@ausil.us> <7874d9dd0707130739u53242707w811f27c09066780b@mail.gmail.com> <80d7e4090707131313j6d903319qae09a6c05d8fdb7b@mail.gmail.com> Message-ID: <469A1BA5.7060907@leemhuis.info> On 13.07.2007 22:13, Stephen John Smoogen wrote: > On 7/13/07, Michael Stahnke wrote: >> On 7/13/07, Dennis Gilmore wrote: >>> Once upon a time Friday 13 July 2007, buildsys at fedoraproject.org wrote: >>>> Packages built and released for Fedora EPEL 5: 13 >>> Just a quick note python-imaging was removed with this push. that is because >>> it is in RHEL5-client and CentOS5 >> Is there a solution for those running RH 5 server? Maybe a topic for >> next weeks' EPEL meeting? > It should be as there will always be issues where people have > Server/Desktop/etc but need something that is only included in one of > the channels. The simplest solution would be to 'rebuild' the packages > to match what is missing (or borrow them from Sci/CentOS). [...] Should be easy afaics: get the RHEL SRPM, put the spec file in EPEL, lower the EVR (?), rebuild, ship. Sounds like a plan. Can the @redhat.com people please state if that sort of trick is acceptable for Red Hat? CU thl (?) -- we should do that to avoid overriding the EL package accidentally. Adding a "0." preix in release should do the trick and is easily done From fedora at leemhuis.info Sun Jul 15 13:09:36 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Jul 2007 15:09:36 +0200 Subject: EPEL announcement planed for 20070726 In-Reply-To: <469673CF.1090408@fedoraproject.org> References: <46965835.9030705@leemhuis.info> <469673CF.1090408@fedoraproject.org> Message-ID: <469A1C90.3080305@leemhuis.info> On 12.07.2007 20:32, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> just a heads up; the current plan is to officially announce EPEL on >> Thursday, 26th 2007. Yes, that's one week later that estimated last >> week, as we need a bit more time to fix all broken deps before the >> announcement. >> >> While at it: Note that new and updated packages for EPEL will go to into >> EPEL-testing repo after the announcement (?) and get moved to the proper >> repo at a later point of time. The plan is to do the move from testing >> to the proper repo in parallel with the "quarterly" EL-releases like >> RHEL 5.1. >> > > Have you folks decided where and how the announcements should be send? > > Fedora announce list > RHEL 4 and 5 lists and announce lists > Red Hat press release > Other news sites > > This might be a useful reference: > > http://fedoraproject.org/wiki/Marketing/SpreadingNews Karsten, what is our plan exactly? I'd really like to see some announcement got out -- it doesn't have to be businesswire, but some linux-sites will likely pick it up if we just send some sane stuff in mail in their direction. CU knurd From fedora at leemhuis.info Sun Jul 15 13:21:01 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Jul 2007 15:21:01 +0200 Subject: Log from this weeks EPEL-SIG meeting (20070711) Message-ID: <469A1F3D.4030603@leemhuis.info> 00:00:12 < knurd> | Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00:12 < knurd> | Hi everybody; who's around? 00:00:12 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00:13 * | knurd likes to remind people that the schedule and the topic list for todays meeting can be found on http://fedoraproject.org/wiki/EPEL/Schedule 00:00:28 * | Jeff_S here 00:00:30 * | mmcgrath here 00:00:43 * | nirik is here. 00:01:14 --> | daMaestro (Jon) has joined #fedora-meeting 00:01:31 < knurd> | lala 00:01:42 * | daMaestro sings along 00:01:48 < daMaestro> | epel++ 00:01:50 < daMaestro> | ;-) 00:02:01 < knurd> | well, let's start slowly 00:02:04 < knurd> | daMaestro, :-) 00:02:06 --- | knurd has changed the topic to: EPEL Meeting ? broken deps ? Jeff_S 00:02:12 --> | mra (matt anderson) has joined #fedora-meeting 00:02:19 < knurd> | Jeff_S, any progress? 00:02:25 < knurd> | did you poke people? 00:02:43 < Jeff_S> | no, I thought mmcgrath did enough of that for me :) 00:02:53 < mmcgrath> | :: sigh :: 00:02:55 < Jeff_S> | actually, I know a couple packages got fixed 00:02:56 < knurd> | hehe :) 00:02:57 < daMaestro> | i got poked 00:03:05 < daMaestro> | but i have no idea how to fix it.. 00:03:09 < knurd> | daMaestro, eeryone got accidentally 00:03:12 < Jeff_S> | but I ran it again today and there is still a big list 00:03:21 < daMaestro> | ahh, ok; good 00:03:37 < knurd> | mmcgrath, is the script working now? 00:03:41 < Jeff_S> | spot says he is planning to import a bunch of his packages soon 00:03:50 < Jeff_S> | so that should help 00:03:54 < mmcgrath> | knurd: Here's the problem with the script... it requires koji. 00:04:02 --- | knurd has changed the topic to: EPEL Meeting ? broken deps/spam-o-magic ? Jeff_S/mmcgrath 00:04:05 * | spot is working on it 00:04:07 < knurd> | mmcgrath, what? 00:04:13 < mmcgrath> | So I'm working to rewrite that part of it to read from owners.list. 00:04:19 < knurd> | how does that script run for FE-6? 00:04:19 < Jeff_S> | but there are some packages which seem to be looking at stuff that is not available in EL4 00:04:19 < spot> | i've just been sidetracked by the need to get rocksndiamonds fixed 00:04:35 * | mmcgrath has no idea. 00:04:42 < knurd> | mmcgrath, ask mschwendt? 00:04:44 < mmcgrath> | spot: Are you working on the script? 00:04:46 < knurd> | mmcgrath, he might know 00:04:56 < knurd> | mmcgrath, and remmeber, owners.epel.list ;-) 00:04:56 < nirik> | I think it has a local copy of owners.list it uses? 00:05:02 < Jeff_S> | http://www.sheltren.com/epel/repoclosure/2007-07-11/epel4-i386-repoclosure.txt <--- see for example postgresql-pgpoolAdmin which requires a higher version of PHP than is in EL4 00:05:02 < mmcgrath> | :) 00:05:41 < quaid> | oi! 00:05:42 < knurd> | well, the plan is to annouce in 8 days iirc 00:05:45 < quaid> | sorry I'm late 00:05:47 < mmcgrath> | spot: ping? 00:05:55 < knurd> | do we get everything fixed until then? 00:05:59 < knurd> | I doubt that a bit 00:06:15 < nirik> | I think we should try and if we need to slip the announcement we can do that... 00:06:23 < Jeff_S> | I doubt it too. The spam script would help, IMO. 00:06:25 < knurd> | mmcgrath, spot afaik only wanted to build his packages, which should solve some of the deps 00:06:35 < mmcgrath> | knurd: ahh. thanks. 00:06:48 < nirik> | mmcgrath: did the spam-o-matic make a valid run after the invalid one? Or it hasn't made a valid run yet? 00:06:52 < knurd> | mmcgrath, send mschwendt a mail about the script 00:06:58 < knurd> | he really should know the answer 00:07:05 < knurd> | mmcgrath, or shall I do? 00:07:13 < mmcgrath> | I'll ping him 00:07:18 < knurd> | mmcgrath, thx 00:07:34 < knurd> | while we were on the shedule already 00:07:36 --- | knurd has changed the topic to: EPEL Meeting ? EPEL annoucement ? quiad 00:07:45 < knurd> | so, broken deps not resolved yet 00:07:50 < knurd> | shall we move it one week? 00:07:58 < knurd> | annoucements isn't prepares either afaik 00:08:00 < knurd> | quaid, ? 00:08:21 < quaid> | eh, I put it off because it's not hard to write 00:08:36 < knurd> | hehe 00:08:36 < quaid> | it's not a blocking factor, fwiw 00:08:40 < Jeff_S> | mmcgrath: also if you need help w/ changing the script for epel, I can help 00:09:05 < mmcgrath> | Jeff_S: thanks. 00:09:23 < knurd> | so, move annoucement back by one week as broken deps likely won't get fixed in the next 8 days? 00:09:35 < quaid> | sounds wise 00:09:48 < quaid> | this is one of those "release early, but only when it's not broken" situations 00:09:54 < Jeff_S> | knurd: +1 -- we need to get this sorted out first 00:09:55 < knurd> | agreed 00:09:57 < nirik> | sure. 00:10:11 < knurd> | 20070726 would be the new target then 00:10:39 < Jeff_S> | and maybe we need a big warning on the wiki about pushing stuff to EPEL before deps are there? 00:10:52 * | dgilmore is here 00:10:55 < Jeff_S> | people seem to be assuming that the deps are there just because they are in fedora (extras) 00:10:55 < knurd> | Jeff_S, maybe add something to the faq 00:11:23 < knurd> | that might be the best afaics 00:11:38 < knurd> | hi dgilmore 00:11:46 < nirik> | wish we could block anything with broken deps from pushing. ;( 00:11:58 < knurd> | so, nobody yelled, so 20070726 is the new target then 00:12:09 < knurd> | nirik, bodhi in hte long term :-) 00:12:12 * | knurd moves on 00:12:19 --- | knurd has changed the topic to: EPEL Meeting ? push new packages to testing after EPEL annoucement ? dgilmore 00:12:24 < knurd> | dgilmore, I added that 00:12:26 < nirik> | true, although bodhi doesn't currently do repoclosure either. ;) 00:12:32 < knurd> | just wanted to make sure we still are in agreement 00:12:43 < knurd> | all new packages after annoucement go to the testing/ dir? 00:12:59 < knurd> | and we hand move stuff over if peole ask for it? 00:13:26 < knurd> | any maybe do a full testing/X > X move some months later (with RHEL 5.1 maybe) 00:13:36 < knurd> | do we agree on that? 00:13:46 * | nirik thinks that sounds good. 00:13:52 < Jeff_S> | +1 00:14:16 < knurd> | dgilmore, is that possible from the infrastrucutre/pushers point? 00:14:23 < dgilmore> | knurd: i said last week I wont spend the time to manually move bits from testing to stable 00:14:33 < dgilmore> | its manual and labour intensive 00:14:44 < knurd> | dgilmore, so what do you suggest as solution 00:14:46 < dgilmore> | i can push everything to testing pretty easily 00:14:55 <-- | XulChris has quit (Read error: 113 (No route to host)) 00:14:58 < knurd> | sure, that's the plan 00:15:01 < nirik> | the only reason we would need anything manual is for security 00:15:06 < knurd> | but what about security fixes? 00:15:06 < dgilmore> | we have no easy way to move things to stable 00:15:24 < knurd> | well, we need a solution 00:15:27 < dgilmore> | how do we know whats security 00:15:39 < knurd> | someone tells us (via the wiki or a e-mail alias) 00:15:42 < dgilmore> | we can easily put things in one location 00:15:56 < dgilmore> | but to move things we have no way to do that 00:16:05 < nirik> | yeah, without a bodhi we need a manual process. ;( 00:16:19 < knurd> | dgilmore, we use the push scripts for another repo 00:16:30 < knurd> | there a simple move and createrepo works 00:16:39 < knurd> | sure, it's a ugly as hell 00:16:42 < nirik> | dgilmore: wouldn't it just be a matter of 'mv testing/foobar.rpm ../5/; createrepo '? 00:16:42 < knurd> | but possible 00:16:51 < nirik> | yeah... ;( 00:16:52 < knurd> | nirik, exactly that is what I mean 00:17:16 < dgilmore> | nirik: sure but you need to do that mv for each package for each arch and SRPMS 00:17:39 < knurd> | dgilmore, sure, but a simple script can do that 00:17:40 < nirik> | yeah. Not fun at all... but beats having no security updates. ;( 00:17:48 < knurd> | and it should not happen that often 00:17:52 < knurd> | nirik, +1 00:18:09 < dgilmore> | what about new packages? 00:18:18 < nirik> | we can ponder on it and see if we can think of a better way to do it? I can't off hand tho. 00:18:20 < dgilmore> | they go to testing? 00:18:21 < knurd> | we could do monthly "make testing become official repo" until EPEL is bigger 00:18:24 < knurd> | dgilmore, yes 00:18:27 < nirik> | new packages and any other udpates go to testing. 00:18:28 < dgilmore> | when do they go stable? 00:18:43 < nirik> | when rhel does a minor bump. 00:18:46 < knurd> | dgilmore, the old plan was to do that with each RHEL minor bump 00:18:54 < nirik> | 5.0 -> 5.1... then we move testing over 00:18:58 < knurd> | but for the start phase it might be better to do it more often 00:00:07 < dgilmore> | people will want new packages immediatly 00:00:21 < knurd> | every month or ever two months maybe? 00:00:43 < knurd> | dgilmore, and when we do what people want we have lots of broken deps 00:00:46 < nirik> | couldn't people who want a new package enable testing? 00:00:47 < knurd> | just look at EPEL now 00:00:52 < knurd> | nirik, +1 00:20:52 < knurd> | EPEL is for EL, not for Fedora -- thus we need to be a bit more carefull 00:20:56 < knurd> | espeially with broken deps 00:21:05 < knurd> | we don't want to scare people away 00:21:13 < knurd> | other opinions? 00:21:21 < dgilmore> | we need new push scripts then 00:21:36 < dgilmore> | we cant easily do what you want with what we have 00:21:56 < knurd> | dgilmore, I'm willing to do that 00:22:08 < knurd> | e.g. move the securty updates from testing to stable 00:22:18 < knurd> | just need access to the repo then 00:22:29 < dgilmore> | knurd: that is nota huge problem 00:22:30 < knurd> | I suppose nirik would be willing to help as well with it 00:22:39 < nirik> | sure. 00:22:42 < dgilmore> | what is is checking for broken deps before doing pushes 00:22:46 < knurd> | if we share the burden then it should work until we get bodhi for epel 00:23:10 < nirik> | dgilmore: now? nothing. :( repoclosure is really slow too unfortunately. 00:23:17 < knurd> | security updates should normally not introduce broken deps 00:23:42 < dgilmore> | nirik: exactly and each time you find something broken you have to start over 00:23:42 < nirik> | for security I would be willing to manually run repoclosure before any push... 00:23:47 < knurd> | that should be a rare prolem 00:23:57 < knurd> | nirik, +1 00:24:06 < knurd> | nirik, or just look at old package <-> new package 00:24:13 < knurd> | that's easier 00:24:14 < nirik> | I think wwoods was working on a way to get repoclosure or something like it going faster. Not sure where that is tho 00:24:20 <-- | lancelan has quit (Read error: 104 (Connection reset by peer)) 00:24:49 --> | lancelan (Lance Davis) has joined #fedora-meeting 00:25:00 < knurd> | so, deal? 00:25:06 < knurd> | all new packages go to testing 00:25:13 < knurd> | security updates hand-moved over 00:25:23 < knurd> | nirik and I will help with that 00:25:32 < knurd> | and we set up a wiki page or a alias up for that? 00:25:34 < nirik> | so, we need script for moving security updates and mass moving testing on minor release? The other current scripts would work ok for testing itself? 00:25:52 < knurd> | script for moving security updates > +1 00:26:06 < knurd> | mass moving testing > + 0.5 00:26:16 < Jeff_S> | well, the mass move is quite simple 00:26:19 < knurd> | that should not happen that often and likely can be done manually 00:26:24 < knurd> | Jeff_S, agreed 00:26:36 < knurd> | check that all deps are sane in stable + testing 00:26:40 < nirik> | well, one is a more general case of the other. ;) But yeah, not a big deal now. 00:26:44 < knurd> | move everything over from testing, done 00:26:47 < Jeff_S> | but yes, a script for moving security updates would be quite helpful I think 00:27:25 < knurd> | settled then? 00:27:55 * | knurd will take silence as agreement soon 00:27:55 < Jeff_S> | sure :) 00:28:03 < knurd> | so let's move on 00:28:12 --- | knurd has changed the topic to: EPEL Meeting ? new meeting time? ? all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) 00:28:18 * | knurd checks that page 00:28:25 < wwoods> | notting and skvidal and lmacken and I discussed a tool for doing quick single-package depchecking but there's no implementation yet 00:28:37 < wwoods> | no one has committed to implementing it 00:28:47 < knurd> | dgilmore, what would be your preferred time? 00:28:57 < Jeff_S> | wwoods: sounds interesting 00:29:22 < Jeff_S> | looks like everyone who edited the page likes the current time 00:29:33 < dgilmore> | knurd: i havent had time to even think about it 00:30:03 < knurd> | well, let's try to get this settled until next week 00:30:16 < dgilmore> | the times that work best for me are probably no good for knurd 00:30:40 < knurd> | dgilmore, sorry, timezone problem... 00:31:02 < knurd> | maybe I should just leave, that would make things easier :-) 00:31:17 < knurd> | dgilmore, ping me when you got some minutes, maybe we can work something out 00:31:23 * | knurd moves on for now 00:31:37 --- | knurd has changed the topic to: EPEL Meeting ? Communication plan for enterprise customers/ISVs/IHVs ? stahnma, quaid 00:31:39 < knurd> | any news? 00:31:55 < knurd> | quaid, or just revisit after annoucement? 00:32:35 < knurd> | lala 00:32:48 * | knurd takes that as revisit next week 00:32:52 --- | knurd has changed the topic to: EPEL Meeting ? ExcludeArch TrackerBugs for EPEL ? notting/knurd 00:32:55 < knurd> | opinions? 00:33:05 < knurd> | + 0.75 for EPEL-Excludearch trackers from me 00:33:21 < knurd> | can't hurt and is not htat much work 00:33:35 < nirik> | yeah, I think we can have epel versions... as long as the arch folks know to look at them. 00:33:44 < dgilmore> | -1 i think we should reuse what exists 00:33:56 < knurd> | dgilmore, that's to confusing 00:33:57 < quaid> | sorry, was writing :) 00:34:08 < Jeff_S> | dgilmore: but won't we have differences between EPEL/fedora? 00:34:12 < nirik> | I don't much care. I think we should track them tho. 00:34:12 < knurd> | dgilmore, as people that might want to fix Fedora stuff would run into EPEl stuf 00:34:31 <-- | tibbs has quit (Remote closed the connection) 00:34:33 --> | tibbs_ (Jason L Tibbitts III) has joined #fedora-meeting 00:34:56 < dgilmore> | having to keep track of things in two places will mean sometimes things get missed 00:35:01 --> | frozty_sa (frozt01100101) has joined #fedora-meeting 00:35:05 < knurd> | dgilmore, we can block the old Fedora bugs with the EPEL specific bug 00:35:09 < dgilmore> | we dont have different trackers for FC-6 and F-7 00:35:32 < dgilmore> | EL-4 and EL-5 are just different versions 00:35:51 < nirik> | what are the current blockers called? 00:36:12 < knurd> | FE-ExcludeArch-x86_64 iirc 00:36:37 < nirik> | were their different ones for fe and fc? 00:36:44 < knurd> | nirik, nope 00:36:53 < knurd> | not that I'm aware off 00:37:20 <-- | k0k has quit (Read error: 104 (Connection reset by peer)) 00:37:33 < knurd> | I'm fine going without them 00:37:39 < knurd> | as long as it's no general problem 00:38:00 < nirik> | we can always revisit... so for now we reuse the existing ones? 00:38:18 < knurd> | nirik, I'd say just ignore the issue for EPEL 00:38:34 < knurd> | devel counts, and that's fedora 00:38:42 --> | _blah_ (rob) has joined #fedora-meeting 00:38:57 < knurd> | I'll send something to the list 00:39:03 < knurd> | then we can decide next week 00:39:12 --- | knurd has changed the topic to: EPEL Meeting ? RHX and EPEL ? quaid 00:39:26 < knurd> | quaid, can wait for some more weeks iirc? 00:39:29 < quaid> | nothing new to report yet 00:39:34 < quaid> | yep 00:39:41 < quaid> | it's going to take the time it takes 00:39:47 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:39:49 < knurd> | quaid, thx 00:39:53 < knurd> | anything else? 00:40:15 * | knurd will close the meeting in 60 00:40:17 < knurd> | seems not 00:40:29 * | quaid no tengo mas 00:40:41 < dgilmore> | i noticed that dag made some derogatory comments about epel on the centos mailing list 00:40:51 < quaid> | oh, good 00:40:58 < quaid> | nothing quite like keeping the flames warm 00:41:01 < dgilmore> | saying that we dont want to work with him 00:41:12 < quaid> | in fact 00:42:01 --- | tibbs_ is now known as tibbs 00:42:01 < quaid> | I thin that's in our guidelines 00:42:02 < quaid> | it says somewheren "EPEL refuses to work with the followng people" 00:42:02 < quaid> | and then a list 00:42:02 < dgilmore> | quaid: :) 00:42:02 * | quaid hopes his sarcasm is evident in the irclog 00:42:03 < nirik> | ok. 00:42:03 <-- | Jeff_S has quit (Read error: 104 (Connection reset by peer)) 00:42:03 * | mmcgrath twiddles thumbs :) 00:42:05 < quaid> | it's hard because these guys all had good points 00:42:15 < quaid> | but they put way too much heat into it 00:42:29 < quaid> | and burned the bridge before it could be built 00:42:45 < quaid> | anyway, water under the ... oh, wait, nevermind 00:42:49 < knurd> | we maybe should some carefully choose words into the wiki 00:42:55 < knurd> | why we didn#t go for repotags 00:43:03 < dgilmore> | http://lists.centos.org/pipermail/centos/2007-July/083569.html 00:43:04 < quaid> | a good FAQ entry 00:43:08 < knurd> | and that we suggest that our contributors cooperate 00:43:26 --> | Jeff_S (Jeff Sheltren) has joined #fedora-meeting 00:43:27 < quaid> | we may be answering this for RHEL's support people when they have customers confused in the future :) 00:43:32 < dgilmore> | i didint know if we should have a statement on the wiki somewhere saying we are willing to accept anybody 00:44:15 < dgilmore> | knurd: repotags were not part of it 00:44:35 < knurd> | well, can't hurt to put some carefully choose words up 00:45:00 < knurd> | any yes, saying somewhere "we are open to annybody to join us" can't hurt either 00:45:24 < knurd> | I can work some sentences out and will send them out 00:45:24 < dgilmore> | i think skvidal would need to do some serious voodoo magic in yum to try and deal with multiple repos providing the same packages in a sane and consistent manner 00:45:29 < dgilmore> | not sure what his voodoo skills are like 00:45:49 < dgilmore> | that is all :) 00:45:53 --> | orc_emac (orc_emac) has joined #fedora-meeting 00:45:59 < knurd> | k, thx for you hints dgilmore 00:46:02 < knurd> | anything else? 00:46:02 < nirik> | priorities or something taging gpg keys to repo would be the only options I can think of. 00:46:39 < daMaestro> | ! 00:46:49 < dgilmore> | knurd: feel free to close up shop 00:47:00 * | knurd will close the meeting in 30 00:47:02 < daMaestro> | I have a question 00:47:11 < knurd> | nirik, a solution might arise over time (or not) 00:47:13 < orc_emac> | knurd: at the end of the day, epel is NOT open to anyone who wants to add patent restricted material; will not sign onto the CLA; or is unwilling to build with non-free binaries 00:47:25 < orc_emac> | that is all OK 00:47:26 < knurd> | orc_emac, okay, you have a point 00:47:35 * | knurd will close the meeting in 20 00:47:39 < orc_emac> | there cannot be total union of all independent packagerts 00:47:39 < mmcgrath> | daMaestro: yes? 00:47:46 < knurd> | knurd, I can add that to the wiki, can't hurt 00:47:50 < daMaestro> | revisor needs the pykickstart from f7; are we "allowed" to build revisor-pykickstart from the bits from f7? 00:47:57 * | knurd will close the meeting in 10 00:47:57 < daMaestro> | or do we have to branch? 00:48:06 < daMaestro> | basically, we'd like to see revisor in epel 00:48:16 < quaid> | fwiw, I'm going to work with the RH GSS (support team) to make sure their standard system checking script knows hunt for non-RHN-provided packages (such as EPEL); I'm sure they have a method, but that's one that would help the support team 00:48:21 < daMaestro> | but we have a blocker requirement of the pykickstart from f7 00:48:21 < nirik> | orc_emac: very true. Can't be everything for everyone. :) 00:48:26 < mmcgrath> | daMaestro: hit us up in #epel after the meeting :) 00:48:30 < daMaestro> | ok 00:48:30 < quaid> | there ya go :) 00:48:34 < knurd> | quaid, good to know :) 00:48:37 * | knurd will close the meeting in 10 00:48:47 < knurd> | -- MARK -- Meeting end 00:48:48 --- | knurd has changed the topic to: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting 00:48:51 <-- | _blah_ has left #fedora-meeting ( ) 00:48:51 < knurd> | thx everyone 00:48:54 < mmcgrath> | knurd: thanks 00:49:00 <-- | daMaestro has left #fedora-meeting ( "Leaving") 00:49:00 --- | You're now known as knurd_afk 00:49:03 < knurd_afk> | have fun! 00:49:08 < knurd_afk> | bye 00:49:15 <-- | orc_emac has left #fedora-meeting ( ) 00:49:28 <-- | Jeff_S has left #fedora-meeting ( ) From fedora at leemhuis.info Sun Jul 15 13:58:34 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Jul 2007 15:58:34 +0200 Subject: EPEL report week 28, 2007 Message-ID: <469A280A.3050706@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week28 = Weekly EPEL Summary = Week 28/2007 == Most important happenings == * target date for for official EPEL announcement was set back by one week onto July the 26th. We need more time to fix all broken deps beforehand (and make sure any new ones hit the repo). Volunteers that help with that would be greatly appreciated. * discussions on the mailing list how to handle python-imaging -- it's in EL5Client, but not in EL5Server; thus if we don't ship it users will run into broken deps on EL5Server == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * Jeff_S (Jeff Sheltren) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * quiad (KarstenWade) Missing from the Steering Committee: * stahnma (MichaelStahnke) Others that participated the meeting: daMaestro === Summary === * broken deps/spam-o-magic ? Jeff_S/mmcgrath * not much progress * mmcgrath still fighting with the script (the latest version seems to depend on koji) he'll talk to mschwendt to find one for EPEL/get help * EPEL announcement ? quiad * we push the estimated announce-date back by one week to 20070726 -- we need more time to fix deps (aka: "release early, but only when it's not broken") * push new packages to testing after EPEL annoucement ? dgilmore * we discussed how to handle new and updated packages in the near future. We proceed as planed earlier: push everything to testing/ (which will become stable with the next quarterly update) and hand-move important updates over to stable; knurd and nirik are willing to help with that job, as that's a manual process. We need a wiki page and/or a e-mail alias for that. The problem will be solved with switching to bodhi in the long term * new meeting time? ? all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) * no new meeting time wound yet; looks a bit like everyone who edited the page likes the current time * ExcludeArch TrackerBugs for EPEL ? notting/knurd * some discussions, no agreement; discuss issue on the list again * free discussions * some derogatory comments about EPEL on another mailing list and some discussions how to improve our docs to avoid make clear what EPEL wants/what EPEL is about === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00086.html == Stats == === General === Number of EPEL Contributors 110 We welcome 3 new contributors: jgranado_AT_redhat.com, lindner_AT_inuus.com, roland_AT_redhat.com === EPEL 5 === Number of source packages: 462 Number of binary packages: 834 There are 23 new Packages: * archivemail | A tool for archiving and compressing old email in mailboxes * colordiff | Color terminal highlighter for diff files * cvsps | Patchset tool for CVS * fftw | Fast Fourier Transform library * fwrestart | A way to more safely re-load firewall rules remotely * geomview | Interactive 3D viewing program * glibmm24 | C++ interface for GTK2 (a GUI library for X) * gshutdown | GShutDown is an advanced shut down utility for GNOME * libpaper | Library and tools for handling papersize * libsigc++20 | Typesafe signal framework for C++ * limph | A PHP5-compatible network host/service poller with web interface * mod_evasive | Denial of Service evasion module for Apache * mussh | Multihost SSH wrapper * mysql-proxy | A proxy for the MySQL Client/Server protocol * ntfsprogs | NTFS filesystem libraries and utilities * perl-MogileFS-Client | Client library for the MogileFS distributed file system * pylibacl | POSIX.1e ACLs library wrapper for python * pyxattr | Extended attributes library wrapper for Python * roundcubemail | Round Cube Webmail is a browser-based multilingual IMAP client * scrub | Disk scrubbing program * sub2srt | Convert files in .sub format to .srt * tiquit | A PHP5-compatible help desk incident tracking/knowledgebase system === EPEL 4 === Number of source packages: 284 Number of binary packages: 583 There are 13 new Packages: * archivemail | A tool for archiving and compressing old email in mailboxes * fftw | Fast Fourier Transform library * geomview | Interactive 3D viewing program * itk | Object oriented extensions to Tk * libpaper | Library and tools for handling papersize * limph | A PHP5-compatible network host/service poller with web interface * perl-MogileFS-Client | Client library for the MogileFS distributed file system * pylibacl | POSIX.1e ACLs library wrapper for python * pyxattr | Extended attributes library wrapper for Python * scrub | Disk scrubbing program * sub2srt | Convert files in .sub format to .srt * tiquit | A PHP5-compatible help desk incident tracking/knowledgebase system ---- ["CategoryEPELReports"] From fedora at leemhuis.info Sun Jul 15 16:02:19 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Jul 2007 18:02:19 +0200 Subject: Draft of Personal Package Request In-Reply-To: <7874d9dd0706281724m11525c07x4307005f6804500@mail.gmail.com> References: <7874d9dd0706202111pefd1144l91d540f70a014215@mail.gmail.com> <4683EA6C.10108@leemhuis.info> <7874d9dd0706281724m11525c07x4307005f6804500@mail.gmail.com> Message-ID: <469A450B.6080504@leemhuis.info> On 29.06.2007 02:24, Michael Stahnke wrote: > On 6/28/07, Thorsten Leemhuis wrote: >> On 21.06.2007 06:11, Michael Stahnke wrote: >>> I updated the draft on the package request email/notification on the wiki. >>> >>> Found currently at : >>> http://fedoraproject.org/wiki/MichaelStahnke/Draft-EPELPackageRequest >>> >>> Reads as follows: [...] >> I just was in the situation where I needed a dep for one of my packages >> in EPEL that is not yet part of it. I took your text and modified it a >> bit to give it a more "personal" touch. Michael, what do you think of >> it? Maybe you can take parts of it? >> >> --- >> Hi! >> >> There are people around that would like to see some of your Fedora >> packages in Extra Packages for Enterprise Linux >> [...] > Look good to me. I normally tend to write short, so that if someone > isn't that interested, I didn't explain everything to them already. > Thorough is probably better here though. I added both your and my version to the wiki at http://fedoraproject.org/wiki/EPEL/AskForFedoraPackageInEPEL If other write something up please consider adding it to that page as well. Cu thl From kwade at redhat.com Sun Jul 15 17:39:23 2007 From: kwade at redhat.com (Karsten Wade) Date: Sun, 15 Jul 2007 10:39:23 -0700 Subject: (draft) announcement Message-ID: <1184521163.26011.93.camel@erato.phig.org> ## Here is a first pass for a release announcement. There are two ## important things, in order of priority: what this is and how to find ## it; write short and clear announcement. ## ## Old-time TV announcer style ... If you use enterprise-class Linux (EL) distributions derived from Fedora, such as Red Hat Enterprise Linux or CentOS, we have something very exciting for you. Ever find yourself rebuilding a Fedora package for your EL version because it didn't ship with the EL distro? Have you built Perl packages with cpan2rpm and felt, "There must be a better way." Friends, there is. May we introduce ... Extra Packages for Enterprise Linux (EPEL) EPEL is a community of package maintainers working from inside of Fedora. Many are the same people who maintain the Fedora package. Yet, there is plenty of room for new packages and contributors. You can read all you want here: http://fedoraproject.org/wiki/EPEL How to use EPEL: http://fedoraproject.org/wiki/EPEL/FAQ#howtouse You can look for packages here: http://fedoraproject.org/wiki/EPEL/FAQ#WhereIsTheSoftwareRepositoryLocated Looking for a package not in EPEL or other questions? http://fedoraproject.org/wiki/EPEL/FAQ ## Fin -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tchung at fedoraproject.org Sun Jul 15 18:08:54 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Sun, 15 Jul 2007 11:08:54 -0700 Subject: EPEL announcement planed for 20070726 In-Reply-To: <469A1C90.3080305@leemhuis.info> References: <46965835.9030705@leemhuis.info> <469673CF.1090408@fedoraproject.org> <469A1C90.3080305@leemhuis.info> Message-ID: <369bce3b0707151108t45ac389x23c66d8038ea475f@mail.gmail.com> On 7/15/07, Thorsten Leemhuis wrote: > On 12.07.2007 20:32, Rahul Sundaram wrote: > > Thorsten Leemhuis wrote: > >> just a heads up; the current plan is to officially announce EPEL on > >> Thursday, 26th 2007. Yes, that's one week later that estimated last > >> week, as we need a bit more time to fix all broken deps before the > >> announcement. > >> > >> While at it: Note that new and updated packages for EPEL will go to into > >> EPEL-testing repo after the announcement (?) and get moved to the proper > >> repo at a later point of time. The plan is to do the move from testing > >> to the proper repo in parallel with the "quarterly" EL-releases like > >> RHEL 5.1. > >> > > > > Have you folks decided where and how the announcements should be send? > > > > Fedora announce list > > RHEL 4 and 5 lists and announce lists > > Red Hat press release > > Other news sites > > > > This might be a useful reference: > > > > http://fedoraproject.org/wiki/Marketing/SpreadingNews > > Karsten, what is our plan exactly? I'd really like to see some > announcement got out -- it doesn't have to be businesswire, but some > linux-sites will likely pick it up if we just send some sane stuff in > mail in their direction. > > CU > knurd As long as we include the announcement in our FWN, it should be picked by most popular Linux news sites. Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From fedora at leemhuis.info Sun Jul 15 18:57:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 15 Jul 2007 20:57:26 +0200 Subject: EPEL 5 Dependency Report - 20070713 In-Reply-To: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> References: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <469A6E16.2000903@leemhuis.info> Hi! If you E-Mail is in the below list you are BCCed to this mail (?) please read on until the end! chris.stone_AT_gmail.com chrisw_AT_redhat.com dev_AT_nigelj.com eric.tanguy_AT_univ-nantes.fr foolish_AT_guezz.net frank-buettner_AT_gmx.net gilboad_AT_gmail.com icon_AT_fedoraproject.org jbowes_AT_redhat.com jeff_AT_ocjtech.us john_AT_ncphotography.com jwboyer_AT_jdub.homelinux.org jwilson_AT_redhat.com lists_AT_forevermore.net lxtnow_AT_gmail.com matthias_AT_rpmforge.net mcepl_AT_redhat.com mmcgrath_AT_redhat.com roozbeh_AT_farsiweb.info steve_AT_silug.org tcallawa_AT_redhat.com So, now that I hopefully got your attention let's get to the point: Rob Myers was so kind to check for broken deps in EPEL5; his results were posted in https://www.redhat.com/archives/epel-devel-list/2007-July/msg00081.html I took his results and looked who own those Packages in EPEL and the missing deps in Fedora. Seems one of those is yours; please take a look at the list (sorted by owner e-mail): --- chris.stone_AT_gmail.com: Package php-pear-Crypt-CHAP requires php-mcrypt which is not in EPEL; its owned by in Fedora. chris.stone_AT_gmail.com: Package php-pear-Crypt-CHAP requires php-mhash which is not in EPEL; its owned by in Fedora. chrisw_AT_redhat.com,jwboyer_AT_jdub.homelinux.org,jbowes_AT_redhat.com: Package git-arch requires tla which is not in EPEL; its owned by jwboyer_AT_jdub.homelinux.org in Fedora. dev_AT_nigelj.com: Package SDL_mixer requires timidity++ which is not in EPEL; its owned by twoerner_AT_redhat.com in Fedora. eric.tanguy_AT_univ-nantes.fr: Package qucs requires iverilog which is not in EPEL; its owned by cbalint_AT_redhat.com,cgoorah_AT_yahoo.com.au in Fedora. foolish_AT_guezz.net: Package perl-libwhisker2 requires perl-MD5 which is not in EPEL; its owned by andreas_AT_bawue.net in Fedora. foolish_AT_guezz.net: Package perl-Net-Pcap requires perl-IO-Interface which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. frank-buettner_AT_gmx.net: Package ctapi-cyberjack requires ctapi-common which is not in EPEL; its owned by ville.skytta_AT_iki.fi,frank-buettner_AT_gmx.net in Fedora. gilboad_AT_gmail.com: Package gmrun requires xterm which is not in EPEL; its owned by mlichvar_AT_redhat.com in Fedora. jeff_AT_ocjtech.us,icon_AT_fedoraproject.org: Package bcfg2 requires python-lxml which is not in EPEL; its owned by shahms_AT_shahms.com in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-Address which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-Address which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-MIME-Attachment-Stripper which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-MIME-Attachment-Stripper which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-MIME-Modifier which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-MIME-Modifier which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-MIME which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-MIME which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-Reply which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-Reply which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-Send which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-Send which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Email-Simple which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Template-Toolkit which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Template-Toolkit which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. john_AT_ncphotography.com: Package bugzilla requires perl-Template-Toolkit which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. jwilson_AT_redhat.com: Package zabbix requires fping which is not in EPEL; its owned by kaboom_AT_oobleck.net in Fedora. lists_AT_forevermore.net: Package dar requires par2cmdline which is not in EPEL; its owned by Laurent.Rineau__fedora_AT_normalesup.org in Fedora. lxtnow_AT_gmail.com: Package ntfs-config requires ntfs-3g which is not in EPEL; its owned by tcallawa_AT_redhat.com in Fedora. matthias_AT_rpmforge.net: Package python-Coherence requires python-nevow which is not in EPEL; its owned by matthias_AT_rpmforge.net in Fedora. matthias_AT_rpmforge.net: Package python-Coherence requires python-twisted-core which is not in EPEL; its owned by thomas_AT_apestaart.org in Fedora. matthias_AT_rpmforge.net: Package python-Coherence requires python-twisted-web which is not in EPEL; its owned by thomas_AT_apestaart.org in Fedora. matthias_AT_rpmforge.net: Package python-Coherence requires SOAPpy which is not in EPEL; its owned by chris.stone_AT_gmail.com in Fedora. mcepl_AT_redhat.com: Package JSDoc requires perl-HTML-Template which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. mmcgrath_AT_redhat.com: Package nagios-plugins-fping requires fping which is not in EPEL; its owned by kaboom_AT_oobleck.net in Fedora. mmcgrath_AT_redhat.com: Package nagios-plugins-game requires qstat which is not in EPEL; its owned by andy_AT_smile.org.ua in Fedora. mmcgrath_AT_redhat.com: Package nagios-plugins-ifoperstatus requires perl-Net-SNMP which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. mmcgrath_AT_redhat.com: Package nagios-plugins-ifstatus requires perl-Net-SNMP which is not in EPEL; its owned by jpo_AT_di.uminho.pt in Fedora. roozbeh_AT_farsiweb.info: Package translate-toolkit requires python-enchant which is not in EPEL; its owned by roozbeh_AT_farsiweb.info in Fedora. steve_AT_silug.org: Package perl-Test-Base requires perl-Module-Install which is not in EPEL; its owned by steve_AT_silug.org in Fedora. tcallawa_AT_redhat.com: Package evolution-bogofilter requires bogofilter which is not in EPEL; its owned by adrian_AT_lisas.de in Fedora. --- Note that this list and script generated and might have some false positives. I apologizes in advance if such a false positive hit you -- please ignore it and let me know. Please get those missing deps fixed withing one week (?), as we plan to announce EPEL on 20070726 (that's 11 days away). We by then want to have a clean repo where all deps are satisfied. If you don't fix the deps in time we might be forced to further delay the EPEL announcement or have to remove your package from the repo for now. In case of questions reply to the list, to me in private or grab me on IRC in #epel. Ohh, btw, thanks for participating in EPEL. CU knurd (?) -- it's being send to epel-devel-list also (?) -- either by asking the Fedora maintainer to build the package in EPEL or by becoming its maintainer in EPEL; see http://fedoraproject.org/wiki/EPEL/FAQ#head-4abf2d9b3e246e2b96746da2867c2436c42351d4 for details in case you have questions how to move on. From icon at fedoraproject.org Sun Jul 15 20:11:30 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sun, 15 Jul 2007 16:11:30 -0400 Subject: python-imaging (was: Re: Fedora EPEL Package Build Report 2007-07-13) In-Reply-To: <469A1BA5.7060907@leemhuis.info> References: <20070713133421.B0D6A152131@buildsys.fedoraproject.org> <200707130836.25733.dennis@ausil.us> <7874d9dd0707130739u53242707w811f27c09066780b@mail.gmail.com> <80d7e4090707131313j6d903319qae09a6c05d8fdb7b@mail.gmail.com> <469A1BA5.7060907@leemhuis.info> Message-ID: On 7/15/07, Thorsten Leemhuis wrote: > (?) -- we should do that to avoid overriding the EL package > accidentally. Adding a "0." preix in release should do the trick and is > easily done This was the policy back in the fedora.us days, specifically for this reason. All packages were 0.foo.xx (or, I guess, 0%{dist}.xx. If that's what we have to do to avoid broken repositories, then I'm fine with doing that. -- Konstantin Ryabitsev Montr?al, Qu?bec From mmcgrath at redhat.com Sun Jul 15 21:29:48 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 15 Jul 2007 16:29:48 -0500 Subject: spam-o-epel Message-ID: <469A91CC.3050904@redhat.com> Spam-o-epel should have gotten run and had deps sent out for RHEL5. Can anyone verify they did or did not get a notification? If we're ready I'll set it up for regular runs. -Mike From mastahnke at gmail.com Sun Jul 15 22:09:48 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sun, 15 Jul 2007 17:09:48 -0500 Subject: (draft) announcement In-Reply-To: <1184521163.26011.93.camel@erato.phig.org> References: <1184521163.26011.93.camel@erato.phig.org> Message-ID: <7874d9dd0707151509g1b176d4w9b5e48bc1967aac8@mail.gmail.com> On 7/15/07, Karsten Wade wrote: > ## Here is a first pass for a release announcement. There are two > ## important things, in order of priority: what this is and how to find > ## it; write short and clear announcement. > ## > ## Old-time TV announcer style ... > > If you use enterprise-class Linux (EL) distributions derived from > Fedora, such as Red Hat Enterprise Linux or CentOS, we have something > very exciting for you. > > Ever find yourself rebuilding a Fedora package for your EL version > because it didn't ship with the EL distro? > > Have you built Perl packages with cpan2rpm and felt, "There must be a > better way." > > Friends, there is. May we introduce ... > > Extra Packages for Enterprise Linux (EPEL) > > EPEL is a community of package maintainers working from inside of > Fedora. Many are the same people who maintain the Fedora package. Yet, > there is plenty of room for new packages and contributors. > > You can read all you want here: > > http://fedoraproject.org/wiki/EPEL > > How to use EPEL: > > http://fedoraproject.org/wiki/EPEL/FAQ#howtouse > > You can look for packages here: > > http://fedoraproject.org/wiki/EPEL/FAQ#WhereIsTheSoftwareRepositoryLocated > > Looking for a package not in EPEL or other questions? > > http://fedoraproject.org/wiki/EPEL/FAQ > > ## Fin > -- > Karsten Wade, 108 Editor ^ Fedora Documentation Project > Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject > quaid.108.redhat.com | gpg key: AD0E0C41 > ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > Somewhere I think we want to touch on the quality of the packages from Fedora. I think that is a big selling point. Granted, not all packages are perfect, but as a RHEL subscriber, my company thinks highly of RHEL and how it is built, and thus like the way Fedora (at least the former Core) was built. Somehow, that should be captured int eh announment, methinks. I am also hesitant to use the Perl message because LOTS of perl stuff still isn't in EPEL. (/me rebuilt several modules last week for RHEL). stahnma From fedora at leemhuis.info Mon Jul 16 04:36:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 16 Jul 2007 06:36:40 +0200 Subject: spam-o-epel In-Reply-To: <469A91CC.3050904@redhat.com> References: <469A91CC.3050904@redhat.com> Message-ID: <469AF5D8.9080304@leemhuis.info> On 15.07.2007 23:29, Mike McGrath wrote: > Spam-o-epel should have gotten run and had deps sent out for RHEL5. Can > anyone verify they did or did not get a notification? [...] I got one, but I currently tend to think it's a false positive: > mail-notification has broken dependencies in the EPEL: > On x86_64: > mail-notification-evolution-plugin - 4.0-2.el5.x86_64 requires libeutil.so.0()(64bit) > On i386: > mail-notification-evolution-plugin - 4.0-2.el5.i386 requires libeutil.so.0 > Please resolve this as soon as possible. libeutil.so.0 is provided by evolution. That for sure is part of the EL5Client; and during build the evo-devel pacakge was found, with makes me even more confident that it's there and also part of the buildroot. But evolution iirc. is not part of the EL5Server. Did the script correctly detect that, did that fool the script somehow or is there something else going wrong somewhere? CU thl From gilboad at gmail.com Mon Jul 16 07:12:59 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 16 Jul 2007 10:12:59 +0300 Subject: EPEL 5 Dependency Report - 20070713 In-Reply-To: <469A6E16.2000903@leemhuis.info> References: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> <469A6E16.2000903@leemhuis.info> Message-ID: <9050516b0707160012l29fb8dpe5284d7856d27e38@mail.gmail.com> On 7/15/07, Thorsten Leemhuis wrote: > Hi! > > If you E-Mail is in the below list you are BCCed to this mail (?) please > read on until the end! > ... > gilboad_AT_gmail.com: Package gmrun requires xterm which is not in EPEL; > its owned by mlichvar_AT_redhat.com in Fedora. Weird. [[SSH] gilboa at gilboa-work-probe ~]$ rpm -qf /usr/bin/xterm xterm-215-4.el5.x86_64 [[SSH] gilboa at gilboa-work-probe ~]$ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5 (Tikanga) - Gilboa From fedora at leemhuis.info Mon Jul 16 07:54:44 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 16 Jul 2007 09:54:44 +0200 Subject: EPEL 5 Dependency Report - 20070713 In-Reply-To: <9050516b0707160012l29fb8dpe5284d7856d27e38@mail.gmail.com> References: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> <469A6E16.2000903@leemhuis.info> <9050516b0707160012l29fb8dpe5284d7856d27e38@mail.gmail.com> Message-ID: <469B2444.3070801@leemhuis.info> On 16.07.2007 09:12, Gilboa Davara wrote: > On 7/15/07, Thorsten Leemhuis wrote: >> Hi! >> >> If you E-Mail is in the below list you are BCCed to this mail (?) please >> read on until the end! > ... >> gilboad_AT_gmail.com: Package gmrun requires xterm which is not in EPEL; >> its owned by mlichvar_AT_redhat.com in Fedora. > Weird. [...] Yeah, really interesting :-/ Did the spam-o-epel stuff Mike set up later yesterday trigger as well (it send a mail directly to you inbox with a subject "Broken dependencies: foo")? If not just ignore. Sorry for the noise. CU thl From jwilson at redhat.com Mon Jul 16 14:35:04 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 16 Jul 2007 10:35:04 -0400 Subject: EPEL 5 Dependency Report - 20070713 In-Reply-To: <469A6E16.2000903@leemhuis.info> References: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> <469A6E16.2000903@leemhuis.info> Message-ID: <469B8218.1030208@redhat.com> Thorsten Leemhuis wrote: [...] > So, now that I hopefully got your attention let's get to the point: Rob > Myers was so kind to check for broken deps in EPEL5; his results were > posted in > https://www.redhat.com/archives/epel-devel-list/2007-July/msg00081.html > > I took his results and looked who own those Packages in EPEL and the > missing deps in Fedora. Seems one of those is yours; please take a look > at the list (sorted by owner e-mail): [...] > jwilson_AT_redhat.com: Package zabbix requires fping which is not in > EPEL; its owned by kaboom_AT_oobleck.net in Fedora. [...] Oops. I've fping'd Chris to see what he'd like to do wrt fping getting into epel... :) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mmcgrath at redhat.com Mon Jul 16 15:25:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 16 Jul 2007 10:25:14 -0500 Subject: EPEL 5 Dependency Report - 20070713 In-Reply-To: <469B2444.3070801@leemhuis.info> References: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> <469A6E16.2000903@leemhuis.info> <9050516b0707160012l29fb8dpe5284d7856d27e38@mail.gmail.com> <469B2444.3070801@leemhuis.info> Message-ID: <469B8DDA.6030001@redhat.com> Thorsten Leemhuis wrote: > On 16.07.2007 09:12, Gilboa Davara wrote: > >> On 7/15/07, Thorsten Leemhuis wrote: >> >>> Hi! >>> >>> If you E-Mail is in the below list you are BCCed to this mail (?) please >>> read on until the end! >>> >> ... >> >>> gilboad_AT_gmail.com: Package gmrun requires xterm which is not in EPEL; >>> its owned by mlichvar_AT_redhat.com in Fedora. >>> >> Weird. [...] >> > > Yeah, really interesting :-/ > > Did the spam-o-epel stuff Mike set up later yesterday trigger as well > (it send a mail directly to you inbox with a subject "Broken > dependencies: foo")? If not just ignore. > > Sorry for the noise. > Just so everyone knows, emails would have gone out for the following packages: Broken deps for i386 ---------------------------------------------------------- JSDoc - 1.10.2-3.el5.noarch requires perl(HTML::Template) SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ bcfg2 - 0.9.3-2.el5.noarch requires python-lxml bcfg2 - 0.9.4-2.el5.noarch requires python-lxml bugzilla - 3.0-1.el5.noarch requires perl(Email::Send) bugzilla - 3.0-1.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-1.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-1.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-1.el5.noarch requires perl(Template::Config) bugzilla - 3.0-1.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-1.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-1.el5.noarch requires perl(Email::Address) bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-2.el5.noarch requires perl-Email-Address bugzilla - 3.0-2.el5.noarch requires perl-Email-Send bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi dar - 2.3.4-1.el5.i386 requires par2cmdline eggdrop - 1.6.18-7.el5.i386 requires libdns.so.21 evolution-bogofilter - 0.2.0-5.el5.1.i386 requires bogofilter evolution-bogofilter - 0.2.0-5.el5.1.i386 requires libeutil.so.0 fail2ban - 0.6.2-3.el5.noarch requires shorewall git-arch - 1.5.2.1-2.el5.i386 requires tla limph - 1.9.4-7.el5.noarch requires php-mcrypt limph - 1.9.4-7.el5.noarch requires php-mhash limph-hostagent - 1.9.4-7.el5.noarch requires php-mcrypt limph-hostagent - 1.9.4-7.el5.noarch requires php-mhash mail-notification-evolution-plugin - 4.0-2.el5.i386 requires libeutil.so.0 nagios-plugins-fping - 1.4.6-3.el5.i386 requires /usr/sbin/fping nagios-plugins-game - 1.4.6-3.el5.i386 requires qstat nagios-plugins-ifoperstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) nagios-plugins-ifstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) ntfs-config - 1.0-0.4.rc5.el5.noarch requires ntfs-3g ntfs-config - 1.0-0.3.rc4.el5.noarch requires ntfs-3g perl-Module-Build - 0.2807-1.el5.noarch requires perl(Pod::Readme) >= 0:0.04 perl-Net-Pcap - 0.14-2.el5.i386 requires perl(IO::Interface) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries::QueueManager) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries::Queue) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries::Message) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQClient::MQSeries) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries) perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) perl-libwhisker2 - 2.4-2.el5.noarch requires perl(MD5) perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash plone - 2.5.3-1.el5.i386 requires python-imaging python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core python-Coherence - 0.2.1-3.el5.noarch requires python-nevow python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web python-docutils - 0.4-3.el5.noarch requires python-imaging qucs - 0.0.12-2.el5.i386 requires iverilog translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant zabbix - 1.1.7-1.el5.i386 requires fping zabbix - 1.1.7-1.el5.1.i386 requires fping Broken deps for ppc ---------------------------------------------------------- JSDoc - 1.10.2-3.el5.noarch requires perl(HTML::Template) SDL_mixer - 1.2.7-2.el5.ppc requires timidity++ bcfg2 - 0.9.3-2.el5.noarch requires python-lxml bcfg2 - 0.9.4-2.el5.noarch requires python-lxml bugzilla - 3.0-1.el5.noarch requires perl(Email::Send) bugzilla - 3.0-1.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-1.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-1.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-1.el5.noarch requires perl(Template::Config) bugzilla - 3.0-1.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-1.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-1.el5.noarch requires perl(Email::Address) bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-2.el5.noarch requires perl-Email-Address bugzilla - 3.0-2.el5.noarch requires perl-Email-Send bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) ctapi-cyberjack - 3.0.0-2.el5.ppc requires /usr/lib/ctapi dar - 2.3.4-1.el5.ppc requires par2cmdline eggdrop - 1.6.18-7.el5.ppc requires libdns.so.21 fail2ban - 0.6.2-3.el5.noarch requires shorewall git-arch - 1.5.2.1-2.el5.ppc requires tla limph - 1.9.4-7.el5.noarch requires php-mcrypt limph - 1.9.4-7.el5.noarch requires php-mhash limph-hostagent - 1.9.4-7.el5.noarch requires php-mcrypt limph-hostagent - 1.9.4-7.el5.noarch requires php-mhash nagios-plugins-fping - 1.4.6-3.el5.ppc requires /usr/sbin/fping nagios-plugins-game - 1.4.6-3.el5.ppc requires qstat nagios-plugins-ifoperstatus - 1.4.6-3.el5.ppc requires perl(Net::SNMP) nagios-plugins-ifstatus - 1.4.6-3.el5.ppc requires perl(Net::SNMP) ntfs-config - 1.0-0.4.rc5.el5.noarch requires ntfs-3g ntfs-config - 1.0-0.3.rc4.el5.noarch requires ntfs-3g perl-Module-Build - 0.2807-1.el5.noarch requires perl(Pod::Readme) >= 0:0.04 perl-Net-Pcap - 0.14-2.el5.ppc requires perl(IO::Interface) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries::QueueManager) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries::Queue) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries::Message) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQClient::MQSeries) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries) perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) perl-libwhisker2 - 2.4-2.el5.noarch requires perl(MD5) perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash plone - 2.5.3-1.el5.ppc requires python-imaging python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core python-Coherence - 0.2.1-3.el5.noarch requires python-nevow python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web python-docutils - 0.4-3.el5.noarch requires python-imaging qucs - 0.0.12-2.el5.ppc requires iverilog translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant zabbix - 1.1.7-1.el5.ppc requires fping zabbix - 1.1.7-1.el5.1.ppc requires fping Broken deps for x86_64 ---------------------------------------------------------- JSDoc - 1.10.2-3.el5.noarch requires perl(HTML::Template) SDL_mixer - 1.2.7-2.el5.x86_64 requires timidity++ SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ bcfg2 - 0.9.3-2.el5.noarch requires python-lxml bcfg2 - 0.9.4-2.el5.noarch requires python-lxml bugzilla - 3.0-1.el5.noarch requires perl(Email::Send) bugzilla - 3.0-1.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-1.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-1.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-1.el5.noarch requires perl(Template::Config) bugzilla - 3.0-1.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-1.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-1.el5.noarch requires perl(Email::Address) bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-2.el5.noarch requires perl-Email-Address bugzilla - 3.0-2.el5.noarch requires perl-Email-Send bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) ctapi-cyberjack - 3.0.0-2.el5.x86_64 requires /usr/lib64/ctapi ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi dar - 2.3.4-1.el5.x86_64 requires par2cmdline eggdrop - 1.6.18-7.el5.x86_64 requires libdns.so.21()(64bit) evolution-bogofilter - 0.2.0-5.el5.1.x86_64 requires libeutil.so.0()(64bit) evolution-bogofilter - 0.2.0-5.el5.1.x86_64 requires bogofilter fail2ban - 0.6.2-3.el5.noarch requires shorewall git-arch - 1.5.2.1-2.el5.x86_64 requires tla limph - 1.9.4-7.el5.noarch requires php-mcrypt limph - 1.9.4-7.el5.noarch requires php-mhash limph-hostagent - 1.9.4-7.el5.noarch requires php-mcrypt limph-hostagent - 1.9.4-7.el5.noarch requires php-mhash mail-notification-evolution-plugin - 4.0-2.el5.x86_64 requires libeutil.so.0()(64bit) nagios-plugins-fping - 1.4.6-3.el5.x86_64 requires /usr/sbin/fping nagios-plugins-game - 1.4.6-3.el5.x86_64 requires qstat nagios-plugins-ifoperstatus - 1.4.6-3.el5.x86_64 requires perl(Net::SNMP) nagios-plugins-ifstatus - 1.4.6-3.el5.x86_64 requires perl(Net::SNMP) ntfs-config - 1.0-0.3.rc4.el5.noarch requires ntfs-3g ntfs-config - 1.0-0.4.rc5.el5.noarch requires ntfs-3g perl-Module-Build - 0.2807-1.el5.noarch requires perl(Pod::Readme) >= 0:0.04 perl-Net-Pcap - 0.14-2.el5.x86_64 requires perl(IO::Interface) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries::QueueManager) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries::Queue) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries::Message) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQClient::MQSeries) perl-SOAP-Lite - 0.68-4.el5.noarch requires perl(MQSeries) perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) perl-libwhisker2 - 2.4-2.el5.noarch requires perl(MD5) perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash plone - 2.5.3-1.el5.x86_64 requires python-imaging python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core python-Coherence - 0.2.1-3.el5.noarch requires python-nevow python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web python-docutils - 0.4-3.el5.noarch requires python-imaging qucs - 0.0.12-2.el5.x86_64 requires iverilog translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant zabbix - 1.1.7-1.el5.1.x86_64 requires fping zabbix - 1.1.7-1.el5.x86_64 requires fping I'm looking into exactly what our packages build against. This report was generated against Server but it looks like I need to add Client as well. -Mike From rob.myers at gtri.gatech.edu Mon Jul 16 19:03:32 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 16 Jul 2007 15:03:32 -0400 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <4690F1B8.1@fedoraproject.org> References: <4687C867.8060400@leemhuis.info> <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> <4690E3A8.2040906@leemhuis.info> <4690F1B8.1@fedoraproject.org> Message-ID: <1184612612.3413.220.camel@rxm-581b.stl.gtri.gatech.edu> On Sun, 2007-07-08 at 19:46 +0530, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > > > If the Fedora maintainer within less then 1 month wants to participate > > in EPEL, then the EPEL maintainer of the package must hand primary per > > release maintainership back to the Fedora maintainer (and become > > comaintainer, if interested), if he's interested. If the Fedora > > maintainer at a later point in time wants to participate in EPEL and get > > his package back then the EPEL maintainer should strongly consider doing > > so, but doesn't has to. > > > > How does this sound? > > Good but I would remove the gender specific language. how does this look? If an EPEL maintainer wants to get a Fedora package into EPEL, first check the ContributorStatus document, located in the wiki at http://fedoraproject.org/wiki/EPEL/ContributorStatus . If the Fedora maintainer of the package has indicated a desire not to participate in EPEL then the EPEL maintainer can request the branch directly via the standard procedures (e.g. via bugzilla currently). The EPEL maintainer should CC the Fedora maintainer on the branch request, so the Fedora maintainer knows that the package is maintained in EPEL as well. If it is unclear if the Fedora maintainer of the package participates in EPEL then the EPEL maintainer should mail the Fedora maintainer and ask about their plans for EPEL in general and the package at hand. If there is no answer within seven days the EPEL maintainer is free to request the EPEL branch (CC the Fedora maintainer here as well). If the Fedora maintainer later decides to participate in EPEL, and no more than one month has passed, then the EPEL maintainer of the package must hand primary per release maintainership back to the Fedora maintainer (and become comaintainer, if interested). If the Fedora maintainer later decides to participate in EPEL, and more than one month has passed, the EPEL maintainer of the package should strongly consider returning maintainership, but does not have to. rob. From sundaram at fedoraproject.org Mon Jul 16 20:44:01 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Jul 2007 02:14:01 +0530 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <1184612612.3413.220.camel@rxm-581b.stl.gtri.gatech.edu> References: <4687C867.8060400@leemhuis.info> <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> <4690E3A8.2040906@leemhuis.info> <4690F1B8.1@fedoraproject.org> <1184612612.3413.220.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <469BD891.5020500@fedoraproject.org> rob myers wrote: If the Fedora > maintainer later decides to participate in EPEL, and more than one month > has passed, the EPEL maintainer of the package should strongly consider > returning maintainership, but does not have to. Looks better but I would suggest recommending co-maintainership rather than a complete hand off. If a Fedora package maintainer has shown no interest when asked and a new maintainer has taken over and been working on EPEL which has a different release strategy and policies then it is better than the existing maintainer in EPEL work together with the Fedora maintainer and help in any transition process or continue as a team. Rahul From rob.myers at gtri.gatech.edu Mon Jul 16 20:54:32 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 16 Jul 2007 16:54:32 -0400 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <469BD891.5020500@fedoraproject.org> References: <4687C867.8060400@leemhuis.info> <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> <4690E3A8.2040906@leemhuis.info> <4690F1B8.1@fedoraproject.org> <1184612612.3413.220.camel@rxm-581b.stl.gtri.gatech.edu> <469BD891.5020500@fedoraproject.org> Message-ID: <1184619272.3413.222.camel@rxm-581b.stl.gtri.gatech.edu> On Tue, 2007-07-17 at 02:14 +0530, Rahul Sundaram wrote: > rob myers wrote: > If the Fedora > > maintainer later decides to participate in EPEL, and more than one month > > has passed, the EPEL maintainer of the package should strongly consider > > returning maintainership, but does not have to. > > Looks better but I would suggest recommending co-maintainership rather > than a complete hand off. If a Fedora package maintainer has shown no > interest when asked and a new maintainer has taken over and been working > on EPEL which has a different release strategy and policies then it is > better than the existing maintainer in EPEL work together with the > Fedora maintainer and help in any transition process or continue as a team. how about if we reword the last bit to be "... should strongly consider co-maintainership, but does not have to." rob. From sundaram at fedoraproject.org Mon Jul 16 20:56:50 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 17 Jul 2007 02:26:50 +0530 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <1184619272.3413.222.camel@rxm-581b.stl.gtri.gatech.edu> References: <4687C867.8060400@leemhuis.info> <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> <4690E3A8.2040906@leemhuis.info> <4690F1B8.1@fedoraproject.org> <1184612612.3413.220.camel@rxm-581b.stl.gtri.gatech.edu> <469BD891.5020500@fedoraproject.org> <1184619272.3413.222.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <469BDB92.5080508@fedoraproject.org> rob myers wrote: > On Tue, 2007-07-17 at 02:14 +0530, Rahul Sundaram wrote: >> rob myers wrote: >> If the Fedora >>> maintainer later decides to participate in EPEL, and more than one month >>> has passed, the EPEL maintainer of the package should strongly consider >>> returning maintainership, but does not have to. >> Looks better but I would suggest recommending co-maintainership rather >> than a complete hand off. If a Fedora package maintainer has shown no >> interest when asked and a new maintainer has taken over and been working >> on EPEL which has a different release strategy and policies then it is >> better than the existing maintainer in EPEL work together with the >> Fedora maintainer and help in any transition process or continue as a team. > > how about if we reword the last bit to be "... should strongly consider > co-maintainership, but does not have to." Yes, that would work. Rahul From rob.myers at gtri.gatech.edu Mon Jul 16 21:08:42 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 16 Jul 2007 17:08:42 -0400 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <469BDB92.5080508@fedoraproject.org> References: <4687C867.8060400@leemhuis.info> <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> <4690E3A8.2040906@leemhuis.info> <4690F1B8.1@fedoraproject.org> <1184612612.3413.220.camel@rxm-581b.stl.gtri.gatech.edu> <469BD891.5020500@fedoraproject.org> <1184619272.3413.222.camel@rxm-581b.stl.gtri.gatech.edu> <469BDB92.5080508@fedoraproject.org> Message-ID: <1184620122.3413.224.camel@rxm-581b.stl.gtri.gatech.edu> On Tue, 2007-07-17 at 02:26 +0530, Rahul Sundaram wrote: > rob myers wrote: > > On Tue, 2007-07-17 at 02:14 +0530, Rahul Sundaram wrote: > >> rob myers wrote: > >> If the Fedora > >>> maintainer later decides to participate in EPEL, and more than one month > >>> has passed, the EPEL maintainer of the package should strongly consider > >>> returning maintainership, but does not have to. > >> Looks better but I would suggest recommending co-maintainership rather > >> than a complete hand off. If a Fedora package maintainer has shown no > >> interest when asked and a new maintainer has taken over and been working > >> on EPEL which has a different release strategy and policies then it is > >> better than the existing maintainer in EPEL work together with the > >> Fedora maintainer and help in any transition process or continue as a team. > > > > how about if we reword the last bit to be "... should strongly consider > > co-maintainership, but does not have to." > > Yes, that would work. here is a complete version, with the co-maintainership changes rahul suggested. comments? If an EPEL maintainer wants to get a Fedora package into EPEL, first check the ContributorStatus document, located in the wiki at http://fedoraproject.org/wiki/EPEL/ContributorStatus . If the Fedora maintainer of the package has indicated a desire not to participate in EPEL then the EPEL maintainer can request the branch directly via the standard procedures (e.g. via bugzilla currently). The EPEL maintainer should CC the Fedora maintainer on the branch request, so the Fedora maintainer knows that the package is maintained in EPEL as well. If it is unclear if the Fedora maintainer of the package participates in EPEL then the EPEL maintainer should mail the Fedora maintainer and ask about their plans for EPEL in general and the package at hand. If there is no answer within seven days the EPEL maintainer is free to request the EPEL branch (CC the Fedora maintainer here as well). If the Fedora maintainer later decides to participate in EPEL, and no more than one month has passed, then the EPEL maintainer of the package must hand primary per release maintainership back to the Fedora maintainer (and become comaintainer, if interested). If the Fedora maintainer later decides to participate in EPEL, and more than one month has passed, the EPEL maintainer of the package should strongly consider co-maintainership, but does not have to. rob. From fedora at leemhuis.info Tue Jul 17 04:48:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 06:48:47 +0200 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <1184620122.3413.224.camel@rxm-581b.stl.gtri.gatech.edu> References: <4687C867.8060400@leemhuis.info> <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> <4690E3A8.2040906@leemhuis.info> <4690F1B8.1@fedoraproject.org> <1184612612.3413.220.camel@rxm-581b.stl.gtri.gatech.edu> <469BD891.5020500@fedoraproject.org> <1184619272.3413.222.camel@rxm-581b.stl.gtri.gatech.edu> <469BDB92.5080508@fedoraproject.org> <1184620122.3413.224.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <469C4A2F.1050803@leemhuis.info> On 16.07.2007 23:08, rob myers wrote: > On Tue, 2007-07-17 at 02:26 +0530, Rahul Sundaram wrote: >> rob myers wrote: >>> On Tue, 2007-07-17 at 02:14 +0530, Rahul Sundaram wrote: >>>> rob myers wrote: > [...] thx rob for working on this. > here is a complete version, with the co-maintainership changes rahul > suggested. comments? Looks good. I'd like to get this ratified in tomorrows meeting. (Note that the old stuff is in the wiki already at http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-00c9e731bb7bc5bb78caf8d124da3a329400fcd8 If this was ratified just add the new text there please. tia!) Ohh, can somebody handle that for me? I'll miss the meeting tomorrow because I'll help a colleague from work with moving to his new house. CU thl From fedora at leemhuis.info Tue Jul 17 05:05:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 07:05:00 +0200 Subject: resolution for python-imaging in EPEL In-Reply-To: <469B7528.3070800@redhat.com> References: <469B7528.3070800@redhat.com> Message-ID: <469C4DFC.2050408@leemhuis.info> On 16.07.2007 15:39, Joel Andres Granados wrote: > > reference : BZ#246444 > > I have 1 of 2 choices: > [...] > Comments greatly appreciated. The better place for this questions is epel-devel-list (CCed and reply to set), where this has been discussed already in the past days and likely will get discussed further. It's also a topic for tomorrows EPEL SIG meeting (20070718, #fedora-meeting, 17:00 UTC). Join us ;-) BTW, I'd currently prefer to take the python-imaging from RHEL, lower the EVR (by using a "0." at the start of Release), and ship it in EPEL, so users of EL5Server have it available as well, and users of EL5Client or CentOS will get their normal package. Not ideal, but KISS and should work if nobody does stupid things. CU knurd P.S.: /me wonders if mailman will eat the follow-up to epel-devel-list at redhat.com P.P.S.:/me bets it will From fedora at leemhuis.info Tue Jul 17 06:01:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 08:01:40 +0200 Subject: EPEL announcement planed for 20070726 In-Reply-To: <369bce3b0707151108t45ac389x23c66d8038ea475f@mail.gmail.com> References: <46965835.9030705@leemhuis.info> <469673CF.1090408@fedoraproject.org> <469A1C90.3080305@leemhuis.info> <369bce3b0707151108t45ac389x23c66d8038ea475f@mail.gmail.com> Message-ID: <469C5B44.3020101@leemhuis.info> On 15.07.2007 20:08, Thomas Chung wrote: > On 7/15/07, Thorsten Leemhuis wrote: >> On 12.07.2007 20:32, Rahul Sundaram wrote: >>> Thorsten Leemhuis wrote: >>>> just a heads up; the current plan is to officially announce EPEL on >>>> Thursday, 26th 2007. Yes, that's one week later that estimated last >>>> week, as we need a bit more time to fix all broken deps before the >>>> announcement. >>>> >>>> While at it: Note that new and updated packages for EPEL will go to into >>>> EPEL-testing repo after the announcement (?) and get moved to the proper >>>> repo at a later point of time. The plan is to do the move from testing >>>> to the proper repo in parallel with the "quarterly" EL-releases like >>>> RHEL 5.1. >>> Have you folks decided where and how the announcements should be send? >>> Fedora announce list >>> RHEL 4 and 5 lists and announce lists >>> Red Hat press release >>> Other news sites >>> This might be a useful reference: >>> http://fedoraproject.org/wiki/Marketing/SpreadingNews >> Karsten, what is our plan exactly? I'd really like to see some >> announcement got out -- it doesn't have to be businesswire, but some >> linux-sites will likely pick it up if we just send some sane stuff in >> mail in their direction. > As long as we include the announcement in our FWN, it should be picked > by most popular Linux news sites. ...and likely only Fedora users will read the FWN -- but those are not exactly EPEL's target audience. Heck, and even some of the Fedorians might miss it, as the FWN are quite long (/me wonders if it should have a "summary" in the beginning for those that that just want a quick overview -- but that's a different topic). I think EPEL deserves a real announcement (e.g. like a Fedora release, but a bit smaller). CU thl From wolfy at nobugconsulting.ro Tue Jul 17 09:17:10 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 17 Jul 2007 12:17:10 +0300 Subject: EPEL announcement planed for 20070726 In-Reply-To: <469C5B44.3020101@leemhuis.info> References: <46965835.9030705@leemhuis.info> <469673CF.1090408@fedoraproject.org> <469A1C90.3080305@leemhuis.info> <369bce3b0707151108t45ac389x23c66d8038ea475f@mail.gmail.com> <469C5B44.3020101@leemhuis.info> Message-ID: <469C8916.4090308@nobugconsulting.ro> Thorsten Leemhuis wrote: > I think EPEL deserves a real announcement (e.g. like a Fedora release, > but a bit smaller). > +1 for that From jgranado at redhat.com Tue Jul 17 10:13:50 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 12:13:50 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... Message-ID: <469C965E.1050505@redhat.com> Hi all: Regarding the python-imaging package... What is the matter with including the 1.1.6 version in EPEL/el5? does it break anything? Both Plone and python-docutils (deps in EPEL) use the Image library from PIL and this library does not have any backward compatibility issues. additionally, RHEL5-client has no package that depends on python-imaging. So I say KISS, and ship 1.1.6 with the EPEL/el5. I know it goes against the EPEL policies, but I think its much better that messing with nvr. Regards. -- Joel Andres Granados From fedora at leemhuis.info Tue Jul 17 10:33:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 12:33:30 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469C965E.1050505@redhat.com> References: <469C965E.1050505@redhat.com> Message-ID: <469C9AFA.5040103@leemhuis.info> On 17.07.2007 12:13, Joel Andres Granados wrote: > > Regarding the python-imaging package... > What is the matter with including the 1.1.6 version in EPEL/el5? does > it break anything? > Both Plone and python-docutils (deps in EPEL) use the Image library from > PIL and this library does not have any > backward compatibility issues. additionally, RHEL5-client has no > package that depends on > python-imaging. So I say KISS, and ship 1.1.6 with the EPEL/el5. I > know it goes against the EPEL policies, > but I think its much better that messing with nvr. This way lie dragons. "EPEL does not replace packages from the distribution it was build for" is IMHO not debatable -- just as it was in Extras before the merge. For the situations at hand: Problem1 -- python-imaging was EPEL: We made a error, but we are still in the testing/buildup phase, so we can still remove it from the repo and say loudly "apologize" and "we are sorry"(?). Not ideal, but problem solved. Problem2 -- python-imaging had a higher EVR then the EL5Client package: Ignore those users that got the newer python-imaging from EPEL (see Problem 1: "EPEL is still in testing" and "apologize"). Rebuild plone and python-docutils against the 1.1.5 package from EL (if that's needed). Solved. Problem3 -- no python-imaging in EL5Server: Not solved yet, but under discussion. CU thl (?) -- we likely should put something (test-scripts?) in place to make sure something similar does not happen again From jgranado at redhat.com Tue Jul 17 11:13:43 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 13:13:43 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469C9AFA.5040103@leemhuis.info> References: <469C965E.1050505@redhat.com> <469C9AFA.5040103@leemhuis.info> Message-ID: <469CA467.9080903@redhat.com> Thorsten Leemhuis wrote: > On 17.07.2007 12:13, Joel Andres Granados wrote: > >> Regarding the python-imaging package... >> What is the matter with including the 1.1.6 version in EPEL/el5? does >> it break anything? >> Both Plone and python-docutils (deps in EPEL) use the Image library from >> PIL and this library does not have any >> backward compatibility issues. additionally, RHEL5-client has no >> package that depends on >> python-imaging. So I say KISS, and ship 1.1.6 with the EPEL/el5. I >> know it goes against the EPEL policies, >> but I think its much better that messing with nvr. >> > > This way lie dragons. > > "EPEL does not replace packages from the distribution it was build for" > is IMHO not debatable -- just as it was in Extras before the merge. > > For the situations at hand: > > Problem1 -- python-imaging was EPEL: We made a error, but we are still > in the testing/buildup phase, so we can still remove it from the repo > Is this true for EPEL/el4 and EPEL/el5? I ask because I have them both in the CVS and assumed that EPEL/el4 was an already *stable* release. > and say loudly "apologize" and "we are sorry"(?). Not ideal, but problem > solved. > > Problem2 -- python-imaging had a higher EVR then the EL5Client package: > Ignore those users that got the newer python-imaging from EPEL (see > Problem 1: "EPEL is still in testing" and "apologize"). IMO this is also very precarious "to ignore the user". Someone might not get the "We made a mistake we are very sorry" and have some sort of updating or installation problems. After they are solved (if they are solved) EPEL would be related with bad packages that don't work properly :(, then again, I might be taking the "ignore user" to seriously:) > Rebuild plone > and python-docutils against the 1.1.5 package from EL (if that's > needed). Solved. > > Problem3 -- no python-imaging in EL5Server: Not solved yet, but under > discussion. > > CU > thl > > > (?) -- we likely should put something (test-scripts?) in place to make > sure something similar does not happen again > IMO, This is VERY necessary. This whole discussion wouldn't have happened if RHELClient wouldn't have had the 1.1.5 version. EPEL would have shipped with the latest version for Client and Server. In other words the policy wouldn't have gotten in the way. Moreover, this might be a simple "erase from repos and rebuild the good one" situation because it is the "testing" version. But what will happen when EPEL ships what is thought to be the best choice for a package and turns out that RHEL introduces the same package but with a more recent version? [1] That will not be a "lets erase and rebuild" situation!!! The idea of putting a "0." in the release is a good one, but I really don't feel comfortable messing with the version in that way. Its something additional to think about when doing builds and it might be an opportunity for another bug to pop up. [1]What I mean is that a package is introduced in one of the flavors (Server, Client) and not on the other. Because if it is introduced in both, the solution is to erase it from EPEL. > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Joel Andres Granados From fedora at leemhuis.info Tue Jul 17 11:44:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 13:44:53 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469CA467.9080903@redhat.com> References: <469C965E.1050505@redhat.com> <469C9AFA.5040103@leemhuis.info> <469CA467.9080903@redhat.com> Message-ID: <469CABB5.1020900@leemhuis.info> On 17.07.2007 13:13, Joel Andres Granados wrote: > Thorsten Leemhuis wrote: >> On 17.07.2007 12:13, Joel Andres Granados wrote: >> For the situations at hand: >> Problem1 -- python-imaging was EPEL: We made a error, but we are still >> in the testing/buildup phase, so we can still remove it from the repo > Is this true for EPEL/el4 and EPEL/el5? I ask because I have them both > in the CVS and assumed that EPEL/el4 was an already *stable* release. /me can't follow, sorry. EPEL in general and the Repos EPEL4 and EPEL5 are still not officially started; that's planed for next weeks Thursday. >> and say loudly "apologize" and "we are sorry"(?). Not ideal, but problem >> solved. >> Problem2 -- python-imaging had a higher EVR then the EL5Client package: >> Ignore those users that got the newer python-imaging from EPEL (see >> Problem 1: "EPEL is still in testing" and "apologize"). > IMO this is also very precarious "to ignore the user". And the users isn't helped if we fix one error by making another (bigger) one. >> (?) -- we likely should put something (test-scripts?) in place to make >> sure something similar does not happen again > IMO, This is VERY necessary. Any volunteers? > [...] CU thl From gilboad at gmail.com Tue Jul 17 12:00:40 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 17 Jul 2007 15:00:40 +0300 Subject: EPEL 5 Dependency Report - 20070713 In-Reply-To: <469B2444.3070801@leemhuis.info> References: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> <469A6E16.2000903@leemhuis.info> <9050516b0707160012l29fb8dpe5284d7856d27e38@mail.gmail.com> <469B2444.3070801@leemhuis.info> Message-ID: <1184673640.1736.1.camel@gilboa-work-dev.localdomain> On Mon, 2007-07-16 at 09:54 +0200, Thorsten Leemhuis wrote: > > On 16.07.2007 09:12, Gilboa Davara wrote: > > On 7/15/07, Thorsten Leemhuis wrote: > >> Hi! > >> > >> If you E-Mail is in the below list you are BCCed to this mail (?) please > >> read on until the end! > > ... > >> gilboad_AT_gmail.com: Package gmrun requires xterm which is not in EPEL; > >> its owned by mlichvar_AT_redhat.com in Fedora. > > Weird. [...] > > Yeah, really interesting :-/ > > Did the spam-o-epel stuff Mike set up later yesterday trigger as well > (it send a mail directly to you inbox with a subject "Broken > dependencies: foo")? If not just ignore. Got the email. Decided it was a mistake. (Send out a build just to be certain - no errors what-so-ever) > > Sorry for the noise. Nothing to it ;) - Gilboa From jgranado at redhat.com Tue Jul 17 12:23:58 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 14:23:58 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469CABB5.1020900@leemhuis.info> References: <469C965E.1050505@redhat.com> <469C9AFA.5040103@leemhuis.info> <469CA467.9080903@redhat.com> <469CABB5.1020900@leemhuis.info> Message-ID: <469CB4DE.3070801@redhat.com> Thorsten Leemhuis wrote: > On 17.07.2007 13:13, Joel Andres Granados wrote: > >> Thorsten Leemhuis wrote: >> >>> On 17.07.2007 12:13, Joel Andres Granados wrote: >>> For the situations at hand: >>> Problem1 -- python-imaging was EPEL: We made a error, but we are still >>> in the testing/buildup phase, so we can still remove it from the repo >>> >> Is this true for EPEL/el4 and EPEL/el5? I ask because I have them both >> in the CVS and assumed that EPEL/el4 was an already *stable* release. >> > > /me can't follow, sorry. > > EPEL in general and the Repos EPEL4 and EPEL5 are still not officially > started; that's planed for next weeks Thursday. > I thought EPEL4 was official, I see that they are both no out yet :) > >>> and say loudly "apologize" and "we are sorry"(?). Not ideal, but problem >>> solved. >>> Problem2 -- python-imaging had a higher EVR then the EL5Client package: >>> Ignore those users that got the newer python-imaging from EPEL (see >>> Problem 1: "EPEL is still in testing" and "apologize"). >>> >> IMO this is also very precarious "to ignore the user". >> > > And the users isn't helped if we fix one error by making another > (bigger) one. > Just to be clear. the process to install (if you have already installed 1.1.6) is to remove the current package, then install from repos? if the answer is yes. And having in mind that this situation might present itself more than once in the future. Will this be the policy to handle all of these situations? Will the message to the user be "to make sure you updates are done correctly and no unexpected behaviors pop up with corner cases, uninstall EPEL package and install it from new/current repo"? Its just something to think about, I know its not a solution !! I'll be on the look out for what is decided on tomorrows meeting. > >>> (?) -- we likely should put something (test-scripts?) in place to make >>> sure something similar does not happen again >>> >> IMO, This is VERY necessary. >> > > Any volunteers? > The scripts is important, the action taken when the scripts finds something is more important. Regards. -- Joel Andres Granados From icon at fedoraproject.org Tue Jul 17 12:24:57 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 17 Jul 2007 08:24:57 -0400 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469C9AFA.5040103@leemhuis.info> References: <469C965E.1050505@redhat.com> <469C9AFA.5040103@leemhuis.info> Message-ID: On 7/17/07, Thorsten Leemhuis wrote: > Problem1 -- python-imaging was EPEL: We made a error, but we are still > in the testing/buildup phase, so we can still remove it from the repo > and say loudly "apologize" and "we are sorry"(?). Not ideal, but problem > solved. Well, to make things clear, python-imaging was branched for EPEL because plague builds in *EPEL5* were failing due to unsatisfied dependency on python-imaging, at least when I tried to build it on May 31st. This means that back then the 5Client packages were not available for plague building -- has that changed? Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From jgranado at redhat.com Tue Jul 17 12:52:31 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 14:52:31 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469C965E.1050505@redhat.com> References: <469C965E.1050505@redhat.com> Message-ID: <469CBB8F.6060606@redhat.com> Joel Andres Granados wrote: > Hi all: > > Regarding the python-imaging package... > What is the matter with including the 1.1.6 version in EPEL/el5? does > it break anything? > Both Plone and python-docutils (deps in EPEL) use the Image library > from PIL and this library does not have any > backward compatibility issues. additionally, RHEL5-client has no > package that depends on > python-imaging. So I say KISS, and ship 1.1.6 with the EPEL/el5. I > know it goes against the EPEL policies, > but I think its much better that messing with nvr. > > Regards. > And what about EPEL/e4, the EPEL wiki says to use code form fedora core 3. FYI, the version for fc3 was 1.1.4 for python-imaging. (will changing to 1.1.4 with a spec from that time be enough?). Moreover, is there an additional way to build EPEL packages. I'm following http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo wiki for the builds. Is this correct? or should I be going with a different process? regards. -- Joel Andres Granados From fedora at leemhuis.info Tue Jul 17 13:28:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 15:28:46 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469CBB8F.6060606@redhat.com> References: <469C965E.1050505@redhat.com> <469CBB8F.6060606@redhat.com> Message-ID: <469CC40E.6030107@leemhuis.info> On 17.07.2007 14:52, Joel Andres Granados wrote: > Joel Andres Granados wrote: >> Regarding the python-imaging package... >> What is the matter with including the 1.1.6 version in EPEL/el5? does >> it break anything? >> Both Plone and python-docutils (deps in EPEL) use the Image library >> from PIL and this library does not have any >> backward compatibility issues. additionally, RHEL5-client has no >> package that depends on >> python-imaging. So I say KISS, and ship 1.1.6 with the EPEL/el5. I >> know it goes against the EPEL policies, >> but I think its much better that messing with nvr. > And what about EPEL/e4, the EPEL wiki says to use code form fedora core > 3. That the advice, yes. > [...] > Moreover, is there an additional way to build EPEL packages. > I'm following > http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo > wiki for the builds. Is this correct? The old Extras procedure applies; e.g. update cvs, run "make tag build"; koji and bodi, which are used for F-7 and rawhide are not yet used for EPEL. CU thl From fedora at leemhuis.info Tue Jul 17 13:30:51 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 15:30:51 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: References: <469C965E.1050505@redhat.com> <469C9AFA.5040103@leemhuis.info> Message-ID: <469CC48B.3040402@leemhuis.info> On 17.07.2007 14:24, Konstantin Ryabitsev wrote: > On 7/17/07, Thorsten Leemhuis wrote: >> Problem1 -- python-imaging was EPEL: We made a error, but we are still >> in the testing/buildup phase, so we can still remove it from the repo >> and say loudly "apologize" and "we are sorry"(?). Not ideal, but problem >> solved. > > Well, to make things clear, python-imaging was branched for EPEL > because plague builds in *EPEL5* were failing due to unsatisfied > dependency on python-imaging, at least when I tried to build it on May > 31st. This means that back then the 5Client packages were not > available for plague building -- has that changed? dgilmore might be able to answer. But at least my package mail-notification (which requires a package that's only available in 5Client) built fine for EPEL5. CU thl From fedora at leemhuis.info Tue Jul 17 13:32:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 15:32:55 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469CB4DE.3070801@redhat.com> References: <469C965E.1050505@redhat.com> <469C9AFA.5040103@leemhuis.info> <469CA467.9080903@redhat.com> <469CABB5.1020900@leemhuis.info> <469CB4DE.3070801@redhat.com> Message-ID: <469CC507.6090901@leemhuis.info> On 17.07.2007 14:23, Joel Andres Granados wrote: > Thorsten Leemhuis wrote: >> On 17.07.2007 13:13, Joel Andres Granados wrote: >>> Thorsten Leemhuis wrote: >>>> On 17.07.2007 12:13, Joel Andres Granados wrote: > >>>> and say loudly "apologize" and "we are sorry"(?). Not ideal, but problem >>>> solved. >>>> Problem2 -- python-imaging had a higher EVR then the EL5Client package: >>>> Ignore those users that got the newer python-imaging from EPEL (see >>>> Problem 1: "EPEL is still in testing" and "apologize"). >>>> >>> IMO this is also very precarious "to ignore the user". >>> >> And the users isn't helped if we fix one error by making another >> (bigger) one. > Just to be clear. the process to install (if you have already installed > 1.1.6) is to remove the current package, then install from repos? Yes. > if the answer is yes. then what? > And having in mind that this situation might > present itself more than once in the future. Just my 2 cent: We should do our best to prevent that such a situation happen again in the future and not design policies for accidents. > [...] CU thl From jgranado at redhat.com Tue Jul 17 13:36:15 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 15:36:15 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469CC40E.6030107@leemhuis.info> References: <469C965E.1050505@redhat.com> <469CBB8F.6060606@redhat.com> <469CC40E.6030107@leemhuis.info> Message-ID: <469CC5CF.5070905@redhat.com> Thorsten Leemhuis wrote: > On 17.07.2007 14:52, Joel Andres Granados wrote: > >> Joel Andres Granados wrote: >> >>> Regarding the python-imaging package... >>> What is the matter with including the 1.1.6 version in EPEL/el5? does >>> it break anything? >>> Both Plone and python-docutils (deps in EPEL) use the Image library >>> from PIL and this library does not have any >>> backward compatibility issues. additionally, RHEL5-client has no >>> package that depends on >>> python-imaging. So I say KISS, and ship 1.1.6 with the EPEL/el5. I >>> know it goes against the EPEL policies, >>> but I think its much better that messing with nvr. >>> >> And what about EPEL/e4, the EPEL wiki says to use code form fedora core >> 3. >> > > That the advice, yes. > > >> [...] >> Moreover, is there an additional way to build EPEL packages. >> I'm following >> http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo >> wiki for the builds. Is this correct? >> > > The old Extras procedure applies; e.g. update cvs, run "make tag build"; > koji and bodi, which are used for F-7 and rawhide are not yet used for EPEL. > ^^^^ this is really nice to know, I am familiar with the EPEL way of doing it. Can you direct me to the wiki, tutorial or info page. Thx. > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Joel Andres Granados From jgranado at redhat.com Tue Jul 17 13:42:23 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 15:42:23 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469CC5CF.5070905@redhat.com> References: <469C965E.1050505@redhat.com> <469CBB8F.6060606@redhat.com> <469CC40E.6030107@leemhuis.info> <469CC5CF.5070905@redhat.com> Message-ID: <469CC73F.8060409@redhat.com> Joel Andres Granados wrote: > Thorsten Leemhuis wrote: >> On 17.07.2007 14:52, Joel Andres Granados wrote: >> >>> Joel Andres Granados wrote: >>> >>>> Regarding the python-imaging package... >>>> What is the matter with including the 1.1.6 version in EPEL/el5? >>>> does it break anything? >>>> Both Plone and python-docutils (deps in EPEL) use the Image library >>>> from PIL and this library does not have any >>>> backward compatibility issues. additionally, RHEL5-client has no >>>> package that depends on >>>> python-imaging. So I say KISS, and ship 1.1.6 with the EPEL/el5. >>>> I know it goes against the EPEL policies, >>>> but I think its much better that messing with nvr. >>>> >>> And what about EPEL/e4, the EPEL wiki says to use code form fedora >>> core 3. >>> >> >> That the advice, yes. >> >> >>> [...] >>> Moreover, is there an additional way to build EPEL packages. >>> I'm following >>> http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo >>> wiki for the builds. Is this correct? >>> >> >> The old Extras procedure applies; e.g. update cvs, run "make tag build"; >> koji and bodi, which are used for F-7 and rawhide are not yet used >> for EPEL. >> > > ^^^^ this is really nice to know, I am familiar with the EPEL way of > doing it. Can you direct me to the > wiki, tutorial or info page. > Thx. > ^^^^ this is really nice to know, I am *Not* familiar with the EPEL way of doing it. Can you direct me to the wiki, tutorial or info page. is it in http://fedoraproject.org/wiki/PackageMaintainers/UsingPlagueClientFaq?highlight=%28plague%29 Thx. -- Joel Andres Granados From jgranado at redhat.com Tue Jul 17 08:53:01 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 10:53:01 +0200 Subject: resolution for python-imaging in EPEL In-Reply-To: <469C4DFC.2050408@leemhuis.info> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> Message-ID: <469C836D.9030203@redhat.com> Thorsten Leemhuis wrote: > On 16.07.2007 15:39, Joel Andres Granados wrote: > >> reference : BZ#246444 >> >> I have 1 of 2 choices: >> [...] >> Comments greatly appreciated. >> > > The better place for this questions is epel-devel-list (CCed and reply > to set), thx, Ill additionally subscribe to the list. ;) > where this has been discussed already in the past days and > likely will get discussed further. It's also a topic for tomorrows EPEL > SIG meeting (20070718, #fedora-meeting, 17:00 UTC). Join us ;-) > I most likely will join you. > BTW, I'd currently prefer to take the python-imaging from RHEL, lower > the EVR (by using a "0." at the start of Release), So if I understand you correctly you want to ship the 1.1.5 source with a 1.1.6-0.3 versioned rpm? IMHO, since this does not really break anything (1.1.6 being in RHEL5 Server) it would be much better to go with the policy of having source version and rpm version consistency than having the EPEL/el5 and RHEL5 consistency. I also consider this being a matter of opinion as both approaches would work in theory :) > and ship it in EPEL, > so users of EL5Server have it available as well, and users of EL5Client > or CentOS will get their normal package. Not ideal, but KISS and should > work if nobody does stupid things. > FWIW, I think that shipping the 1.1.6 version to EPEL/el5 is more KISS than modifying the release bit. > CU > knurd > > P.S.: /me wonders if mailman will eat the follow-up to > epel-devel-list at redhat.com > > P.P.S.:/me bets it will > I'll check this out and see if mailman did something funny. > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Joel Andres Granados From jkeating at redhat.com Tue Jul 17 13:44:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jul 2007 09:44:08 -0400 Subject: resolution for python-imaging in EPEL In-Reply-To: <469C4DFC.2050408@leemhuis.info> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> Message-ID: <20070717094408.3c64cfa0@localhost.localdomain> I am not on this list yet, please keep me in cc replies. On Tue, 17 Jul 2007 07:05:00 +0200 Thorsten Leemhuis wrote: > BTW, I'd currently prefer to take the python-imaging from RHEL, lower > the EVR (by using a "0." at the start of Release), and ship it in > EPEL, so users of EL5Server have it available as well, and users of > EL5Client or CentOS will get their normal package. Not ideal, but > KISS and should work if nobody does stupid things. Correct me if I'm wrong here, but aren't we supposed to /not/ be doing offerings like this? EPEL isn't supposed to be a way for RHEL customers to get around their subscriptions, and we shouldn't be taking packages from one channel and just offering them in EPEL so that the rest of the people can have them. That's a very easy way to get Red Hat to put as much roadblock in EPEL's way as possible. That said, somebody really needs to verify what I was told earlier, which is customers of EL5Server can use RHN and subscribe to the Client channels and get the content. Perhaps not vice-versa, but in this case it should be enough. Before we go down the road of doom, lets verify whether or not 5Server customers can get access to python-imaging through RHN. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From icon at fedoraproject.org Tue Jul 17 14:15:38 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 17 Jul 2007 10:15:38 -0400 Subject: resolution for python-imaging in EPEL In-Reply-To: <20070717094408.3c64cfa0@localhost.localdomain> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> Message-ID: On 7/17/07, Jesse Keating wrote: > That said, somebody really needs to verify what I was told earlier, > which is customers of EL5Server can use RHN and subscribe to the Client > channels and get the content. Perhaps not vice-versa, but in this case > it should be enough. Before we go down the road of doom, lets verify > whether or not 5Server customers can get access to python-imaging > through RHN. I don't think this is true. I have RHEL-5Server (academic) entitlement, and I don't see "Client" listed anywhere in my list of available software channels. I only see: # RHEL Virtualization (v. 5 for 32-bit x86) # RHEL Supplementary (v. 5 for 32-bit x86) # RHEL Hardware Certification (v. 5 for 32-bit x86) # RHEL FasTrack (v. 5 for 32-bit x86) # Red Hat Network Tools for RHEL Server (v.5 32-bit x86) And "python-imaging" is definitely not available to me: root at bakserv:[~]# yum list python-imaging Loading "rhnplugin" plugin Loading "installonlyn" plugin Setting up repositories rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 Reading repository metadata in from local files Finished The situation may be different for those who paid full enterprise price for RHEL entitlements, but that doesn't change the fact that unless EPEL provides "client" packages, I'll be left with broken repositories. I will note, that it makes that much harder for me to justify paying money to RH if I can have a better service using Centos+EPEL. Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From jgranado at redhat.com Tue Jul 17 14:23:40 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 16:23:40 +0200 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469CC507.6090901@leemhuis.info> References: <469C965E.1050505@redhat.com> <469C9AFA.5040103@leemhuis.info> <469CA467.9080903@redhat.com> <469CABB5.1020900@leemhuis.info> <469CB4DE.3070801@redhat.com> <469CC507.6090901@leemhuis.info> Message-ID: <469CD0EC.1080906@redhat.com> Thorsten Leemhuis wrote: > On 17.07.2007 14:23, Joel Andres Granados wrote: > >> Thorsten Leemhuis wrote: >> >>> On 17.07.2007 13:13, Joel Andres Granados wrote: >>> >>>> Thorsten Leemhuis wrote: >>>> >>>>> On 17.07.2007 12:13, Joel Andres Granados wrote: >>>>> >>>>> and say loudly "apologize" and "we are sorry"(?). Not ideal, but problem >>>>> solved. >>>>> Problem2 -- python-imaging had a higher EVR then the EL5Client package: >>>>> Ignore those users that got the newer python-imaging from EPEL (see >>>>> Problem 1: "EPEL is still in testing" and "apologize"). >>>>> >>>>> >>>> IMO this is also very precarious "to ignore the user". >>>> >>>> >>> And the users isn't helped if we fix one error by making another >>> (bigger) one. >>> >> Just to be clear. the process to install (if you have already installed >> 1.1.6) is to remove the current package, then install from repos? >> > > Yes. > > >> if the answer is yes. >> > > then what? > Will this be the policy to handle all of these situations? Will the message to the user be: "to make sure you updates are done correctly and no unexpected behaviors pop up with corner cases, uninstall EPEL package and install it from new/current repo"? > >> And having in mind that this situation might >> present itself more than once in the future. >> > > Just my 2 cent: We should do our best to prevent that such a situation > happen again in the future and not design policies for accidents. > I agree. Maybe there should be some sort of policy stating that the version of the package included in EPEL will be the one that dates back to the initial release of the main RHEL version. In this case python-imaging changed from 1.1.5 to 1.1.6 in Mon Feb 5 2007 (change log) and RHEL5 was released in 2007-03-14. In this particular case, this hypothetical policy would not have stopped the mistake from occurring. But the policy can further be refined stating that the package has to have a certain maturity level to be included in EPEL, say for example 6 months after release (just thinking out loud). So to be included in EPEL just select the version of the package that was released a certain period of time before the main RHEL release. I really don't think I'm making myself clear..... Let me expand with an example: the policy would say: the version of foo to be included in EPEL/e(N) [1] will be the one that, at the moment of RHEL(N)'s release, had at least X amount of months of existence. :) So, (assuming X=6) 1.1.6 wouldn't have been considered because it was released on December 3-2006, 4 months and 11 days before RHEL5's release. 1.1.5 would have to be used because *it* was released on March 28-2005, more than 6 months before RHEL5's release. And in case RHEL(N) decides, for whatever reason, to include the newest version of the package (version released X months before RHEL), then all EPEL has to do is, build an newer version :) The question is now, what is the value for X? [1] N being the version. Regards PS: It's kinda difficult to explain, tell me if I need to send a graph or picture or slide presentation :) ** > >> [...] >> > > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Joel Andres Granados From jkeating at redhat.com Tue Jul 17 14:23:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 17 Jul 2007 10:23:26 -0400 Subject: resolution for python-imaging in EPEL In-Reply-To: References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> Message-ID: <20070717102326.387e997a@localhost.localdomain> On Tue, 17 Jul 2007 10:15:38 -0400 "Konstantin Ryabitsev" wrote: > The situation may be different for those who paid full enterprise > price for RHEL entitlements, but that doesn't change the fact that > unless EPEL provides "client" packages, I'll be left with broken > repositories. I will note, that it makes that much harder for me to > justify paying money to RH if I can have a better service using > Centos+EPEL. Yes I know, and this is the exact problem I yelled at our RHEL pm about months ago, as well as other EPEL heads at the time. I forewarned that this was a problem that needed to be solved, and nobody listened. I'll dig more on my side of things to find out the scoop of what all 5Server should have access to via RHN. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From riek at redhat.com Tue Jul 17 14:47:32 2007 From: riek at redhat.com (Daniel Riek) Date: Tue, 17 Jul 2007 10:47:32 -0400 Subject: EPEL, RHEL-5Server and RHEL-5Client... In-Reply-To: <469C9AFA.5040103@leemhuis.info> References: <469C965E.1050505@redhat.com> <469C9AFA.5040103@leemhuis.info> Message-ID: <1184683652.4481.124.camel@scorp> I think the right solution is, to move add python imaging to the core server. In that way it will be available to every user. I have to review why it was moved to the Client only (it will be available to server customers in a separate channel containing the Client-only packages as soon as the RHN profiles get updated). I assume dependencies where only from that Repo. We'll target that for 5.1 Regards, Daniel On Tue, 2007-07-17 at 12:33 +0200, Thorsten Leemhuis wrote: > > On 17.07.2007 12:13, Joel Andres Granados wrote: > > > > Regarding the python-imaging package... > > What is the matter with including the 1.1.6 version in EPEL/el5? does > > it break anything? > > Both Plone and python-docutils (deps in EPEL) use the Image library from > > PIL and this library does not have any > > backward compatibility issues. additionally, RHEL5-client has no > > package that depends on > > python-imaging. So I say KISS, and ship 1.1.6 with the EPEL/el5. I > > know it goes against the EPEL policies, > > but I think its much better that messing with nvr. > > This way lie dragons. > > "EPEL does not replace packages from the distribution it was build for" > is IMHO not debatable -- just as it was in Extras before the merge. > > For the situations at hand: > > Problem1 -- python-imaging was EPEL: We made a error, but we are still > in the testing/buildup phase, so we can still remove it from the repo > and say loudly "apologize" and "we are sorry"(?). Not ideal, but problem > solved. > > Problem2 -- python-imaging had a higher EVR then the EL5Client package: > Ignore those users that got the newer python-imaging from EPEL (see > Problem 1: "EPEL is still in testing" and "apologize"). Rebuild plone > and python-docutils against the 1.1.5 package from EL (if that's > needed). Solved. > > Problem3 -- no python-imaging in EL5Server: Not solved yet, but under > discussion. > > CU > thl > > > (?) -- we likely should put something (test-scripts?) in place to make > sure something similar does not happen again > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list -- Daniel Riek, Product Manager Red Hat Enterprise Linux, Red Hat Inc. E-Mail: riek at redhat.com, http://www.redhat.com/ Key-FP: 3DD7 C376 C3E0 1917 9A63 6343 5A26 2C59 6C07 6F32 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jgranado at redhat.com Tue Jul 17 14:51:35 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 16:51:35 +0200 Subject: resolution for python-imaging in EPEL In-Reply-To: <20070717102326.387e997a@localhost.localdomain> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <20070717102326.387e997a@localhost.localdomain> Message-ID: <469CD777.4010803@redhat.com> Jesse Keating wrote: > On Tue, 17 Jul 2007 10:15:38 -0400 > "Konstantin Ryabitsev" wrote: > > >> The situation may be different for those who paid full enterprise >> price for RHEL entitlements, but that doesn't change the fact that >> unless EPEL provides "client" packages, I'll be left with broken >> repositories. I will note, that it makes that much harder for me to >> justify paying money to RH if I can have a better service using >> Centos+EPEL. >> > > Yes I know, and this is the exact problem I yelled at our RHEL pm about > months ago, as well as other EPEL heads at the time. I forewarned that > this was a problem that needed to be solved, and nobody listened. > > I'll dig more on my side of things to find out the scoop of what all > 5Server should have access to via RHN. > > > ------------------------------------------------------------------------ > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > As I understand it, If the main channel or child channels don't have the package a new channel must be acquired. I'll ask around the office. -- Joel Andres Granados From riek at redhat.com Tue Jul 17 14:51:35 2007 From: riek at redhat.com (Daniel Riek) Date: Tue, 17 Jul 2007 10:51:35 -0400 Subject: resolution for python-imaging in EPEL In-Reply-To: References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> Message-ID: <1184683895.4481.128.camel@scorp> The client packages are going to become available to all server customers as soon as the RHN profiles get updated. That takes some time as it is a major repull of data. For python-imaging my proposal is to move it to the core server. Did you open a ticket about this package with RH support? Regards, Daniel On Tue, 2007-07-17 at 10:15 -0400, Konstantin Ryabitsev wrote: > On 7/17/07, Jesse Keating wrote: > > That said, somebody really needs to verify what I was told earlier, > > which is customers of EL5Server can use RHN and subscribe to the Client > > channels and get the content. Perhaps not vice-versa, but in this case > > it should be enough. Before we go down the road of doom, lets verify > > whether or not 5Server customers can get access to python-imaging > > through RHN. > > I don't think this is true. I have RHEL-5Server (academic) > entitlement, and I don't see "Client" listed anywhere in my list of > available software channels. I only see: > > # RHEL Virtualization (v. 5 for 32-bit x86) > # RHEL Supplementary (v. 5 for 32-bit x86) > # RHEL Hardware Certification (v. 5 for 32-bit x86) > # RHEL FasTrack (v. 5 for 32-bit x86) > # Red Hat Network Tools for RHEL Server (v.5 32-bit x86) > > And "python-imaging" is definitely not available to me: > > root at bakserv:[~]# yum list python-imaging > Loading "rhnplugin" plugin > Loading "installonlyn" plugin > Setting up repositories > rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 > Reading repository metadata in from local files > Finished > > The situation may be different for those who paid full enterprise > price for RHEL entitlements, but that doesn't change the fact that > unless EPEL provides "client" packages, I'll be left with broken > repositories. I will note, that it makes that much harder for me to > justify paying money to RH if I can have a better service using > Centos+EPEL. > > Regards, -- Daniel Riek, Product Manager Red Hat Enterprise Linux, Red Hat Inc. E-Mail: riek at redhat.com, http://www.redhat.com/ Key-FP: 3DD7 C376 C3E0 1917 9A63 6343 5A26 2C59 6C07 6F32 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jgranado at redhat.com Tue Jul 17 15:01:56 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 17:01:56 +0200 Subject: resolution for python-imaging in EPEL In-Reply-To: <1184683895.4481.128.camel@scorp> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <1184683895.4481.128.camel@scorp> Message-ID: <469CD9E4.2080108@redhat.com> Daniel Riek wrote: > The client packages are going to become available to all server > customers as soon as the RHN profiles get updated. That takes some time > as it is a major repull of data. > > For python-imaging my proposal is to move it to the core server. > > Did you open a ticket about this package with RH support? > > Regards, > > Daniel > > On Tue, 2007-07-17 at 10:15 -0400, Konstantin Ryabitsev wrote: > >> On 7/17/07, Jesse Keating wrote: >> >>> That said, somebody really needs to verify what I was told earlier, >>> which is customers of EL5Server can use RHN and subscribe to the Client >>> channels and get the content. Perhaps not vice-versa, but in this case >>> it should be enough. Before we go down the road of doom, lets verify >>> whether or not 5Server customers can get access to python-imaging >>> through RHN. >>> >> I don't think this is true. I have RHEL-5Server (academic) >> entitlement, and I don't see "Client" listed anywhere in my list of >> available software channels. I only see: >> >> # RHEL Virtualization (v. 5 for 32-bit x86) >> # RHEL Supplementary (v. 5 for 32-bit x86) >> # RHEL Hardware Certification (v. 5 for 32-bit x86) >> # RHEL FasTrack (v. 5 for 32-bit x86) >> # Red Hat Network Tools for RHEL Server (v.5 32-bit x86) >> >> And "python-imaging" is definitely not available to me: >> >> root at bakserv:[~]# yum list python-imaging >> Loading "rhnplugin" plugin >> Loading "installonlyn" plugin >> Setting up repositories >> rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 >> Reading repository metadata in from local files >> Finished >> >> The situation may be different for those who paid full enterprise >> price for RHEL entitlements, but that doesn't change the fact that >> unless EPEL provides "client" packages, I'll be left with broken >> repositories. I will note, that it makes that much harder for me to >> justify paying money to RH if I can have a better service using >> Centos+EPEL. >> >> Regards, >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> epel-devel-list mailing list >> epel-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/epel-devel-list >> Question: was the fact that python-imaging got introduced to RHELClient and not Server a conscious determination or was it a mistake? if it was a conscious determination, what are the policies that dictate when and how this occurs? and where can they be found? Regards. -- Joel Andres Granados From mmcgrath at redhat.com Tue Jul 17 15:14:28 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 17 Jul 2007 10:14:28 -0500 Subject: spam-o-epel In-Reply-To: <469AF5D8.9080304@leemhuis.info> References: <469A91CC.3050904@redhat.com> <469AF5D8.9080304@leemhuis.info> Message-ID: <469CDCD4.6070905@redhat.com> Thorsten Leemhuis wrote: > > libeutil.so.0 is provided by evolution. That for sure is part of the > EL5Client; and during build the evo-devel pacakge was found, with makes > me even more confident that it's there and also part of the buildroot. > > But evolution iirc. is not part of the EL5Server. Did the script > correctly detect that, did that fool the script somehow or is there > something else going wrong somewhere? > This is correct, I ran the script against Server and not Client, I've corrected it to run against both (which removed this false positive). I'll wait till the meeting tomorrow before I enable it completely. -Mike From riek at redhat.com Tue Jul 17 15:22:20 2007 From: riek at redhat.com (Daniel Riek) Date: Tue, 17 Jul 2007 15:22:20 +0000 Subject: resolution for python-imaging in EPEL In-Reply-To: <469CD9E4.2080108@redhat.com> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <1184683895.4481.128.camel@scorp> <469CD9E4.2080108@redhat.com> Message-ID: <1184685740.4481.150.camel@scorp> On Tue, 2007-07-17 at 17:01 +0200, Joel Andres Granados wrote: > >> > Question: was the fact that python-imaging got introduced to RHELClient > and not Server a conscious determination or > was it a mistake? > if it was a conscious determination, what are the policies that dictate > when and how this occurs? and where can they be found? I think it was a side effect of the decision to move whatever required it to the Client but not the core Server (need to review that). There is no publicly available policy document on this, but in general packages that are pulled in by another package, move to the repository of that other package. It also was a mistake because I could have forseen that sofware wants to use it. Regards, Daniel -- Daniel Riek, Product Manager Red Hat Enterprise Linux, Red Hat Inc. E-Mail: riek at redhat.com, http://www.redhat.com/ Key-FP: 3DD7 C376 C3E0 1917 9A63 6343 5A26 2C59 6C07 6F32 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From icon at fedoraproject.org Tue Jul 17 15:26:12 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 17 Jul 2007 11:26:12 -0400 Subject: resolution for python-imaging in EPEL In-Reply-To: <1184683895.4481.128.camel@scorp> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <1184683895.4481.128.camel@scorp> Message-ID: On 7/17/07, Daniel Riek wrote: > The client packages are going to become available to all server > customers as soon as the RHN profiles get updated. That takes some time > as it is a major repull of data. Ah, sweet! I knew there was a sane solution to this. :) > For python-imaging my proposal is to move it to the core server. > > Did you open a ticket about this package with RH support? No, it's not something that affects me directly. I'm interested purely because I was the one that requested that python-imaging be branched for EPEL, and hence was responsible for the creation of the situation. Besides, I'm academic. We don't get support. ;) Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From jgranado at redhat.com Tue Jul 17 15:35:27 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Jul 2007 17:35:27 +0200 Subject: resolution for python-imaging in EPEL In-Reply-To: <1184685740.4481.150.camel@scorp> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <1184683895.4481.128.camel@scorp> <469CD9E4.2080108@redhat.com> <1184685740.4481.150.camel@scorp> Message-ID: <469CE1BF.8010505@redhat.com> Daniel Riek wrote: > On Tue, 2007-07-17 at 17:01 +0200, Joel Andres Granados wrote: > >>>> >>>> >> Question: was the fact that python-imaging got introduced to RHELClient >> and not Server a conscious determination or >> was it a mistake? >> if it was a conscious determination, what are the policies that dictate >> when and how this occurs? and where can they be found? >> > I think it was a side effect of the decision to move whatever required > it to the Client but not the core Server (need to review that). There is > no publicly available policy document on this, but in general packages > that are pulled in by another package, move to the repository of that > other package. It also was a mistake because I could have forseen that > sofware wants to use it. > > Regards, > I'm the maintainer in RHEL for this package. do I need some special considerations or do I just rebuild for 5.1? thx. > Daniel > > ------------------------------------------------------------------------ > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Joel Andres Granados From riek at redhat.com Tue Jul 17 16:57:58 2007 From: riek at redhat.com (Daniel Riek) Date: Tue, 17 Jul 2007 16:57:58 +0000 Subject: resolution for python-imaging in EPEL In-Reply-To: <469CE1BF.8010505@redhat.com> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <1184683895.4481.128.camel@scorp> <469CD9E4.2080108@redhat.com> <1184685740.4481.150.camel@scorp> <469CE1BF.8010505@redhat.com> Message-ID: <1184691479.4481.172.camel@scorp> You don't need to do anything. We just move it in the buildsystem. We can always move packages from a child repository (-channel) to the base. If there are other issues, please contact me off-list. Regards, Daniel On Tue, 2007-07-17 at 17:35 +0200, Joel Andres Granados wrote: > Daniel Riek wrote: > > On Tue, 2007-07-17 at 17:01 +0200, Joel Andres Granados wrote: > > > >>>> > >>>> > >> Question: was the fact that python-imaging got introduced to RHELClient > >> and not Server a conscious determination or > >> was it a mistake? > >> if it was a conscious determination, what are the policies that dictate > >> when and how this occurs? and where can they be found? > >> > > I think it was a side effect of the decision to move whatever required > > it to the Client but not the core Server (need to review that). There is > > no publicly available policy document on this, but in general packages > > that are pulled in by another package, move to the repository of that > > other package. It also was a mistake because I could have forseen that > > sofware wants to use it. > > > > Regards, > > > > I'm the maintainer in RHEL for this package. do I need some special > considerations or do I just rebuild for 5.1? > thx. > > > Daniel > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > epel-devel-list mailing list > > epel-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > > -- Daniel Riek, Product Manager Red Hat Enterprise Linux, Red Hat Inc. E-Mail: riek at redhat.com, http://www.redhat.com/ Key-FP: 3DD7 C376 C3E0 1917 9A63 6343 5A26 2C59 6C07 6F32 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From riek at redhat.com Tue Jul 17 16:59:35 2007 From: riek at redhat.com (Daniel Riek) Date: Tue, 17 Jul 2007 16:59:35 +0000 Subject: resolution for python-imaging in EPEL In-Reply-To: References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <1184683895.4481.128.camel@scorp> Message-ID: <1184691575.4481.175.camel@scorp> On Tue, 2007-07-17 at 11:26 -0400, Konstantin Ryabitsev wrote: [...] > > Did you open a ticket about this package with RH support? > > No, it's not something that affects me directly. I'm interested purely > because I was the one that requested that python-imaging be branched > for EPEL, and hence was responsible for the creation of the situation. > Well, thanks then for finding the issue and bringing it forward. Without this discussion we would have not realized that we were causing frustration... > Besides, I'm academic. We don't get support. ;) Oh, well ;-) Regards, Daniel > Cheers, -- Daniel Riek, Product Manager Red Hat Enterprise Linux, Red Hat Inc. E-Mail: riek at redhat.com, http://www.redhat.com/ Key-FP: 3DD7 C376 C3E0 1917 9A63 6343 5A26 2C59 6C07 6F32 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Tue Jul 17 17:03:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 19:03:13 +0200 Subject: Plan for tomorrows (20070718) EPEL SIG meeting Message-ID: <469CF651.9000601@leemhuis.info> Hi all, find below the list of topics that are planed for the next EPEL SIG meeting which is scheduled for tomorrow, Wednesday at 17:00 UTC in #fedora-extras on irc.freenode.org. /topic EPEL Meeting ? broken deps ? Jeff_S /topic EPEL Meeting ? spam o magic script ? mmcgrath /topic EPEL Meeting ? branch for EPEL if Fedora maintainer does not react ? knurd /topic EPEL Meeting ? push new packages to testing after EPEL annoucement ? dgilmore /topic EPEL Meeting ? EPEL announcement ? qua8d /topic EPEL Meeting ? new meeting time? ? all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) /topic EPEL Meeting ? how about packges that part of EL5Client, but not part of EL5Server (aka python-imaging-issue) You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics at the end of the meeting itself. If your name/nick is on above list please give a update. That way all the interested parties know what up ahead of the meeting; that will avoid long delays and "status update monologues in the meeting. Thanks! CU knurd From fedora at leemhuis.info Tue Jul 17 17:11:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 19:11:26 +0200 Subject: Plan for tomorrows (20070718) EPEL SIG meeting In-Reply-To: <469CF651.9000601@leemhuis.info> References: <469CF651.9000601@leemhuis.info> Message-ID: <469CF83E.8020209@leemhuis.info> Hi! On 17.07.2007 19:03, Thorsten Leemhuis wrote: > > find below the list of topics that are planed for the next EPEL SIG > meeting which is scheduled for tomorrow, Wednesday at 17:00 UTC > in #fedora-extras on irc.freenode.org. As I mentioned earlier already, I'll miss tomorrows meeting. Sorry. > /topic EPEL Meeting ? broken deps ? Jeff_S dgilmore, could you push newly build packages once in the next 24 hours? And can somebody after that tun a script to check what deps are still broken? We have only 8 days left and I don't want to go into a if (broken deps); then delay_epel_annoucement by one week; fi loop that might never end. To avoid that I'd say we should on Sunday try to move all packages with broken deps to testing that can be moved there without introducing new broken deps (I'm willing to help with that if I get the neccessary permissions to the repo and the spam-o-epel script). Could you guys discuss this please tomorrow? > /topic EPEL Meeting ? spam o magic script ? mmcgrath Only ran until EL5Server afaics which lead to "interesting" results. And progress here? > /topic EPEL Meeting ? branch for EPEL if Fedora maintainer does not > react ? knurd See https://www.redhat.com/archives/epel-devel-list/2007-July/msg00104.html and https://www.redhat.com/archives/epel-devel-list/2007-July/msg00105.html Please get this ratified; gets a +1 from me. > /topic EPEL Meeting ? push new packages to testing after EPEL > annoucement ? dgilmore We should adjust this one or two days before the final announcement and make sure no new broken deps hit the repo. > /topic EPEL Meeting ? EPEL announcement ? quaid Everything else ready? > /topic EPEL Meeting ? new meeting time? ? all (see also > http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) Can wait > /topic EPEL Meeting ? how about packges that part of EL5Client, but not > part of EL5Server (aka python-imaging-issue) Discussed on the list currently, but should get attention in the meeting likely as well. Cu knurd From dlutter at redhat.com Tue Jul 17 17:33:38 2007 From: dlutter at redhat.com (David Lutterkort) Date: Tue, 17 Jul 2007 10:33:38 -0700 Subject: EPEL announcement planed for 20070726 In-Reply-To: <469C5B44.3020101@leemhuis.info> References: <46965835.9030705@leemhuis.info> <469673CF.1090408@fedoraproject.org> <469A1C90.3080305@leemhuis.info> <369bce3b0707151108t45ac389x23c66d8038ea475f@mail.gmail.com> <469C5B44.3020101@leemhuis.info> Message-ID: <1184693618.24028.13.camel@galia.watzmann.net> On Tue, 2007-07-17 at 08:01 +0200, Thorsten Leemhuis wrote: > I think EPEL deserves a real announcement (e.g. like a Fedora release, > but a bit smaller). Have you thought about an article for Redhat Magazine[1] ? I think that's quite popular with RHEL subscribers etc. and would give the opportunity for a hands-on intro to EPEL David [1] http://www.redhatmagazine.com/ From fedora at leemhuis.info Tue Jul 17 17:40:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 19:40:56 +0200 Subject: EPEL 5 Dependency Report - 20070713 In-Reply-To: <1184673640.1736.1.camel@gilboa-work-dev.localdomain> References: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> <469A6E16.2000903@leemhuis.info> <9050516b0707160012l29fb8dpe5284d7856d27e38@mail.gmail.com> <469B2444.3070801@leemhuis.info> <1184673640.1736.1.camel@gilboa-work-dev.localdomain> Message-ID: <469CFF28.8010906@leemhuis.info> On 17.07.2007 14:00, Gilboa Davara wrote: > On Mon, 2007-07-16 at 09:54 +0200, Thorsten Leemhuis wrote: >> On 16.07.2007 09:12, Gilboa Davara wrote: >>> On 7/15/07, Thorsten Leemhuis wrote: >>>> If you E-Mail is in the below list you are BCCed to this mail (?) please >>>> read on until the end! >>> ... >>>> gilboad_AT_gmail.com: Package gmrun requires xterm which is not in EPEL; >>>> its owned by mlichvar_AT_redhat.com in Fedora. >>> Weird. [...] >> Yeah, really interesting :-/ >> Did the spam-o-epel stuff Mike set up later yesterday trigger as well >> (it send a mail directly to you inbox with a subject "Broken >> dependencies: foo")? If not just ignore. > Got the email. /me suspects somethings stupid is going on here > Decided it was a mistake. (Send out a build just to be certain - no > errors what-so-ever) k, if you continue to get this mails in the future (e.g. if you still get them in two or three weeks) let us know so we can fix the bug (if there is one) or whitelist this package CU thl From fedora at leemhuis.info Tue Jul 17 17:43:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 17 Jul 2007 19:43:48 +0200 Subject: resolution for python-imaging in EPEL In-Reply-To: <1184683895.4481.128.camel@scorp> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <1184683895.4481.128.camel@scorp> Message-ID: <469CFFD4.6050105@leemhuis.info> On 17.07.2007 16:51, Daniel Riek wrote: > The client packages are going to become available to all server > customers as soon as the RHN profiles get updated. That takes some time > as it is a major repull of data. thx for your help Daniel. CU knurd From mastahnke at gmail.com Tue Jul 17 17:49:24 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 17 Jul 2007 12:49:24 -0500 Subject: RFC: EPEL branching if Fedora maintainer does not react In-Reply-To: <469C4A2F.1050803@leemhuis.info> References: <4687C867.8060400@leemhuis.info> <1183557174.3413.102.camel@rxm-581b.stl.gtri.gatech.edu> <4690E3A8.2040906@leemhuis.info> <4690F1B8.1@fedoraproject.org> <1184612612.3413.220.camel@rxm-581b.stl.gtri.gatech.edu> <469BD891.5020500@fedoraproject.org> <1184619272.3413.222.camel@rxm-581b.stl.gtri.gatech.edu> <469BDB92.5080508@fedoraproject.org> <1184620122.3413.224.camel@rxm-581b.stl.gtri.gatech.edu> <469C4A2F.1050803@leemhuis.info> Message-ID: <7874d9dd0707171049i4bdb7a6kc471fb9f28c502e2@mail.gmail.com> On 7/16/07, Thorsten Leemhuis wrote: > > > On 16.07.2007 23:08, rob myers wrote: > > On Tue, 2007-07-17 at 02:26 +0530, Rahul Sundaram wrote: > >> rob myers wrote: > >>> On Tue, 2007-07-17 at 02:14 +0530, Rahul Sundaram wrote: > >>>> rob myers wrote: > > [...] > > thx rob for working on this. > > > here is a complete version, with the co-maintainership changes rahul > > suggested. comments? > > Looks good. I'd like to get this ratified in tomorrows meeting. > > (Note that the old stuff is in the wiki already at > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-00c9e731bb7bc5bb78caf8d124da3a329400fcd8 > If this was ratified just add the new text there please. tia!) > > Ohh, can somebody handle that for me? I'll miss the meeting tomorrow > because I'll help a colleague from work with moving to his new house. > > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > I can do it. stahnma From buildsys at fedoraproject.org Tue Jul 17 18:27:58 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 17 Jul 2007 14:27:58 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-17 Message-ID: <20070717182758.96F55152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 11 NEW cacti-0.8.6j-1.el5 : An rrd based graphing tool NEW ctapi-common-1.0-4.el5 : Common files and packaging infrastructure for CT-API modules NEW ftgl-2.1.2-5.el5 : OpenGL frontend to Freetype 2 NEW iksemel-1.2-13.el5 : An XML parser library designed for Jabber applications NEW logserial-0.4.2-4.el5 : Package for logging incoming bytes on asynchronous serial ports mod_fcgid-2.1-3.el5 NEW rdiff-backup-1.0.5-2.el5 : Convenient and transparent local/remote incremental mirror/backup NEW tachyon-0.97-2.el5 : Parallel / Multiprocessor Ray Tracing System wine-0.9.41-1.el5 wine-docs-0.9.41-1.el5 zabbix-1.4.1-1.el5 Packages built and released for Fedora EPEL 4: 6 NEW ctapi-common-1.0-4.el4 : Common files and packaging infrastructure for CT-API modules NEW iksemel-1.2-13.el4 : An XML parser library designed for Jabber applications NEW logserial-0.4.2-4.el4 : Package for logging incoming bytes on asynchronous serial ports NEW rdiff-backup-1.0.5-2.el4 : Convenient and transparent local/remote incremental mirror/backup NEW tachyon-0.97-6.el4 : Parallel / Multiprocessor Ray Tracing System wine-0.9.41-1.el4 Changes in Fedora EPEL 5: cacti-0.8.6j-1.el5 ------------------ * Sat May 05 2007 Mike McGrath - 0.8.6j-5 - Upstream released new version ctapi-common-1.0-4.el5 ---------------------- * Fri Sep 15 2006 Ville Skytt? - 1.0-4 - Rebuild. ftgl-2.1.2-5.el5 ---------------- * Sat Jul 14 2007 kwizart < kwizart at gmail.com > - 2.1.2-5 - Fix version field the whole package * Fri Jul 13 2007 kwizart < kwizart at gmail.com > - 2.1.2-4 - Modified ftgl-2.1.2-pc_req.patch - Add Requires freefont to -utils * Fri Jul 13 2007 kwizart < kwizart at gmail.com > - 2.1.2-3 - Add Requirements for -devel - Preserve timestramp for install step - Add ftgl-utils to prevent conflict with multilibs Add patch to prevent rpath iksemel-1.2-13.el5 ------------------ * Thu Nov 16 2006 Jeffrey C. Ollie - 1.2-13 - ppp != ppc logserial-0.4.2-4.el5 --------------------- * Tue Nov 14 2006 lonely wolf 0.4.2-4 - remove some debugging lines from the spec. No effect on generated binaries mod_fcgid-2.1-3.el5 ------------------- * Fri Jun 15 2007 Paul Howarth 2.1-3 - Major update of SELinux policy, supporting accessing data on NFS/CIFS shares and a new boolean, httpd_fastcgi_can_sendmail, to allow connections to SMTP servers - Fix for SELinux policy on Fedora 7, which didn't work due to changes in the permissions macros in the underlying selinux-policy package * Wed Mar 21 2007 Paul Howarth 2.1-2 - Add RHEL5 with SELinux support - Rename README.Fedora to README.RPM rdiff-backup-1.0.5-2.el5 ------------------------ * Fri Jun 15 2007 Gavin Henry 1.0.5-2 - Applied patch from Marcin Zajaczkowski for addition of pylibacl, pyxattr in Requires section tachyon-0.97-2.el5 ------------------ * Wed Nov 29 2006 Dominik 'Rathann' Mierzejewski 0.97-2 - use only kosher CFLAGS - fix target setting wine-0.9.41-1.el5 ----------------- * Mon Jul 16 2007 Andreas Bierfert - 0.9.41-1 - version upgrade wine-docs-0.9.41-1.el5 ---------------------- * Mon Jul 16 2007 Andreas Bierfert - 0.9.41-1 - version upgrade * Sun Jun 17 2007 Andreas Bierfert 0.9.39-1 - version upgrade zabbix-1.4.1-1.el5 ------------------ * Mon Jul 02 2007 Jarod Wilson 1.4.1-1 - New upstream release * Fri Jun 29 2007 Jarod Wilson 1.4-3 - Install correct sql init files (#244991) - Add Requires: php-bcmath to zabbix-web (#245767) * Wed May 30 2007 Jarod Wilson 1.4-2 - Add placeholder zabbix.conf.php * Tue May 29 2007 Jarod Wilson 1.4-1 - New upstream release Changes in Fedora EPEL 4: ctapi-common-1.0-4.el4 ---------------------- * Fri Sep 15 2006 Ville Skytt? - 1.0-4 - Rebuild. iksemel-1.2-13.el4 ------------------ * Thu Nov 16 2006 Jeffrey C. Ollie - 1.2-13 - ppp != ppc logserial-0.4.2-4.el4 --------------------- * Tue Nov 14 2006 lonely wolf 0.4.2-4 - remove some debugging lines from the spec. No effect on generated binaries rdiff-backup-1.0.5-2.el4 ------------------------ * Fri Jun 15 2007 Gavin Henry 1.0.5-2 - Applied patch from Marcin Zajaczkowski for addition of pylibacl, pyxattr in Requires section tachyon-0.97-6.el4 ------------------ * Mon Jul 16 2007 Dominik 'Rathann' Mierzejewski 0.97-6 - there's no lam-devel in RHEL, BR: lam * Sat Jul 14 2007 Dominik 'Rathann' Mierzejewski 0.97-5 - port to EL-4 branch - drop SPARC support wine-0.9.41-1.el4 ----------------- * Mon Jul 16 2007 Andreas Bierfert - 0.9.41-1 - version upgrade For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dag at wieers.com Tue Jul 17 19:05:25 2007 From: dag at wieers.com (Dag Wieers) Date: Tue, 17 Jul 2007 21:05:25 +0200 (CEST) Subject: Log from this weeks EPEL-SIG meeting (20070711) In-Reply-To: <469A1F3D.4030603@leemhuis.info> References: <469A1F3D.4030603@leemhuis.info> Message-ID: On Sun, 15 Jul 2007, Thorsten Leemhuis wrote: > 00:40:41 < dgilmore> | i noticed that dag made some derogatory comments about epel on the centos mailing list > 00:40:51 < quaid> | oh, good > 00:40:58 < quaid> | nothing quite like keeping the flames warm > 00:41:01 < dgilmore> | saying that we dont want to work with him > 00:41:12 < quaid> | in fact -snip- > 00:42:05 < quaid> | it's hard because these guys all had good points > 00:42:15 < quaid> | but they put way too much heat into it > 00:42:29 < quaid> | and burned the bridge before it could be built > 00:42:45 < quaid> | anyway, water under the ... oh, wait, nevermind > 00:42:49 < knurd> | we maybe should some carefully choose words into the wiki > 00:42:55 < knurd> | why we didn#t go for repotags -snip- My statements are *NOT* about repotags. Repotags would not provide compatibility, but repotags would help cope with incompatibility. Nevertheless, my statements had nothing to do with repotags. > 00:43:03 < dgilmore> | http://lists.centos.org/pipermail/centos/2007-July/083569.html > 00:43:04 < quaid> | a good FAQ entry > 00:43:08 < knurd> | and that we suggest that our contributors cooperate I stand by that statement. There is no interest from EPEL to work together with other repositories. The policy is to be the one and only single repository for RHEL/CentOS. EPEL is in its right to go for that, but that should be advertised. Instead what is happening is that EPEL is claiming that 'their contributors cooperate'. Much like Fedora Extras in the past claimed this. If Fedora Extras did cooperate, their may not have been any compatibilities and who knows, there may not have been an RPMforge, or an ATrpms today. Nevertheless, if someone would say exactly that "EPEL is not interested in compatibility with other repositories" or even "EPEL claims it is impossible to achieve compatibility with 3rd party repositories" He is starting a flameware ? Is being derogatory ? I can understand that EPEL wants to hide this fact from the public, or create another perception. But EPEL is being dishonest about its intentions to lure packagers and users. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From sundaram at fedoraproject.org Tue Jul 17 19:43:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Jul 2007 01:13:59 +0530 Subject: EPEL announcement planed for 20070726 In-Reply-To: <1184693618.24028.13.camel@galia.watzmann.net> References: <46965835.9030705@leemhuis.info> <469673CF.1090408@fedoraproject.org> <469A1C90.3080305@leemhuis.info> <369bce3b0707151108t45ac389x23c66d8038ea475f@mail.gmail.com> <469C5B44.3020101@leemhuis.info> <1184693618.24028.13.camel@galia.watzmann.net> Message-ID: <469D1BFF.3010204@fedoraproject.org> David Lutterkort wrote: > On Tue, 2007-07-17 at 08:01 +0200, Thorsten Leemhuis wrote: >> I think EPEL deserves a real announcement (e.g. like a Fedora release, >> but a bit smaller). > > Have you thought about an article for Redhat Magazine[1] ? I think > that's quite popular with RHEL subscribers etc. and would give the > opportunity for a hands-on intro to EPEL I can write one if that is ok. Rahul From notting at redhat.com Tue Jul 17 20:32:43 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 17 Jul 2007 16:32:43 -0400 Subject: orphaning/removing packages before launch? Message-ID: <20070717203243.GA5158@nostromo.devel.redhat.com> So, I built g-wrap for EPEL-5 because it was needed by gnucash; however, the new version of gnucash does not need it. Is it best to leave it unused in the repo, or to remove and orphan it before we launch? Bill From sundaram at fedoraproject.org Tue Jul 17 21:01:54 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Jul 2007 02:31:54 +0530 Subject: orphaning/removing packages before launch? In-Reply-To: <20070717203243.GA5158@nostromo.devel.redhat.com> References: <20070717203243.GA5158@nostromo.devel.redhat.com> Message-ID: <469D2E42.7010304@fedoraproject.org> Bill Nottingham wrote: > So, I built g-wrap for EPEL-5 because it was needed by gnucash; however, > the new version of gnucash does not need it. Is it best to leave it unused > in the repo, or to remove and orphan it before we launch? Remove and orphan IMO. Rahul From notting at redhat.com Tue Jul 17 21:21:33 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 17 Jul 2007 17:21:33 -0400 Subject: orphaning/removing packages before launch? In-Reply-To: <469D2E42.7010304@fedoraproject.org> References: <20070717203243.GA5158@nostromo.devel.redhat.com> <469D2E42.7010304@fedoraproject.org> Message-ID: <20070717212133.GA15163@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Bill Nottingham wrote: >> So, I built g-wrap for EPEL-5 because it was needed by gnucash; however, >> the new version of gnucash does not need it. Is it best to leave it unused >> in the repo, or to remove and orphan it before we launch? > > Remove and orphan IMO. OK, will go through the motions. Bill From dennis at ausil.us Tue Jul 17 21:29:13 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 17 Jul 2007 16:29:13 -0500 Subject: orphaning/removing packages before launch? In-Reply-To: <20070717212133.GA15163@nostromo.devel.redhat.com> References: <20070717203243.GA5158@nostromo.devel.redhat.com> <469D2E42.7010304@fedoraproject.org> <20070717212133.GA15163@nostromo.devel.redhat.com> Message-ID: <200707171629.18926.dennis@ausil.us> Once upon a time Tuesday 17 July 2007, Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: > > Bill Nottingham wrote: > >> So, I built g-wrap for EPEL-5 because it was needed by gnucash; however, > >> the new version of gnucash does not need it. Is it best to leave it > >> unused in the repo, or to remove and orphan it before we launch? > > > > Remove and orphan IMO. > > OK, will go through the motions. > > Bill It has been removed from the repository Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From buildsys at fedoraproject.org Tue Jul 17 21:32:40 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 17 Jul 2007 17:32:40 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-17 Message-ID: <20070717213240.32223152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 2 gnucash-2.2.0-1.el5 NEW goffice-0.2.2-1.el5 : Goffice support libraries Changes in Fedora EPEL 5: gnucash-2.2.0-1.el5 ------------------- * Mon Jul 16 2007 Bill Nottingham - 2.2.0-1 - update to 2.2.0 * Mon Jul 02 2007 Bill Nottingham - 2.1.5-1 - update to 2.1.5 * Mon Jun 25 2007 Bill Nottingham - 2.1.4-1 - update to RC version 2.1.4 - switch to using goffice04, and stock gtkhtml3 - no more g-wrap or libtool-ltdl - use swig goffice-0.2.2-1.el5 ------------------- * Thu Mar 01 2007 Hans de Goede 0.2.2-1 - New upstream release 0.2.2 - Fix rpath usage on x86_64 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From smooge at gmail.com Tue Jul 17 22:23:51 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 17 Jul 2007 16:23:51 -0600 Subject: resolution for python-imaging in EPEL In-Reply-To: <469CFFD4.6050105@leemhuis.info> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <1184683895.4481.128.camel@scorp> <469CFFD4.6050105@leemhuis.info> Message-ID: <80d7e4090707171523sca196e4ga183deb4ee523b1@mail.gmail.com> On 7/17/07, Thorsten Leemhuis wrote: > > > On 17.07.2007 16:51, Daniel Riek wrote: > > The client packages are going to become available to all server > > customers as soon as the RHN profiles get updated. That takes some time > > as it is a major repull of data. > > thx for your help Daniel. > Yes thanks to all the RH people on this.. Longterm, there is going to be a mismatch between RHEL and CentOS/Scientific Linux offerings. As in, an EPEL package might need stuff from MultiOS or RHAPS (or whatever its future incarnation is) or etc etc etc. There should be a methodology for dealing with these packages or problems: 1) Should packages be built/included that can work with the lowest common denominator of channel offerings? [EG desktop or whatever is the smallest channel offering?] 2) If not, how do you offer packages that do not 'break' for people. If I do a yum install xyz and it includes something from outside of my 'Desktop' channel ... do I get a 'Dependencies not found. Please pony up more money.' message? Or do I get those dependencies via the .0 method 3) Other issues that my blood sugar cant think of at the moment. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From smooge at gmail.com Tue Jul 17 23:11:33 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 17 Jul 2007 17:11:33 -0600 Subject: EPEL announcement planed for 20070726 In-Reply-To: <469D1BFF.3010204@fedoraproject.org> References: <46965835.9030705@leemhuis.info> <469673CF.1090408@fedoraproject.org> <469A1C90.3080305@leemhuis.info> <369bce3b0707151108t45ac389x23c66d8038ea475f@mail.gmail.com> <469C5B44.3020101@leemhuis.info> <1184693618.24028.13.camel@galia.watzmann.net> <469D1BFF.3010204@fedoraproject.org> Message-ID: <80d7e4090707171611o57ce6334ub34e06a2da4fd440@mail.gmail.com> On 7/17/07, Rahul Sundaram wrote: > David Lutterkort wrote: > > On Tue, 2007-07-17 at 08:01 +0200, Thorsten Leemhuis wrote: > >> I think EPEL deserves a real announcement (e.g. like a Fedora release, > >> but a bit smaller). > > > > Have you thought about an article for Redhat Magazine[1] ? I think > > that's quite popular with RHEL subscribers etc. and would give the > > opportunity for a hands-on intro to EPEL > > I can write one if that is ok. > Announcing to LWN is also known to work :). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From sundaram at fedoraproject.org Tue Jul 17 23:16:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Jul 2007 04:46:33 +0530 Subject: EPEL announcement planed for 20070726 In-Reply-To: <80d7e4090707171611o57ce6334ub34e06a2da4fd440@mail.gmail.com> References: <46965835.9030705@leemhuis.info> <469673CF.1090408@fedoraproject.org> <469A1C90.3080305@leemhuis.info> <369bce3b0707151108t45ac389x23c66d8038ea475f@mail.gmail.com> <469C5B44.3020101@leemhuis.info> <1184693618.24028.13.camel@galia.watzmann.net> <469D1BFF.3010204@fedoraproject.org> <80d7e4090707171611o57ce6334ub34e06a2da4fd440@mail.gmail.com> Message-ID: <469D4DD1.8050803@fedoraproject.org> Stephen John Smoogen wrote: > On 7/17/07, Rahul Sundaram wrote: >> David Lutterkort wrote: >> > On Tue, 2007-07-17 at 08:01 +0200, Thorsten Leemhuis wrote: >> >> I think EPEL deserves a real announcement (e.g. like a Fedora release, >> >> but a bit smaller). >> > >> > Have you thought about an article for Redhat Magazine[1] ? I think >> > that's quite popular with RHEL subscribers etc. and would give the >> > opportunity for a hands-on intro to EPEL >> >> I can write one if that is ok. >> > > Announcing to LWN is also known to work :). That's part of the spreading news list in the wiki page I pointed earlier. Rahul From sundaram at fedoraproject.org Tue Jul 17 23:19:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 18 Jul 2007 04:49:55 +0530 Subject: resolution for python-imaging in EPEL In-Reply-To: <80d7e4090707171523sca196e4ga183deb4ee523b1@mail.gmail.com> References: <469B7528.3070800@redhat.com> <469C4DFC.2050408@leemhuis.info> <20070717094408.3c64cfa0@localhost.localdomain> <1184683895.4481.128.camel@scorp> <469CFFD4.6050105@leemhuis.info> <80d7e4090707171523sca196e4ga183deb4ee523b1@mail.gmail.com> Message-ID: <469D4E9B.2030609@fedoraproject.org> Stephen John Smoogen wrote: > On 7/17/07, Thorsten Leemhuis wrote: >> >> >> On 17.07.2007 16:51, Daniel Riek wrote: >> > The client packages are going to become available to all server >> > customers as soon as the RHN profiles get updated. That takes some time >> > as it is a major repull of data. >> >> thx for your help Daniel. >> > > Yes thanks to all the RH people on this.. Longterm, there is going to > be a mismatch between RHEL and CentOS/Scientific Linux offerings. As > in, an EPEL package might need stuff from MultiOS or RHAPS (or > whatever its future incarnation is) or etc etc etc. There should be a > methodology for dealing with these packages or problems: > > 1) Should packages be built/included that can work with the lowest > common denominator of channel offerings? [EG desktop or whatever is > the smallest channel offering?] > > 2) If not, how do you offer packages that do not 'break' for people. > If I do a yum install xyz and it includes something from outside of my > 'Desktop' channel ... do I get a 'Dependencies not found. Please pony > up more money.' message? Or do I get those dependencies via the .0 > method > > 3) Other issues that my blood sugar cant think of at the moment. 3) What do you do when Red Hat introduces new packages into RHEL when those packages already exist in EPEL? These can happen during the regular major updates like 5.1 or 4.6. Prior information on what new packages goes into those updates are not always available publicly. Rahul From fedora at leemhuis.info Wed Jul 18 04:47:54 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Jul 2007 06:47:54 +0200 Subject: EPEL announcement planed for 20070726 In-Reply-To: <469D1BFF.3010204@fedoraproject.org> References: <46965835.9030705@leemhuis.info> <469673CF.1090408@fedoraproject.org> <469A1C90.3080305@leemhuis.info> <369bce3b0707151108t45ac389x23c66d8038ea475f@mail.gmail.com> <469C5B44.3020101@leemhuis.info> <1184693618.24028.13.camel@galia.watzmann.net> <469D1BFF.3010204@fedoraproject.org> Message-ID: <469D9B7A.1000405@leemhuis.info> On 17.07.2007 21:43, Rahul Sundaram wrote: > David Lutterkort wrote: >> On Tue, 2007-07-17 at 08:01 +0200, Thorsten Leemhuis wrote: >>> I think EPEL deserves a real announcement (e.g. like a Fedora release, >>> but a bit smaller). >> Have you thought about an article for Redhat Magazine[1] ? I think >> that's quite popular with RHEL subscribers etc. and would give the >> opportunity for a hands-on intro to EPEL > I can write one if that is ok. That would be really great; if you need help/feedback just come here (or ask me or someone else that's heavily involved in EPEL in private). Thx for helping Rahul. CU thl From fedora at leemhuis.info Wed Jul 18 09:34:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Jul 2007 11:34:56 +0200 Subject: Log from this weeks EPEL-SIG meeting (20070711) In-Reply-To: References: <469A1F3D.4030603@leemhuis.info> Message-ID: <469DDEC0.2020500@leemhuis.info> On 17.07.2007 21:05, Dag Wieers wrote: > On Sun, 15 Jul 2007, Thorsten Leemhuis wrote: > >> 00:40:41 < dgilmore> | i noticed that dag made some derogatory comments about epel on the centos mailing list >> 00:40:51 < quaid> | oh, good >> 00:40:58 < quaid> | nothing quite like keeping the flames warm >> 00:41:01 < dgilmore> | saying that we dont want to work with him >> 00:41:12 < quaid> | in fact > -snip- >> 00:42:05 < quaid> | it's hard because these guys all had good points >> 00:42:15 < quaid> | but they put way too much heat into it >> 00:42:29 < quaid> | and burned the bridge before it could be built >> 00:42:45 < quaid> | anyway, water under the ... oh, wait, nevermind >> 00:42:49 < knurd> | we maybe should some carefully choose words into the wiki >> 00:42:55 < knurd> | why we didn#t go for repotags > -snip- > > My statements are *NOT* about repotags. And my statements were not about your statements -- they just triggered a "we should document the reasons why we do some things (like for example no repotags) the way we do them" for me. That's all. > [...] CU knurd From sheltren at cs.ucsb.edu Wed Jul 18 12:17:24 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 18 Jul 2007 08:17:24 -0400 Subject: Plan for tomorrows (20070718) EPEL SIG meeting In-Reply-To: <469CF83E.8020209@leemhuis.info> References: <469CF651.9000601@leemhuis.info> <469CF83E.8020209@leemhuis.info> Message-ID: <9F3EE5D1-33CB-4AEB-8EAC-9A7C44DCC218@cs.ucsb.edu> On Jul 17, 2007, at 1:11 PM, Thorsten Leemhuis wrote: >> /topic EPEL Meeting ? broken deps ? Jeff_S > > dgilmore, could you push newly build packages once in the next 24 > hours? > And can somebody after that tun a script to check what deps are still > broken? We have only 8 days left and I don't want to go into a > I can run repoclosure against CentOS 4 & 5 trees, but it would be nice if someone could also run against the RHEL packages we are building against. For example, can the spam-o-lot script be run without emailing out notices simply to come up with a list of broken deps? Or can someone run repoclosure against the RHEL sources we are building against? Thanks, Jeff From mmahut at fedoraproject.org Wed Jul 18 13:14:35 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Wed, 18 Jul 2007 15:14:35 +0200 Subject: Self-introduction: Marek Mahiut Message-ID: <469E123B.6060705@fedoraproject.org> Hello all! Just a quick self-introduction. My name is Marek Mahut and I want to help you to build/maintain the EPEL project. I already committed my packages /2 :-)/ into EPEL trees. At daily basis (at work), I'm dealing with problems and maintenance of about 1000 RHEL4/5 stations and I find EPEL project very useful. Any questions are welcome. -- Marek Mahut http://www.fedoraproject.org/ Fedora Ambassador http://www.jamendo.com/ From mmcgrath at redhat.com Wed Jul 18 13:22:21 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 18 Jul 2007 08:22:21 -0500 Subject: Plan for tomorrows (20070718) EPEL SIG meeting In-Reply-To: <9F3EE5D1-33CB-4AEB-8EAC-9A7C44DCC218@cs.ucsb.edu> References: <469CF651.9000601@leemhuis.info> <469CF83E.8020209@leemhuis.info> <9F3EE5D1-33CB-4AEB-8EAC-9A7C44DCC218@cs.ucsb.edu> Message-ID: <469E140D.2020001@redhat.com> Jeff Sheltren wrote: > On Jul 17, 2007, at 1:11 PM, Thorsten Leemhuis wrote: >>> /topic EPEL Meeting ? broken deps ? Jeff_S >> >> dgilmore, could you push newly build packages once in the next 24 hours? >> And can somebody after that tun a script to check what deps are still >> broken? We have only 8 days left and I don't want to go into a >> > > I can run repoclosure against CentOS 4 & 5 trees, but it would be nice > if someone could also run against the RHEL packages we are building > against. For example, can the spam-o-lot script be run without > emailing out notices simply to come up with a list of broken deps? Or > can someone run repoclosure against the RHEL sources we are building > against? Already done, just waiting for the meeting today to enable it completely. -Mike From fedora at leemhuis.info Wed Jul 18 13:58:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Jul 2007 15:58:33 +0200 Subject: Self-introduction: Marek Mahiut In-Reply-To: <469E123B.6060705@fedoraproject.org> References: <469E123B.6060705@fedoraproject.org> Message-ID: <469E1C89.9000707@leemhuis.info> On 18.07.2007 15:14, Marek Mahut wrote: > Just a quick self-introduction. My name is Marek Mahut and I want to > help you to build/maintain the EPEL project. Welcome Marek! > Any questions are welcome. In case you (or others interested in EPEL) looks for something to work on: it could be nice if somebody could look over the EPEL wishlist http://fedoraproject.org/wiki/EPEL/WishList , check if the Fedora might be interested in EPEL and pick up a package or two (or more ;-) ) for EPEL. Ohh, and there are some pacakge in FC6 which are not part of EPEL; see http://fedoraproject.org/wiki/EPEL/FAQ#head-f1c2fc524be33cdc730200379a3814c3d80c0203 Some of them would be nice to have in EPEL, too. Note, I'm not sure if both lists are fully up2date; getting it up2date and cleaned up would be yet another task for a volunteer with some spare cycles ;-) CU thl From mmahut at fedoraproject.org Wed Jul 18 14:08:20 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Wed, 18 Jul 2007 16:08:20 +0200 Subject: Self-introduction: Marek Mahiut In-Reply-To: <469E1C89.9000707@leemhuis.info> References: <469E123B.6060705@fedoraproject.org> <469E1C89.9000707@leemhuis.info> Message-ID: <469E1ED4.7020204@fedoraproject.org> Hey Thorsten, Thorsten Leemhuis wrote: > On 18.07.2007 15:14, Marek Mahut wrote: >> Just a quick self-introduction. My name is Marek Mahut and I want to >> help you to build/maintain the EPEL project. > > Welcome Marek! Thank you! >> Any questions are welcome. > > In case you (or others interested in EPEL) looks for something to work > on: it could be nice if somebody could look over the EPEL wishlist > http://fedoraproject.org/wiki/EPEL/WishList , check if the Fedora might > be interested in EPEL and pick up a package or two (or more ;-) ) for EPEL. Has been the letter asking maintainers to branch their packages for EPEL sent for packages listed on EPEL/WishList? > Ohh, and there are some pacakge in FC6 which are not part of EPEL; see > http://fedoraproject.org/wiki/EPEL/FAQ#head-f1c2fc524be33cdc730200379a3814c3d80c0203 > Some of them would be nice to have in EPEL, too. > > Note, I'm not sure if both lists are fully up2date; getting it up2date > and cleaned up would be yet another task for a volunteer with some spare > cycles ;-) > > CU > thl -- /Marek. -- Marek Mahut http://www.fedoraproject.org/ Fedora Ambassador http://www.jamendo.com/ From fedora at leemhuis.info Wed Jul 18 14:20:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 18 Jul 2007 16:20:52 +0200 Subject: Self-introduction: Marek Mahiut In-Reply-To: <469E1ED4.7020204@fedoraproject.org> References: <469E123B.6060705@fedoraproject.org> <469E1C89.9000707@leemhuis.info> <469E1ED4.7020204@fedoraproject.org> Message-ID: <469E21C4.4010804@leemhuis.info> On 18.07.2007 16:08, Marek Mahut wrote: > Thorsten Leemhuis wrote: >> On 18.07.2007 15:14, Marek Mahut wrote: >>> Any questions are welcome. >> In case you (or others interested in EPEL) looks for something to work >> on: it could be nice if somebody could look over the EPEL wishlist >> http://fedoraproject.org/wiki/EPEL/WishList , check if the Fedora might >> be interested in EPEL and pick up a package or two (or more ;-) ) for EPEL. > Has been the letter asking maintainers to branch their packages for EPEL > sent for packages listed on EPEL/WishList? Don't think so. But the template-letter might need some small adjustments if you'd use it for this purpose. Note that we should avoid sending mails "would you be filling to maintain foo in EPEL" to people multiple times. People that stated to not participate in EPEL should not be poked either. Feel free to enhance the wiki pages if needed. CU thl From sheltren at cs.ucsb.edu Wed Jul 18 15:36:14 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 18 Jul 2007 11:36:14 -0400 Subject: Plan for tomorrows (20070718) EPEL SIG meeting In-Reply-To: <469E140D.2020001@redhat.com> References: <469CF651.9000601@leemhuis.info> <469CF83E.8020209@leemhuis.info> <9F3EE5D1-33CB-4AEB-8EAC-9A7C44DCC218@cs.ucsb.edu> <469E140D.2020001@redhat.com> Message-ID: <1ADA0992-7E88-4C26-B8DE-970507268FC0@cs.ucsb.edu> On Jul 18, 2007, at 9:22 AM, Mike McGrath wrote: > Jeff Sheltren wrote: >> I can run repoclosure against CentOS 4 & 5 trees, but it would be >> nice if someone could also run against the RHEL packages we are >> building against. For example, can the spam-o-lot script be run >> without emailing out notices simply to come up with a list of >> broken deps? Or can someone run repoclosure against the RHEL >> sources we are building against? > > Already done, just waiting for the meeting today to enable it > completely. > > -Mike > Cool, thanks. I just ran repoclosure against EPEL 4/5 and CentOS 4/5, and put the results here: http://www.sheltren.com/epel/repoclosure/2007-07-18/ It looks like we've still got a bunch of broken dependencies... -Jeff From mastahnke at gmail.com Wed Jul 18 17:54:41 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 18 Jul 2007 12:54:41 -0500 Subject: Log from this weeks EPEL-SIG meeting (20070718) Message-ID: <7874d9dd0707181054g6c7ff0a4i141e251dbf8a99e4@mail.gmail.com> [12:00] ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, quaid [12:00] * Jeff_S here [12:00] hi [12:00] * nirik is only going to be around for the first few minutes... have another meeting I have to go off to. ;( [12:00] ok [12:00] any topics, you need to ring on nirik? [12:00] anyone else around? [12:01] * dgilmore is here [12:01] lets see... let me look at the schedule. [12:02] We'll give people another minute or so, and then get started [12:02] would like to see the spam-o-matic active if it isn't already. We need those broken deps fixed... [12:02] --> mdomsch has joined this channel (n=Matt_Dom at cpe-70-124-62-55.austin.res.rr.com). [12:02] agreed, but it seems much/all of the issues stem from lack of packges [12:03] yeah. [12:04] *** You set the channel topic to "EPEL Meeting - broken Deps - Jeff_S". [12:04] Jeff_S: not sure how your name alone got assigned to this, but any updates? [12:04] see my email I just sent out - there are still lots of missing deps [12:05] I agree with knurd that we should perhaps move them to testing next week if we still don't have a response from the maintainers [12:05] I saw that, do we have any plans for a solution? [12:05] quaid is likely not around [12:05] ok, mmcgrath is also MIA [12:05] * quaid is here, sorry [12:05] if we can run the spammy script at least once more this week, that might help bug people enough to fix things [12:06] is it people fixing their own dependencies though, or is dependencies between other packages? [12:06] mmcgrath: can you send out a summary of what be broke [12:06] but I don't think we should sit around waiting for everything to get fixed, as it may never happen [12:06] Only a week to add/branch/build a lot of packages seems pretty quick [12:06] pong [12:06] sorry [12:06] Sure [12:06] stahnma: it seems to me it is missing other people's packages [12:06] let me do a run right now (it takes a bit) [12:06] that was the impression I got also [12:06] I've found that if you mail maintainers direct with a solution, most of them will do something... I can try and do that some in the next few days. [12:07] ie. people may need to step up and co-maintain for epel to get their needed deps [12:07] there is some movement to fix bugzilla... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248765 [12:07] * dgilmore wonders if mmcgrath will take fping :) or should j-rod [12:08] dgilmore: here's my list against centos: http://www.sheltren.com/epel/repoclosure/2007-07-18/ [12:08] * nirik packs up to head out. Sorry I got double meeting booked. Feel free to email me or catch me later if there is anything specific folks would like me to help with. [12:08] should we send an update out to the list once again, asking them to branch/update status? I feel like we have done this a number of times already [12:08] bye nirik [12:09] stahnma: yes, we have done that already [12:09] --> _blah_ has joined this channel (i=rob at 216.115.88.10). [12:09] ok, well maybe we talk about the testing solution then [12:10] i though i had blacklisted nagios from being multilib [12:10] I think we need to either do that or drop the broken packages [12:10] dgilmore: what's the feasability of quarentining packages with broken deps? [12:11] stahnma: its manual process [12:11] hmm [12:11] i.e. move them out of the tree [12:13] so tha't s quite painful? [12:15] any proposed solution? [12:15] should we bring it up on list again? I really don't understand the effort required from infrastructure side to remove broken dep packages. [12:15] knurd volunteered to do the work on that if needed [12:16] that's a plus :) [12:16] ok, next topic? [12:16] well, can we all agree that something needs to get done before announce? [12:16] +1 [12:16] we can discuss specifics on the list [12:17] is everyone gone? :) [12:17] should I enable a weekly run of the spam script? [12:17] * mmcgrath is running one right now with --nomail to get a list of whats borked. [12:17] mmcgrath: I think that would be nice [12:17] *** You set the channel topic to "EPEL Meeting - spam o magic script - mmcgrath". [12:18] <_blah_> weekly? how about daily? :) [12:18] I vote once the kinks are worked out, we enable it [12:18] mmcgrath: is it easy to change the script to point to testing/ once we start using that directory? [12:19] stahnma: I think the kinks are mostly worked out, Once this thing finishes I'll send it to paste bin (or the list if it takes too long) [12:20] mmcgrath: id like to see a weekly run [12:20] +1 [12:21] Jeff_S: yes, it should be pretty easy. [12:22] great [12:22] ok [12:22] /topic EPEL Meeting ? branch for EPEL if Fedora maintainer does not [12:22] react ? knurd [12:22] friggen [12:22] :) [12:22] *** You set the channel topic to "EPEL Meeting - branch for EPEL if Fedora Maintainer does not react". [12:23] http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-00c9e731bb7bc5bb78caf8d124da3a329400fcd8 [12:23] This is what the List has put together [12:23] do we like it? [12:23] I think knurd wanted to ratify it [12:23] I think it serves it's purpose [12:23] works for me [12:24] * stahnma looks around and wonders if anyone else will speak up [12:24] * mmcgrath notes - http://pastebin.ca/624953 <--- spam-o-epel script run on RHEL4 tree [12:24] <_blah_> it isn't what is on the list [12:25] https://www.redhat.com/archives/epel-devel-list/2007-July/msg00104.html <-- is that what should be in the wiki? [12:26] it looks good to me [12:26] <_blah_> jeff_s: yes, that is the latest from the list. [12:27] * stahnma has the wrong URL? :) [12:27] * stahnma will update the wiki [12:28] with the text from list [12:28] assuming we agree it says the right thing [12:28] <_blah_> stahnma: thanks. that is what needs to be done. [12:28] +1 [12:28] <_blah_> i don't get a vote but +1 :) [12:29] any thoughts quaid mmcgrath dgilmore? [12:29] * quaid reads [12:30] I'm remiss in finishing the edit oon Guidelines... but it's all language, not details [12:30] details seemed fine with me [12:30] ok [12:30] sorry, but I need to go! [12:30] ok [12:30] hmm [12:30] we're reaching a very small number here [12:30] I think we need knurd to discuss the meeting time anyway [12:31] * stahnma would like to talk about meeting times, but not enough people here.... [12:31] i dont think we have enough people to make a descison [12:31] (must be a bad time to have a meeting ) [12:31] * stahnma hints [12:31] ;) [12:31] mmcgrath: spam-o-matic output looks good [12:31] usually this is good, but I've got a lot of stuff that just came up... [12:31] ok, I will move to general discussion and we'll postpone the rest [12:31] We need to have things branched that are needed [12:32] *** You set the channel topic to "EPEL - general discussion". [12:32] stahnma: I expect epel5 to be finished running in a bit [12:32] so dgilmore, are the cvs admins behind on branching, or is it a lack of requests? [12:33] nirik: has been branching like crazy [12:33] its a lack of requests [12:33] ok [12:33] that's what I thought [12:34] any thoughts on the RHEL5 server vs RHEL5 client stuff? [12:34] other than, it's a headache [12:36] [470] #php ##php Forwarding to another channel [12:36] [Notice] -ChanServ- [##php] "Welcome to ##php - Help and Discussion; PHP Social channel is at #phpc" [12:37] no freaking idea [12:37] we need to find out what Red Hat support will find acceptable [12:37] * mmcgrath shakes head and sighs. [12:37] which will probably require the skills of quaid [12:37] dgilmore: thats probably the best route. [12:38] before we even think of something we need to make sure its ok [12:38] <_blah_> mmcgrath: odd i tried to diff your spam-o-epel output from mine, and the packages are slightly out of order making the diff pointless. in general they look very similar. [12:39] _blah_: thats always fun. I suppose you could sort the output of each first. [12:40] dgilmore: sounds like we should stay away from packaging stuff in RHX for now [12:40] give them some room to work things out [12:40] <_blah_> riek seems responsive to getting usable RHEL5 Server / Client divides. [12:40] quaid: possibly yeah [12:41] quaid: i still want zimbra packaged in a sane fashion [12:41] * stahnma thinks if we can fix Client/Server that would be a great start. RHX can wait a little while...at least official RHX in EPEL [12:41] and a syncml plugin so i can sync my laptop/desktops/crackberry [12:42] dgilmore: let's talk with dhuff about helping him help the ISVs? [12:42] quaid: sounds good [12:42] --> JSchmitt has joined this channel (n=s4504kr at p54B12D6B.dip0.t-ipconnect.de). [12:42] * rdieter sits in the back, shares popcorn with knurd_afk [12:43] * dgilmore puts rdieter to work :) [12:43] anything else? [12:44] <_blah_> stahnma: +1 [12:44] _blah_: ? [12:45] <_blah_> stahnma: RHX can wait. fix Client/Server now. [12:45] oh, I see [12:45] :) [12:45] planning to end meeting now...unless anyone has somethign else to bring up [12:46] next week will include meeting times and revisit of deps [12:46] END in 30 [12:46] * frozty_sa wants to speak to stahnma after meeting has ended [12:46] END in 15 [12:46] frozty_sa: ok [12:47] END MEETING From mmcgrath at redhat.com Wed Jul 18 21:33:02 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 18 Jul 2007 16:33:02 -0500 Subject: EPEL Deps (spam-o-epel) Message-ID: <469E870E.4030700@redhat.com> If these look ok I'll enable the runs this weekend: http://mmcgrath.fedorapeople.org/epel5 http://mmcgrath.fedorapeople.org/epel4 -Mike From fedora at leemhuis.info Thu Jul 19 07:28:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Jul 2007 09:28:56 +0200 Subject: Log from this weeks EPEL-SIG meeting (20070718) In-Reply-To: <7874d9dd0707181054g6c7ff0a4i141e251dbf8a99e4@mail.gmail.com> References: <7874d9dd0707181054g6c7ff0a4i141e251dbf8a99e4@mail.gmail.com> Message-ID: <469F12B8.60306@leemhuis.info> On 18.07.2007 19:54, Michael Stahnke wrote: [...] > [12:17] should I enable a weekly run of the spam script? > [12:17] * mmcgrath is running one right now with --nomail to get a > list of whats borked. > [12:17] mmcgrath: I think that would be nice > [12:17] *** You set the channel topic to "EPEL Meeting - spam o magic > script - mmcgrath". > [12:18] <_blah_> weekly? how about daily? :) > [12:18] I vote once the kinks are worked out, we enable it > [12:18] mmcgrath: is it easy to change the script to point to > testing/ once we start using that directory? > [12:19] stahnma: I think the kinks are mostly worked out, > Once this thing finishes I'll send it to paste bin (or the list if it > takes too long) > [12:20] mmcgrath: id like to see a weekly run > [12:20] +1 Could a push of new packages trigger the script run? That how it seems to have worked in Extras, and that's likely the best solution afaics, as people that build new packages then will immediately get "you broke something feedback" -- that's afaics much better then up to a week later. Cu thl From jgranado at redhat.com Thu Jul 19 09:39:09 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 19 Jul 2007 11:39:09 +0200 Subject: python-imaging end of life in cvs Message-ID: <469F313D.4000200@redhat.com> Hi All: As python-imaging is no longer needed in EPEL/el given the addition in the RHEL5-Server repo, the issue must be closed. Do I follow http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife or is the CVS stuff just going to be erased? Thx for the info. Regards -- Joel Andres Granados From jamatos at fc.up.pt Thu Jul 19 09:51:18 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 19 Jul 2007 10:51:18 +0100 Subject: python-imaging end of life in cvs In-Reply-To: <469F313D.4000200@redhat.com> References: <469F313D.4000200@redhat.com> Message-ID: <200707191051.19054.jamatos@fc.up.pt> On Thursday 19 July 2007 10:39:09 Joel Andres Granados wrote: > Hi All: Hi Joel, > As python-imaging is no longer needed in EPEL/el given the addition in > the RHEL5-Server repo, the issue must be closed. > Do I follow > http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife or is > the CVS stuff just going to be erased? I would expect the later as python-imaging is maintained in all the other branches of Fedora so it it is not going to die soon. :-) > Thx for the info. > Regards -- Jos? Ab?lio From jgranado at redhat.com Thu Jul 19 10:03:32 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 19 Jul 2007 12:03:32 +0200 Subject: python-imaging end of life in cvs In-Reply-To: <200707191051.19054.jamatos@fc.up.pt> References: <469F313D.4000200@redhat.com> <200707191051.19054.jamatos@fc.up.pt> Message-ID: <469F36F4.9060907@redhat.com> Jos? Matos wrote: > On Thursday 19 July 2007 10:39:09 Joel Andres Granados wrote: > >> Hi All: >> > > Hi Joel, > > >> As python-imaging is no longer needed in EPEL/el given the addition in >> the RHEL5-Server repo, the issue must be closed. >> Do I follow >> http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife or is >> the CVS stuff just going to be erased? >> > > I would expect the later as python-imaging is maintained in all the other > branches of Fedora so it it is not going to die soon. :-) > mmm, maybe I didn't make myself clear. :(. I'm asking about the EPEL cvs branch for python-imaging. I know the others are there to stay:) thx. > >> Thx for the info. >> Regards >> > > -- Joel Andres Granados From fedora at leemhuis.info Thu Jul 19 10:15:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Jul 2007 12:15:53 +0200 Subject: python-imaging end of life in cvs In-Reply-To: <469F36F4.9060907@redhat.com> References: <469F313D.4000200@redhat.com> <200707191051.19054.jamatos@fc.up.pt> <469F36F4.9060907@redhat.com> Message-ID: <469F39D9.9050208@leemhuis.info> On 19.07.2007 12:03, Joel Andres Granados wrote: > Jos? Matos wrote: >> On Thursday 19 July 2007 10:39:09 Joel Andres Granados wrote: >>> As python-imaging is no longer needed in EPEL/el given the addition in >>> the RHEL5-Server repo, the issue must be closed. >>> Do I follow >>> http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife or is >>> the CVS stuff just going to be erased? >> I would expect the later as python-imaging is maintained in all the other >> branches of Fedora so it it is not going to die soon. :-) > mmm, maybe I didn't make myself clear. :(. I'm asking about the EPEL cvs > branch for python-imaging. > I know the others are there to stay:) We these days afaik try to avoid to delete any branches that were created. For this case it might make sense, but its a whole lot easier and likely more that good enough to just delete all files from the EL5/ directory and put a dead.branch file into it which explains the situation in a few words. CU thl From jgranado at redhat.com Thu Jul 19 10:43:10 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 19 Jul 2007 12:43:10 +0200 Subject: python-imaging end of life in cvs In-Reply-To: <469F39D9.9050208@leemhuis.info> References: <469F313D.4000200@redhat.com> <200707191051.19054.jamatos@fc.up.pt> <469F36F4.9060907@redhat.com> <469F39D9.9050208@leemhuis.info> Message-ID: <469F403E.9070405@redhat.com> Thorsten Leemhuis wrote: > On 19.07.2007 12:03, Joel Andres Granados wrote: > >> Jos? Matos wrote: >> >>> On Thursday 19 July 2007 10:39:09 Joel Andres Granados wrote: >>> >>>> As python-imaging is no longer needed in EPEL/el given the addition in >>>> the RHEL5-Server repo, the issue must be closed. >>>> Do I follow >>>> http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife or is >>>> the CVS stuff just going to be erased? >>>> >>> I would expect the later as python-imaging is maintained in all the other >>> branches of Fedora so it it is not going to die soon. :-) >>> >> mmm, maybe I didn't make myself clear. :(. I'm asking about the EPEL cvs >> branch for python-imaging. >> I know the others are there to stay:) >> > > We these days afaik try to avoid to delete any branches that were created. > > For this case it might make sense, but its a whole lot easier and likely > more that good enough to just delete all files from the EL5/ directory > and put a dead.branch file into it which explains the situation in a few > words. > > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > understood -- Joel Andres Granados From jgranado at redhat.com Thu Jul 19 11:46:26 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 19 Jul 2007 13:46:26 +0200 Subject: python-imaging end of life in cvs In-Reply-To: <469F403E.9070405@redhat.com> References: <469F313D.4000200@redhat.com> <200707191051.19054.jamatos@fc.up.pt> <469F36F4.9060907@redhat.com> <469F39D9.9050208@leemhuis.info> <469F403E.9070405@redhat.com> Message-ID: <469F4F12.8030409@redhat.com> Joel Andres Granados wrote: > Thorsten Leemhuis wrote: >> On 19.07.2007 12:03, Joel Andres Granados wrote: >> >>> Jos? Matos wrote: >>> >>>> On Thursday 19 July 2007 10:39:09 Joel Andres Granados wrote: >>>> >>>>> As python-imaging is no longer needed in EPEL/el given the >>>>> addition in >>>>> the RHEL5-Server repo, the issue must be closed. >>>>> Do I follow >>>>> http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife >>>>> or is >>>>> the CVS stuff just going to be erased? >>>>> >>>> I would expect the later as python-imaging is maintained in all >>>> the other branches of Fedora so it it is not going to die soon. :-) >>>> >>> mmm, maybe I didn't make myself clear. :(. I'm asking about the EPEL >>> cvs branch for python-imaging. >>> I know the others are there to stay:) >>> >> >> We these days afaik try to avoid to delete any branches that were >> created. >> >> For this case it might make sense, but its a whole lot easier and likely >> more that good enough to just delete all files from the EL5/ directory >> and put a dead.branch file into it which explains the situation in a few >> words. >> >> CU >> thl >> >> _______________________________________________ >> epel-devel-list mailing list >> epel-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/epel-devel-list >> > understood > > Done:). For the EPEL/el5 branch. I checked the channels for RHEL4 and AFAIK python-imaging is not there. This would mean that it should be in EPEL. So the right thing to do according to what was discussed, is to build with package based on fc3 (python 1.1.4) and use 1.1.4-1 as a release number. And prepare a "We are sorry for the hassle" message for the people that had already used python-imaging.1.1.6 from EPEL/el4 repos. or have things changed since? Comments? -- Joel Andres Granados From fedora at leemhuis.info Thu Jul 19 12:05:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 19 Jul 2007 14:05:09 +0200 Subject: python-imaging end of life in cvs In-Reply-To: <469F4F12.8030409@redhat.com> References: <469F313D.4000200@redhat.com> <200707191051.19054.jamatos@fc.up.pt> <469F36F4.9060907@redhat.com> <469F39D9.9050208@leemhuis.info> <469F403E.9070405@redhat.com> <469F4F12.8030409@redhat.com> Message-ID: <469F5375.3070700@leemhuis.info> On 19.07.2007 13:46, Joel Andres Granados wrote: > Joel Andres Granados wrote: >> Thorsten Leemhuis wrote: >>> On 19.07.2007 12:03, Joel Andres Granados wrote: >>>> Jos? Matos wrote: >>>>> On Thursday 19 July 2007 10:39:09 Joel Andres Granados wrote: >>>>>> As python-imaging is no longer needed in EPEL/el given the >>>>>> addition in >>>>>> the RHEL5-Server repo, the issue must be closed. >>>>>> Do I follow >>>>>> http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife >>>>>> or is >>>>>> the CVS stuff just going to be erased? >>>>> I would expect the later as python-imaging is maintained in all >>>>> the other branches of Fedora so it it is not going to die soon. :-) >>>> mmm, maybe I didn't make myself clear. :(. I'm asking about the EPEL >>>> cvs branch for python-imaging. >>>> I know the others are there to stay:) >>> We these days afaik try to avoid to delete any branches that were >>> created. >>> For this case it might make sense, but its a whole lot easier and likely >>> more that good enough to just delete all files from the EL5/ directory >>> and put a dead.branch file into it which explains the situation in a few >>> words. >> understood > Done:). For the EPEL/el5 branch. I checked the channels for RHEL4 and AFAIK > python-imaging is not there. thx > This would mean that it should be in EPEL. So the right thing to do > according to what was discussed, is to > build with package based on fc3 (python 1.1.4) and use 1.1.4-1 as a > release number. Sounds like a plan. You should just make sure the release stays lower that what's in EPEL5 or EL5, to not break update paths. > And prepare a "We are sorry for the hassle" message for the people that > had already used python-imaging.1.1.6 > from EPEL/el4 repos. Not sure, but we have not yet a place to sent it to besides this list(?), so maybe we don't need to send one, as all that are on this list are likely aware of the problem in between. CU thl (?) we likely need a epel-announce list or a special channel on fedora-package-announce soon; which of the two would people prefer? From buildsys at fedoraproject.org Thu Jul 19 14:53:19 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 19 Jul 2007 10:53:19 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-19 Message-ID: <20070719145319.D2E37152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 1 eclipse-cdt-3.1.2-6.el5 Changes in Fedora EPEL 5: eclipse-cdt-3.1.2-6.el5 ----------------------- * Tue Jul 17 2007 Jeff Johnston 3.1.2-6 - Rebase autotools to 0.1.0 - Change automake editor to embed if/else constructs in outline view For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From limb at jcomserv.net Thu Jul 19 14:45:37 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 19 Jul 2007 09:45:37 -0500 (CDT) Subject: EPEL Deps (spam-o-epel) In-Reply-To: <469E870E.4030700@redhat.com> References: <469E870E.4030700@redhat.com> Message-ID: <43481.65.192.24.164.1184856337.squirrel@mail.jcomserv.net> I maintain limph, and I could have sworn RHEL had php-mhash and php-mcrypt. Since these aren't EPEL packages ( and I see php-pear-crypt-chap needs them for epel5 as well), whom do I talk to about resolving this? I think they're build as part of the mail php SRPM, no? > If these look ok I'll enable the runs this weekend: > > http://mmcgrath.fedorapeople.org/epel5 > http://mmcgrath.fedorapeople.org/epel4 > > -Mike > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- novus ordo absurdum From limb at jcomserv.net Thu Jul 19 14:45:52 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 19 Jul 2007 09:45:52 -0500 (CDT) Subject: EPEL Deps (spam-o-epel) In-Reply-To: <469E870E.4030700@redhat.com> References: <469E870E.4030700@redhat.com> Message-ID: <43755.65.192.24.164.1184856352.squirrel@mail.jcomserv.net> s/mail/main/ > If these look ok I'll enable the runs this weekend: > > http://mmcgrath.fedorapeople.org/epel5 > http://mmcgrath.fedorapeople.org/epel4 > > -Mike > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- novus ordo absurdum From sheltren at cs.ucsb.edu Thu Jul 19 15:58:35 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 19 Jul 2007 11:58:35 -0400 Subject: EPEL Deps (spam-o-epel) In-Reply-To: <43481.65.192.24.164.1184856337.squirrel@mail.jcomserv.net> References: <469E870E.4030700@redhat.com> <43481.65.192.24.164.1184856337.squirrel@mail.jcomserv.net> Message-ID: <7B0BC69E-826B-4A07-B3AB-6555E6EB3FBA@cs.ucsb.edu> On Jul 19, 2007, at 10:45 AM, Jon Ciesla wrote: > I maintain limph, and I could have sworn RHEL had php-mhash and > php-mcrypt. Since these aren't EPEL packages ( and I see > php-pear-crypt-chap needs them for epel5 as well), whom do I talk > to about > resolving this? I think they're build as part of the mail php > SRPM, no? > I believe that in Fedora, these are part of the php-extras RPM. I think another issue is that those packages rely on mhash and mcrypt which AFAIK are not present in RHEL and have not yet been built for EPEL. -Jeff From limb at jcomserv.net Thu Jul 19 15:49:21 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 19 Jul 2007 10:49:21 -0500 (CDT) Subject: EPEL Deps (spam-o-epel) In-Reply-To: <7B0BC69E-826B-4A07-B3AB-6555E6EB3FBA@cs.ucsb.edu> References: <469E870E.4030700@redhat.com> <43481.65.192.24.164.1184856337.squirrel@mail.jcomserv.net> <7B0BC69E-826B-4A07-B3AB-6555E6EB3FBA@cs.ucsb.edu> Message-ID: <33770.65.192.24.164.1184860161.squirrel@mail.jcomserv.net> > On Jul 19, 2007, at 10:45 AM, Jon Ciesla wrote: > >> I maintain limph, and I could have sworn RHEL had php-mhash and >> php-mcrypt. Since these aren't EPEL packages ( and I see >> php-pear-crypt-chap needs them for epel5 as well), whom do I talk >> to about >> resolving this? I think they're build as part of the mail php >> SRPM, no? >> > > I believe that in Fedora, these are part of the php-extras RPM. I > think another issue is that those packages rely on mhash and mcrypt > which AFAIK are not present in RHEL and have not yet been built for > EPEL. Given that, what do I do? Have the EPEL4/5 builds of limph pulled, and note the cvs branches? And do more thorough deps checking for my next attempted EPEL build? :) > -Jeff > -- novus ordo absurdum From sheltren at cs.ucsb.edu Thu Jul 19 16:54:51 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 19 Jul 2007 12:54:51 -0400 Subject: EPEL Deps (spam-o-epel) In-Reply-To: <33770.65.192.24.164.1184860161.squirrel@mail.jcomserv.net> References: <469E870E.4030700@redhat.com> <43481.65.192.24.164.1184856337.squirrel@mail.jcomserv.net> <7B0BC69E-826B-4A07-B3AB-6555E6EB3FBA@cs.ucsb.edu> <33770.65.192.24.164.1184860161.squirrel@mail.jcomserv.net> Message-ID: On Jul 19, 2007, at 11:49 AM, Jon Ciesla wrote: > > Given that, what do I do? Have the EPEL4/5 builds of limph pulled, > and > note the cvs branches? That's one option. Or you can become a co-maintainer for the needed packages in EPEL. See the wiki for more info on that if you're interested. > And do more thorough deps checking for my next > attempted EPEL build? :) > Yes, and I believe we need to really emphasize this for people wanting to build packages for EPEL. At this point in time, it is not safe to assume that a package is in EPEL simply because it exists in Fedora/Extras. -Jeff From bojan at rexursive.com Fri Jul 20 04:40:21 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 20 Jul 2007 14:40:21 +1000 Subject: rt3 requirements Message-ID: <1184906421.17393.26.camel@shrek.rexursive.com> Just a heads-up for anyone wanting to bring rt3 into EPEL 5, attached are the Perl packages I had to pinch from Fedora development in order to build/install RT. No intervention on any of them was needed - they build and install just fine on EL5. -- Bojan -------------- next part -------------- perl-Apache-Session-1.83-1.fc8.src.rpm perl-B-Keywords-1.06-1.fc7.src.rpm perl-Cache-Cache-1.05-1.fc6.src.rpm perl-Cache-Simple-TimedExpiry-0.27-1.fc7.src.rpm perl-Calendar-Simple-1.17-1.fc6.src.rpm perl-capitalization-0.03-4.fc6.src.rpm perl-Class-Accessor-0.30-1.fc7.src.rpm perl-Class-Container-0.12-5.fc7.src.rpm perl-Class-Data-Inheritable-0.06-1.fc7.src.rpm perl-Class-Inspector-1.16-3.fc7.src.rpm perl-Class-MethodMaker-2.08-4.fc6.src.rpm perl-Class-ReturnValue-0.53-6.fc7.src.rpm perl-Class-Singleton-1.03-4.fc7.src.rpm perl-Clone-0.22-1.fc7.src.rpm perl-Config-Tiny-2.10-1.fc6.src.rpm perl-Data-OptList-0.101-2.fc6.src.rpm perl-DateTime-0.38-2.fc8.src.rpm perl-DBIx-DBSchema-0.33-1.fc8.src.rpm perl-DBIx-SearchBuilder-1.48-1.fc7.src.rpm perl-Devel-Cycle-1.07-1.fc6.src.rpm perl-Devel-StackTrace-1.15-1.fc7.src.rpm perl-Devel-Symdump-2.07-1.fc7.src.rpm perl-Exception-Class-1.23-3.fc7.src.rpm perl-ExtUtils-AutoInstall-0.63-5.fc6.src.rpm perl-File-Find-Rule-0.30-2.fc6.src.rpm perl-File-HomeDir-0.65-1.fc8.src.rpm perl-File-Remove-0.37-1.fc8.src.rpm perl-File-Which-0.05-2.fc7.src.rpm perl-Font-AFM-1.19-4.fc6.src.rpm perl-FreezeThaw-0.43-5.fc6.src.rpm perl-GnuPG-Interface-0.33-8.fc6.src.rpm perl-Hook-LexWrap-0.20-4.fc6.src.rpm perl-HTML-Format-2.04-5.fc6.src.rpm perl-HTML-Mason-1.36-1.fc8.src.rpm perl-HTML-Scrubber-0.08-4.fc6.src.rpm perl-HTML-Tree-3.23-1.fc7.src.rpm perl-HTTP-Server-Simple-0.27-1.fc7.src.rpm perl-HTTP-Server-Simple-Mason-0.09-5.fc6.src.rpm perl-IO-Tty-1.07-2.fc6.src.rpm perl-IPC-Run-0.80-3.fc7.src.rpm perl-IPC-ShareLite-0.09-9.fc7.src.rpm perl-List-MoreUtils-0.22-2.fc6.src.rpm perl-Locale-Maketext-Fuzzy-0.02-4.fc6.src.rpm perl-Locale-Maketext-Lexicon-0.64-1.fc8.src.rpm perl-Log-Dispatch-2.18-1.fc8.src.rpm perl-Mail-GnuPG-0.08-5.fc6.src.rpm perl-Mail-Sender-0.8.13-2.fc6.src.rpm perl-Mail-Sendmail-0.79-9.fc6.src.rpm perl-Module-Pluggable-3.60-1.fc7.src.rpm perl-Module-Versions-Report-1.03-1.fc8.src.rpm perl-Number-Compare-0.01-7.fc7.src.rpm perl-Package-Generator-0.100-2.fc6.src.rpm perl-PadWalker-1.5-1.fc7.src.rpm perl-Params-Util-0.25-1.fc8.src.rpm perl-Params-Validate-0.88-1.fc7.src.rpm perl-Perl-Critic-1.053-1.fc8.src.rpm perl-Pod-Coverage-0.18-2.fc6.src.rpm perl-Pod-Spell-1.01-2.fc7.src.rpm perl-PPI-1.118-1.fc6.src.rpm perl-Regexp-Common-2.120-5.fc6.src.rpm perl-Sort-Versions-1.5-5.fc6.src.rpm perl-String-Format-1.14-1.fc6.src.rpm perl-Sub-Exporter-0.974-1.fc8.src.rpm perl-Sub-Install-0.924-1.fc7.src.rpm perl-Sub-Uplevel-0.14-1.fc7.src.rpm perl-Taint-Runtime-0.02-2.fc6.src.rpm perl-TermReadKey-2.30-1.2.2.1.src.rpm perl-Test-ClassAPI-1.04-1.fc7.src.rpm perl-Test-Deep-0.096-2.fc7.src.rpm perl-Test-Exception-0.21-3.fc6.src.rpm perl-Test-Memory-Cycle-1.04-1.fc6.src.rpm perl-Test-NoWarnings-0.083-2.fc7.src.rpm perl-Test-Object-0.07-1.fc6.src.rpm perl-Test-Output-0.10-2.fc8.src.rpm perl-Test-Perl-Critic-1.01-1.fc7.src.rpm perl-Test-Pod-Coverage-1.08-3.fc6.src.rpm perl-Test-Spelling-0.11-1.fc7.src.rpm perl-Test-SubCalls-1.06-1.fc6.src.rpm perl-Test-Taint-1.04-3.fc6.src.rpm perl-Test-Tester-0.104-2.fc7.src.rpm perl-Text-Glob-0.08-1.fc7.src.rpm perl-Text-Wrapper-1.01-1.fc7.src.rpm perltidy-20070508-1.fc7.src.rpm perl-Time-modules-2003.1126-4.fc6.src.rpm perl-Tree-Simple-1.17-1.fc7.src.rpm perl-UNIVERSAL-require-0.11-1.fc7.src.rpm perl-Want-0.14-1.fc7.src.rpm From kyle.gonzales at gmail.com Fri Jul 20 10:42:50 2007 From: kyle.gonzales at gmail.com (Kyle Gonzales) Date: Fri, 20 Jul 2007 06:42:50 -0400 Subject: Maintaining vpnc and NetworkManager-vpnc for EPEL Message-ID: <1184928170.24211.4.camel@x2.ultrasound.home> Hello! I contacted the current Fedora maintainers of vpnc and NetworkManager-vpnc. For vpnc, the author was glad to have me assist. For NetworkManager-vpnc, there was no response from the author for several days now. How do I get started in getting these packages into EPEL? I can do builds for both RHEL4 and RHEL5. -- Kyle Gonzales Tech blog at http://techiebloggiethingie.blogspot.com/ From fedora at leemhuis.info Sun Jul 22 12:37:13 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Jul 2007 14:37:13 +0200 Subject: EPEL report week 29 2007 Message-ID: <46A34F79.2030000@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week29 = Weekly EPEL Summary = Week 29/2007 == Most important happenings == * RH will plans to add stuff that is part of the EL5Client (like python-imaging) to the Channels for EL5Server; that should solve most of our problem on that topic == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * Jeff_S (Jeff Sheltren) (had to leave after half the meeting) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) (had to leave early) * quiad (KarstenWade) * stahnma (MichaelStahnke) Missing from the Steering Committee: * knurd (ThorstenLeemhuis) Others that participated the meeting: === Summary === * broken Deps - Jeff_S * still lots of broken deps * nirik> I've found that if you mail maintainers direct with a solution, most of them will do something... I can try and do that some in the next few days. * more on the list * branch for EPEL if Fedora Maintainer does not react * https://www.redhat.com/archives/epel-devel-list/2007-July/msg00104.html not yet ratified as tehre were not enough people to vote * early end of meeting due to the latter fact === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00164.html == Stats == === General === Number of EPEL Contributors 112 We welcome 2 new contributors: kwizart_AT_gmail.com, mattdm_AT_mattdm.org === EPEL 5 === Number of source packages: 469 Number of binary packages: 853 There are 7 new Packages: * cacti | An rrd based graphing tool * ctapi-common | Common files and packaging infrastructure for CT-API modules * ftgl | OpenGL frontend to Freetype 2 * goffice | Goffice support libraries * iksemel | An XML parser library designed for Jabber applications * logserial | Package for logging incoming bytes on asynchronous serial ports * rdiff-backup | Convenient and transparent local/remote incremental mirror/backup * tachyon | Parallel / Multiprocessor Ray Tracing System === EPEL 4 === Number of source packages: 289 Number of binary packages: 596 There are 5 new Packages: * ctapi-common | Common files and packaging infrastructure for CT-API modules * iksemel | An XML parser library designed for Jabber applications * logserial | Package for logging incoming bytes on asynchronous serial ports * rdiff-backup | Convenient and transparent local/remote incremental mirror/backup * tachyon | Parallel / Multiprocessor Ray Tracing System ---- ["CategoryEPELReports"] From sundaram at fedoraproject.org Sun Jul 22 13:04:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 22 Jul 2007 18:34:07 +0530 Subject: EPEL report week 29 2007 In-Reply-To: <46A34F79.2030000@leemhuis.info> References: <46A34F79.2030000@leemhuis.info> Message-ID: <46A355C7.1030308@fedoraproject.org> Thorsten Leemhuis wrote: > > === EPEL 5 === > > Number of source packages: 469 > > Number of binary packages: 853 > The count here is different from the number of indexed packages at http://download.fedora.redhat.com/pub/epel/5/i386/repoview/index.html. Why is that? Also shouldn't this report also include a section on EPEL 4? Rahul From fedora at leemhuis.info Sun Jul 22 13:48:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Jul 2007 15:48:18 +0200 Subject: EPEL report week 29 2007 In-Reply-To: <46A355C7.1030308@fedoraproject.org> References: <46A34F79.2030000@leemhuis.info> <46A355C7.1030308@fedoraproject.org> Message-ID: <46A36022.4090809@leemhuis.info> On 22.07.2007 15:04, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> === EPEL 5 === >> >> Number of source packages: 469 >> Number of binary packages: 853 > The count here is different from the number of indexed packages at > http://download.fedora.redhat.com/pub/epel/5/i386/repoview/index.html. > Why is that? Afaics this is the reason: repoview (icon, please correct me if I'm wrong) counts all packages in the repo which sometimes includes old versions -- E.g. the wine package for example is counted twice, because 0.9.39-1.el5 and 0.9.41-1.el5 are in the repo. See http://download.fedora.redhat.com/pub/epel/5/x86_64/repoview/wine.html My script uses repoquery and counts only the latest version of a package (e.g. I don't use "--show-dupes"). Both approaches IMHO make sense for their purpose. Sure, I could use "--show-dupes" as well, but the number would be a bit misleading IMHO. > Also shouldn't this report also include a section on EPEL 4? Hmmm, it's part of it afaics. Cu thl From ville.skytta at iki.fi Sun Jul 22 16:37:25 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 22 Jul 2007 19:37:25 +0300 Subject: Broken dependencies: git In-Reply-To: <200707221610.l6MGAwE0004776@app5.fedora.phx.redhat.com> References: <200707221610.l6MGAwE0004776@app5.fedora.phx.redhat.com> Message-ID: <200707221937.26183.ville.skytta@iki.fi> On Sunday 22 July 2007, you wrote: > git has broken dependencies in the EPEL: > On ppc: > git-cvs - 1.5.2.1-2.el4.ppc requires cvsps > On x86_64: > git-cvs - 1.5.2.1-2.el4.x86_64 requires cvsps > On i386: > git-cvs - 1.5.2.1-2.el4.i386 requires cvsps Anyone interested in looking after cvsps in EL-4? In any case, I'd rather not continue to receive these mails for it, see http://www.redhat.com/archives/epel-devel-list/2007-July/msg00039.html OT: could someone fix the spelling error in the description of this list in mailman (s/disccusion/discussion/) :) From buildsys at fedoraproject.org Mon Jul 23 07:53:26 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 23 Jul 2007 03:53:26 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-23 Message-ID: <20070723075326.B2301152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 21 ctapi-cyberjack-3.0.2-1.el5 dar-2.3.4-2.el5 NEW GeoIP-1.4.2-1.el5 : C library for country/city/organization to IP address or hostname mapping gnucash-docs-2.2.0-1.el5 NEW libmcrypt-2.5.7-5.el5 : Encryption algorithms library NEW librx-1.5-8.el5 : POSIX regexp functions NEW logjam-4.5.3-8.el5.1 : GTK2 client for LiveJournal NEW lout-3.30-6.el5 : A document formatting system NEW perl-File-MMagic-1.27-2.el5 : A Perl module emulating the file(1) command NEW perl-File-MMagic-XS-0.09002-1.el5 : Guess file type with XS NEW perl-Geography-Countries-1.4-1.el5 : 2-letter, 3-letter, and numerical codes for countries NEW perl-Mail-IMAPClient-2.2.9-3.el5 : An IMAP Client API NEW perl-Net-Domain-TLD-1.65-1.el5 : Work with TLD names NEW perl-Object-Realize-Later-0.16-1.el5 : Delayed creation of objects NEW perl-Parse-RecDescent-1.94-6.el5 : Parse-RecDescent Perl module NEW perl-Pod-POM-0.17-6.el5 : Object-oriented interface to Perl POD documents perl-SOAP-Lite-0.68-6.el5 NEW perl-Taint-Runtime-0.03-1.el5 : Runtime enable taint checking NEW perl-User-Identity-0.91-1.el5 : Maintains info about a physical person NEW QuantLib-0.8.1-1.el5 : A software framework for quantitative finance trac-0.10.4-1.el5 Packages built and released for Fedora EPEL 4: 20 ctapi-cyberjack-3.0.2-1.el4 NEW GeoIP-1.4.2-1.el4 : C library for country/city/organization to IP address or hostname mapping NEW graphviz-2.6-3.el4 : Graph Visualization Tools NEW libmcrypt-2.5.7-5.el4 : Encryption algorithms library NEW librx-1.5-8.el4 : POSIX regexp functions NEW logjam-4.5.3-8.el4.1 : GTK2 client for LiveJournal NEW lout-3.30-4.el4 : A document formatting system NEW perl-Date-Pcalc-1.2-4.el4 : Gregorian calendar date calculations NEW perl-File-MMagic-1.27-2.el4 : A Perl module emulating the file(1) command NEW perl-File-MMagic-XS-0.09002-1.el4 : Guess file type with XS NEW perl-Geography-Countries-1.4-1.el4 : 2-letter, 3-letter, and numerical codes for countries NEW perl-Mail-IMAPClient-2.2.9-3.el4 : An IMAP Client API NEW perl-MIME-tools-5.420-3.el4 : Modules for parsing and creating MIME entities in Perl NEW perl-Net-Domain-TLD-1.65-1.el4 : Work with TLD names NEW perl-Object-Realize-Later-0.16-1.el4 : Delayed creation of objects NEW perl-Parse-RecDescent-1.94-6.el4 : Parse-RecDescent Perl module NEW perl-Pod-POM-0.17-6.el4 : Object-oriented interface to Perl POD documents NEW perl-Taint-Runtime-0.03-1.el4 : Runtime enable taint checking NEW perl-TimeDate-1.16-6.el4 : A Perl module for time and date manipulation NEW perl-User-Identity-0.91-1.el4 : Maintains info about a physical person Changes in Fedora EPEL 5: ctapi-cyberjack-3.0.2-1.el5 --------------------------- * Sat Jul 21 2007 Frank B?ttner - 3.0.2-1 - update to 3.0.2 * Sat Jun 23 2007 Frank B?ttner - 3.0.0-3.el5 - disable PC/SC part for EL4 dar-2.3.4-2.el5 --------------- * Sun Jul 22 2007 Chris Petersen 2.3.4-2 - Coment par2cmdline requirement. It's not really necessary, and not in Epel GeoIP-1.4.2-1.el5 ----------------- * Sun Apr 01 2007 Michael Fleming 1.4.2-1 - New upstream release. - Sync with devel - Fix dumb typo in fetch-geoipdata-city.pl gnucash-docs-2.2.0-1.el5 ------------------------ * Mon Jul 16 2007 Bill Nottingham - 2.2.0-1 - update to 2.2.0 libmcrypt-2.5.7-5.el5 --------------------- * Sun Oct 08 2006 Ed Hill 2.5.7-5 - bz 209913 : libmcrypt.m4 in -devel and properly quote it librx-1.5-8.el5 --------------- * Mon Sep 11 2006 Tom "spot" Callaway 1.5-8 - fix bz 200090 logjam-4.5.3-8.el5.1 -------------------- * Fri Jul 20 2007 Tom "spot" Callaway 1:4.5.3-8.1 - disable xmms for EL-5 lout-3.30-6.el5 --------------- * Tue Sep 12 2006 Tom "spot" Callaway 3.30-6 - bump for FC-6 perl-File-MMagic-1.27-2.el5 --------------------------- * Fri Jul 20 2007 Robin Norwood - 1.27-2.el5 - Build for EL5 - Fix minor specfile issues perl-File-MMagic-XS-0.09002-1.el5 --------------------------------- * Thu Jul 19 2007 Tom "spot" Callaway 0.09002-1 - hate hate hate perl versioning perl-Geography-Countries-1.4-1.el5 ---------------------------------- * Mon Apr 02 2007 Tom "spot" Callaway - 1.4-1 - Initial package for Fedora perl-Mail-IMAPClient-2.2.9-3.el5 -------------------------------- * Mon Apr 09 2007 Tom "spot" Callaway - 2.2.9-3 - set examples as non-exec, fix intepreter perl-Net-Domain-TLD-1.65-1.el5 ------------------------------ * Wed Jan 17 2007 Tom "spot" Callaway 1.65-1 - initial package for Fedora Extras perl-Object-Realize-Later-0.16-1.el5 ------------------------------------ * Mon Apr 02 2007 Tom "spot" Callaway - 0.16-1 - Initial package for Fedora perl-Parse-RecDescent-1.94-6.el5 -------------------------------- * Fri Jul 20 2007 Robin Norwood - 1.94-6.el5 - build for EL5. - Fix minor specfile issues - Package the docs as well perl-Pod-POM-0.17-6.el5 ----------------------- * Fri Sep 15 2006 Tom "spot" Callaway 0.17-6 - build for fc6 perl-SOAP-Lite-0.68-6.el5 ------------------------- * Sun Jul 22 2007 Mike McGrath - 0.86-6 - Release bump perl-Taint-Runtime-0.03-1.el5 ----------------------------- * Thu Jul 19 2007 Tom "spot" Callaway 0.03-1 - bump to 0.03 perl-User-Identity-0.91-1.el5 ----------------------------- * Mon Apr 02 2007 Tom "spot" Callaway - 0.91-1 - Initial package for Fedora QuantLib-0.8.1-1.el5 -------------------- * Tue Jul 10 2007 Tom "spot" Callaway 0.8.1-1 - bump to 0.8.1 trac-0.10.4-1.el5 ----------------- * Thu May 03 2007 Jeffrey C. Ollie - 0.10.4-1 - Update to 0.10.4 Changes in Fedora EPEL 4: ctapi-cyberjack-3.0.2-1.el4 --------------------------- * Sat Jul 21 2007 Frank B?ttner - 3.0.2-1 - update to 3.0.2 GeoIP-1.4.2-1.el4 ----------------- * Mon Feb 12 2007 Michael Fleming 1.4.2-1 - New upstream release. graphviz-2.6-3.el4 ------------------ * Thu Jul 19 2007 Patrick "Jima" Laughton 2.6-3 - Uncommenting %excludes to exclude erroneously installed ltdl libs * Thu Jul 19 2007 Patrick "Jima" Laughton 2.6-2 - Hoping BR on libtool-ltdl-devel is non-fatal (not found in EL-4) libmcrypt-2.5.7-5.el4 --------------------- * Sun Oct 08 2006 Ed Hill 2.5.7-5 - bz 209913 : libmcrypt.m4 in -devel and properly quote it librx-1.5-8.el4 --------------- * Mon Sep 11 2006 Tom "spot" Callaway 1.5-8 - fix bz 200090 logjam-4.5.3-8.el4.1 -------------------- * Fri Jul 20 2007 Tom "spot" Callaway 1:4.5.3-8.1 - disable sqlite for EL-4 lout-3.30-4.el4 --------------- * Fri Jul 01 2005 Tom "spot" Callaway 3.30-4 - delete hidden trash file perl-Date-Pcalc-1.2-4.el4 ------------------------- * Thu Sep 07 2006 Mike McGrath - 1.2-4 - Release bump perl-File-MMagic-1.27-2.el4 --------------------------- * Fri Jul 20 2007 Robin Norwood - 1.27-2.el4 - Build for EL4 - Fix minor specfile issues perl-File-MMagic-XS-0.09002-1.el4 --------------------------------- * Thu Jul 19 2007 Tom "spot" Callaway 0.09002-1 - hate hate hate perl versioning perl-Geography-Countries-1.4-1.el4 ---------------------------------- * Mon Apr 02 2007 Tom "spot" Callaway - 1.4-1 - Initial package for Fedora perl-Mail-IMAPClient-2.2.9-3.el4 -------------------------------- * Mon Apr 09 2007 Tom "spot" Callaway - 2.2.9-3 - set examples as non-exec, fix intepreter perl-MIME-tools-5.420-3.el4 --------------------------- * Tue Apr 17 2007 Paul Howarth 5.420-3 - Buildrequire perl(ExtUtils::MakeMaker) - Fix argument order for find with -depth perl-Net-Domain-TLD-1.65-1.el4 ------------------------------ * Wed Jan 17 2007 Tom "spot" Callaway 1.65-1 - initial package for Fedora Extras perl-Object-Realize-Later-0.16-1.el4 ------------------------------------ * Mon Apr 02 2007 Tom "spot" Callaway - 0.16-1 - Initial package for Fedora perl-Parse-RecDescent-1.94-6.el4 -------------------------------- * Fri Jul 20 2007 Robin Norwood - 1.94-6.el4 - build for EL4. - Fix minor specfile issues - Package the docs as well perl-Pod-POM-0.17-6.el4 ----------------------- * Fri Sep 15 2006 Tom "spot" Callaway 0.17-6 - build for fc6 perl-Taint-Runtime-0.03-1.el4 ----------------------------- * Thu Jul 19 2007 Tom "spot" Callaway 0.03-1 - bump to 0.03 perl-TimeDate-1.16-6.el4 ------------------------ * Thu Jun 28 2007 Robin Norwood 1:1.16-6 - Bump release to outpace RHEL5 - Add dist tag to release field perl-User-Identity-0.91-1.el4 ----------------------------- * Mon Apr 02 2007 Tom "spot" Callaway - 0.91-1 - Initial package for Fedora For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From chris.stone at gmail.com Mon Jul 23 15:05:50 2007 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 23 Jul 2007 08:05:50 -0700 Subject: EPEL 5 Dependency Report - 20070713 In-Reply-To: <469A6E16.2000903@leemhuis.info> References: <1184364635.3413.193.camel@rxm-581b.stl.gtri.gatech.edu> <469A6E16.2000903@leemhuis.info> Message-ID: On 7/15/07, Thorsten Leemhuis wrote: > chris.stone_AT_gmail.com: Package php-pear-Crypt-CHAP requires > php-mcrypt which is not in EPEL; its owned by in Fedora. > > chris.stone_AT_gmail.com: Package php-pear-Crypt-CHAP requires php-mhash > which is not in EPEL; its owned by in Fedora. php-pear-Crypt-CHAP has been marked as a dead.package in the EL-5 CVS directory. I now need this RPM to be removed from the EPEL repository. It should have never been branched to EL-5 in the first place. My bad. From fedora at leemhuis.info Mon Jul 23 16:53:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 23 Jul 2007 18:53:15 +0200 Subject: Maintaining vpnc and NetworkManager-vpnc for EPEL In-Reply-To: <1184928170.24211.4.camel@x2.ultrasound.home> References: <1184928170.24211.4.camel@x2.ultrasound.home> Message-ID: <46A4DCFB.5050306@leemhuis.info> On 20.07.2007 12:42, Kyle Gonzales wrote: > > I contacted the current Fedora maintainers of vpnc and > NetworkManager-vpnc. For vpnc, the author was glad to have me assist. > For NetworkManager-vpnc, there was no response from the author for > several days now. > > How do I get started in getting these packages into EPEL? I can do > builds for both RHEL4 and RHEL5. Well, are you a Fedora contributor already? I can't locate your name on https://admin.fedora.redhat.com/accounts/dump-group.cgi?group=cvsextras&role_type=user&format=html Until all EPEL Contributors came into EPEL via Fedora and its sponsor process. CU thl From fedora at leemhuis.info Mon Jul 23 17:05:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 23 Jul 2007 19:05:40 +0200 Subject: rt3 requirements In-Reply-To: <1184906421.17393.26.camel@shrek.rexursive.com> References: <1184906421.17393.26.camel@shrek.rexursive.com> Message-ID: <46A4DFE4.30506@leemhuis.info> On 20.07.2007 06:40, Bojan Smojver wrote: > Just a heads-up for anyone wanting to bring rt3 into EPEL 5, attached > are the Perl packages I had to pinch from Fedora development in order to > build/install RT. > > No intervention on any of them was needed - they build and install just > fine on EL5. Maybe those people that interested in both EPEL and perl could work on getting more of the Fedora perl modules into EPEL? I for example know that Ralf Corsepius maintains some perl-modules, but stated to not participate in EPEL. So those people that want to see his packages in EPEL could just go ahead and start maintaining them for EPEL. That what http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-00c9e731bb7bc5bb78caf8d124da3a329400fcd8 allows. Here is a list of his perl-packages (taken from owners.list; some might be in EPEL already; didn't check): perl-Algorithm-Dependency perl-Business-Hours perl-Cache-Simple-TimedExpiry perl-Calendar-Simple perl-Class-Autouse perl-Class-Inspector perl-Class-ReturnValue perl-DBIx-DBSchema perl-DBIx-SearchBuilder perl-Devel-StackTrace perl-ExtUtils-AutoInstall perl-File-Copy-Recursive perl-File-Find-Rule perl-File-Flat perl-File-NCopy perl-File-Remove perl-File-Slurp perl-Font-AFM perl-HTML-Format perl-HTTP-Server-Simple-Mason perl-Locale-Maketext-Lexicon perl-Mail-GnuPG perl-Module-Refresh perl-Number-Compare perl-Params-Util perl-Params-Validate perl-Pod-Tests perl-Regexp-Common perl-Sort-Versions perl-Test-ClassAPI perl-Test-Inline perl-Test-LongString perl-Test-Taint perl-Text-Glob perl-Text-Quoted perl-Text-Wrapper perl-Tree-Simple perl-Want perl-capitalization perl-gettext perl-prefork CU thl From fedora at leemhuis.info Mon Jul 23 17:13:47 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 23 Jul 2007 19:13:47 +0200 Subject: rt3 requirements In-Reply-To: <1184906421.17393.26.camel@shrek.rexursive.com> References: <1184906421.17393.26.camel@shrek.rexursive.com> Message-ID: <46A4E1CB.9000904@leemhuis.info> On 20.07.2007 06:40, Bojan Smojver wrote: > Just a heads-up for anyone wanting to bring rt3 into EPEL 5, attached > are the Perl packages I had to pinch from Fedora development in order to > build/install RT. > > No intervention on any of them was needed - they build and install just > fine on EL5. Find below the owners from Fedora's owners.list for those packages; lots of them are participating in EPEL afaics; I suppose they just need to be asked friendly if someone really want to get rt3 into EPEL and they might bring those modules into EPEL. cweyl_AT_alumni.drew.edu perl-Data-OptList cweyl_AT_alumni.drew.edu perl-Package-Generator cweyl_AT_alumni.drew.edu perl-Sub-Exporter cweyl_AT_alumni.drew.edu perl-Sub-Install dgregor_AT_redhat.com perl-Class-MethodMaker jpo_AT_di.uminho.pt perl-B-Keywords jpo_AT_di.uminho.pt perl-Cache-Cache jpo_AT_di.uminho.pt perl-Config-Tiny jpo_AT_di.uminho.pt perl-Devel-Cycle jpo_AT_di.uminho.pt perl-File-HomeDir jpo_AT_di.uminho.pt perl-File-Which jpo_AT_di.uminho.pt perl-FreezeThaw jpo_AT_di.uminho.pt perl-Hook-LexWrap jpo_AT_di.uminho.pt perl-HTML-Scrubber jpo_AT_di.uminho.pt perl-HTTP-Server-Simple jpo_AT_di.uminho.pt perl-IO-Tty jpo_AT_di.uminho.pt perl-List-MoreUtils jpo_AT_di.uminho.pt perl-Locale-Maketext-Fuzzy jpo_AT_di.uminho.pt perl-Log-Dispatch jpo_AT_di.uminho.pt perl-Mail-Sender jpo_AT_di.uminho.pt perl-Mail-Sendmail jpo_AT_di.uminho.pt perl-Module-Versions-Report jpo_AT_di.uminho.pt perl-PadWalker jpo_AT_di.uminho.pt perl-Perl-Critic jpo_AT_di.uminho.pt perl-Pod-Coverage jpo_AT_di.uminho.pt perl-Pod-Spell jpo_AT_di.uminho.pt perl-PPI jpo_AT_di.uminho.pt perl-String-Format jpo_AT_di.uminho.pt perl-Sub-Uplevel jpo_AT_di.uminho.pt perl-Test-Exception jpo_AT_di.uminho.pt perl-Test-Memory-Cycle jpo_AT_di.uminho.pt perl-Test-Object jpo_AT_di.uminho.pt perl-Test-Perl-Critic jpo_AT_di.uminho.pt perl-Test-Pod-Coverage jpo_AT_di.uminho.pt perl-Test-Spelling jpo_AT_di.uminho.pt perl-Test-SubCalls kaboom_AT_oobleck.net perl-Time-modules Matt_Domsch_AT_dell.com perl-GnuPG-Interface rc040203_AT_freenet.de,lxtnow at gmail.com perl-Cache-Simple-TimedExpiry rc040203_AT_freenet.de,lxtnow at gmail.com perl-capitalization rc040203_AT_freenet.de,lxtnow at gmail.com perl-Class-Inspector rc040203_AT_freenet.de,lxtnow at gmail.com perl-Class-ReturnValue rc040203_AT_freenet.de,lxtnow at gmail.com perl-DBIx-DBSchema rc040203_AT_freenet.de,lxtnow at gmail.com perl-DBIx-SearchBuilder rc040203_AT_freenet.de,lxtnow at gmail.com perl-Devel-StackTrace rc040203_AT_freenet.de,lxtnow at gmail.com perl-ExtUtils-AutoInstall rc040203_AT_freenet.de,lxtnow at gmail.com perl-File-Find-Rule rc040203_AT_freenet.de,lxtnow at gmail.com perl-File-Remove rc040203_AT_freenet.de,lxtnow at gmail.com perl-Font-AFM rc040203_AT_freenet.de,lxtnow at gmail.com perl-HTML-Format rc040203_AT_freenet.de,lxtnow at gmail.com perl-HTTP-Server-Simple-Mason rc040203_AT_freenet.de,lxtnow at gmail.com perl-Locale-Maketext-Lexicon rc040203_AT_freenet.de,lxtnow at gmail.com perl-Mail-GnuPG rc040203_AT_freenet.de,lxtnow at gmail.com perl-Number-Compare rc040203_AT_freenet.de,lxtnow at gmail.com perl-Params-Util rc040203_AT_freenet.de,lxtnow at gmail.com perl-Params-Validate rc040203_AT_freenet.de,lxtnow at gmail.com perl-Regexp-Common rc040203_AT_freenet.de,lxtnow at gmail.com perl-Sort-Versions rc040203_AT_freenet.de,lxtnow at gmail.com perl-Test-ClassAPI rc040203_AT_freenet.de,lxtnow at gmail.com perl-Test-Taint rc040203_AT_freenet.de,lxtnow at gmail.com perl-Text-Glob rc040203_AT_freenet.de,lxtnow at gmail.com perl-Text-Wrapper rc040203_AT_freenet.de,lxtnow at gmail.com perl-Tree-Simple rc040203_AT_freenet.de,lxtnow at gmail.com perl-Want rc040203_AT_freenet.de perl-Calendar-Simple rnorwood_AT_redhat.com perl-Devel-Symdump rnorwood_AT_redhat.com perl-TermReadKey steve_AT_silug.org perl-Apache-Session steve_AT_silug.org perl-Class-Container steve_AT_silug.org perl-Class-Singleton steve_AT_silug.org perl-DateTime steve_AT_silug.org perl-Exception-Class steve_AT_silug.org perl-HTML-Mason steve_AT_silug.org perl-IPC-ShareLite steve_AT_silug.org perl-Module-Pluggable steve_AT_silug.org perl-Test-Deep steve_AT_silug.org perl-Test-NoWarnings steve_AT_silug.org perl-Test-Output steve_AT_silug.org perl-Test-Tester tcallawa_AT_redhat.com perl-Class-Accessor tcallawa_AT_redhat.com perl-Class-Data-Inheritable tcallawa_AT_redhat.com perl-Clone tcallawa_AT_redhat.com perl-HTML-Tree tcallawa_AT_redhat.com perl-Taint-Runtime tcallawa_AT_redhat.com perl-UNIVERSAL-require ville.skytta_AT_iki.fi perl-IPC-Run ville.skytta_AT_iki.fi perltidy Cu knurd From kyle.gonzales at gmail.com Mon Jul 23 18:20:09 2007 From: kyle.gonzales at gmail.com (Kyle Gonzales) Date: Mon, 23 Jul 2007 14:20:09 -0400 Subject: Maintaining vpnc and NetworkManager-vpnc for EPEL In-Reply-To: <46A4DCFB.5050306@leemhuis.info> References: <1184928170.24211.4.camel@x2.ultrasound.home> <46A4DCFB.5050306@leemhuis.info> Message-ID: <1185214809.24314.3.camel@x2.ultrasound.home> On Mon, 2007-07-23 at 18:53 +0200, Thorsten Leemhuis wrote: > > On 20.07.2007 12:42, Kyle Gonzales wrote: > > > > I contacted the current Fedora maintainers of vpnc and > > NetworkManager-vpnc. For vpnc, the author was glad to have me assist. > > For NetworkManager-vpnc, there was no response from the author for > > several days now. > > > > How do I get started in getting these packages into EPEL? I can do > > builds for both RHEL4 and RHEL5. > > Well, are you a Fedora contributor already? I can't locate your name on > https://admin.fedora.redhat.com/accounts/dump-group.cgi?group=cvsextras&role_type=user&format=html > > Until all EPEL Contributors came into EPEL via Fedora and its sponsor > process. > > CU > thl I am not currently maintaining any Fedora packages, but I have created both a Fedora user and wiki accounts, and signed the CLA. So, I guess you are staying then that my next step is to be sponsored as someone, so that I can maintain packages? If so, then I have someone who can sponsor me. -- Kyle Gonzales Tech blog at http://techiebloggiethingie.blogspot.com/ From jgranado at redhat.com Tue Jul 24 09:14:44 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 24 Jul 2007 11:14:44 +0200 Subject: There are still dependencies for python-imaging el5 Message-ID: <46A5C304.9040309@redhat.com> Hi all: Received two automated email (attached) stating that plone depends on python-imaging for el5. python-imaging for el5 terminated from EPEL due to its existence in both RHEL5 Client and Server. Additionally the mail states that the broken dependency is only valid for ppc, as I don't see the other arch listed. Does the plone spec in EPEL have to change? Does the python-imaging in RHEL5 need modifying of some sort? Does python-imaging in EPEL/el4 need modifying (some tag I don't know of)? Or is there some black voodoo magic that is done to fix this? Regards. -- Joel Andres Granados -------------- next part -------------- An embedded message was scrubbed... From: root Subject: Broken dependencies: plone Date: Sun, 22 Jul 2007 10:11:00 -0700 Size: 1859 URL: -------------- next part -------------- An embedded message was scrubbed... From: root Subject: Broken dependencies: python-docutils Date: Sun, 22 Jul 2007 10:11:01 -0700 Size: 1887 URL: From jgranado at redhat.com Tue Jul 24 09:21:54 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 24 Jul 2007 11:21:54 +0200 Subject: There are still dependencies for python-imaging el5 In-Reply-To: <46A5C304.9040309@redhat.com> References: <46A5C304.9040309@redhat.com> Message-ID: <46A5C4B2.3010004@redhat.com> Joel Andres Granados wrote: > Hi all: > > Received two automated email (attached) stating that plone depends on > python-imaging for el5. > python-imaging for el5 terminated from EPEL due to its existence in > both RHEL5 Client and Server. > Additionally the mail states that the broken dependency is only valid > for ppc, as I don't see the other > arch listed. > Does the plone spec in EPEL have to change? > Does the python-imaging in RHEL5 need modifying of some sort? > Does python-imaging in EPEL/el4 need modifying (some tag I don't know > of)? > Or is there some black voodoo magic that is done to fix this? > > Regards. Ok, the second mail talks about docutils instead of plone, but its the same situation as stated above. Any suggestions? -- Joel Andres Granados From fedora at leemhuis.info Tue Jul 24 09:29:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 24 Jul 2007 11:29:24 +0200 Subject: There are still dependencies for python-imaging el5 In-Reply-To: <46A5C304.9040309@redhat.com> References: <46A5C304.9040309@redhat.com> Message-ID: <46A5C674.6060400@leemhuis.info> On 24.07.2007 11:14, Joel Andres Granados wrote: > > Received two automated email (attached) stating that plone depends on > python-imaging for el5. > python-imaging for el5 terminated from EPEL due to its existence in both > RHEL5 Client and Server. > Additionally the mail states that the broken dependency is only valid > for ppc, as I don't see the other arch listed. Reason for that afaics: there is no PPC-EL5Client, thus the package from it could not be added to the server, thus python-imaging is still missing on PPC. > Does the plone spec in EPEL have to change? > Does the python-imaging in RHEL5 need modifying of some sort? > Does python-imaging in EPEL/el4 need modifying (some tag I don't know of)? > Or is there some black voodoo magic that is done to fix this? The proper workaround would be to excludearch ppc for plone and other packages that require python-imaging. The proper solution would be to ship python-imaging in EL5Server for PPC *or* ship it in EPEL5-PPC only. Going for the latter route might be a best short term fix. Just make EVR lower then the EL5 package, in case EL5Server starts shipping python-imaging sooner or later. Does that sound like a plan? CU kurd From jgranado at redhat.com Tue Jul 24 10:33:40 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 24 Jul 2007 12:33:40 +0200 Subject: There are still dependencies for python-imaging el5 In-Reply-To: <46A5C674.6060400@leemhuis.info> References: <46A5C304.9040309@redhat.com> <46A5C674.6060400@leemhuis.info> Message-ID: <46A5D584.9050406@redhat.com> Thorsten Leemhuis wrote: > On 24.07.2007 11:14, Joel Andres Granados wrote: > >> Received two automated email (attached) stating that plone depends on >> python-imaging for el5. >> python-imaging for el5 terminated from EPEL due to its existence in both >> RHEL5 Client and Server. >> Additionally the mail states that the broken dependency is only valid >> for ppc, as I don't see the other arch listed. >> > > Reason for that afaics: there is no PPC-EL5Client, thus the package from > it could not be added to the server, thus python-imaging is still > missing on PPC. > strange :-/ > >> Does the plone spec in EPEL have to change? >> Does the python-imaging in RHEL5 need modifying of some sort? >> Does python-imaging in EPEL/el4 need modifying (some tag I don't know of)? >> Or is there some black voodoo magic that is done to fix this? >> > > The proper workaround would be to excludearch ppc for plone and other > packages that require python-imaging. > > The proper solution would be to ship python-imaging in EL5Server for PPC > *or* ship it in EPEL5-PPC only. Going for the latter route might be a > best short term fix. Just make EVR lower then the EL5 package, in case > EL5Server starts shipping python-imaging sooner or later. > > Does that sound like a plan? > Ok, Ill speak with Dan Riek and see what we can do on the RHEL side. Additionally I will build a new python-imaging on the el5 branch with the 1.1.5 version and a release that is lower than the one in RHEL that is only for ppc arch. In this way the situation is fixed immediately and if python-imaging is added to RHELppc in the near future I will dead the package again. Regards > CU > kurd > > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- Joel Andres Granados From mmahut at fedoraproject.org Tue Jul 24 11:23:43 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Tue, 24 Jul 2007 13:23:43 +0200 Subject: rt3 requirements In-Reply-To: <1184906421.17393.26.camel@shrek.rexursive.com> References: <1184906421.17393.26.camel@shrek.rexursive.com> Message-ID: <46A5E13F.3040401@fedoraproject.org> Hello Bojan, Bojan Smojver wrote: > Just a heads-up for anyone wanting to bring rt3 into EPEL 5, attached > are the Perl packages I had to pinch from Fedora development in order to > build/install RT. I'm interested to have RequestTracker in EPEL, as we are using it in my company. Are you working on the port to EPEL? > No intervention on any of them was needed - they build and install just > fine on EL5. -- Marek Mahut http://www.fedoraproject.org/ Fedora Ambassador http://www.jamendo.com/ From jgranado at redhat.com Tue Jul 24 13:56:07 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 24 Jul 2007 15:56:07 +0200 Subject: There are still dependencies for python-imaging el5 In-Reply-To: <46A5D584.9050406@redhat.com> References: <46A5C304.9040309@redhat.com> <46A5C674.6060400@leemhuis.info> <46A5D584.9050406@redhat.com> Message-ID: <46A604F7.1050702@redhat.com> Joel Andres Granados wrote: > Thorsten Leemhuis wrote: >> On 24.07.2007 11:14, Joel Andres Granados wrote: >> >>> Received two automated email (attached) stating that plone depends >>> on python-imaging for el5. >>> python-imaging for el5 terminated from EPEL due to its existence in >>> both RHEL5 Client and Server. >>> Additionally the mail states that the broken dependency is only >>> valid for ppc, as I don't see the other arch listed. >>> >> >> Reason for that afaics: there is no PPC-EL5Client, thus the package from >> it could not be added to the server, thus python-imaging is still >> missing on PPC. >> > > strange :-/ python-imaging already in RHEL ppc. going to build for EPEL for ppc to see if it fixes deps. Probably it will not go past that first build as RHEL5.1 will include the package. Regards. -- Joel Andres Granados From fedora at leemhuis.info Tue Jul 24 14:04:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 24 Jul 2007 16:04:03 +0200 Subject: There are still dependencies for python-imaging el5 In-Reply-To: <46A604F7.1050702@redhat.com> References: <46A5C304.9040309@redhat.com> <46A5C674.6060400@leemhuis.info> <46A5D584.9050406@redhat.com> <46A604F7.1050702@redhat.com> Message-ID: <46A606D3.8040703@leemhuis.info> On 24.07.2007 15:56, Joel Andres Granados wrote: > Joel Andres Granados wrote: >> Thorsten Leemhuis wrote: >>> On 24.07.2007 11:14, Joel Andres Granados wrote: >>> >>>> Received two automated email (attached) stating that plone depends >>>> on python-imaging for el5. >>>> python-imaging for el5 terminated from EPEL due to its existence in >>>> both RHEL5 Client and Server. >>>> Additionally the mail states that the broken dependency is only >>>> valid for ppc, as I don't see the other arch listed. >>>> >>> Reason for that afaics: there is no PPC-EL5Client, thus the package from >>> it could not be added to the server, thus python-imaging is still >>> missing on PPC. >> strange :-/ > python-imaging already in RHEL ppc. What did you mean exactly? Is it available via RHN these days for PPC also? Then save yourself the work and don't build it for EPEL-PPC -- our scripts can't detect that case currently, but it's safe to ignore the mails in that case. CU knurd From riek at redhat.com Tue Jul 24 14:04:53 2007 From: riek at redhat.com (Daniel Riek) Date: Tue, 24 Jul 2007 10:04:53 -0400 Subject: There are still dependencies for python-imaging el5 In-Reply-To: <46A604F7.1050702@redhat.com> References: <46A5C304.9040309@redhat.com> <46A5C674.6060400@leemhuis.info> <46A5D584.9050406@redhat.com> <46A604F7.1050702@redhat.com> Message-ID: <1185285893.31336.48.camel@scorp> Hi, sorry, I missed that problem. We are going to try to fix that in 5.1 during the Beta. I might have missed how you want to handle this in EPEL: in RHEL you will have to update to 5.1 to get python-imaging. So do you want to keep lower n-v-r in EPEL? Regards, Daniel On Tue, 2007-07-24 at 15:56 +0200, Joel Andres Granados wrote: > Joel Andres Granados wrote: > > Thorsten Leemhuis wrote: > >> On 24.07.2007 11:14, Joel Andres Granados wrote: > >> > >>> Received two automated email (attached) stating that plone depends > >>> on python-imaging for el5. > >>> python-imaging for el5 terminated from EPEL due to its existence in > >>> both RHEL5 Client and Server. > >>> Additionally the mail states that the broken dependency is only > >>> valid for ppc, as I don't see the other arch listed. > >>> > >> > >> Reason for that afaics: there is no PPC-EL5Client, thus the package from > >> it could not be added to the server, thus python-imaging is still > >> missing on PPC. > >> > > > > strange :-/ > > python-imaging already in RHEL ppc. going to build for EPEL for ppc to > see if it fixes deps. Probably it will not go > past that first build as RHEL5.1 will include the package. > > Regards. > -- Daniel Riek, Product Manager Red Hat Enterprise Linux, Red Hat Inc. E-Mail: riek at redhat.com, http://www.redhat.com/ Key-FP: 3DD7 C376 C3E0 1917 9A63 6343 5A26 2C59 6C07 6F32 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Tue Jul 24 14:07:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 24 Jul 2007 16:07:56 +0200 Subject: Maintaining vpnc and NetworkManager-vpnc for EPEL In-Reply-To: <1185214809.24314.3.camel@x2.ultrasound.home> References: <1184928170.24211.4.camel@x2.ultrasound.home> <46A4DCFB.5050306@leemhuis.info> <1185214809.24314.3.camel@x2.ultrasound.home> Message-ID: <46A607BC.4050204@leemhuis.info> On 23.07.2007 20:20, Kyle Gonzales wrote: > On Mon, 2007-07-23 at 18:53 +0200, Thorsten Leemhuis wrote: >> On 20.07.2007 12:42, Kyle Gonzales wrote: >>> I contacted the current Fedora maintainers of vpnc and >>> NetworkManager-vpnc. For vpnc, the author was glad to have me assist. >>> For NetworkManager-vpnc, there was no response from the author for >>> several days now. >>> >>> How do I get started in getting these packages into EPEL? I can do >>> builds for both RHEL4 and RHEL5. >> Well, are you a Fedora contributor already? I can't locate your name on >> https://admin.fedora.redhat.com/accounts/dump-group.cgi?group=cvsextras&role_type=user&format=html >> >> Until all EPEL Contributors came into EPEL via Fedora and its sponsor >> process. > > I am not currently maintaining any Fedora packages, but I have created > both a Fedora user and wiki accounts, and signed the CLA. k, that's a start. > So, I guess you are staying then that my next step is to be sponsored as > someone, so that I can maintain packages? Yes. > If so, then I have someone who can sponsor me. You already have somebody who will sponser you? That would be the easiest solution, as the normal process for getting sponsored is to create a package and get it reviewed and approved by your sponsor. CU knurd From fedora at leemhuis.info Tue Jul 24 14:11:55 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 24 Jul 2007 16:11:55 +0200 Subject: There are still dependencies for python-imaging el5 In-Reply-To: <1185285893.31336.48.camel@scorp> References: <46A5C304.9040309@redhat.com> <46A5C674.6060400@leemhuis.info> <46A5D584.9050406@redhat.com> <46A604F7.1050702@redhat.com> <1185285893.31336.48.camel@scorp> Message-ID: <46A608AB.4050905@leemhuis.info> On 24.07.2007 16:04, Daniel Riek wrote: > sorry, I missed that problem. Well, it's a corner case only a few users might hit, so its not a big problem afaics (nevertheless one we should better fix). > We are going to try to fix that in 5.1 > during the Beta. Great. > I might have missed how you want to handle this in EPEL: in RHEL you > will have to update to 5.1 to get python-imaging. So do you want to keep > lower n-v-r in EPEL? Yeah, we could do that as interim solution for now and have the missing package only in EPEL5-PCC with a lower n-v-r -- shouldn't hurt anyone afaics, as we don't replace anything from RHEL. And when RHEL 5.1 comes out it will replace the package from EPEL. Cu knurd > On Tue, 2007-07-24 at 15:56 +0200, Joel Andres Granados wrote: >> Joel Andres Granados wrote: >>> Thorsten Leemhuis wrote: >>>> On 24.07.2007 11:14, Joel Andres Granados wrote: >>>> >>>>> Received two automated email (attached) stating that plone depends >>>>> on python-imaging for el5. >>>>> python-imaging for el5 terminated from EPEL due to its existence in >>>>> both RHEL5 Client and Server. >>>>> Additionally the mail states that the broken dependency is only >>>>> valid for ppc, as I don't see the other arch listed. >>>>> >>>> Reason for that afaics: there is no PPC-EL5Client, thus the package from >>>> it could not be added to the server, thus python-imaging is still >>>> missing on PPC. >>>> >>> strange :-/ >> python-imaging already in RHEL ppc. going to build for EPEL for ppc to >> see if it fixes deps. Probably it will not go >> past that first build as RHEL5.1 will include the package. >> >> Regards. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> epel-devel-list mailing list >> epel-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/epel-devel-list From jgranado at redhat.com Tue Jul 24 18:00:38 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 24 Jul 2007 20:00:38 +0200 Subject: There are still dependencies for python-imaging el5 In-Reply-To: <46A606D3.8040703@leemhuis.info> References: <46A5C304.9040309@redhat.com> <46A5C674.6060400@leemhuis.info> <46A5D584.9050406@redhat.com> <46A604F7.1050702@redhat.com> <46A606D3.8040703@leemhuis.info> Message-ID: <46A63E46.3020804@redhat.com> Thorsten Leemhuis wrote: > On 24.07.2007 15:56, Joel Andres Granados wrote: > >> Joel Andres Granados wrote: >> >>> Thorsten Leemhuis wrote: >>> >>>> On 24.07.2007 11:14, Joel Andres Granados wrote: >>>> >>>> >>>>> Received two automated email (attached) stating that plone depends >>>>> on python-imaging for el5. >>>>> python-imaging for el5 terminated from EPEL due to its existence in >>>>> both RHEL5 Client and Server. >>>>> Additionally the mail states that the broken dependency is only >>>>> valid for ppc, as I don't see the other arch listed. >>>>> >>>>> >>>> Reason for that afaics: there is no PPC-EL5Client, thus the package from >>>> it could not be added to the server, thus python-imaging is still >>>> missing on PPC. >>>> >>> strange :-/ >>> >> python-imaging already in RHEL ppc. >> > > What did you mean exactly? Is it available via RHN these days for PPC > also? Then save yourself the work and don't build it for EPEL-PPC -- our > scripts can't detect that case currently, but it's safe to ignore the > mails in that case. > > Its already in the nightlies for RHEL5.1. In the mean time I have build the python-imaging package in el5 for ppc (only), so I think that takes care of deps for now. Regards. -- Joel Andres Granados From jdf.lists at gmail.com Tue Jul 24 20:06:00 2007 From: jdf.lists at gmail.com (Joshua Daniel Franklin) Date: Tue, 24 Jul 2007 13:06:00 -0700 Subject: alpine package Message-ID: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> Hello, I am a longtime Red Hat Linux / RHEL sysadmin and I am interested in participating in EPEL. After reading a lot of information on the fedoraproject.org website I created a package for alpine, the Apache-licensed successor to pine: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249365 However, now I think perhaps I was supposed to get a sponsor before submitting a package. From jwilson at redhat.com Tue Jul 24 20:08:15 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 24 Jul 2007 16:08:15 -0400 Subject: alpine package In-Reply-To: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> References: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> Message-ID: <46A65C2F.2050704@redhat.com> Joshua Daniel Franklin wrote: > Hello, I am a longtime Red Hat Linux / RHEL sysadmin and I > am interested in participating in EPEL. After reading a lot of > information on the fedoraproject.org website I created a > package for alpine, the Apache-licensed successor to pine: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249365 > > However, now I think perhaps I was supposed to get a > sponsor before submitting a package. Actually, creating a package and having it reviewed and accepted by a sponsor is one of the ways you *get* sponsored. :) -- Jarod Wilson jwilson at redhat.com From fedora at leemhuis.info Wed Jul 25 04:45:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Jul 2007 06:45:57 +0200 Subject: Plan for tomorrows (20070725) EPEL SIG meeting Message-ID: <46A6D585.105@leemhuis.info> Hi all, find below the list of topics that are planed for the next EPEL SIG meeting which is scheduled for tomorrow, Wednesday at 17:00 UTC in #fedora-extras on irc.freenode.org. /topic EPEL Meeting ? broken deps ? Jeff_S, All /topic EPEL Meeting ? when to run the spam o magic script ? mmcgrath /topic EPEL Meeting ? branch for EPEL if Fedora maintainer does not react ? knurd /topic EPEL Meeting ? push new packages to testing after EPEL annoucement ? dgilmore /topic EPEL Meeting ? EPEL announcement -- everything ready? ? quaid, all /topic EPEL Meeting ? new meeting time? ? all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics at the end of the meeting itself. If your name/nick is on above list please give a update. That way all the interested parties know what up ahead of the meeting; that will avoid long delays and "status update monologues in the meeting. Thanks! CU knurd From sundaram at fedoraproject.org Wed Jul 25 05:21:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 25 Jul 2007 10:51:51 +0530 Subject: alpine package In-Reply-To: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> References: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> Message-ID: <46A6DDEF.1000406@fedoraproject.org> Joshua Daniel Franklin wrote: > Hello, I am a longtime Red Hat Linux / RHEL sysadmin and I > am interested in participating in EPEL. After reading a lot of > information on the fedoraproject.org website I created a > package for alpine, the Apache-licensed successor to pine: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249365 > > However, now I think perhaps I was supposed to get a > sponsor before submitting a package. Welcome to EPEL. You are supposed to submit a package and potentially review others waiting on queue to demonstrate knowledge on packaging for getting sponsored. If this isn't clear in the guidelines let me know and I will fix it. Rahul From smooge at gmail.com Wed Jul 25 05:45:12 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 24 Jul 2007 23:45:12 -0600 Subject: alpine package In-Reply-To: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> References: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> Message-ID: <80d7e4090707242245m5682e28fjde0ceb541f539220@mail.gmail.com> On 7/24/07, Joshua Daniel Franklin wrote: > Hello, I am a longtime Red Hat Linux / RHEL sysadmin and I > am interested in participating in EPEL. After reading a lot of > information on the fedoraproject.org website I created a > package for alpine, the Apache-licensed successor to pine: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249365 > > However, now I think perhaps I was supposed to get a > sponsor before submitting a package. > Cool. You saved me from finishing up my package for review tomorrow. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From pertusus at free.fr Wed Jul 25 11:46:28 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 25 Jul 2007 13:46:28 +0200 Subject: bcond_with on RHEL4 missing? Message-ID: <20070725114628.GA3445@free.fr> Hello, There was discussion about bcond_with not being in RHEL/CENTOS4 and it seems that it is working in the builders, but what should be done to be able to make it work on CENTOS/RHEL4? Otherwise it isn't possible to rebuild a package with a bcond_with on the distro it is supposed to be installed in. I tried a construct like: %if 0%{?rhel} %if "%rhel" <= "4" %define bcond_with %{expand:%%{?_with_%{1}:%%global with_%{1} 1}} %define bcond_without %{expand:%%{!?_without_%{1}:%%global with_%{1} 1}} %endif %if "%rhel" > "4" %bcond_without gfortran %else %bcond_with gfortran %endif %endif but it fails. -- Pat From sheltren at cs.ucsb.edu Wed Jul 25 11:56:57 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 25 Jul 2007 07:56:57 -0400 Subject: packages that conflict with centos? In-Reply-To: <4690E568.50006@leemhuis.info> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> Message-ID: <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 8, 2007, at 9:23 AM, Thorsten Leemhuis wrote: > > On 07.07.2007 16:32, Manuel Wolfshant wrote: >> I for one am 100% in favor of including them in EPEL. At least >> because >> RH5 uses yum. > > +1 (except centos-yumconf of course) > > But we should not create trouble for CentOS, so I'm in favor of this, > what was said somewhere else in this thread: > > On 07.07.2007 22:58, Steven Pritchard wrote: >> On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote: >>> But then EPEL conflicts with Centos. >> Why not just track their package with a lower Release? > > CU > thl > I have rebuilt the following packages by using those included in CentOS 4.5 and prepending a '0' to the release tag (and in some cases, adding a dist tag): createrepo python-elementtree python-sqlite python-urlgrabber sqlite yum For the yum package I also made a change to the yum.conf file which gets installed so that it looks at redhat-release instead of centos- release. CentOS users should not be installing these packages due to the lower release number, so this should work nicely to allow RHEL 4 users to install yum if needed. I've put all the SRPMs here: http://www.sheltren.com/epel/packages/ The sha1sums can be found in sha1sums.txt signed with my gpg key. If these packages look good to everyone, I'm willing to coordinate with the Fedora maintainers to get these into EPEL. If the maintainers don't want to maintain the package in EPEL, I am willing to co-maintain them in EPEL (or have someone else do it if anyone's interested). Thoughts, questions, comments? - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGpzqJKe7MLJjUbNMRAsm4AJ915q/4ysjAVtWLK7QHipnxBGSRUgCgoPCe q0s2lZ8YsdXykfB5ngAhY1I= =OB3h -----END PGP SIGNATURE----- From sheltren at cs.ucsb.edu Wed Jul 25 12:35:50 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 25 Jul 2007 08:35:50 -0400 Subject: Plan for tomorrows (20070725) EPEL SIG meeting In-Reply-To: <46A6D585.105@leemhuis.info> References: <46A6D585.105@leemhuis.info> Message-ID: On Jul 25, 2007, at 12:45 AM, Thorsten Leemhuis wrote: > /topic EPEL Meeting ? broken deps ? Jeff_S, All See http://www.sheltren.com//epel/repoclosure/2007-07-25/ for a run of repoclosure this morning. This is against CentOS 4.5 base + updates, so it may be slightly different than what the spam-o-epel reports, but we should be looking at both. Summary: There are still a number of unresolved dependencies. I think that any unresolved deps should be removed from the repos before going live. For example, give maintainers until the start of next week to get the needed deps into EPEL. Also something to consider: we should re-run repoclosure after removing the packages with broken deps to see what else we broke by removing them -- hopefully this is not a lot of packages! -Jeff From mastahnke at gmail.com Wed Jul 25 13:33:58 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 25 Jul 2007 08:33:58 -0500 Subject: packages that conflict with centos? In-Reply-To: <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> Message-ID: <7874d9dd0707250633g148cf0d6s99f25c5eb419672b@mail.gmail.com> Thanks for taking some action here. I think it seems like a great idea. Having the abillity to simply install Yum on RHEL 4 will probably make many enterprise customers happy. Additionally, having this as a compatability across RHEL and Centos should only help the EPEL cause. stahnma From pertusus at free.fr Wed Jul 25 13:50:04 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 25 Jul 2007 15:50:04 +0200 Subject: bcond_with on RHEL4 missing? In-Reply-To: <20070725114628.GA3445@free.fr> References: <20070725114628.GA3445@free.fr> Message-ID: <20070725135004.GA2946@free.fr> On Wed, Jul 25, 2007 at 01:46:28PM +0200, Patrice Dumas wrote: > Hello, > I solved it, one has to use: %define with() %{expand:%%{?with_%{1}:1}%%{!?with_%{1}:0}} %define without() %{expand:%%{?with_%{1}:0}%%{!?with_%{1}:1}} %define bcond_with() %{expand:%%{?_with_%{1}:%%global with_%{1} 1}} %define bcond_without() %{expand:%%{!?_without_%{1}:%%global with_%{1} 1}} -- Pat From buildsys at fedoraproject.org Wed Jul 25 15:11:23 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 25 Jul 2007 11:11:23 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-25 Message-ID: <20070725151123.8FF56152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 18 NEW drupal-5.1-5.el5 : An open-source content-management platform NEW fuse-2.7.0-3.el5 : File System in Userspace (FUSE) utilities git-1.5.2.1-3.el5 NEW mcrypt-2.6.4-3.el5 : Replacement for crypt() NEW memcached-1.2.3-4.el5 : High Performance, Distributed Memory Object Cache NEW mhash-0.9.2-6.el5 : Thread-safe hash algorithms library NEW mod_geoip-1.1.8-2.el5 : GeoIP module for the Apache HTTP Server NEW ntfs-3g-1.710-1.el5 : Linux NTFS userspace driver NEW phpMyAdmin-2.10.3-1.el5 : Web based MySQL browser written in php NEW python-GeoIP-1.2.1-5.el5 : Python bindings for the GeoIP geographical lookup libraries python-imaging-1.1.5-1.el5 python-paramiko-1.7.1-2.el5 NEW qfaxreader-0.3.1-7.el5 : A multipage monochrome/color TIFF/FAX viewer NEW qstat-2.11-2.el5 : Real-time Game Server Status for FPS game servers R-mvtnorm-0.8-2.el5 NEW sipp-2.0.1-2.el5 : SIP test tool / traffic generator NEW sipsak-0.9.6-1.el5 : SIP swiss army knife NEW smolt-0.9.8.3-1.el5 : Fedora hardware profiler Packages built and released for Fedora EPEL 4: 17 NEW drupal-5.1-5.el4 : An open-source content-management platform NEW fuse-2.7.0-3.el4 : File System in Userspace (FUSE) utilities git-1.5.2.1-3.el4 NEW mcrypt-2.6.4-2.el4 : Replacement for crypt() NEW mhash-0.9.2-2.el4 : Thread-safe hash algorithms library NEW mod_geoip-1.1.8-2.el4 : GeoIP module for the Apache HTTP Server NEW ntfs-3g-1.710-1.el4 : Linux NTFS userspace driver NEW perl-MIME-Lite-3.01-5.el4 : MIME::Lite - low-calorie MIME generator (!) perl-TimeDate-1.16-6.el4 : INVALID rebuild, not published! NEW phpMyAdmin-2.10.3-1.el4 : Web based MySQL browser written in php NEW python-cheetah-2.0-0.6.rc8.el4 : Template engine and code-generator NEW python-GeoIP-1.2.1-6.el4 : Python bindings for the GeoIP geographical lookup libraries python-imaging-1.1.4-1 NEW qfaxreader-0.3.1-7.el4 : A multipage monochrome/color TIFF/FAX viewer NEW qstat-2.11-2.el4.1 : Real-time Game Server Status for FPS game servers NEW sipp-2.0.1-3.2.el4 : SIP test tool / traffic generator NEW sipsak-0.9.6-1.el4 : SIP swiss army knife Changes in Fedora EPEL 5: drupal-5.1-5.el5 ---------------- * Fri Jul 20 2007 Jon Ciesla - 5.1-5 - Corrected buildroot. - Moved /etc/drupal/all/README.txt to correct place. * Wed Jul 04 2007 Jon Ciesla - 5.1-4 - Made settings.php not readonly by default, with note in drupal-README.fedora - Locked down initial security configuration, documented steps required. - Description cleanup. - Added wget requires. fuse-2.7.0-3.el5 ---------------- * Sun Jul 22 2007 Tom "spot" Callaway 2.7.0-3 - put pkgconfig file in correct place - enable compat symlinks for files in /bin * Sat Jul 21 2007 Tom "spot" Callaway 2.7.0-2 - redefine exec_prefix to / - redefine bindir to /bin - redefine libdir to %{_lib} - don't pass --disable-static to configure - manually rm generated static libs * Wed Jul 18 2007 Peter Lemenkov 2.7.0-1 - Version 2.7.0 - Redefined exec_prefix due to demands from NTFS-3G git-1.5.2.1-3.el5 ----------------- * Mon Jul 23 2007 James Bowes 1.5.2.1-3 - Remove the git-arch subpackage (tla is not in epel). mcrypt-2.6.4-3.el5 ------------------ * Tue Sep 12 2006 Tom "spot" Callaway 2.6.4-3 - bump for FC-6 memcached-1.2.3-4.el5 --------------------- * Fri Jul 13 2007 Paul Lindner - 1.2.3-4 - Remove test that fails in fedora build system on ppc64 * Sat Jul 07 2007 root - 1.2.3-2 - Upgrade to 1.2.3 upstream - Adjust make install to preserve man page timestamp - Conform with LSB init scripts standards, add force-reload * Wed Jul 04 2007 Paul Lindner - 1.2.2-5 - Use /var/run/memcached/ directory to hold PID file mhash-0.9.2-6.el5 ----------------- * Tue Jul 24 2007 Jon Ciesla - 0.9.2-6 Added disttag for EPEL. mod_geoip-1.1.8-2.el5 --------------------- * Sun Sep 03 2006 Michael Fleming 1.1.8-2 - Bump and rebuild ntfs-3g-1.710-1.el5 ------------------- * Sun Jul 22 2007 Tom "spot" Callaway 2:1.710-1 - bump to 1.710 - add compat symlinks * Wed Jun 27 2007 Tom "spot" Callaway 2:1.616-1 - bump to 1.616 phpMyAdmin-2.10.3-1.el5 ----------------------- * Mon Jul 23 2007 Mike McGrath 2.10.3-1 - Upstream released new version python-GeoIP-1.2.1-5.el5 ------------------------ * Mon Sep 04 2006 Michael Fleming 1.2.1-5 - Rebuild python-imaging-1.1.5-1.el5 -------------------------- * Tue Jul 24 2007 Joel Granados - 1.1.5-1 - Rebuild for ppc in EPEL. python-paramiko-1.7.1-2.el5 --------------------------- * Thu Jul 19 2007 Jeffrey C. Ollie - 1.7.1-2 - Bump rev * Thu Jul 19 2007 Jeffrey C. Ollie - 1.7.1-1 - Update to 1.7.1 qfaxreader-0.3.1-7.el5 ---------------------- * Tue Jul 24 2007 manuel wolfshant - 0.3.1-7 - Parallel build, take two (yet another patch) * Mon Jul 23 2007 manuel wolfshant - 0.3.1-6 - Adding automake as BR * Mon Jul 23 2007 manuel wolfshant - 0.3.1-5 - More cleanup - Reenable SMP * Mon Jul 23 2007 manuel wolfshant - 0.3.1-4 - Spec file cleanup - Disabled parallel build, it does not seem to work. qstat-2.11-2.el5 ---------------- * Wed May 23 2007 Andy Shevchenko 2.11-2 - Fix URL tag R-mvtnorm-0.8-2.el5 ------------------- * Tue Jul 24 2007 Orion Poplawski - 0.8-2 - Update to 0.8-1, fixes test * Mon Jul 23 2007 Orion Poplawski - 0.8-1 - Update to 0.8-0 sipp-2.0.1-2.el5 ---------------- * Sun Jun 10 2007 Peter Lemenkov 2.0.1-2 - rebuild sipsak-0.9.6-1.el5 ------------------ * Sun Sep 17 2006 Peter Lemenkov 0.9.6-1 - Initial build for FE smolt-0.9.8.3-1.el5 ------------------- * Fri Jun 22 2007 Mike McGrath 0.9.8.3 - Upstream released new version Changes in Fedora EPEL 4: drupal-5.1-5.el4 ---------------- * Fri Jul 20 2007 Jon Ciesla - 5.1-5 - Corrected buildroot. - Moved /etc/drupal/all/README.txt to correct place. * Wed Jul 04 2007 Jon Ciesla - 5.1-4 - Made settings.php not readonly by default, with note in drupal-README.fedora - Locked down initial security configuration, documented steps required. - Description cleanup. - Added wget requires. fuse-2.7.0-3.el4 ---------------- * Sun Jul 22 2007 Tom "spot" Callaway 2.7.0-3 - put pkgconfig file in correct place - enable compat symlinks for files in /bin * Sat Jul 21 2007 Tom "spot" Callaway 2.7.0-2 - redefine exec_prefix to / - redefine bindir to /bin - redefine libdir to %{_lib} - don't pass --disable-static to configure - manually rm generated static libs * Wed Jul 18 2007 Peter Lemenkov 2.7.0-1 - Version 2.7.0 - Redefined exec_prefix due to demands from NTFS-3G git-1.5.2.1-3.el4 ----------------- * Mon Jul 23 2007 James Bowes 1.5.2.1-3 - Remove the git-arch subpackage (tla is not in epel). mcrypt-2.6.4-2.el4 ------------------ * Tue Feb 28 2006 Tom "spot" Callaway 2.6.4-2 - bump for FC-5 mhash-0.9.2-2.el4 ----------------- * Tue Jul 24 2007 Jon Ciesla - 0:0.9.2-2 - Added disttag for epel. mod_geoip-1.1.8-2.el4 --------------------- * Sun Sep 03 2006 Michael Fleming 1.1.8-2 - Bump and rebuild ntfs-3g-1.710-1.el4 ------------------- * Sun Jul 22 2007 Tom "spot" Callaway 2:1.710-1 - bump to 1.710 - add compat symlinks * Wed Jun 27 2007 Tom "spot" Callaway 2:1.616-1 - bump to 1.616 perl-MIME-Lite-3.01-5.el4 ------------------------- * Sun Sep 10 2006 Mike McGrath 3.01-5 - Rebuild perl-TimeDate-1.16-6.el4 ------------------------ * Thu Jun 28 2007 Robin Norwood 1:1.16-6 - Bump release to outpace RHEL5 - Add dist tag to release field phpMyAdmin-2.10.3-1.el4 ----------------------- * Mon Jul 23 2007 Mike McGrath 2.10.3-1 - Upstream released new version python-cheetah-2.0-0.6.rc8.el4 ------------------------------ * Thu May 03 2007 Mike Bonnet - 2.0-0.6.rc8 - bump release for rebuild python-GeoIP-1.2.1-6.el4 ------------------------ * Sat Dec 09 2006 Michael Fleming 1.2.1-6 - Rebuild for python 2.5 python-imaging-1.1.4-1 ---------------------- * Mon Jul 23 2007 Joel Andres Granados - 0:1.1.4-1 - Build python-imaging for EPEL4 with the version from FC3. EPEL4 are packages - that can be installed in RHEL4**. qfaxreader-0.3.1-7.el4 ---------------------- * Tue Jul 24 2007 manuel wolfshant - 0.3.1-7 - Parallel build, take two (yet another patch) * Mon Jul 23 2007 manuel wolfshant - 0.3.1-6 - Adding automake as BR * Mon Jul 23 2007 manuel wolfshant - 0.3.1-5 - More cleanup - Reenable SMP * Mon Jul 23 2007 manuel wolfshant - 0.3.1-4 - Spec file cleanup - Disabled parallel build, it does not seem to work. qstat-2.11-2.el4.1 ------------------ * Tue Jul 24 2007 Andy Shevchenko 2.11-2.1 - Do not use -delete for find sipp-2.0.1-3.2.el4 ------------------ * Wed Jul 25 2007 Peter Lemenkov 2.0.1-3.2 - finally added correct BR for EL-4 * Wed Jul 25 2007 Peter Lemenkov 2.0.1-3.1 - rebuild * Wed Jul 25 2007 Peter Lemenkov 2.0.1-3 - Added tcpdump instead of libpcap as BR for EL-4 sipsak-0.9.6-1.el4 ------------------ * Sun Sep 17 2006 Peter Lemenkov 0.9.6-1 - Initial build for FE For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Wed Jul 25 15:33:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 25 Jul 2007 17:33:57 +0200 Subject: broken deps in EPEL5 and fixing them (was Re: Plan for tomorrows (20070725) EPEL SIG meetin) In-Reply-To: References: <46A6D585.105@leemhuis.info> Message-ID: <46A76D65.20403@leemhuis.info> On 25.07.2007 14:35, Jeff Sheltren wrote: > On Jul 25, 2007, at 12:45 AM, Thorsten Leemhuis wrote: >> /topic EPEL Meeting ? broken deps ? Jeff_S, All > > See http://www.sheltren.com//epel/repoclosure/2007-07-25/ for a run > of repoclosure this morning. This is against CentOS 4.5 base + > updates, so it may be slightly different than what the spam-o-epel > reports, but we should be looking at both. > > Summary: There are still a number of unresolved dependencies. I did a local run here as well, including the needsign repo; i386 and EPEL5 only. package: JSDoc - 1.10.2-3.el5.noarch from thl-epel unresolved deps: perl(HTML::Template) /me votes for moving it to testing package: SDL_mixer - 1.2.7-2.el5.i386 from thl-epel unresolved deps: timidity++ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=248311 package: bcfg2 - 0.9.4-2.el5.noarch from thl-epel unresolved deps: python-lxml /me votes for moving it to testing package: bugzilla - 3.0-2.el5.noarch from thl-epel unresolved deps: perl-Email-Send perl(Email::Address) perl-Email-MIME-Attachment-Stripper perl(Email::Reply) perl(Email::MIME::Attachment::Stripper) perl(Email::MIME) perl(Email::Send) perl-Email-MIME perl(Email::MIME::Modifier) perl(Template::Stash) perl-Template-Toolkit perl-Email-Simple perl(Template::Config) perl-Email-Reply perl-Email-MIME-Modifier perl-Email-Address /me votes for moving it to testing package: evolution-bogofilter - 0.2.0-5.el5.1.i386 from thl-epel unresolved deps: bogofilter /me votes for moving it to testing package: fail2ban - 0.6.2-3.el5.noarch from thl-epel unresolved deps: shorewall /me votes for removing, as maintainer left EPEL package: limph - 1.9.4-7.el5.noarch from thl-epel unresolved deps: php-mhash php-mcrypt /me votes for moving it to testing package: limph-hostagent - 1.9.4-7.el5.noarch from thl-epel unresolved deps: php-mhash php-mcrypt /me votes for moving it to testing package: nagios-plugins-fping - 1.4.6-3.el5.i386 from thl-epel unresolved deps: /usr/sbin/fping Ignore and fix asap (in progress already)? package: nagios-plugins-ifoperstatus - 1.4.6-3.el5.i386 from thl-epel unresolved deps: perl(Net::SNMP) Ignore and fix asap (in progress already)? package: nagios-plugins-ifstatus - 1.4.6-3.el5.i386 from thl-epel unresolved deps: perl(Net::SNMP) Ignore and fix asap (in progress already)? package: perl-Net-Pcap - 0.14-2.el5.i386 from thl-epel unresolved deps: perl(IO::Interface) /me votes for moving it to testing package: perl-Test-Base - 0.53-1.el5.noarch from thl-epel unresolved deps: perl(Module::Install::Base) /me votes for moving it to testing package: perl-libwhisker2 - 2.4-3.el5.noarch from thl-epel unresolved deps: perl(MD5) /me votes for moving it to testing package: php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch from thl-epel unresolved deps: php-mhash php-mcrypt /me votes for moving it to testing package: python-Coherence - 0.2.1-3.el5.noarch from thl-epel unresolved deps: python-twisted-core python-nevow python-twisted-web SOAPpy /me votes for moving it to testing package: qucs - 0.0.12-2.el5.i386 from thl-epel unresolved deps: iverilog /me votes for moving it to testing package: translate-toolkit - 0.10.1-1.el5.noarch from thl-epel unresolved deps: python-enchant /me votes for moving it to testing package: zabbix - 1.4.1-1.el5.i386 from thl-epel unresolved deps: fping Ignore and fix asap (in progress already)? --- If we move all those into testing that I flagged as "/me votes for moving it to testing" then we need to move php-pear-File-SMBPasswd-1.0.2-1.el5.noarch.rpm nikto-1.36-3.el5.noarch.rpm as well, as they depend on packages being moved. CU thl From limb at jcomserv.net Wed Jul 25 15:31:52 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 25 Jul 2007 10:31:52 -0500 (CDT) Subject: broken deps in EPEL5 and fixing them (was Re: Plan for tomorrows (20070725) EPEL SIG meetin) In-Reply-To: <46A76D65.20403@leemhuis.info> References: <46A6D585.105@leemhuis.info> <46A76D65.20403@leemhuis.info> Message-ID: <34201.65.192.24.164.1185377512.squirrel@mail.jcomserv.net> > > package: limph - 1.9.4-7.el5.noarch from thl-epel > unresolved deps: > php-mhash > php-mcrypt > > /me votes for moving it to testing > package: limph-hostagent - 1.9.4-7.el5.noarch from thl-epel > unresolved deps: > php-mhash > php-mcrypt > > /me votes for moving it to testing I am in the process of getting these deps fixed. mhash and mcrypt have been built, and php-extras that provides php-mhash and php-mcrypt is on it's way. > --- > > If we move all those into testing that I flagged as "/me votes for > moving it to testing" then we need to move > php-pear-File-SMBPasswd-1.0.2-1.el5.noarch.rpm > nikto-1.36-3.el5.noarch.rpm > as well, as they depend on packages being moved. > > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- novus ordo absurdum From jima at beer.tclug.org Wed Jul 25 15:53:47 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 25 Jul 2007 10:53:47 -0500 (CDT) Subject: alpine package In-Reply-To: <80d7e4090707242245m5682e28fjde0ceb541f539220@mail.gmail.com> References: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> <80d7e4090707242245m5682e28fjde0ceb541f539220@mail.gmail.com> Message-ID: On Tue, 24 Jul 2007, Stephen John Smoogen wrote: > Cool. You saved me from finishing up my package for review tomorrow. By all means, jump in on the review and voice any thoughts you have. I had an Alpine package in okay-ish shape (just needed some time to polish it up before review), as well. While I can't sponsor Joshua, I can give some feedback to try and make the package as good as possible. (Conversely, he got some things right that I'll readily acknowledge I'd done wrong in mine. Like I said in the review bug, yay for open source collaboration.) Hopefully a sponsor will come along, too. :-) Jima From sundaram at fedoraproject.org Wed Jul 25 16:01:59 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 25 Jul 2007 21:31:59 +0530 Subject: Fedora EPEL Package Build Report 2007-07-25 In-Reply-To: <20070725151123.8FF56152131@buildsys.fedoraproject.org> References: <20070725151123.8FF56152131@buildsys.fedoraproject.org> Message-ID: <46A773F7.20706@fedoraproject.org> buildsys at fedoraproject.org wrote: > Packages built and released for Fedora EPEL 5: 18 > > NEW fuse-2.7.0-3.el5 : File System in Userspace (FUSE) utilities Note that RHEL 5 kernel does not have FUSE enabled. I believe CentOS does offer a alternative kernel so it might be useful there. > NEW fuse-2.7.0-3.el4 : File System in Userspace (FUSE) utilities FUSE won't work in RHEL 4 at all since the kernel is older. Rahul From kwade at redhat.com Wed Jul 25 17:15:53 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 25 Jul 2007 10:15:53 -0700 Subject: (draft) announcement In-Reply-To: <7874d9dd0707151509g1b176d4w9b5e48bc1967aac8@mail.gmail.com> References: <1184521163.26011.93.camel@erato.phig.org> <7874d9dd0707151509g1b176d4w9b5e48bc1967aac8@mail.gmail.com> Message-ID: <1185383753.17380.724.camel@erato.phig.org> On Sun, 2007-07-15 at 17:09 -0500, Michael Stahnke wrote: > > > Somewhere I think we want to touch on the quality of the packages from > Fedora. I think that is a big selling point. Granted, not all > packages are perfect, but as a RHEL subscriber, my company thinks > highly of RHEL and how it is built, and thus like the way Fedora (at > least the former Core) was built. Somehow, that should be captured > int eh announment, methinks. > > I am also hesitant to use the Perl message because LOTS of perl stuff > still isn't in EPEL. (/me rebuilt several modules last week for > RHEL). Good points; I'll replace the Perl stuff with stuff about package quality, Fedora => RHEL, etc. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jdf.lists at gmail.com Wed Jul 25 17:29:15 2007 From: jdf.lists at gmail.com (Joshua Daniel Franklin) Date: Wed, 25 Jul 2007 10:29:15 -0700 Subject: alpine package In-Reply-To: <46A6DDEF.1000406@fedoraproject.org> References: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> <46A6DDEF.1000406@fedoraproject.org> Message-ID: <67437bc40707251029x1fd96016qfdf9c6854027a411@mail.gmail.com> On 7/24/07, Rahul Sundaram wrote: > Joshua Daniel Franklin wrote: > > However, now I think perhaps I was supposed to get a > > sponsor before submitting a package. > > You are supposed to submit a package and potentially review others > waiting on queue to demonstrate knowledge on packaging for getting > sponsored. If this isn't clear in the guidelines let me know and I will > fix it. OK, the "Getting Sponsored" section confused me: https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored?highlight=%28sponsor%29 If I re-read it carefully, it accurately describes the process, but some statements could be easily misread, such as "A sponsor will assist you with some aspects of packaging". Additionally, I began at https://fedoraproject.org/wiki/PackageMaintainers/Join (or actually at EPEL/SIG but that makes it clear you need to join Fedora first) which has a wonderful ordered list of steps: # Read the Guidelines # Create a Bugzilla Account # Join the important Mailing Lists # Read Other Submissions # Make a Package # Upload Your Package # Create Your Review Request # Watch for Feedback # Get a Fedora Account # Get Sponsored However, PackageMaintainers/HowToGetSponsored indicates that you should do a few package reviews first since "sponsors will want to see what reviews you have done". Also the sentence in the review section "the more you indicate that you understand, the better your chances of being sponsored" makes it sound like someone might sponsor you from reading your reviews. (BTW, that page also lists FE-REVIEW twice.) Thanks, Joshua From rayvd at bludgeon.org Wed Jul 25 17:35:42 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Wed, 25 Jul 2007 10:35:42 -0700 Subject: alpine package In-Reply-To: <67437bc40707251029x1fd96016qfdf9c6854027a411@mail.gmail.com> References: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> <46A6DDEF.1000406@fedoraproject.org> <67437bc40707251029x1fd96016qfdf9c6854027a411@mail.gmail.com> Message-ID: <20070725173542.GA1378@bludgeon.org> On Wed, Jul 25, 2007 at 10:29:15AM -0700, Joshua Daniel Franklin wrote: > OK, the "Getting Sponsored" section confused me: > https://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored?highlight=%28sponsor%29 > If I re-read it carefully, it accurately describes the process, but some > statements could be easily misread, such as > "A sponsor will assist you with some aspects of packaging". > > Additionally, I began at > https://fedoraproject.org/wiki/PackageMaintainers/Join > (or actually at EPEL/SIG but that makes it clear you need to join Fedora > first) > which has a wonderful ordered list of steps: > > # Read the Guidelines > # Create a Bugzilla Account > # Join the important Mailing Lists > # Read Other Submissions > # Make a Package > # Upload Your Package > # Create Your Review Request > # Watch for Feedback > # Get a Fedora Account > # Get Sponsored > > However, PackageMaintainers/HowToGetSponsored indicates that you should > do a few package reviews first since "sponsors will want to see what reviews > you have done". Also the sentence in the review section "the more you > indicate > that you understand, the better your chances of being sponsored" makes it > sound like someone might sponsor you from reading your reviews. > (BTW, that page also lists FE-REVIEW twice.) > Heh, yes... the steps are way too complex IMO. I believe they are working on FAS2 to at least make the getting an account part a little more streamlined... I recently submitted a package and went through the same process you are. I'd say get going with your Bugzilla account, and even submit your review request and at least get that ball rolling. You can get your FAS account set up, do a "pre-review" or someone else's package and then find someone to review your package and sponsor you (often the same person). I just ended up getting the ball rolling on my review and doing the other steps a little out of order :) Ray From smooge at gmail.com Wed Jul 25 20:25:55 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 25 Jul 2007 14:25:55 -0600 Subject: alpine package In-Reply-To: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> References: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> Message-ID: <80d7e4090707251325x26ae458ehd18558820695a480@mail.gmail.com> On 7/24/07, Joshua Daniel Franklin wrote: > Hello, I am a longtime Red Hat Linux / RHEL sysadmin and I > am interested in participating in EPEL. After reading a lot of > information on the fedoraproject.org website I created a > package for alpine, the Apache-licensed successor to pine: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249365 > > However, now I think perhaps I was supposed to get a > sponsor before submitting a package. By the way, do you know if this version of alpine has their webclient included in it (I have a much older tarball)? I am wanting to look at that... and if it does, I would suspect you would want to seperate that out as a sub-package). -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jdf.lists at gmail.com Wed Jul 25 20:42:19 2007 From: jdf.lists at gmail.com (Joshua Daniel Franklin) Date: Wed, 25 Jul 2007 13:42:19 -0700 Subject: alpine package In-Reply-To: <80d7e4090707251325x26ae458ehd18558820695a480@mail.gmail.com> References: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> <80d7e4090707251325x26ae458ehd18558820695a480@mail.gmail.com> Message-ID: <67437bc40707251342y3d850731r1bfe20aa0f565db4@mail.gmail.com> On 7/25/07, Stephen John Smoogen wrote: > By the way, do you know if this version of alpine has their webclient > included in it (I have a much older tarball)? I am wanting to look at > that... and if it does, I would suspect you would want to seperate > that out as a sub-package). The tarball does, but I didn't build or configure it. I am UW staff so I am sometimes forced to use "WebPine" and it's OK if you want a CGI frontend slapped onto pine, but isn't very impressive compared to virtually any other web-based email system. From smooge at gmail.com Wed Jul 25 20:51:39 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 25 Jul 2007 14:51:39 -0600 Subject: alpine package In-Reply-To: <67437bc40707251342y3d850731r1bfe20aa0f565db4@mail.gmail.com> References: <67437bc40707241306x5baf99a8qfbd70ac7c6d16d7f@mail.gmail.com> <80d7e4090707251325x26ae458ehd18558820695a480@mail.gmail.com> <67437bc40707251342y3d850731r1bfe20aa0f565db4@mail.gmail.com> Message-ID: <80d7e4090707251351w2bddd79bod2edd35c76d3a534@mail.gmail.com> On 7/25/07, Joshua Daniel Franklin wrote: > On 7/25/07, Stephen John Smoogen wrote: > > By the way, do you know if this version of alpine has their webclient > > included in it (I have a much older tarball)? I am wanting to look at > > that... and if it does, I would suspect you would want to seperate > > that out as a sub-package). > > The tarball does, but I didn't build or configure it. I am UW staff > so I am sometimes forced to use "WebPine" and it's OK if you > want a CGI frontend slapped onto pine, but isn't very impressive > compared to virtually any other web-based email system. > Ah ok. We have some webstuff that makes pine look like a godsend... and reading the webpages it made the webpine sound better than Squirrelmail. Will just avoid it then. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From bojan at rexursive.com Thu Jul 26 01:12:29 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 26 Jul 2007 01:12:29 +0000 (UTC) Subject: Fedora EPEL Package Build Report 2007-07-25 References: <20070725151123.8FF56152131@buildsys.fedoraproject.org> Message-ID: writes: > NEW phpMyAdmin-2.10.3-1.el5 : Web based MySQL browser written in php Thanks Mike! -- Bojan From fedora at leemhuis.info Thu Jul 26 05:29:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Jul 2007 07:29:41 +0200 Subject: Log from yesterdays (20070726) EPEL SIG Meeting Message-ID: <46A83145.4090402@leemhuis.info> 00:00:00 < knurd> | Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00:00 < knurd> | Hi everybody; who's around? 00:00:00 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00:02 * | knurd likes to remind people that the schedule and the topic list for todays meeting can be found on http://fedoraproject.org/wiki/EPEL/Schedule 00:00:15 < f13> | I'm here by accident. 00:00:30 * | dgilmore is here 00:00:45 < Jeff_S> | f13: that's what my parents said too :( 00:00:52 < dgilmore> | f13: we will take you as one of our own :) 00:01:22 < knurd> | mmcgrath ponged in #epel 00:01:26 * | Jeff_S here and making lame jokes 00:01:50 < knurd> | well, let's start slowly 00:02:01 --- | knurd has changed the topic to: EPEL Meeting ? broken deps ? Jeff_S, All 00:02:28 < mmcgrath> | Doah :) 00:02:31 < mmcgrath> | pong 00:02:34 < knurd> | the stuff mether posted to #epel really annoys me 00:02:46 < knurd> | why fuse one day before we want to annouce EPEL 00:02:51 < knurd> | and then obviously broken? 00:02:56 * | marek is here too 00:03:04 < marek> | hello guys, my first meeting 00:03:05 < knurd> | (in case it's true what mether wrote, but I assume that for now) 00:03:08 < knurd> | hi marek 00:03:19 < knurd> | anyway, how to move on 00:03:21 < f13> | knurd: you mean epel-list? 00:03:26 < knurd> | f13, yes 00:03:34 < dgilmore> | knurd: thats Rhaul for you 00:03:39 < f13> | er epel-devel-list 00:03:47 < knurd> | move those to testing which I porposed on epel-devel-list? 00:04:03 < knurd> | f13, there is only epel-devel-list (at least afaik) 00:04:04 --> | jbowes (James Bowes) has joined #fedora-meeting 00:04:15 < knurd> | dgilmore, ? 00:04:28 < dgilmore> | knurd: it seems to be what he does best lately 00:04:32 < dgilmore> | anyways 00:04:40 < dgilmore> | knurd: there is only the one list 00:04:44 < knurd> | ohh :-) 00:04:44 < Jeff_S> | ok, well if he's correct then let's move them to testing (or remove them) 00:04:48 <-- | svahl has quit ("Ex-Chat") 00:04:51 < knurd> | Jeff_S, +1 00:04:54 < marek> | is there any consideration to postpone the announce of EPEL? 00:04:57 < knurd> | what about the other broken deps? 00:05:09 < knurd> | marek, we could do that, but it looks bad 00:05:22 < mether> | dgilmore: i cant really guess that fuse was going to be pushed out before it was 00:05:25 < knurd> | I#d prefer to get EPEL5 in shape now, and annouce EPEL and EPEL5 00:05:26 < mmcgrath> | knurd: I think people have been responsive. 00:05:26 < Jeff_S> | knurd: at first I didn't like the idea of putting them in testing/ but the idea is growing on me 00:05:31 < marek> | better to release good product later, that bad product at time (imho) 00:05:48 < knurd> | marek, yeah, but otherwise we might never release... 00:06:06 < Jeff_S> | mmcgrath: yep, it seems like some people are taking the initiative to get their deps into EPEL 00:06:09 < quaid> | release early, release often :) 00:06:11 < knurd> | Jeff_S, yeah, we should fix everything in testing soon as well 00:06:27 < dgilmore> | knurd: so anything broken needs to get moved into testing 00:06:35 < knurd> | dgilmore, well, I posted to the list 00:06:37 < dgilmore> | which is manual but needs doing 00:06:39 < knurd> | some stuff is in progress 00:06:43 < Jeff_S> | knurd: yes, I don't like having things broken in /testing/ but at least people can see what's there and build on that 00:06:44 < knurd> | dgilmore, yeah, that's manual 00:06:52 < knurd> | dgilmore, if you give me access I can handle it 00:07:22 < knurd> | (in case you are busy with other stuff) 00:07:23 < stahnma> | here now 00:07:30 < dgilmore> | knurd: i can get you setup. or i can do it 00:07:39 * | dgilmore is traveling toomoroow 00:07:54 < knurd> | dgilmore, well, I'd think it might be a good idea if I or someone else gets access 00:08:08 < knurd> | as you and mmcgrath seems to be a bottleneck afaics 00:08:12 < dgilmore> | knurd: :) we will make it happen 00:08:19 < knurd> | dgilmore, k, thx 00:08:31 < knurd> | what about EPEL4? shall we try to fix that up in a similar way? 00:08:49 < Jeff_S> | knurd: yes 00:09:21 < knurd> | I'm busy tomorrow at 18:00 UTC, but I think it could try to fix everything up to then 00:09:55 < knurd> | quaid, could you send the annoucement afterwards? 00:10:25 < knurd> | dgilmore, can you give me access later today or early tomorrow? 00:10:34 < knurd> | then I'll try to fix everything 00:10:42 < knurd> | dgilmore, but you'd need to adjust the push scripts 00:10:47 < quaid> | knurd: sure 00:10:53 < knurd> | to make sure that all the new stuff from now own goes to testing 00:11:04 < knurd> | otherwise we'll have broken deps soon again 00:11:05 < dgilmore> | knurd: yes 00:11:11 < knurd> | dgilmore, k, thx 00:11:17 < knurd> | anything else regarding this topic? 00:11:33 < mmcgrath> | knurd: one quick question. What exactly are dgilmore and I the bottlenecks of? 00:11:39 < Jeff_S> | well, the yum-related packages I posted earlier 00:11:51 < Jeff_S> | I'd rather have those in the main repo than in testing/ 00:11:54 < knurd> | mmcgrath, not exactly bottlenecks, but you are busy and have lots of load already 00:11:59 < Jeff_S> | but that's just my opinion :) 00:12:04 < mmcgrath> | knurd: what hasn't been getting done? 00:12:22 < knurd> | mmcgrath, it wasn#t meant as offense 00:12:37 < knurd> | but I would have fixed the deps days agao if I would have had access 00:12:42 * | mmcgrath not offended, just confused. We can't branch and build peopels packages for them. 00:12:56 < knurd> | mmcgrath, sure, I meant the moving 00:13:05 < knurd> | I'd preferred to have that done last weekend or so 00:13:06 < mmcgrath> | ahh, well have fun :) 00:13:07 < dgilmore> | knurd: we will need to change mock configs on the builders also 00:13:16 < knurd> | dgilmore, upphs 00:13:21 < knurd> | dgilmore, can you handle that? 00:13:32 < dgilmore> | we will want whats in testing in the buildroot 00:13:36 < knurd> | dgilmore, +1 00:13:39 < dgilmore> | yes 00:13:41 < Jeff_S> | yes 00:13:49 < stahnma> | yes 00:14:19 < knurd> | k, so I'll get acess and fix the broken deps and dgilmore will update the mock configs and the push scripts 00:14:20 < quaid> | sorry, did we pick a time (yet) for official door opening/ 00:14:29 < quaid> | or just be ready to announce when it is ready? 00:14:50 < knurd> | quaid, I'd say we should aim 15:00 UTC 00:15:08 < knurd> | quaid, I'll give you a heads up when I have the deps fixed 00:15:15 < knurd> | does that sound like a plan? 00:15:59 < quaid> | ok 00:16:38 < knurd> | mmcgrath, are you around tomorrow in case I need help and in case dgilmore is traveling? 00:17:06 < mmcgrath> | knurd: yep 00:17:11 < knurd> | great 00:17:17 * | knurd moves on then 00:17:23 --- | knurd has changed the topic to: EPEL Meeting ? when to run the spam o magic script ? mmcgrath 00:17:33 < knurd> | mmcgrath, could the script run when we push new pacakges? 00:17:42 < knurd> | that's what Extras did/does 00:17:56 < knurd> | that sounds a bit better then just once a week 00:18:03 < knurd> | at least if it isn#t to hard to set up 00:00:19 * | knurd moves on for now, we can get back if needed 00:00:23 --- | knurd has changed the topic to: EPEL Meeting ? branch for EPEL if Fedora maintainer does not 00:00:30 --- | knurd has changed the topic to: EPEL Meeting ? branch for EPEL if Fedora maintainer does not react ? knurd 00:00:40 < mmcgrath> | knurd: the spam-o-matic script? Probably not. It takes over an hour to run right now. 00:00:52 <-- | giallu has quit (Read error: 110 (Connection timed out)) 00:20:03 < knurd> | mmcgrath, could it just be triggered to run maybe? 00:20:07 <-- | JSchmitt has quit ("Konversation terminated!") 00:20:11 < knurd> | then nobody would have to wait for it 00:20:14 < mmcgrath> | http://git.fedoraproject.org/hosted/fedora-infrastructure.git/scripts/?p=hosted/fedora-infrastructure.git;a=tree;f=scripts/spam-o-epel 00:20:20 < stahnma> | any idea why it takes over an hour? Is that normal (I just don't know) 00:20:22 < Jeff_S> | mmcgrath: how many repos is it looking at? repoview takes a few minutes at the most for me 00:20:33 < mmcgrath> | stahnma: not really, I'd have to take a look. 00:20:47 < mmcgrath> | Perhaps we should re-think what we're doing. 00:21:14 < mmcgrath> | we're looking to do more of a "Sorry, we couldn't push this file because of these deps:" 00:21:23 < mmcgrath> | and so they'd stay in needsign. 00:21:27 < mmcgrath> | dgilmore: does that make sense? 00:21:34 < mmcgrath> | s/push this file/push this package/ 00:21:43 < knurd> | mmcgrath, won't we get that with bodhi soon? 00:21:48 < dgilmore> | mmcgrath: yeah 00:22:08 < mmcgrath> | knurd: 'soon' is very misleading. 00:22:10 < dgilmore> | knurd: its not known we we will be able to move that way 00:22:18 < knurd> | k, was just wondering 00:22:28 < dgilmore> | knurd: it will probably be many months 00:22:33 < mmcgrath> | knurd: I have a suspicion it won't be in there until someone steps up and submits the patches. 00:22:47 < knurd> | k 00:23:14 < knurd> | in that case it might be worth to enhance the current push scripts 00:23:33 < stahnma> | brb 00:23:37 < mmcgrath> | stahnma: well it only takes an hour for epel5, epel4 is significantly faster. 00:23:39 < knurd> | k, so back to the current topic 00:23:45 < knurd> | branch for EPEL if Fedora maintainer does not react 00:23:50 <-- | Kevin_Kofler has left #fedora-meeting ( "Bye!") 00:23:54 < knurd> | is https://www.redhat.com/archives/epel-devel-list/2007-July/msg00104.html fine for everyone? 00:23:59 <-- | LetoTo has left #fedora-meeting ( ) 00:24:16 < knurd> | gets a +1 from me 00:24:19 --> | LetoTo (Paul Wouters) has joined #fedora-meeting 00:24:37 < marek> | +1 from my side 00:24:48 <-- | LetoTo has quit (Client Quit) 00:24:53 < Jeff_S> | +1 00:24:55 * | knurd will wait until we get 4 +1 from steering committee members 00:25:05 < dgilmore> | knurd: as long as someone and no 00:25:05 < dgilmore> | more than one month has passed, then the EPEL maintainer of the package 00:25:05 < dgilmore> | must hand primary per release maintainership back to the Fedora 00:25:08 < dgilmore> | maintainer (and become comaintainer, if interested). 00:25:11 < dgilmore> | gahh 00:25:15 --> | LetoTo (Paul Wouters) has joined #fedora-meeting 00:25:24 <-- | LetoTo has quit (Remote closed the connection) 00:25:24 < dgilmore> | that doesnt rub overly well with me 00:25:33 < knurd> | then why didn#t you post to the list 00:25:39 < knurd> | dgilmore, could you do that please 00:25:47 < knurd> | then we'll get to this topic in next weeks meeting 00:26:03 < dgilmore> | i think we simplify it and say if the maintainer wants to work on EPEL then great both people become co maintainers 00:26:04 < stahnma> | I thought that was changed on list, to something like, become comaintainers or something 00:26:18 < stahnma> | dgilmore: +1 00:26:27 * | Jeff_S happy either way 00:26:30 < dgilmore> | otherwise im good with it 00:26:33 < knurd> | dgilmore, can you work out the wording? 00:26:34 < stahnma> | me too 00:26:43 < knurd> | dgilmore, then we'll ACk it next week 00:27:07 < dgilmore> | knurd: sure 00:27:12 < knurd> | dgilmore, tia 00:27:19 --- | knurd has changed the topic to: EPEL Meeting ? EPEL announcement -- everything ready? ? quaid, all 00:27:23 < knurd> | we discussed this already 00:27:28 < knurd> | did we miss anything? 00:27:48 < stahnma> | do we want some blogs/articles on it? 00:27:55 < knurd> | stahnma, good idea 00:28:05 < stahnma> | I can write up something on opensource.apress.com 00:28:20 < stahnma> | and maybe try to get something into newsforge, if I have time 00:28:31 < knurd> | stahnma, would be great 00:28:41 < knurd> | I'll try to blog about it as well 00:28:58 * | knurd moves on 00:29:02 --- | knurd has changed the topic to: EPEL Meeting ? new meeting time? ? all (see also 00:29:03 < knurd> | http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) 00:29:29 < knurd> | dgilmore, your times are still missing 00:30:11 < knurd> | stahnma, yours as well afaics 00:30:14 < dgilmore> | knurd: i have not had time to look at it. 00:30:21 < quaid> | huh, weird 00:30:25 < quaid> | how did I get up there? 00:30:30 < quaid> | must be the old numbers :) 00:30:42 < knurd> | quaid, check the history; no idea... 00:30:43 * | quaid thinks they are still good 00:30:44 < Jeff_S> | quaid: I think you edited the page I created and I moved your times over 00:30:47 * | stahnma doesn't really care for any of the times....I'm at my dayjob during the entire open schedule 00:30:50 < quaid> | ok, yeah 00:30:52 < Jeff_S> | but I don't remember :) 00:31:27 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:31:30 < knurd> | anything else? 00:31:35 * | mmcgrath has nothing. 00:31:54 < marek> | I want to ask, what do you think about security response team for EPEL? 00:32:13 < Jeff_S> | any thoughts about those yum-related packages I posted? It'd be nice to get those taken care of for EPEL-4 00:32:15 < dgilmore> | marek: its needed you volunteering? 00:32:30 < knurd> | marek, I'm all for having one, but such issues should be discussed on the list IMHO 00:32:36 < quaid> | yep 00:32:37 < marek> | dgilmore: not yet, just an idea. I want to know what do you think about it 00:32:44 < knurd> | marek, that's for the initial discussion a lot easier than here in the meeting 00:32:48 < quaid> | we should be coordinate with the main Fedora SRT 00:32:48 <-- | k0k has quit (No route to host) 00:32:49 < dgilmore> | Jeff_S: we cant do yum for epel 00:32:50 < marek> | ok, I'll bring it to the list 00:32:58 < Jeff_S> | dgilmore: why not? 00:33:01 < knurd> | Jeff_S, I like the plan, but didn't look at the packages itself 00:33:06 < Jeff_S> | I thought we decided it was needed? 00:33:16 < dgilmore> | Jeff_S: because RHEL is not available in a way yum could use 00:33:40 < stahnma> | Jeff_S: I like what you did. It fixes the gap for people trying to use yum-utils or createrepo on RHEL 4 00:33:41 < dgilmore> | Jeff_S: so if you went to yum install a package from epel and needed RHEL deps your screwed 00:33:52 < stahnma> | ah 00:33:55 < knurd> | marek, many thx 00:34:10 < knurd> | dgilmore, yum is mainly needed for mock afaik 00:34:10 < quaid> | dgilmore: but ... wouldn't you just get a list of deps and could go up2date them? 00:34:21 < knurd> | or am I missing something here? 00:34:22 < dgilmore> | quaid: you could but thats ugly 00:34:32 < mmcgrath> | cobbler has yum deps (which was how we started talking about it) 00:34:32 < Jeff_S> | dgilmore: it is not there to become the system update tool for RHEL (although people could do that if they really wanted) -- but this will let people build things which rely on yum, yum-utils, etc. 00:34:39 < dgilmore> | up2date the package from epel direct 00:34:46 < quaid> | k 00:34:53 < mmcgrath> | hink in that case, yum will just have to be another tool on RHEL4, and not one they can update their system with. 00:34:57 < Jeff_S> | it's not providing any repo files 00:34:59 * | quaid didn't realize up2date in RHEL 4 supported yum repos 00:35:10 < stahnma> | it does....poorly 00:35:20 * | stahnma loves up2date (ducks) 00:35:28 < marek> | yes, but it isn't very good :/ 00:36:01 < dgilmore> | Jeff_S: i feel if its there people will expect it to work as an update tool 00:36:01 < knurd> | Jeff_S, why do we need yum? for mock? for something else? dgilmore's point is valid 00:36:29 < Jeff_S> | currently it was needed to have cobbler (which needs yum-utils, which needs yum) 00:36:44 < Jeff_S> | I think there were some other requests, but I don't recall off the top of my head 00:37:06 < knurd> | Jeff_S, i#d say wwe go without yum for now and look closer at the issues at hand later 00:37:23 < knurd> | even if that means to move mock into testing/4/ for now 00:37:29 < dgilmore> | Jeff_S: we need to be super careful here we need to use the a EVR lower version than CentOS 00:37:40 < stahnma> | I think Jeff_S did that 00:37:41 < mmcgrath> | perhaps we should document it very well in the yum config files. 00:37:51 < mmcgrath> | which, by default, would point to nothing (not even epel) 00:37:54 < Jeff_S> | dgilmore: yes, I did that 00:37:58 < dgilmore> | an d we need to make sure people understand they can not use itto keep there RHEL box up2date 00:38:04 < Jeff_S> | mmcgrath: yep, there is only yum.conf but it doesn't point to any repos 00:38:51 < mmcgrath> | I think thats reasonable. 00:38:55 < Jeff_S> | ok, maybe we need to discuss this more on the list? 00:38:58 --> | rdieter (Rex Dieter) has joined #fedora-meeting 00:39:00 < knurd> | Jeff_S, +1 00:39:16 < stahnma> | +1 00:39:23 < Jeff_S> | the thread was 'packages that conflict with centos?' -- and everyone that responded was positive about including them... 00:40:19 < knurd> | Jeff_S, that afaics seems to become more and more a problem 00:40:24 < knurd> | we discuss stuff on the list 00:40:37 < knurd> | and then suddenly someone raises problems in hte meetings 00:40:45 < knurd> | and the whole discussion restarts 00:40:52 < dgilmore> | Jeff_S: we need tomake sure it does not touch CentOS setups in bad ways 00:40:52 < knurd> | that#s a bit annoying 00:41:08 < dgilmore> | Jeff_S: epel-release has an epel repo file 00:41:19 < mmcgrath> | knurd: I much prefer that to people not showing up to the meeting and commenting on the notes after the fact. 00:41:44 < quaid> | we have to recognize that sometimes people only pay attention when a meeting is happening 00:41:49 < stahnma> | specifically for Yum-based users in epel-release, this could be difficult 00:41:52 < quaid> | because of busyness .. "Wow, it's been a week?!?" 00:41:54 < Jeff_S> | dgilmore: agreed... They all have a lower release number than the centos versions, so a centos-4 machine should never install them in the first place 00:41:56 < knurd> | mmcgrath, maybe, but raising stuff directly when it gets discussed it teven better 00:42:16 < quaid> | knurd: so maybe if someone comes in late, we can quickly decide if the conversation needs to continue ... 00:42:40 < quaid> | knurd: OT -- what do you think about the idea that nothing can leave a list for a vote in a meeting until there is a consensus to vote? 00:42:45 < stahnma> | if they have epel-release isntalled and then install yum, will yum on RHEL try to be an update tool? 00:42:46 < quaid> | is that too much bureaucracy? :) 00:43:21 < knurd> | quaid, liekly :-/ 00:43:24 < Jeff_S> | stahnma: if someone tries to use it as such, yes 00:43:41 < knurd> | quaid, but the idea has some appeal nevertheless 00:43:49 < quaid> | knurd: then we are always going to have that situation ... 00:43:55 < quaid> | maybe a guideline rather than a rule 00:44:04 < knurd> | quaid, the problem at hand would not be solved 00:44:07 < quaid> | but it could be good across _all_ projects/sigs 00:44:08 < dgilmore> | Jeff_S: my main concern is that people dont try use it on RHEL it just wont work there 00:44:09 < quaid> | true 00:44:13 * | quaid did note it was OT:) 00:44:24 < dgilmore> | Jeff_S: we could probably not put a yum.conf in at all 00:44:24 < knurd> | someone that did not take part in the discussion could step up in the meeting and say "hell, no" 00:44:39 < stahnma> | dgilmore: perhaps we should test that 00:44:43 < stahnma> | that might work 00:45:37 < knurd> | anyway, any more stuff to discuss? 00:45:42 < knurd> | or shall I close the meeting? 00:45:47 * | dgilmore needs to go to the colo 00:45:52 < dgilmore> | please clos e 00:46:00 < stahnma> | thanks all 00:46:03 * | knurd will close the meeting in 30 00:46:08 <-- | stahnma has left #fedora-meeting ( "Time for something else....") 00:46:26 * | knurd will close the meeting in 15 00:46:41 < knurd> | -- MARK -- Meeting end From mailing-lists at hughesjr.com Thu Jul 26 13:49:05 2007 From: mailing-lists at hughesjr.com (Johnny Hughes) Date: Thu, 26 Jul 2007 08:49:05 -0500 Subject: packages that conflict with centos? In-Reply-To: <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> Message-ID: <46A8A651.1060101@hughesjr.com> Jeff Sheltren wrote: > On Jul 8, 2007, at 9:23 AM, Thorsten Leemhuis wrote: > >> On 07.07.2007 16:32, Manuel Wolfshant wrote: >>> I for one am 100% in favor of including them in EPEL. At least because >>> RH5 uses yum. > >> +1 (except centos-yumconf of course) > >> But we should not create trouble for CentOS, so I'm in favor of this, >> what was said somewhere else in this thread: > >> On 07.07.2007 22:58, Steven Pritchard wrote: >>> On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote: >>>> But then EPEL conflicts with Centos. >>> Why not just track their package with a lower Release? > >> CU >> thl > > > I have rebuilt the following packages by using those included in CentOS > 4.5 and prepending a '0' to the release tag (and in some cases, adding a > dist tag): > createrepo > python-elementtree > python-sqlite > python-urlgrabber > sqlite > yum > > For the yum package I also made a change to the yum.conf file which gets > installed so that it looks at redhat-release instead of centos-release. > CentOS users should not be installing these packages due to the lower > release number, so this should work nicely to allow RHEL 4 users to > install yum if needed. > > I've put all the SRPMs here: http://www.sheltren.com/epel/packages/ > The sha1sums can be found in sha1sums.txt signed with my gpg key. > > If these packages look good to everyone, I'm willing to coordinate with > the Fedora maintainers to get these into EPEL. If the maintainers don't > want to maintain the package in EPEL, I am willing to co-maintain them > in EPEL (or have someone else do it if anyone's interested). > > Thoughts, questions, comments? > > -Jeff I would like to take the opportunity to publicly thank Jeff and Mike McGrath for discussing this issue with the CentOS developers. The CentOS devels think that this is a great solution to the problem. Since I have complained loudly on this list for the lack of collaboration in the past, I figured I should also praise a good effort too. Thanks, Johnny Hughes CentOS Developer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From buildsys at fedoraproject.org Thu Jul 26 14:43:51 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 26 Jul 2007 10:43:51 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-26 Message-ID: <20070726144351.122AC152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 3 bzr-0.18-1.el5 NEW bzr-gtk-0.18.0-1.el5 : Bazaar plugin for GTK+ interfaces to most Bazaar operations NEW lighttpd-1.4.16-1.el5 : Lightning fast webserver with light system requirements Changes in Fedora EPEL 5: bzr-0.18-1.el5 -------------- * Wed Jul 25 2007 Warren Togami - 0.18-1 - Update to 0.18. * Tue Jun 26 2007 Warren Togami - 0.17-2 - Update to 0.17. * Tue May 08 2007 Toshio Kuratomi - 0.16-1 - Update to 0.16. bzr-gtk-0.18.0-1.el5 -------------------- * Wed Jul 25 2007 Warren Togami 0.18.0-1 - Update to 0.18.0. * Thu Jun 28 2007 Warren Togami 0.17.0-1 - Update to 0.17.0. lighttpd-1.4.16-1.el5 --------------------- * Thu Jul 26 2007 Matthias Saou 1.4.16-1 - Update to 1.4.16 security fix release. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Thu Jul 26 16:59:43 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 26 Jul 2007 12:59:43 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-26 Message-ID: <20070726165943.7EC08152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 0 Packages built and released for Fedora EPEL 4: 0 Changes in Fedora EPEL 5: Changes in Fedora EPEL 4: For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Thu Jul 26 17:14:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Jul 2007 19:14:37 +0200 Subject: fuse, ntfs-config und ntfs-3g removed (was: Re: Fedora EPEL Package Build Report 2007-07-25) In-Reply-To: <46A773F7.20706@fedoraproject.org> References: <20070725151123.8FF56152131@buildsys.fedoraproject.org> <46A773F7.20706@fedoraproject.org> Message-ID: <46A8D67D.50402@leemhuis.info> On 25.07.2007 18:01, Rahul Sundaram wrote: > buildsys at fedoraproject.org wrote: >> Packages built and released for Fedora EPEL 5: 18 >> >> NEW fuse-2.7.0-3.el5 : File System in Userspace (FUSE) utilities > > Note that RHEL 5 kernel does not have FUSE enabled. I believe CentOS > does offer a alternative kernel so it might be useful there. > >> NEW fuse-2.7.0-3.el4 : File System in Userspace (FUSE) utilities > > FUSE won't work in RHEL 4 at all since the kernel is older. I removed fuse, ntfs-config and ntfs-3g for now from the repos to have a clean sane repo (e.g. without broken deps) for the EPEL announcement until this problem is being evaluated further. Maintainers CCed, to make sure they are aware of it. CU thl From buildsys at fedoraproject.org Thu Jul 26 17:16:03 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 26 Jul 2007 13:16:03 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-26 Message-ID: <20070726171603.81B79152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 0 Packages built and released for Fedora EPEL 4: 0 Changes in Fedora EPEL 5: Changes in Fedora EPEL 4: For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Thu Jul 26 17:27:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 26 Jul 2007 19:27:23 +0200 Subject: main repos should now be sane Message-ID: <46A8D97B.6090408@leemhuis.info> Hi all! I did some moving and cleanups in the master repos. There *shouldn't* be any major broken deps or broken packages anymore (I hope -- I only tested with repoclosure against CentOS now; we'll soon make another run against RHEL; if that turns up anything I'll move it tomorrow in the morning). Most stuff got moved to testing -- you can find a list below. Note that we should aim to clean those deps up there soon as well, because a testing/ repo with lots of broken deps doesn't make much sense IMHO. CU knurd (soon afk for today -- sorry) ---- SRPMS moved to EPEL5 testing: bcfg2 bugzilla evolution-bogofilter JSDoc limph nikto perl-libwhisker2 perl-Net-Pcap perl-Test-Base php-pear-File-SMBPasswd python-Coherence qucs translate-toolkit zabbix ---- SRPMS moved to EPEL4 testing: bcfg2 bugzilla cobbler JSDoc limph mimedefang mock nikto perl-libwhisker2 postgresql-dbi-link postgresql-pgpoolAdmin python-Coherence qucs SDL_mixer specto sqlgrey zabbix From jwilson at redhat.com Thu Jul 26 17:56:38 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 26 Jul 2007 13:56:38 -0400 Subject: main repos should now be sane In-Reply-To: <46A8D97B.6090408@leemhuis.info> References: <46A8D97B.6090408@leemhuis.info> Message-ID: <46A8E056.508@redhat.com> Thorsten Leemhuis wrote: > Hi all! > > I did some moving and cleanups in the master repos. There *shouldn't* be > any major broken deps or broken packages anymore (I hope -- I only > tested with repoclosure against CentOS now; we'll soon make another run > against RHEL; if that turns up anything I'll move it tomorrow in the > morning). Most stuff got moved to testing -- you can find a list below. > > Note that we should aim to clean those deps up there soon as well, > because a testing/ repo with lots of broken deps doesn't make much sense > IMHO. > > CU > knurd (soon afk for today -- sorry) > > ---- SRPMS moved to EPEL5 testing: [...] > zabbix > > > ---- SRPMS moved to EPEL4 testing: [...] > zabbix *grumble* still haven't heard back from the fedora fping maintainer, so I guess I get to maintain fping for epel... -- Jarod Wilson jwilson at redhat.com From kwade at redhat.com Thu Jul 26 18:22:52 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 26 Jul 2007 11:22:52 -0700 Subject: final announcement for last check Message-ID: <1185474173.17380.864.camel@erato.phig.org> If you use enterprise-class Linux (EL) distributions derived from Fedora, such as Red Hat Enterprise Linux or CentOS, we have something very exciting for you. Ever find yourself rebuilding one of the high-quality Fedora packages for your EL version because it didn't ship with the EL distro? Friends, there is a new way. May we introduce ... Extra Packages for Enterprise Linux (EPEL) EPEL is a community of package maintainers working from inside of Fedora. Many are the same people who maintain the Fedora package. Yet, there is plenty of room for new packages and contributors. http://fedoraproject.org/wiki/EPEL How to use EPEL: http://fedoraproject.org/wiki/EPEL/FAQ#howtouse You can look for packages here: http://fedoraproject.org/wiki/EPEL/FAQ#WhereIsTheSoftwareRepositoryLocated Looking for a package not in EPEL or other questions? http://fedoraproject.org/wiki/EPEL/FAQ ## 30 ## -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Thu Jul 26 18:38:30 2007 From: kwade at redhat.com (Karsten Wade) Date: Thu, 26 Jul 2007 11:38:30 -0700 Subject: final announcement for last check (updated from IRC feedback) Message-ID: <1185475110.17380.868.camel@erato.phig.org> If you use enterprise-class Linux (EL) distributions derived from Fedora, such as Red Hat Enterprise Linux or CentOS, we have something very exciting for you. Ever find yourself rebuilding one of the high-quality Fedora packages for your EL version because it didn't ship with the EL distro? Friends, there is a new way. May we introduce ... Extra Packages for Enterprise Linux (EPEL) EPEL is a community of package maintainers working from inside of Fedora. Many are the same people who maintain the Fedora package. Yet, there is plenty of room for new packages and contributors. Currently, around 1000 packages are available, and we've been growing at the rate of several dozen packages every week. http://fedoraproject.org/wiki/EPEL How to use EPEL: http://fedoraproject.org/wiki/EPEL/FAQ#howtouse You can look for packages here: http://fedoraproject.org/wiki/EPEL/FAQ#WhereIsTheSoftwareRepositoryLocated Looking for a package not in EPEL or other questions? http://fedoraproject.org/wiki/EPEL/FAQ ## 30 ## -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwilson at redhat.com Thu Jul 26 19:03:49 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 26 Jul 2007 15:03:49 -0400 Subject: EPEL 4 and 5 branches for fping Message-ID: <46A8F015.5050400@redhat.com> I've got a package (zabbix) in EPEL4 and 5 that has an unsatisfied dependency on fping. I've pinged Chris about it, but haven't heard back, and he's listed in the wiki as "unknown" whether he wants to have anything to do with EPEL or not, so I'm assuming he's not particularly interested, in which case I'd like to have fping branched for EPEL4 and 5, and I'll maintain it. Thank you, -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Fri Jul 27 04:55:09 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 27 Jul 2007 00:55:09 -0400 Subject: EPEL 4 and 5 branches for fping In-Reply-To: <46A8F015.5050400@redhat.com> References: <46A8F015.5050400@redhat.com> Message-ID: <46A97AAD.9010701@redhat.com> Jarod Wilson wrote: > I've got a package (zabbix) in EPEL4 and 5 that has an unsatisfied > dependency on fping. I've pinged Chris about it, but haven't heard back, > and he's listed in the wiki as "unknown" whether he wants to have > anything to do with EPEL or not, so I'm assuming he's not particularly > interested, in which case I'd like to have fping branched for EPEL4 and > 5, and I'll maintain it. Okay, so I actually read the wiki pages, and opened a bug, put in the proper branch request stuff, etc. Only now that I think about it, I forgot to include in the request that I should be the EPEL maintainer. D'oh. Guess I'd better go fix that now, and everyone can just continue to ignore my emails... :) -- Jarod Wilson jwilson at redhat.com From kwade at redhat.com Fri Jul 27 07:53:13 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 27 Jul 2007 00:53:13 -0700 Subject: Extra Packages for Enterprise Linux (EPEL) Now Open Message-ID: <1185522793.17380.994.camel@erato.phig.org> If you use enterprise-class Linux (EL) distributions derived from Fedora, such as Red Hat Enterprise Linux or CentOS, we have something very exciting for you. Ever find yourself rebuilding one of the high-quality Fedora packages for your EL version because it didn't ship with the EL distro? Friends, there is a new way. May we introduce ... Extra Packages for Enterprise Linux (EPEL) EPEL is a community of package maintainers working from inside of Fedora. Many are the same people who maintain the Fedora version. Yet, there room for new packages and contributors. Currently, around 1000 packages are available, and we've been growing at the rate of several dozen packages every week. http://fedoraproject.org/wiki/EPEL How to use EPEL: http://fedoraproject.org/wiki/EPEL/FAQ#howtouse You can look for packages here: http://fedoraproject.org/wiki/EPEL/FAQ#WhereIsTheSoftwareRepositoryLocated Looking for a package not in EPEL or other questions? http://fedoraproject.org/wiki/EPEL/FAQ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dag at wieers.com Fri Jul 27 08:59:59 2007 From: dag at wieers.com (Dag Wieers) Date: Fri, 27 Jul 2007 10:59:59 +0200 (CEST) Subject: Extra Packages for Enterprise Linux (EPEL) Now Open In-Reply-To: <1185522793.17380.994.camel@erato.phig.org> References: <1185522793.17380.994.camel@erato.phig.org> Message-ID: On Fri, 27 Jul 2007, Karsten Wade wrote: > If you use enterprise-class Linux (EL) distributions derived from > Fedora, such as Red Hat Enterprise Linux or CentOS, we have something > very exciting for you. > > Ever find yourself rebuilding one of the high-quality Fedora packages > for your EL version because it didn't ship with the EL distro? > > Friends, there is a new way. May we introduce ... > > Extra Packages for Enterprise Linux (EPEL) > > EPEL is a community of package maintainers working from inside of > Fedora. Many are the same people who maintain the Fedora version. Yet, > there room for new packages and contributors. Currently, around 1000 > packages are available, and we've been growing at the rate of several > dozen packages every week. > > http://fedoraproject.org/wiki/EPEL > > How to use EPEL: > > http://fedoraproject.org/wiki/EPEL/FAQ#howtouse > > You can look for packages here: > > http://fedoraproject.org/wiki/EPEL/FAQ#WhereIsTheSoftwareRepositoryLocated > > Looking for a package not in EPEL or other questions? > > http://fedoraproject.org/wiki/EPEL/FAQ Could the FAQ specifically state that EPEL is not compatible with 3rd party repositories like RPMforge, ATrpms or CentOS Extras ? -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From fedora at leemhuis.info Fri Jul 27 10:12:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 27 Jul 2007 12:12:46 +0200 Subject: Extra Packages for Enterprise Linux (EPEL) Now Open In-Reply-To: References: <1185522793.17380.994.camel@erato.phig.org> Message-ID: <46A9C51E.8060101@leemhuis.info> On 27.07.2007 10:59, Dag Wieers wrote: > On Fri, 27 Jul 2007, Karsten Wade wrote: >> If you use enterprise-class Linux (EL) distributions derived from >> Fedora, such as Red Hat Enterprise Linux or CentOS, we have something >> very exciting for you. > [...] >> Looking for a package not in EPEL or other questions? >> >> http://fedoraproject.org/wiki/EPEL/FAQ > > Could the FAQ specifically state that EPEL is not compatible with 3rd > party repositories like RPMforge, ATrpms or CentOS Extras ? In general: sure. But I don't want to name other repositories, because that might be problematic from a legal standpoint for the Fedora Project (just being careful here, not sure if I'm overreacting). So I just added this to the FAQ: ---- Compatibility with other repositories Mixing different RPM-Repositories that were not designed to be mixed can lead to incompatibilities that often result in depsoving problems in yum or up2date; sometimes it even happens that software is not working as expected if libraries and applications come from different repositories. EPEL is designed as add-on repository for RHEL and compatible derivates and not to be mixed with other repos -- thus not mixing EPEL with other repositories on the same system is the best way to avoid mixing problems. Some people nevertheless do it -- the yum priorities plugin can help to avoid the worst problems. If you encounter a problem where packages from EPEL are incompatible with another repository or lead yum or up2date to boil out during depsolving please report a bug to Bugzilla; contact the maintainer of the other repository as well. The EPEL project encourages its maintainers to solve such problems together with the maintainers from other repository's, to find a solution that is acceptable for both sides. But there is no guarantee such a solution can or will be found in every case, as technical solutions to solve a repository-mixing issue might have side-effects or drawbacks for one of the repositories involved, which it thus might not be willing to realize. ---- http://fedoraproject.org/wiki/EPEL/FAQ#head-b631b303a0b54605688fd911f0f3dfc90676b5a0 CU thl From mmcgrath at redhat.com Fri Jul 27 13:28:19 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 27 Jul 2007 08:28:19 -0500 Subject: Extra Packages for Enterprise Linux (EPEL) Now Open In-Reply-To: <46A9C51E.8060101@leemhuis.info> References: <1185522793.17380.994.camel@erato.phig.org> <46A9C51E.8060101@leemhuis.info> Message-ID: <46A9F2F3.8070807@redhat.com> Thorsten Leemhuis wrote: > > In general: sure. But I don't want to name other repositories, because > that might be problematic from a legal standpoint for the Fedora Project > (just being careful here, not sure if I'm overreacting). So I just added > this to the FAQ: > ---- > > http://fedoraproject.org/wiki/EPEL/FAQ#head-b631b303a0b54605688fd911f0f3dfc90676b5a0 > I think this is good, There are tons of places to get 3rd party RPMs out there. ATrpms, dribble, freshRPMS, jpackage, Livna, RPMForge, PlanetCCRMA all come up in a google search. We certainly aren't asking any of them to mention which repos they are incompatible with and I highly doubt all of them are completely compatible with eachother*. -Mike *I have not tried putting all of those repos together on one machine to see that they are all compatible.... I know better :) From mdehaan at redhat.com Fri Jul 27 15:48:59 2007 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 27 Jul 2007 11:48:59 -0400 Subject: packages that conflict with centos? In-Reply-To: <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> References: <20070707140041.GF3144@free.fr> <468FA3E4.7080204@nobugconsulting.ro> <4690E568.50006@leemhuis.info> <1C7EA4D2-9237-4E18-8B72-0790FAEB2B22@cs.ucsb.edu> Message-ID: <46AA13EB.6050609@redhat.com> Jeff Sheltren wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Jul 8, 2007, at 9:23 AM, Thorsten Leemhuis wrote: >> >> On 07.07.2007 16:32, Manuel Wolfshant wrote: >>> I for one am 100% in favor of including them in EPEL. At least because >>> RH5 uses yum. >> >> +1 (except centos-yumconf of course) >> >> But we should not create trouble for CentOS, so I'm in favor of this, >> what was said somewhere else in this thread: >> >> On 07.07.2007 22:58, Steven Pritchard wrote: >>> On Sat, Jul 07, 2007 at 10:47:25PM +0200, Patrice Dumas wrote: >>>> But then EPEL conflicts with Centos. >>> Why not just track their package with a lower Release? >> >> CU >> thl >> > > I have rebuilt the following packages by using those included in > CentOS 4.5 and prepending a '0' to the release tag (and in some cases, > adding a dist tag): > createrepo > python-elementtree > python-sqlite > python-urlgrabber > sqlite > yum > > For the yum package I also made a change to the yum.conf file which > gets installed so that it looks at redhat-release instead of > centos-release. CentOS users should not be installing these packages > due to the lower release number, so this should work nicely to allow > RHEL 4 users to install yum if needed. > > I've put all the SRPMs here: http://www.sheltren.com/epel/packages/ > The sha1sums can be found in sha1sums.txt signed with my gpg key. > > If these packages look good to everyone, I'm willing to coordinate > with the Fedora maintainers to get these into EPEL. If the maintainers > don't want to maintain the package in EPEL, I am willing to > co-maintain them in EPEL (or have someone else do it if anyone's > interested). > > Thoughts, questions, comments? > > - -Jeff > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (Darwin) > > iD8DBQFGpzqJKe7MLJjUbNMRAsm4AJ915q/4ysjAVtWLK7QHipnxBGSRUgCgoPCe > q0s2lZ8YsdXykfB5ngAhY1I= > =OB3h > -----END PGP SIGNATURE----- > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list I haven't looked at these packages yet, but I'm really glad to see this work being done. I mentioned this on #epel a few days ago -- lots of folks will be looking for yum to be there. The selfish reason for me to want it is that Cobbler (http://cobbler.et.redhat.com) uses it for repository management and is otherwise broken in EPEL (http://cobbler.et.redhat.com) -- the not so selfish reason is tons of RHEL4 users are already using yum for various things (including maintaining their own repositories of lots of stuff, including, sometimes, updates) and it would be nice if they could get their yum from EPEL and use yum with EPEL if they wanted. Thanks! --Michael DeHaan From Matt_Domsch at Dell.com Mon Jul 30 14:58:32 2007 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Mon, 30 Jul 2007 09:58:32 -0500 Subject: epel-testing can use mirrorlists now Message-ID: The epel-testing.repo files don't use mirrorlist, so they won't get bit right now. But, what strings should we use? How about: repo=testing-epel$releasever&arch=$basearch repo=testing-debug-epel$releasever&arch=$basearch repo=testing-source-epel$releasever&arch=$basearch This is what I've enabled in mirrormanager now. Michael, can you update the epel-testing.repo file to use mirrorlists? Thanks, Matt From mmahut at fedoraproject.org Mon Jul 30 15:48:11 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Mon, 30 Jul 2007 17:48:11 +0200 Subject: rt3 requirements In-Reply-To: <46A5E13F.3040401@fedoraproject.org> References: <1184906421.17393.26.camel@shrek.rexursive.com> <46A5E13F.3040401@fedoraproject.org> Message-ID: <46AE083B.3020406@fedoraproject.org> Hello Everyone, I created a page on wiki to track all dependencies for RequestTracker 3 package. Please, feel free to update it, I'll continue with that page later today. [1] http://fedoraproject.org/wiki/EPEL/WishList/rt3 Marek Mahut wrote: > Hello Bojan, > > Bojan Smojver wrote: >> Just a heads-up for anyone wanting to bring rt3 into EPEL 5, attached >> are the Perl packages I had to pinch from Fedora development in order to >> build/install RT. > > I'm interested to have RequestTracker in EPEL, as we are using it in my > company. Are you working on the port to EPEL? > >> No intervention on any of them was needed - they build and install just >> fine on EL5. -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From fedora at leemhuis.info Mon Jul 30 17:11:15 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 30 Jul 2007 19:11:15 +0200 Subject: EPEL report week 30 2007 Message-ID: <46AE1BB3.7010908@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week30 = Weekly EPEL Summary = Week 30/2007 == Most important happenings == * It's party time -- EPEL was announced! https://www.redhat.com/archives/epel-devel-list/2007-July/msg00237.html == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * Jeff_S (Jeff Sheltren) (had to leave after half the meeting) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * quaid (KarstenWade) * stahnma (MichaelStahnke) Missing from the Steering Committee: * nirik (KevinFenzi) (vacation) Others that participated the meeting: marek === Summary === * broken deps -- all * move them to testing (happened in between) to have a clean proper repo for announcement * when to run the spam o magic script -- mmcgrath * not that easy to let it run asynchronously after a push; we'll stick to the weekly run * branch for EPEL if Fedora maintainer does not react -- knurd * dglimore issued concerns about https://www.redhat.com/archives/epel-devel-list/2007-July/msg00104.html ; he'll write something up and post it to the list * Free discussion around EPEL * some discussion about yum in EPEL4; continue on the list === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-July/msg00225.html == Stats == === General === Number of EPEL Contributors 124 We welcome 12 new contributors: andreas_AT_bawue.net, andy_AT_smile.org.ua, bugs.michael_AT_gmx.net, cbalint_AT_redhat.com, cgoorah_AT_yahoo.com.au, dmitry_AT_butskoy.name, ivazqueznet_AT_gmail.com, kaboom_AT_oobleck.net, lemenkov_AT_gmail.com, matt_AT_truch.net, neslami_AT_redhat.com, rvinyard_AT_cs.nmsu.edu === EPEL 5 === Number of source packages: 483 Number of binary packages: 872 There are 30 new Packages: * drupal | An open-source content-management platform * GeoIP | C library for country/city/organization to IP address or hostname mapping * libmcrypt | Encryption algorithms library * librx | POSIX regexp functions * lighttpd | Lightning fast webserver with light system requirements * logjam | GTK2 client for LiveJournal * lout | A document formatting system * mcrypt | Replacement for crypt() * memcached | High Performance, Distributed Memory Object Cache * mhash | Thread-safe hash algorithms library * mod_geoip | GeoIP module for the Apache HTTP Server * perl-File-MMagic | A Perl module emulating the file(1) command * perl-File-MMagic-XS | Guess file type with XS * perl-Geography-Countries | 2-letter, 3-letter, and numerical codes for countries * perl-Mail-IMAPClient | An IMAP Client API * perl-Net-Domain-TLD | Work with TLD names * perl-Object-Realize-Later | Delayed creation of objects * perl-Parse-RecDescent | Parse-RecDescent Perl module * perl-Pod-POM | Object-oriented interface to Perl POD documents * perl-Taint-Runtime | Runtime enable taint checking * perl-User-Identity | Maintains info about a physical person * phpMyAdmin | Web based MySQL browser written in php * python-GeoIP | Python bindings for the GeoIP geographical lookup libraries * python-imaging | Python's own image processing library * qfaxreader | A multipage monochrome/color TIFF/FAX viewer * qstat | Real-time Game Server Status for FPS game servers * QuantLib | A software framework for quantitative finance * sipp | SIP test tool / traffic generator * sipsak | SIP swiss army knife * smolt | Fedora hardware profiler === EPEL 4 === Number of source packages: 295 Number of binary packages: 596 There are 31 new Packages: * drupal | An open-source content-management platform * GeoIP | C library for country/city/organization to IP address or hostname mapping * graphviz | Graph Visualization Tools * libmcrypt | Encryption algorithms library * librx | POSIX regexp functions * logjam | GTK2 client for LiveJournal * lout | A document formatting system * mcrypt | Replacement for crypt() * mhash | Thread-safe hash algorithms library * mod_geoip | GeoIP module for the Apache HTTP Server * perl-Date-Pcalc | Gregorian calendar date calculations * perl-File-MMagic | A Perl module emulating the file(1) command * perl-File-MMagic-XS | Guess file type with XS * perl-Geography-Countries | 2-letter, 3-letter, and numerical codes for countries * perl-Mail-IMAPClient | An IMAP Client API * perl-MIME-Lite | MIME::Lite - low-calorie MIME generator * perl-MIME-tools | Modules for parsing and creating MIME entities in Perl * perl-Net-Domain-TLD | Work with TLD names * perl-Object-Realize-Later | Delayed creation of objects * perl-Parse-RecDescent | Parse-RecDescent Perl module * perl-Pod-POM | Object-oriented interface to Perl POD documents * perl-Taint-Runtime | Runtime enable taint checking * perl-TimeDate | A Perl module for time and date manipulation * perl-User-Identity | Maintains info about a physical person * phpMyAdmin | Web based MySQL browser written in php * python-cheetah | Template engine and code-generator * python-GeoIP | Python bindings for the GeoIP geographical lookup libraries * qfaxreader | A multipage monochrome/color TIFF/FAX viewer * qstat | Real-time Game Server Status for FPS game servers * sipp | SIP test tool / traffic generator * sipsak | SIP swiss army knife ---- ["CategoryEPELReports"] From sheltren at cs.ucsb.edu Mon Jul 30 17:40:18 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 30 Jul 2007 10:40:18 -0700 Subject: EPEL report week 30 2007 In-Reply-To: <46AE1BB3.7010908@leemhuis.info> References: <46AE1BB3.7010908@leemhuis.info> Message-ID: <321DFBE1-6975-45F8-8150-AD222D378ED3@cs.ucsb.edu> On Jul 30, 2007, at 10:11 AM, Thorsten Leemhuis wrote: > > === Attending === > > * Jeff_S (Jeff Sheltren) (had to leave after half the meeting) > Hi Thorsten, I was there the whole time :) Sorry, but I won' be able to make it this week since I'll be traveling on Wednesday. -Jeff From orion at cora.nwra.com Mon Jul 30 19:37:08 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 30 Jul 2007 13:37:08 -0600 Subject: Need package remove from repo Message-ID: <46AE3DE4.4030304@cora.nwra.com> I need perl-XML-DOM-0-1.44-2.el4 removed from the EPEL repository - it should not have been released as it replaces and existing EL-4 package. I emailed rel-eng but got no response. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From fedora at leemhuis.info Mon Jul 30 20:40:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 30 Jul 2007 22:40:45 +0200 Subject: EPEL report week 30 2007 In-Reply-To: <321DFBE1-6975-45F8-8150-AD222D378ED3@cs.ucsb.edu> References: <46AE1BB3.7010908@leemhuis.info> <321DFBE1-6975-45F8-8150-AD222D378ED3@cs.ucsb.edu> Message-ID: <46AE4CCD.6080402@leemhuis.info> On 30.07.2007 19:40, Jeff Sheltren wrote: > On Jul 30, 2007, at 10:11 AM, Thorsten Leemhuis wrote: >> === Attending === >> >> * Jeff_S (Jeff Sheltren) (had to leave after half the meeting) >> > > Hi Thorsten, I was there the whole time :) > > Sorry, but I won' be able to make it this week since I'll be > traveling on Wednesday. Sorry, cut'n'paste error (I used a old report as a base and failed to adjust this part). I'll fix it in the wiki. CU knurd From mmahut at fedoraproject.org Mon Jul 30 20:47:40 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Mon, 30 Jul 2007 22:47:40 +0200 Subject: EPEL report week 30 2007 In-Reply-To: <46AE1BB3.7010908@leemhuis.info> References: <46AE1BB3.7010908@leemhuis.info> Message-ID: <46AE4E6C.2080901@fedoraproject.org> Thorsten Leemhuis wrote: > === EPEL 5 === > > Number of source packages: 483 > > Number of binary packages: 872 > > There are 30 new Packages: > > * drupal | An open-source content-management platform > * GeoIP | C library for country/city/organization to IP address or > hostname mapping > * libmcrypt | Encryption algorithms library > * librx | POSIX regexp functions > * lighttpd | Lightning fast webserver with light system requirements > * logjam | GTK2 client for LiveJournal > * lout | A document formatting system > * mcrypt | Replacement for crypt() > * memcached | High Performance, Distributed Memory Object Cache > * mhash | Thread-safe hash algorithms library > * mod_geoip | GeoIP module for the Apache HTTP Server > * perl-File-MMagic | A Perl module emulating the file(1) command > * perl-File-MMagic-XS | Guess file type with XS > * perl-Geography-Countries | 2-letter, 3-letter, and numerical codes > for countries > * perl-Mail-IMAPClient | An IMAP Client API > * perl-Net-Domain-TLD | Work with TLD names > * perl-Object-Realize-Later | Delayed creation of objects > * perl-Parse-RecDescent | Parse-RecDescent Perl module > * perl-Pod-POM | Object-oriented interface to Perl POD documents > * perl-Taint-Runtime | Runtime enable taint checking > * perl-User-Identity | Maintains info about a physical person > * phpMyAdmin | Web based MySQL browser written in php > * python-GeoIP | Python bindings for the GeoIP geographical lookup > libraries > * python-imaging | Python's own image processing library > * qfaxreader | A multipage monochrome/color TIFF/FAX viewer > * qstat | Real-time Game Server Status for FPS game servers > * QuantLib | A software framework for quantitative finance > * sipp | SIP test tool / traffic generator > * sipsak | SIP swiss army knife > * smolt | Fedora hardware profiler > > === EPEL 4 === > > Number of source packages: 295 > > Number of binary packages: 596 > > There are 31 new Packages: > > * drupal | An open-source content-management platform > * GeoIP | C library for country/city/organization to IP address or > hostname mapping > * graphviz | Graph Visualization Tools > * libmcrypt | Encryption algorithms library > * librx | POSIX regexp functions > * logjam | GTK2 client for LiveJournal > * lout | A document formatting system > * mcrypt | Replacement for crypt() > * mhash | Thread-safe hash algorithms library > * mod_geoip | GeoIP module for the Apache HTTP Server > * perl-Date-Pcalc | Gregorian calendar date calculations > * perl-File-MMagic | A Perl module emulating the file(1) command > * perl-File-MMagic-XS | Guess file type with XS > * perl-Geography-Countries | 2-letter, 3-letter, and numerical codes > for countries > * perl-Mail-IMAPClient | An IMAP Client API > * perl-MIME-Lite | MIME::Lite - low-calorie MIME generator > * perl-MIME-tools | Modules for parsing and creating MIME entities in Perl > * perl-Net-Domain-TLD | Work with TLD names > * perl-Object-Realize-Later | Delayed creation of objects > * perl-Parse-RecDescent | Parse-RecDescent Perl module > * perl-Pod-POM | Object-oriented interface to Perl POD documents > * perl-Taint-Runtime | Runtime enable taint checking > * perl-TimeDate | A Perl module for time and date manipulation > * perl-User-Identity | Maintains info about a physical person > * phpMyAdmin | Web based MySQL browser written in php > * python-cheetah | Template engine and code-generator > * python-GeoIP | Python bindings for the GeoIP geographical lookup > libraries > * qfaxreader | A multipage monochrome/color TIFF/FAX viewer > * qstat | Real-time Game Server Status for FPS game servers > * sipp | SIP test tool / traffic generator > * sipsak | SIP swiss army knife Hmm, where's irssi? I build it few days ago. -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From buildsys at fedoraproject.org Mon Jul 30 22:01:01 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 30 Jul 2007 18:01:01 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-30 Message-ID: <20070730220101.11CDF152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 36 NEW cairomm-1.2.4-1.el5 : Cairomm is the C++ API for the cairo graphics library NEW cfitsio-3.030-2.el5 : Library for manipulating FITS data files ctapi-cyberjack-3.0.3-1.el5 drupal-5.2-1.el5 eggdrop-1.6.18-9.el5 NEW fping-2.4b2-7.el5 : Scriptable, parallelized ping-like utility NEW freetds-0.64-6.el5 : Implementation of the TDS (Tabular DataStream) protocol glpk-4.20-1.el5 NEW gtkmm24-2.10.10-1.el5 : C++ interface for GTK2 (a GUI library for X) NEW irssi-0.8.10-6.a.el5 : Modular text mode IRC client with Perl scripting NEW iverilog-0.9.20070608-1.el5 : Icarus Verilog is a verilog compiler and simulator mksh-30-1.el5 NEW nail-12.3-1.el5 : Enhanced implementation of the mailx command NEW net6-1.3.5-1.el5 : A TCP protocol abstraction for library C++ NEW obby-0.4.4-1.el5 : A library which provides synced document buffers NEW octave-2.9.13-1.el5 : A high-level language for numerical computations NEW perl-AnyData-0.10-3.el5 : Easy access to data in many formats NEW perl-Apache-LogRegex-1.4-1.el5 : Parse a line from an Apache logfile into a hash NEW perl-Cache-Mmap-0.09-1.el5 : Shared data cache using memory mapped files NEW perl-Class-Accessor-0.31-1.el5 : Automated accessor generation NEW perl-Class-Data-Inheritable-0.06-1.el5.2 : Inheritable, overridable class data NEW perl-Clone-0.27-1.el5 : Recursively copy perl datatypes NEW perl-CPAN-DistnameInfo-0.06-2.el5 : CPAN::DistnameInfo Perl module NEW perl-MIME-Types-1.20-1.el5 : MIME types module for Perl NEW perl-Module-CoreList-2.11-1.el5 : Perl core modules indexed by perl versions perl-Taint-Runtime-0.03-1.el5.1 NEW perl-Test-Tester-0.104-1.el5 : Ease testing test modules built with Test::Builder NEW perl-UNIVERSAL-require-0.11-1.el5 : Require() modules from a variable NEW perl-XML-XPath-1.13-4.el5 : XPath parser and evaluator for Perl NEW suitesparse-3.0.0-1.el5 : A collection of sparse matrix libraries NEW timidity++-2.13.2-2 : A software wavetable MIDI synthesizer. NEW trac-bazaar-plugin-0.2-2.20070717bzr180.el5 : Bazaar plugin for Trac wine-0.9.42-1.el5 wine-docs-0.9.42-1.el5 NEW wxGTK-2.8.4-4.el5 : GTK2 port of the wxWidgets GUI library yumex-1.9.11-1.el5 Packages built and released for Fedora EPEL 4: 23 NEW cfitsio-3.006-3.el4 : Library for manipulating FITS data files ctapi-cyberjack-3.0.3-1.el4 drupal-5.2-1.el4 eggdrop-1.6.18-9.el4 NEW fping-2.4b2-7.el4 : Scriptable, parallelized ping-like utility NEW freetds-0.64-6.el4 : Implementation of the TDS (Tabular DataStream) protocol NEW irssi-0.8.9-6.el4 : Modular text mode IRC client with Perl scripting NEW iverilog-0.9.20070608-1.el4 : Icarus Verilog is a verilog compiler and simulator mksh-30-1.el4 NEW nail-12.0-2.el4 : Enhanced implementation of the mailx command NEW perl-AnyData-0.10-2.el4 : Easy access to data in many formats NEW perl-Apache-LogRegex-1.4-1.el4 : Parse a line from an Apache logfile into a hash NEW perl-Cache-Mmap-0.09-1.el4 : Shared data cache using memory mapped files NEW perl-Class-Accessor-0.31-1.el4 : Automated accessor generation NEW perl-Class-Data-Inheritable-0.06-1.el4.2 : Inheritable, overridable class data NEW perl-Clone-0.27-1.el4 : Recursively copy perl datatypes NEW perl-CPAN-DistnameInfo-0.06-1.el4 : CPAN::DistnameInfo Perl module perl-Taint-Runtime-0.03-1.el4.1 NEW perl-Test-Tester-0.104-1.el4 : Ease testing test modules built with Test::Builder NEW perl-UNIVERSAL-require-0.11-1.el4 : Require() modules from a variable NEW perl-XML-XPath-1.13-2 : XPath parser and evaluator for Perl NEW timidity++-2.13.2-2 : A software wavetable MIDI synthesizer. wine-0.9.42-1.el4 Changes in Fedora EPEL 5: cairomm-1.2.4-1.el5 ------------------- * Wed Jan 17 2007 Rick L Vinyard Jr - 1.2.4-1 - New release cfitsio-3.030-2.el5 ------------------- * Sat Feb 17 2007 Matthew Truch - 3.030-2 - Require pkgconfig for -devel. - export CC=gcc so we don't clobber $RPM_OPT_FLAGS, thereby ruining any -debuginfo packages. See RedHat Bugzilla 229041. ctapi-cyberjack-3.0.3-1.el5 --------------------------- * Sat Jul 28 2007 Frank B?ttner - 3.0.3-1 - update to 3.0.3 - next fix for the "only root problem" * Sat Jul 21 2007 Frank B?ttner - 3.0.2-2 - fix the old "only root can use the reader" problem drupal-5.2-1.el5 ---------------- * Thu Jul 26 2007 Jon Ciesla - 5.2-1 - Upgrade to 5.2, Cross-site request forgery fix. eggdrop-1.6.18-9.el5 -------------------- * Sun Jul 29 2007 Robert Scheck 1.6.18-9 - Rebuild for new bind fping-2.4b2-7.el5 ----------------- * Mon Sep 11 2006 Chris Ricker 2.4b2-7 - Bump and rebuild freetds-0.64-6.el5 ------------------ * Fri Jun 15 2007 Dmitry Butskoy - 0.64-6 - bump release to provide update path over Livna glpk-4.20-1.el5 --------------- * Fri Jul 27 2007 Quentin Spencer 4.20-1 - New release. - Split static libs into separate package. gtkmm24-2.10.10-1.el5 --------------------- * Tue Jul 10 2007 Denis Leroy - 2.10.10-1 - Update to 2.10.10, memory leak fix - Fixed documentation devhelp support irssi-0.8.10-6.a.el5 -------------------- * Sun Sep 17 2006 Dams - 0.8.10-6.a - Bumped release iverilog-0.9.20070608-1.el5 --------------------------- * Sun Jun 10 2007 Balint Cristian 0.9.20070608-1 - new snapshot release upstream. mksh-30-1.el5 ------------- * Sat Jul 28 2007 Robert Scheck 30-1 - Upgrade to 30 nail-12.3-1.el5 --------------- * Tue Jul 24 2007 Dmitry Butskoy - 12.3-1 - update to 12.3 net6-1.3.5-1.el5 ---------------- * Sat Jun 16 2007 Luke Macken - 1.3.5-1 - 1.3.5 obby-0.4.4-1.el5 ---------------- * Wed Apr 25 2007 Luke Macken - 0.4.4-1 - 0.4.4 octave-2.9.13-1.el5 ------------------- * Thu Jul 26 2007 Quentin Spencer 2.9.13-1 - New release. - Changed ufsparse-devel dependency to suitesparse-devel. - Add configure flag to close bug 245562. - Add directories for add-on packages (bug 234012). - Since texinfo is now separate from tetex, it is a build requirement. - In EPEL, fftw is called fftw3. perl-AnyData-0.10-3.el5 ----------------------- * Thu Sep 14 2006 Tom "spot" Callaway 0.10-3 - bump for FC-6 perl-Apache-LogRegex-1.4-1.el5 ------------------------------ * Mon Oct 30 2006 Steven Pritchard 1.4-1 - Update to 1.4. - Cleanup to more closely match cpanspec output. perl-Cache-Mmap-0.09-1.el5 -------------------------- * Tue Oct 17 2006 Steven Pritchard 0.09-1 - Specfile autogenerated by cpanspec 1.69.1. - Fix License. - Drop execute bits on cmmtest (included as documentation). perl-Class-Accessor-0.31-1.el5 ------------------------------ * Fri Jul 27 2007 Tom "spot" Callaway 0.31-1 - update for 0.31, hooray for performance patches perl-Class-Data-Inheritable-0.06-1.el5.2 ---------------------------------------- * Wed Jan 17 2007 Tom "spot" Callaway 0.06-1 - bump to 0.06 perl-Clone-0.27-1.el5 --------------------- * Fri Jul 27 2007 Tom "spot" Callaway 0.27-1 - bump to 0.27 perl-CPAN-DistnameInfo-0.06-2.el5 --------------------------------- * Sat Sep 16 2006 Steven Pritchard 0.06-2 - Canonicalize Source0 URL. - Fix find option order. perl-MIME-Types-1.20-1.el5 -------------------------- * Wed Jun 13 2007 Ville Skytt? - 1.20-1 - 1.20. - Convert docs to UTF-8. perl-Module-CoreList-2.11-1.el5 ------------------------------- * Wed May 30 2007 Jose Pedro Oliveira - 2.11-1 - Update to 2.11. perl-Taint-Runtime-0.03-1.el5.1 ------------------------------- * Tue Jul 24 2007 Tom "spot" Callaway 0.03-1.1 - BR: perl(Test::More) perl-Test-Tester-0.104-1.el5 ---------------------------- * Tue Dec 26 2006 Steven Pritchard 0.104-1 - Update to 0.104. - Use fixperms macro instead of our own chmod incantation. perl-UNIVERSAL-require-0.11-1.el5 --------------------------------- * Wed Jan 17 2007 Tom "spot" Callaway 0.11-1 - bump to 0.11 perl-XML-XPath-1.13-4.el5 ------------------------- * Thu Aug 31 2006 Chris Weyl 1.13-4 - bump for mass rebuild suitesparse-3.0.0-1.el5 ----------------------- * Tue Jul 03 2007 Quentin Spencer 3.0.0-1 - Change package name to match upstream, including provides and obsoletes. - New release. Numerous changes in build to reflect source reorganization. - Moved static libs into separate package. timidity++-2.13.2-2 ------------------- * Sat Jul 28 2007 Nigel Jones - 2.13.2-2 - Build for EL-5 trac-bazaar-plugin-0.2-2.20070717bzr180.el5 ------------------------------------------- * Wed Jul 18 2007 Toshio Kuratomi - 0.2-2.20070717bzr180 - Fixes from review comments: RH BZ#248815 + Make macros consistent. + Remove extraneous comment. * Wed Jul 18 2007 Toshio Kuratomi - 0.2-1.20070717bzr180 - Initial build. wine-0.9.42-1.el5 ----------------- * Sat Jul 28 2007 Andreas Bierfert - 0.9.42-1 - version upgrade wine-docs-0.9.42-1.el5 ---------------------- * Sat Jul 28 2007 Andreas Bierfert - 0.9.42-1 - version upgrade wxGTK-2.8.4-4.el5 ----------------- * Mon Jul 16 2007 Matthew Miller - 2.8.4-4 - patch from svn to fix rh bug #247414 * Thu Jul 12 2007 Matthew Miller - 2.8.4-3 - include libwx_gtk2u_media, since I'm now listing the buildreqs properly. * Thu Jul 12 2007 Matthew Miller - 2.8.4-2 - buildrequires for libSM-devel, gstreamer-plugins-base-devel, and GConf2-devel * Wed Jul 11 2007 Matthew Miller - 2.8.4-1 - update to 2.8.4 - obsolete compat-wxGTK - add -fno-strict-aliasing yumex-1.9.11-1.el5 ------------------ * Sun Jul 08 2007 Tim Lauridsen - 1.9.11-1 - Development Release 1.9.11-1 * Sun Jul 08 2007 Tim Lauridsen - 1.9.10-2.0 - Development Release 1.9.10-2.0 * Sat Jul 07 2007 Tim Lauridsen - 1.9.10-1.0 - Development Release 1.9.10-1.0 Changes in Fedora EPEL 4: cfitsio-3.006-3.el4 ------------------- * Thu Mar 30 2006 Matthew Truch - 3.006-3 - Use defattr() for devel package as well - bug 187366 ctapi-cyberjack-3.0.3-1.el4 --------------------------- * Sat Jul 28 2007 Frank B?ttner - 3.0.3-1 - update to 3.0.3 - next fix for the "only root problem" * Sat Jul 21 2007 Frank B?ttner - 3.0.2-2 - fix the old "only root can use the reader" problem drupal-5.2-1.el4 ---------------- * Thu Jul 26 2007 Jon Ciesla - 5.2-1 - Upgrade to 5.2, Cross-site request forgery fix. eggdrop-1.6.18-9.el4 -------------------- * Sun Jul 29 2007 Robert Scheck 1.6.18-9 - Rebuild for new bind fping-2.4b2-7.el4 ----------------- * Mon Sep 11 2006 Chris Ricker 2.4b2-7 - Bump and rebuild freetds-0.64-6.el4 ------------------ * Fri Jun 15 2007 Dmitry Butskoy - 0.64-6 - bump release to provide update path over Livna irssi-0.8.9-6.el4 ----------------- * Fri Jul 27 2007 Marek Mahut 0:0.8.9-6 - Rebuild for EPEL iverilog-0.9.20070608-1.el4 --------------------------- * Sun Jun 10 2007 Balint Cristian 0.9.20070608-1 - new snapshot release upstream. mksh-30-1.el4 ------------- * Sat Jul 28 2007 Robert Scheck 30-1 - Upgrade to 30 nail-12.0-2.el4 --------------- * Wed Mar 22 2006 Dmitry Butskoy - 12.0-2 - complete "mailx to nail" changes in the manual and config files - drop _smp_mflags: it caused make to work incorrectly. perl-AnyData-0.10-2.el4 ----------------------- * Fri Mar 31 2006 Tom "spot" Callaway 0.10-2 - minor cleanups perl-Apache-LogRegex-1.4-1.el4 ------------------------------ * Mon Oct 30 2006 Steven Pritchard 1.4-1 - Update to 1.4. - Cleanup to more closely match cpanspec output. perl-Cache-Mmap-0.09-1.el4 -------------------------- * Tue Oct 17 2006 Steven Pritchard 0.09-1 - Specfile autogenerated by cpanspec 1.69.1. - Fix License. - Drop execute bits on cmmtest (included as documentation). perl-Class-Accessor-0.31-1.el4 ------------------------------ * Fri Jul 27 2007 Tom "spot" Callaway 0.31-1 - update for 0.31, hooray for performance patches perl-Class-Data-Inheritable-0.06-1.el4.2 ---------------------------------------- * Wed Jan 17 2007 Tom "spot" Callaway 0.06-1 - bump to 0.06 perl-Clone-0.27-1.el4 --------------------- * Fri Jul 27 2007 Tom "spot" Callaway 0.27-1 - bump to 0.27 perl-CPAN-DistnameInfo-0.06-1.el4 --------------------------------- * Mon Sep 19 2005 Steven Pritchard 0.06-1 - Specfile autogenerated. perl-Taint-Runtime-0.03-1.el4.1 ------------------------------- * Tue Jul 24 2007 Tom "spot" Callaway 0.03-1.1 - BR: perl(Test::More) perl-Test-Tester-0.104-1.el4 ---------------------------- * Tue Dec 26 2006 Steven Pritchard 0.104-1 - Update to 0.104. - Use fixperms macro instead of our own chmod incantation. perl-UNIVERSAL-require-0.11-1.el4 --------------------------------- * Wed Jan 17 2007 Tom "spot" Callaway 0.11-1 - bump to 0.11 perl-XML-XPath-1.13-2 --------------------- * Sun Jul 11 2004 Ville Skytt? - 0:1.13-2 - Bring up to date with current fedora.us Perl spec template. timidity++-2.13.2-2 ------------------- * Sat Jul 28 2007 Nigel Jones - 2.13.2-2 - Build for EL-4 wine-0.9.42-1.el4 ----------------- * Sat Jul 28 2007 Andreas Bierfert - 0.9.42-1 - version upgrade For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From florin at andrei.myip.org Tue Jul 31 01:04:49 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 30 Jul 2007 18:04:49 -0700 Subject: add to wish list: munin and munin-node Message-ID: <46AE8AB1.2020903@andrei.myip.org> I am trying to add munin and munin-node to the wishlist but it looks like my Wiki user doesn't have permissions to do that. So I am posting the request to this list instead. Thanks, -- Florin Andrei http://florin.myip.org/ From kevin at tummy.com Tue Jul 31 02:26:52 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 30 Jul 2007 20:26:52 -0600 Subject: add to wish list: munin and munin-node In-Reply-To: <46AE8AB1.2020903@andrei.myip.org> References: <46AE8AB1.2020903@andrei.myip.org> Message-ID: <20070730202652.2bf1f027@ghistelwchlohm.scrye.com> On Mon, 30 Jul 2007 18:04:49 -0700 florin at andrei.myip.org (Florin Andrei) wrote: > I am trying to add munin and munin-node to the wishlist but it looks > like my Wiki user doesn't have permissions to do that. So I am > posting the request to this list instead. No need. I am planning on branching munin for epel... just haven't had time to finish getting the prereq's done and munin tested. (It still needs perl-HTML-Template). Hopefully I will have it done soon... > Thanks, kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Tue Jul 31 02:41:53 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 30 Jul 2007 22:41:53 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-07-30 Message-ID: <20070731024153.A8177152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 1 NEW bacula-2.0.3-9.el5 : Cross platform network backup for Linux, Unix, Mac and Windows Packages built and released for Fedora EPEL 4: 1 NEW svnmailer-1.0.8-3.el4 : Tool to post subversion repository commit information Changes in Fedora EPEL 5: bacula-2.0.3-9.el5 ------------------ * Wed Jul 25 2007 Andreas Thienemann 2.0.3-9 - Corrected the %post alternatives calls. Fixing #249560. * Thu Jul 19 2007 Andreas Thienemann 2.0.3-8 - Moved some files around in the %files section and refactored spec parts a bit - Fixed up the catalog-backup scripts by including them in the alternatives system - Applied tls patch fixing some tls disconnection issues. * Wed Jul 18 2007 Andreas Thienemann 2.0.3-7 - Minor specchanges, mostly typos in the comments - Incorporated minor changes from dgilmore's review. * Fri Jul 13 2007 Andreas Thienemann 2.0.3-6 - Fixing %preun scripts. Thx to Dan for spotting this * Fri Jul 13 2007 Andreas Thienemann 2.0.3-5 - Fixed provides and requires * Wed Jul 11 2007 Andreas Thienemann 2.0.3-4 - Fixed many rpmlint issues Changes in Fedora EPEL 4: svnmailer-1.0.8-3.el4 --------------------- * Sat Dec 09 2006 Michael Fleming 1.0.8-3 - Rebuild for python 2.5 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From limb at jcomserv.net Tue Jul 31 11:04:32 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 31 Jul 2007 06:04:32 -0500 (CDT) Subject: EPEL report week 30 2007 In-Reply-To: <46AE4E6C.2080901@fedoraproject.org> References: <46AE1BB3.7010908@leemhuis.info> <46AE4E6C.2080901@fedoraproject.org> Message-ID: <3424.65.192.24.164.1185879872.squirrel@mail.jcomserv.net> > Thorsten Leemhuis wrote: >> === EPEL 5 === >> >> Number of source packages: 483 >> >> Number of binary packages: 872 >> >> There are 30 new Packages: >> >> * drupal | An open-source content-management platform >> * GeoIP | C library for country/city/organization to IP address or >> hostname mapping >> * libmcrypt | Encryption algorithms library >> * librx | POSIX regexp functions >> * lighttpd | Lightning fast webserver with light system requirements >> * logjam | GTK2 client for LiveJournal >> * lout | A document formatting system >> * mcrypt | Replacement for crypt() >> * memcached | High Performance, Distributed Memory Object Cache >> * mhash | Thread-safe hash algorithms library >> * mod_geoip | GeoIP module for the Apache HTTP Server >> * perl-File-MMagic | A Perl module emulating the file(1) command >> * perl-File-MMagic-XS | Guess file type with XS >> * perl-Geography-Countries | 2-letter, 3-letter, and numerical codes >> for countries >> * perl-Mail-IMAPClient | An IMAP Client API >> * perl-Net-Domain-TLD | Work with TLD names >> * perl-Object-Realize-Later | Delayed creation of objects >> * perl-Parse-RecDescent | Parse-RecDescent Perl module >> * perl-Pod-POM | Object-oriented interface to Perl POD documents >> * perl-Taint-Runtime | Runtime enable taint checking >> * perl-User-Identity | Maintains info about a physical person >> * phpMyAdmin | Web based MySQL browser written in php >> * python-GeoIP | Python bindings for the GeoIP geographical lookup >> libraries >> * python-imaging | Python's own image processing library >> * qfaxreader | A multipage monochrome/color TIFF/FAX viewer >> * qstat | Real-time Game Server Status for FPS game servers >> * QuantLib | A software framework for quantitative finance >> * sipp | SIP test tool / traffic generator >> * sipsak | SIP swiss army knife >> * smolt | Fedora hardware profiler >> >> === EPEL 4 === >> >> Number of source packages: 295 >> >> Number of binary packages: 596 >> >> There are 31 new Packages: >> >> * drupal | An open-source content-management platform >> * GeoIP | C library for country/city/organization to IP address or >> hostname mapping >> * graphviz | Graph Visualization Tools >> * libmcrypt | Encryption algorithms library >> * librx | POSIX regexp functions >> * logjam | GTK2 client for LiveJournal >> * lout | A document formatting system >> * mcrypt | Replacement for crypt() >> * mhash | Thread-safe hash algorithms library >> * mod_geoip | GeoIP module for the Apache HTTP Server >> * perl-Date-Pcalc | Gregorian calendar date calculations >> * perl-File-MMagic | A Perl module emulating the file(1) command >> * perl-File-MMagic-XS | Guess file type with XS >> * perl-Geography-Countries | 2-letter, 3-letter, and numerical codes >> for countries >> * perl-Mail-IMAPClient | An IMAP Client API >> * perl-MIME-Lite | MIME::Lite - low-calorie MIME generator >> * perl-MIME-tools | Modules for parsing and creating MIME entities in >> Perl >> * perl-Net-Domain-TLD | Work with TLD names >> * perl-Object-Realize-Later | Delayed creation of objects >> * perl-Parse-RecDescent | Parse-RecDescent Perl module >> * perl-Pod-POM | Object-oriented interface to Perl POD documents >> * perl-Taint-Runtime | Runtime enable taint checking >> * perl-TimeDate | A Perl module for time and date manipulation >> * perl-User-Identity | Maintains info about a physical person >> * phpMyAdmin | Web based MySQL browser written in php >> * python-cheetah | Template engine and code-generator >> * python-GeoIP | Python bindings for the GeoIP geographical lookup >> libraries >> * qfaxreader | A multipage monochrome/color TIFF/FAX viewer >> * qstat | Real-time Game Server Status for FPS game servers >> * sipp | SIP test tool / traffic generator >> * sipsak | SIP swiss army knife > > Hmm, where's irssi? I build it few days ago. > I thought tidy had been built, as well? -- novus ordo absurdum From kyle.gonzales at gmail.com Tue Jul 31 11:48:49 2007 From: kyle.gonzales at gmail.com (Kyle Gonzales) Date: Tue, 31 Jul 2007 07:48:49 -0400 Subject: Snort in EPEL? Message-ID: <1185882529.24709.5.camel@x2.ultrasound.home> Is anyone working on getting Snort and its associated packages into EPEL currently? -- Kyle Gonzales Tech blog at http://techiebloggiethingie.blogspot.com/ From dennis at ausil.us Tue Jul 31 12:45:10 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 31 Jul 2007 07:45:10 -0500 Subject: Snort in EPEL? In-Reply-To: <1185882529.24709.5.camel@x2.ultrasound.home> References: <1185882529.24709.5.camel@x2.ultrasound.home> Message-ID: <200707310745.18108.dennis@ausil.us> Once upon a time Tuesday 31 July 2007, Kyle Gonzales wrote: > Is anyone working on getting Snort and its associated packages into EPEL > currently? im working on getting snort in better shape. It is nearly there. if you want to co-maintain it with id be more than happy for the help. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From fedora at leemhuis.info Tue Jul 31 17:32:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 31 Jul 2007 19:32:24 +0200 Subject: Plan for tomorrows (20070801) EPEL SIG meeting Message-ID: <46AF7228.7020703@leemhuis.info> Hi all, find below the list of topics that are planed to come up in the next EPEL SIG meeting which is scheduled for tomorrow, Wednesday at 17:00 UTC in #fedora-meeting on irc.freenode.org. EPEL announcement happened -- are we satisfied with how everything worked out? branch for EPEL if Fedora maintainer does not react -- dgilmore new push scripts for pushing to testing, adjust mock configs to use testing -- dgilmore EPEL announcement happened -- what next? You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics at the end of the meeting itself. If your name/nick is on above list please give a update. That way all the interested parties know what up ahead of the meeting; that will avoid long delays and "status update monologues in the meeting. Thanks! CU knurd From fedora at leemhuis.info Tue Jul 31 17:38:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 31 Jul 2007 19:38:12 +0200 Subject: EPEL report week 30 2007 In-Reply-To: <3424.65.192.24.164.1185879872.squirrel@mail.jcomserv.net> References: <46AE1BB3.7010908@leemhuis.info> <46AE4E6C.2080901@fedoraproject.org> <3424.65.192.24.164.1185879872.squirrel@mail.jcomserv.net> Message-ID: <46AF7384.8060409@leemhuis.info> On 31.07.2007 13:04, Jon Ciesla wrote: >> Thorsten Leemhuis wrote: >>> === EPEL 5 === >>> >>> Number of source packages: 483 >>> >>> Number of binary packages: 872 >>> >>> There are 30 new Packages: >>> >>> * drupal | An open-source content-management platform > [...] >>> * sipsak | SIP swiss army knife >> Hmm, where's irssi? I build it few days ago. Please note that the script does only look at what's actually in the repo -- it doesn't look at the needsign queue in plague, as that stuff is not yet available to the users. Anyway, irssi is now in the repo as the needsign repoi was pushed -- that shouldn't have happened, as all new stuff will go to the testing repo from now and will be moved over on masse at a later point in time. The next move will likely happen in parallel together with the RHEL 5.1 announcement. > I thought tidy had been built, as well? No idea. Check the plague-interface and the reports from the push script that get send to this list. Cu knurd From mmahut at fedoraproject.org Tue Jul 31 18:10:39 2007 From: mmahut at fedoraproject.org (Marek Mahut) Date: Tue, 31 Jul 2007 20:10:39 +0200 Subject: EPEL report week 30 2007 In-Reply-To: <46AF7384.8060409@leemhuis.info> References: <46AE1BB3.7010908@leemhuis.info> <46AE4E6C.2080901@fedoraproject.org> <3424.65.192.24.164.1185879872.squirrel@mail.jcomserv.net> <46AF7384.8060409@leemhuis.info> Message-ID: <46AF7B1F.3050900@fedoraproject.org> Thorsten Leemhuis wrote: > On 31.07.2007 13:04, Jon Ciesla wrote: >>> Thorsten Leemhuis wrote: >>>> === EPEL 5 === >>>> >>>> Number of source packages: 483 >>>> >>>> Number of binary packages: 872 >>>> >>>> There are 30 new Packages: >>>> >>>> * drupal | An open-source content-management platform >> [...] >>>> * sipsak | SIP swiss army knife >>> Hmm, where's irssi? I build it few days ago. > > Please note that the script does only look at what's actually in the > repo -- it doesn't look at the needsign queue in plague, as that stuff > is not yet available to the users. > > Anyway, irssi is now in the repo as the needsign repoi was pushed -- > that shouldn't have happened, as all new stuff will go to the testing > repo from now and will be moved over on masse at a later point in time. > The next move will likely happen in parallel together with the RHEL 5.1 > announcement. Yes, I see it in the current report. Sorry. >> I thought tidy had been built, as well? > > No idea. Check the plague-interface and the reports from the push script > that get send to this list. > > Cu > knurd -- Marek Mahut http://www.fedoraproject.org/ Fedora Project http://www.jamendo.com/ From kwade at redhat.com Tue Jul 31 20:19:40 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 31 Jul 2007 13:19:40 -0700 Subject: el-4 confusion, misstatement on Wiki? Message-ID: <1185913180.3521.158.camel@erato.phig.org> Is this inaccurate/old? http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-8d21749b79a31472a018664cc02e7f248e53fe1e If so, what do we want to say instead? - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: