From tcallawa at redhat.com Sat Sep 1 23:29:42 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 01 Sep 2007 19:29:42 -0400 Subject: My packages for EPEL In-Reply-To: <46D7C8C5.6040509@city-fan.org> References: <1188419380.3480.86.camel@dhcp83-165.boston.redhat.com> <46D7C8C5.6040509@city-fan.org> Message-ID: <1188689383.7665.25.camel@new-host> On Fri, 2007-08-31 at 08:52 +0100, Paul Howarth wrote: > Tom "spot" Callaway wrote: > > As one of the top 5 Fedora packagers (top 5? I used to be top 2, must be > > slipping), I've finally finished rebuilding as many of my packages for > > EL-4 and EL-5 as possible. Here's what I couldn't build: > > > > Quantlib (EL-4, boost too old) > > SimGear (missing deps for EL-4, EL-5) > > blacs (EL-4, deps are not new enough) > > gambas (EL-4, EL-5, needs sqlite2-devel) > > lincity-ng (EL-4, EL-5, needs SDL_mixer, SDL_gfx) > > ntfsprogs (fails on EL-4, gnutls is too old) > > perl-Apache-Session-Wrapper (EL-4, EL-5, needs Params::Validate) > > perl-CGI-Untaint-date (EL-4, EL-5, needs Date::Simple) > > Date::Simple is now built for EL-4 and EL-5. And now, so is CGI::Untaint::Date. :) ~spot From Fedora at FamilleCollet.com Mon Sep 3 13:59:06 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 03 Sep 2007 15:59:06 +0200 Subject: PHP extension in EL4 Message-ID: <46DC132A.8070604@FamilleCollet.com> I've a look to PHP and extensions in EL4. We have a lot "PEAR" and PECL extensions in EPEL for EL5 which cannot go to EPEL for EL4 because of very old PHP and PEAR version. RHEL 4 users can use packages from RHWAS (Web Application Stack 1.0) ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/RHWAS/SRPMS ftp://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4ES/en/RHWAS/SRPMS We found there - php-5.1.6 (as for RHEL5) - pear-1.4.11 CentOS 4 users can use packages from centosplus repository We found there all RHWAS RPM and a lot of RPM from Fedora/EPEL (i've read some changelog to verify) http://isoredirect.centos.org/centos/4/centosplus/SRPMS/ I think the packages from EPEL-5 could easily be maintain for an EPEL-4+ repository (using RHEL + RHWAS as references). I also think it's quite strange than CentOS repository is more complete than EPEL using only RHEL + Fedora community work... What must we do in EPEL-4 ? Regards From mastahnke at gmail.com Mon Sep 3 15:43:13 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 3 Sep 2007 10:43:13 -0500 Subject: PHP extension in EL4 In-Reply-To: <46DC132A.8070604@FamilleCollet.com> References: <46DC132A.8070604@FamilleCollet.com> Message-ID: <7874d9dd0709030843v49e4eb93m6da5e34cd35bd149@mail.gmail.com> On 9/3/07, Remi Collet wrote: > I've a look to PHP and extensions in EL4. > > We have a lot "PEAR" and PECL extensions in EPEL for EL5 which cannot go > to EPEL for EL4 because of very old PHP and PEAR version. > > RHEL 4 users can use packages from RHWAS (Web Application Stack 1.0) > ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/RHWAS/SRPMS > ftp://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4ES/en/RHWAS/SRPMS Our policy is not to step on top of RH offered materials. RHWAS is offered as a channel is RHN, if I am correct. So, I don't think we can offer the RPMs that are RHWAS. If people would like a newer stack, I guess they can move to EL4, or compile the src rpms you have linked to. stahnma > > We found there > - php-5.1.6 (as for RHEL5) > - pear-1.4.11 > > CentOS 4 users can use packages from centosplus repository > We found there all RHWAS RPM and a lot of RPM from Fedora/EPEL (i've > read some changelog to verify) > http://isoredirect.centos.org/centos/4/centosplus/SRPMS/ > > I think the packages from EPEL-5 could easily be maintain for an EPEL-4+ > repository (using RHEL + RHWAS as references). > > I also think it's quite strange than CentOS repository is more complete > than EPEL using only RHEL + Fedora community work... > > > What must we do in EPEL-4 ? > Regards > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From Fedora at FamilleCollet.com Mon Sep 3 20:56:23 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 03 Sep 2007 22:56:23 +0200 Subject: PHP extension in EL4 In-Reply-To: <7874d9dd0709030843v49e4eb93m6da5e34cd35bd149@mail.gmail.com> References: <46DC132A.8070604@FamilleCollet.com> <7874d9dd0709030843v49e4eb93m6da5e34cd35bd149@mail.gmail.com> Message-ID: <46DC74F7.2030602@FamilleCollet.com> Michael Stahnke a ?crit : > Our policy is not to step on top of RH offered materials. RHWAS is > offered as a channel is RHN, if I am correct. So, I don't think we > can offer the RPMs that are RHWAS. That's not what i mean. I only say : >> I think the packages from EPEL-5 could easily be maintain for an EPEL-4+ >> repository (using RHEL + RHWAS as references). So building RPM for "RHEL + RHWAS" users (such as pear and pecl extensions). Remi. From sheltren at cs.ucsb.edu Tue Sep 4 13:19:33 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 4 Sep 2007 08:19:33 -0500 Subject: Meeting Tomorrow Message-ID: <431BD41F-CE93-4315-968D-67C189B9A0F9@cs.ucsb.edu> I'll be traveling tomorrow so I won't be able to make the meeting. Have fun without me! :) -Jeff From fedora at leemhuis.info Tue Sep 4 16:29:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 04 Sep 2007 18:29:22 +0200 Subject: EPEL SIG Meetings now alternating between 17:00 and 23:00 UTC on Wednesdays Message-ID: <46DD87E2.70403@leemhuis.info> Hi all! Just FYI, in the EPEL SIG meeting last week it was decided to have alternating meeting times for our weekly meetings on Wednesdays. In weeks with an even number (like this one, as it's the 36th week currently; the gnome panel date applet will tell you the current week number) we'll have the meetings at 23:00 UTC. In the weeks with and odd number we'll continue to have them at 17:00 UTC. Time are daylight saving times. During the winters we'll adjust them by one hour, to make sure the effective meeting time stays the same. So join us in the next meeting, which is scheduled for tomorrow at 23:00**UTC in #fedora-meeting. CU knurd P.S.: Note that this new meeting scheme doesn't revert the plan to try to get more stuff done on the list and less in the meetings. That still the plan, but we need to experiment a bit how to actually have a good workflow on the list (and quick meetings that still will be needed). From fedora at leemhuis.info Tue Sep 4 17:23:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 04 Sep 2007 19:23:45 +0200 Subject: Log from last weeks (200700829) EPEL SIG Meeting Message-ID: <46DD94A1.9000400@leemhuis.info> 00:00:46 < knurd> | Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00:46 < knurd> | Hi everybody; who's around? 00:00:46 * | 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:46 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00:50 < mmcgrath> | pong 00:00:57 < stahnma> | pong 00:01:20 * | nirik is here. 00:01:43 * | stahnma tried to solicit interest from #rhn 00:02:12 < knurd> | well, let's start 00:02:15 --- | knurd has changed the topic to: EPEL Meeting|push to stable easily -- knurd 00:02:25 < knurd> | mschwendt did some improvements to the scripts 00:02:42 < knurd> | they should make it easy to moev something from testing to stable 00:02:50 < knurd> | the final patch was not applied yet 00:03:11 < knurd> | I talked to dgilmore about it (he knows the scripts way better than I do) and wants to take a look 00:03:23 < knurd> | if he doesn#t find the time i'll take the risk over the next few days 00:03:33 < nirik> | we just need to be carefull that a update doesn't depend on something else in testing. 00:03:55 < knurd> | ohh, and I'd like to say "thx for your work mschwendt" 00:04:18 < stahnma> | as someone not too familiar with the infrastructure side of things, were are these scripts at? 00:04:21 < knurd> | nirik, well, with the current policy we only move updates for stable packages 00:04:24 < stahnma> | and can I review them? 00:04:52 * | dgilmore is here 00:04:57 < mmcgrath> | I actually don't know where the canonical spot for that stuff is 00:04:59 < knurd> | stahnma, somewhere in http://cvs.fedora.redhat.com/viewcvs/?root=fedora 00:05:15 < dgilmore> | extras-buildsys 00:05:20 < nirik> | knurd: are you talking about moving single packages from testing-> stable, or moving all packages in testing-> stable? 00:05:37 < knurd> | nirk, for now only single packages 00:05:37 < stahnma> | ok, I can take that offline, I just would like to be a bit more involved in some of the infrastructure for EPEL 00:05:45 < knurd> | e.g. in case of urgent bugixes 00:05:52 < nirik> | the first we need to make sure the package is not built against any of the other packages that are still sitting in testing... 00:06:30 < knurd> | dgilmore, I suppose you didn#t find time yet to look into the improvements from mschwendt? 00:06:46 --> | BobJensen (Robert 'Bob' Jensen) has joined #Fedora-Meeting 00:06:51 < knurd> | nirik, well, normally there should be any new stuff where in testing which could lead to problems 00:06:53 < dgilmore> | knurd: not yet. its on my todo list after fixing plague 00:07:02 < knurd> | nirik, but yeah, we shound not forget about it 00:07:06 < nirik> | yeah, we also need that for security updates. I should perhaps see if we can add a audit file for epel and discuss on the list security. 00:07:06 < knurd> | dgilmore, k, thx 00:07:10 < stahnma> | dgilmore: are the EL-5 builders still amuck? 00:07:17 < stahnma> | (I have no idea if I spelled that right) 00:07:52 < dgilmore> | stahnma: all plague builds 00:08:20 < rsc> | dgilmore: just to comment. I was one of the guys having such problems. I fired lots of builds the last days, no problems for me. But I can't speak for all. 00:08:36 < dgilmore> | rsc: there has still been reports 00:09:33 < knurd> | well, anything else for now? 00:09:42 * | knurd will move on soon 00:09:59 --- | knurd has changed the topic to: EPEL Meeting|new meeting schedule/scheme 00:10:13 < stahnma> | I sent out some feelers on list 00:10:18 < knurd> | stahnma, would you be willing to run the meetings every second week at 23:00 UTC? 00:10:20 < stahnma> | didn't get much back other than the SIG 00:10:28 < nirik> | I'm happy to try an alternate meeting time... we can always try and if no more people show we can stop doing it. ;) 00:10:29 < stahnma> | knurd: I think so 00:10:29 < knurd> | then I'd say we just try it 00:10:45 < knurd> | (even if I never will be able to make those meetings) 00:10:59 < knurd> | is the timeslot fee in this channel? 00:11:03 < stahnma> | hmm 00:11:08 < stahnma> | probably something I should ahve looked at 00:11:18 < stahnma> | yeag 00:11:46 * | stahnma will add to the #fedora-meeting schedule 00:11:53 < knurd> | k 00:12:33 < knurd> | so agreed we agree on: one week at 17:00 UTC, the other week on 23:00 UTC, this channel and Wednesday 00:12:38 < knurd> | is that correct? 00:12:45 < knurd> | and fine for everybody? 00:12:57 < mmcgrath> | we're still meeting weekly, just different times each week? 00:13:07 < knurd> | mmcgrath, seems so 00:13:12 < nirik> | so next week starts the other meeting time? 00:13:15 < nirik> | or today? 00:13:19 < knurd> | nirik, next week 00:13:29 < stahnma> | next week 00:13:34 < knurd> | nirik, or do you want to have two meetings on one day? ;-) 00:13:48 < nirik> | ok, but we should note that it's a trial, and if there isn't much response we will not be doing it further. 00:13:52 --> | mpdehaan (Michael DeHaan) has joined #fedora-meeting 00:13:54 < nirik> | ha. No thanks. ;) 00:14:07 < knurd> | nirik, "trial" > sounds like a good plan 00:14:28 < knurd> | settled then? yell now or I'll consider it accepted 00:14:29 < stahnma> | ok 00:14:39 < knurd> | stahnma, will you write the meeting summaries for the reports as well? 00:14:45 < stahnma> | sure 00:14:49 < knurd> | great :) 00:15:22 * | knurd considers it as accepted and moves on 00:15:25 < knurd> | ohh, wait, stop 00:15:35 < knurd> | I think we nevertheless should try to do more on the list 00:15:39 < stahnma> | +1 00:15:41 < knurd> | or what do other think? 00:15:44 < knurd> | others 00:15:52 < nirik> | sure, I agree. 00:16:06 < knurd> | k 00:16:13 < knurd> | I hope to write something up about it 00:16:15 < knurd> | soon 00:16:19 * | knurd moves on 00:16:21 --- | knurd has changed the topic to: EPEL Meeting| MetaData for all Packages available to contributors. -- stahnma 00:16:24 < knurd> | stahnma ? 00:16:43 < stahnma> | I've been trying to get a better definition of the problem 00:16:53 < stahnma> | I understand the issue, but use-cases etc would be nice 00:17:09 < stahnma> | we need a clear stance on EPEL not stepping on RHN provided material 00:17:17 < stahnma> | and a way to hopefully enforce it 00:17:18 < knurd> | stahnma, maybe it would be a good start to at lest have a package list online somewhere 00:17:21 < stahnma> | but how, I haven't got there yet 00:17:25 < stahnma> | ok 00:17:25 < knurd> | for 5Desktop and 5Server 00:17:28 < stahnma> | I can probably do that 00:17:33 < stahnma> | if it's not already done 00:17:38 < nirik> | I'm still unsure whats in all those hundreds of channels. 00:17:39 < knurd> | not that I know of 00:17:52 <-- | TowerBE has left #fedora-meeting ( "I'm outta here") 00:17:55 * | knurd doesn't know that either 00:17:56 < nirik> | is that other packages or just a different set (like a fedora spin?) 00:17:57 < stahnma> | nirik: packages :) Many of them are old RH channels 00:18:00 < stahnma> | like 7.2 00:18:01 < stahnma> | and 7.3 00:18:03 < stahnma> | and such 00:18:13 < nirik> | ah ha. 00:18:15 --> | Jeff_S (Jeff) has joined #fedora-meeting 00:18:19 < nirik> | well, most of those can be ignored I bet. 00:18:21 < stahnma> | and separate channels for each arch and each flavor (AS, ES, AP) 00:18:22 < stahnma> | right 00:18:30 < stahnma> | it's mostly a matter of sorting through them 00:18:32 * | Jeff_S on phone, sorry :( 00:18:40 < nirik> | stahnma: perhaps a list of channels would be good to post? or is that info something redhat wouldn't want released? 00:18:49 < stahnma> | I think I have it on fedorapeople 00:18:51 < stahnma> | let me check 00:19:00 < stahnma> | http://stahnma.fedorapeople.org/rhn_channels.txt 00:19:09 < stahnma> | this is a week or two old 00:19:39 < nirik> | ok, so what info can you get from each channel? packages names? 00:19:44 < stahnma> | yes 00:19:49 < stahnma> | and EVRs 00:19:50 < nirik> | how about files? 00:19:51 < stahnma> | if we want them 00:19:55 < stahnma> | I *think* so 00:19:59 < stahnma> | I have to check on that one 00:20:06 < nirik> | or provides? 00:20:34 < stahnma> | yup, I can get a list of files for each package 00:20:56 < nirik> | basically what I think we want is a tool or something where we can do a lookup by name/provides/files so we can tell if a package someone wants to move into epel conflicts with that. 00:21:24 < stahnma> | I can get provides 00:21:31 < stahnma> | the RHN API is pretty cool 00:21:37 < nirik> | ie, search on 'openmotif' and or 'Provides: libm.so.4' or whatever. 00:21:51 * | nirik guesses thats a bad example, but that kind of thing. 00:22:02 < stahnma> | I'll see what I can come up with 00:22:08 < knurd> | I'd say we should not overengeneer the problem 00:22:18 < stahnma> | knurd: ++ 00:22:20 < nirik> | perhaps just name is good enough. 00:22:26 < stahnma> | I'll start there :) 00:22:26 < knurd> | nirik, for the start 00:22:31 < knurd> | then we can see what people need 00:22:35 <-- | mbacovsk has quit (Read error: 110 (Connection timed out)) 00:22:41 < knurd> | and provide more informations if really needed 00:23:26 < nirik> | sounds good to me. 00:23:28 < knurd> | stahnma, will you take care of it ? 00:23:48 < stahnma> | yeah 00:23:59 < stahnma> | give me a week or two 00:24:03 < knurd> | k 00:24:07 < knurd> | then let's move on now 00:24:25 --- | knurd has changed the topic to: EPEL Meeting| mandate for the Steering Committee 00:24:35 < knurd> | I kicked the discussion of on fedora-devel 00:24:46 < knurd> | I liked quaid's mail 00:25:13 < knurd> | we just actually need to adjut some details to lower the influence of the Steering Committee 00:25:24 < knurd> | to make "more power to the people" possible 00:25:34 < knurd> | anything else regarding the topic? 00:25:48 < nirik> | I liked that too... 00:26:03 * | knurd really should start sending out topic lists ahead of th meeting again 00:26:11 < nirik> | so do we need to get any kind of ack from fesco? or we just switch to a SIG and move ahead as we like? 00:26:28 < knurd> | nirik, well, I think we need a ack 00:26:48 < knurd> | some kind of "we extend the mandate for the EPEL Steering Committe by 6 months / a year" 00:27:22 < knurd> | nirik, can you make sure it gets discussed over the next two weeks maybe? 00:27:30 < nirik> | yep. 00:27:38 < knurd> | nirik, thx 00:28:05 --- | knurd has changed the topic to: EPEL Meeting | push quicker to stable 00:28:18 < knurd> | seems this topic is getting discussed a bit more again 00:28:32 < nirik> | I'm not opposed to faster pushes from testing... but we need to be carefull... 00:28:35 < knurd> | my 2 cent: I'm fine with moving new packages over after four weeks or so 00:28:38 < mmcgrath> | the current method has worked well for me both as a contributor and as a consumer. 00:28:52 < knurd> | but updates to existing packages only should get over if there is a need to (and not automatically) 00:29:02 < nirik> | are the redhat 'quarterly' updates really quarterly? 00:29:08 < stahnma> | nirik: no 00:29:19 < stahnma> | nirik: they are every-so-often 00:29:24 < nirik> | yeah, thats what I thought. 00:29:31 < knurd> | nirik, yeah, if they are not then we really should do them more often for new packages 00:29:32 < stahnma> | 4-5 months lately, it seems like 00:29:46 < mmcgrath> | But if we are trying to match RHEL as a great complimentary repo to RHEL, we just have to take their lead. 00:29:54 < knurd> | with four people beeing alte to push we might have the manpower to do it soon 00:30:20 * | nirik is happy to do pushes after he gets trained on how to. ;) 00:30:21 < knurd> | but we'd need to prepare that one machine, check the deps, and after that do it in the repo 00:30:29 < knurd> | to make sure all the deps are fulfilt 00:30:41 < knurd> | mmcgrath, +1 00:30:45 < nirik> | yeah. 00:30:48 < knurd> | mmcgrath, but we are still in the early stages 00:31:01 < knurd> | so pushing new packages (not updated ones) more often might be a good idea 00:31:22 < knurd> | nirik, I'll tell you soon how to push 00:31:27 < mmcgrath> | 00:31:47 < stahnma> | ok 00:31:47 * | knurd has a headache today and will leave the keyboard right after the meeting 00:32:02 < nirik> | yeah, how about weekly we push any new package that has been in testing for 4 weeks (provided it has no broken deps or anything) 00:32:21 < Jeff_S> | I agree -- for the time being, it would be really nice to push 'new' packages to stable more often 00:32:30 < nirik> | 5-6 months does seem a while to wait for your new package if it's all stable. 00:32:30 < knurd> | nirik, well, I think that's do much work with the current tools 00:32:46 < knurd> | nirik, I'd say one a months should be often enough 00:33:17 < nirik> | yeah, I don't know how hard it would be... I am pretty good about doing scheduled tasks like that tho... so whatever works. 00:33:35 < mpdehaan> | more often would be goodness 00:33:37 < knurd> | nirik, I#d just say we try it once and see how much work it is 00:33:49 < nirik> | yeah. 00:33:52 < knurd> | and decide then if we do it each week, every two, or evrey four 00:34:01 < nirik> | mpdehaan: yeah, would that meet your needs somewhat? you wanted faster pushes... 00:34:23 < Jeff_S> | mpdehaan: btw, yum, createrepo, etc. are now in EPEL-4 testing if you hadn't noticed 00:34:24 < mpdehaan> | haven't been following this chat too closely -- how often is how often? 00:34:42 < mpdehaan> | anyhow, the problem is that testing can be any varying degree of unstable, while stable is very old 00:34:48 < mpdehaan> | just some middle ground would would be great 00:35:01 < mpdehaan> | Jeff_S, awesome 00:35:02 < nirik> | it's not been decided yet. ;) We were thinking if a new package has been in testing a month it gets moved to stable. 00:35:02 <-- | LetoTo has quit (Read error: 110 (Connection timed out)) 00:35:04 < Jeff_S> | I think once a month or so is a good starting spot and we can see how that goes 00:35:04 < knurd> | mmcgrath, I'd say "every four week" if likely for now 00:35:11 < mpdehaan> | nirik, 1 month sounds great 00:35:12 < knurd> | weeks 00:35:32 < nirik> | bugfixes, updates, stay in testing until the next rhel quarterly unless they are security or major. 00:35:44 < knurd> | well, anything else regarding this topic? 00:35:44 < mmcgrath> | now are we saying the rpms have to be in testing for 4 weeks? or if someone happens to build the night before a push, it goes? 00:35:51 < mpdehaan> | umh, don't know about the quarterly business 00:35:53 * | knurd waits 00:36:01 < mpdehaan> | just 4 weeks sounds great 00:36:10 < knurd> | mmcgrath, we'd evaluate when we do it for the first time 00:36:23 < knurd> | mmcgrath, we can check the buildtime of the packages 00:36:29 < Jeff_S> | mmcgrath: I think they'd need to be in testing for some amount of time (which we can discuss) 00:36:34 < nirik> | mmcgrath: I would say we try and look at whats in testing and only move things that are: a) new package and b) been there 4 weeks or longer 00:36:54 < knurd> | should not be to hard, as we need to prepare it in a local test repo in any case, to make sure all deps are available 00:37:15 < mmcgrath> | just a matter of the scripts. It would be nice to keep this stuff as simple as possible though. 00:37:24 < knurd> | mmcgrath, +1 00:37:41 < mmcgrath> | thats one reason I like the current way, everyone knows what happens when and its easy to explain (even though we haven't actually done it yet really :) 00:37:42 < knurd> | especailly as we might need new scripts once we switch to bodhi 00:37:56 < mpdehaan> | X weeks is easy enough to explain :) 00:38:04 --- | stickster is now known as stickster_afk 00:38:42 < knurd> | well, I'd say we move on now, and finetune the details somewhen else 00:38:50 < nirik> | well, but it's not just X weeks everything pushes... so it's harder to explain. ;) 00:39:00 < mmcgrath> | except that if we only do a push every 4 weeks, some people will have RPMs in there for 7.9 weeks. 00:39:29 < nirik> | right. thats why I was thinking weekly, but not sure how much hassle it is. 00:39:29 < mmcgrath> | s/there/testing/ 00:40:00 < Jeff_S> | nirik: or bi-weekly 00:40:15 < knurd> | Jeff_S, let's seee how much work it is, and decide then 00:40:16 < nirik> | I can post to the list and see what people suggest? or we just figure out whats feasable on the current scripts? 00:40:26 < Jeff_S> | knurd: agreed 00:40:34 < Jeff_S> | but it really depends on the people doing the pushing IMO 00:40:42 < knurd> | nirik, let's try it once, and then decide or ask the list 00:40:46 < nirik> | ok. 00:41:09 * | knurd moves on now if nobody yells 00:41:23 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:41:28 < knurd> | anything else to discuss? 00:41:49 < mpdehaan> | I want a pony? 00:42:16 < knurd> | the weather sucks 00:42:17 < nirik> | I'm going to try and add security setup for epel... security team people are probibly greatfully accepted. ;) 00:42:50 < stahnma> | I am trying to get some more #rhel and #rhn people involved here in EPEL 00:43:05 < stahnma> | I just started today, so we'll see how it goes 00:43:22 < knurd> | nirik, "security setup" as in: people that check security lists and makre sure all issues releavant to EPEL get solved? 00:43:24 < nirik> | could we possibly get someone to write a redhat magazine article on epel? that might get to a lot more rhel folks... 00:43:40 < stahnma> | can anyone write for RH magazine? 00:43:44 < knurd> | nirik, mether indicated to write one weeks ago 00:43:46 < stahnma> | if so, I would happily write it 00:43:49 < knurd> | not sure if he ever did it 00:44:02 < mmcgrath> | stahnma: I think so, I've written for it twice. Send an email to gdk and ask for sure. 00:44:09 < stahnma> | ok 00:44:15 < nirik> | knurd: yeah, hopefully we can add it into the existing fedora setup. Make a audit/epel4 audit/epel5 files and track CVE's against epel packages... file bugs against them, make sure pushes happen for security, etc; 00:44:26 < knurd> | stahnma, and ask mether if he prepared something already 00:44:31 < stahnma> | ok 00:44:38 < nirik> | oh, another thing... did folks see my clamav post? 00:44:38 < knurd> | nirik, sounds great :) 00:45:24 < knurd> | nirik, saw it, but I have a mental filter for anything with clamav in the topic ;-) 00:45:33 < knurd> | well, no, I actually read it 00:45:57 < nirik> | yeah, I can take it over if no one else wants to... (I'd prefer not to), but if I do, I would want to diverge a lot from the current package... 00:46:04 < knurd> | and solving the problems with the packaging and compatapility with dag7rpmforge would be good 00:46:35 < knurd> | nirik, well, I'd prefer if stuff is similar in Fedora and EPEL 00:46:40 < nirik> | frankly, I would love to just use the dag version... perhaps even try and talk him into maintaining or something. 00:46:49 < nirik> | yeah, thats the issue... :( 00:46:50 < knurd> | but well, that won't work always, and this is such a case afaics 00:47:25 < knurd> | nirik, I think going to use dag's version is fine 00:47:27 < nirik> | clamav is also a security nightmare. ;( 00:47:44 < knurd> | (but I never looked to close at it in any case, so my opinion is not much worth) 00:48:05 < nirik> | well, I didn't get much reply on the mailing list. I guess I will wait a while and then move forward. 00:48:23 < knurd> | nirik, sounds good 00:48:25 --> | LetoTo (Paul Wouters) has joined #fedora-meeting 00:48:42 < knurd> | anything else? 00:49:03 * | nirik has nothing. 00:49:11 < Jeff_S> | nope 00:49:22 * | knurd will close the meeting in n 00:49:23 < mmcgrath> | nothing here 00:49:25 * | knurd will close the meeting in 30 00:49:27 <-- | LetoTo has left #fedora-meeting ( ) 00:49:41 * | knurd will close the meeting in 15 00:49:42 < stahnma> | thanks 00:49:46 <-- | stahnma has left #fedora-meeting ( "Time for something else....") 00:49:56 < knurd> | -- MARK -- Meeting end 00:49:56 --- | knurd has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule 00:50:00 < knurd> | thx everyone 00:50:02 < mmcgrath> | thanks knurd 00:50:13 < nirik> | thanks knurd From mastahnke at gmail.com Tue Sep 4 22:09:12 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 4 Sep 2007 17:09:12 -0500 Subject: EPEL Meeting This week [new time] Message-ID: <7874d9dd0709041509v11cdeefekf816dea138e504e2@mail.gmail.com> Reminder, EPEL is trying alternative meeting times to encourage more attendance from everyone ( not just steering coommittee memebers). If you have any interest in EPEL, please come join us! LOOK -----------> Meeting is at 23:00 UTC this week. /topic EPEL Meeting|push to stable easily -- all /topic EPEL Meeting| MetaData for all Packages available to contributors. -- stahnma /topic EPEL Meeting|[:EPEL/CommunicationPlan:Communication plan] for enterprise customers/ISVs/IHVs -- stahnma, quaid /topic EPEL Meeting|[:EPEL/PackageMaintainer/GenericJobDescription: Generic Job Description]||[:KarstenWade:quaid] /topic EPEL Meeting|new meeting time? -- all (see also http://fedoraproject.org/wiki/EPEL/NewMeetingTime ) stahnma From fedora at leemhuis.info Wed Sep 5 05:32:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 05 Sep 2007 07:32:09 +0200 Subject: EPEL report week 35 2007 Message-ID: <46DE3F59.7050303@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week35 (sorry, a bit late this time; was busy on sunday, afk Monday after work and didn't get it completely finished yesterday evening) = Weekly EPEL Summary = Week 35/2007 == Most important happenings == * we will do alternate meeting times now; 23:00 one week, 17:00 UTC the other; next meeting at 20070905 at 23:00 UTC * FESCo [https://www.redhat.com/archives/fedora-devel-list/2007-August/msg02213.html extended the mandate] for the EPEL Steering Committee * the plan is to push new packages (not updates ones) more often to stable in the future; likely every four weeks for now -- no exact timeframe can be given yet, as we need to see how complicate it is (the process needs to be prepared manually by someone in a local test-repo first, to check if all deps are still satisfied before packages can actually be moved) == EPEL SIG Meeting == === Attending === >From the Steering Committee: * dgilmore (DennisGilmore) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Missing from the Steering Committee: * quaid (KarstenWade) === Summary === * easier pushing from testing to stable * nirik can push for EPEL as well (in addition to dgilmore, knurd and mmcgrath) * mschwendt did some improvements to the scripts (many thx mschwendt for your work!); they should make it easy to move something from testing to stable ; the final patch to the scripts-in-production was not applied yet ; knurd talked to dgilmore about it (he knows the scripts way better than I do) and wants to take a look (on his todo list after fixing plague ); if he doesn't find the time knurd will take the risk over the next few days as do it himself * we need to be careful that a update doesn't depend on something else in testing. * new meeting schedule/scheme * alternate meetings are the new black; find the details in https://www.redhat.com/archives/epel-devel-list/2007-September/msg00005.html and http://fedoraproject.org/wiki/EPEL/Meetings * MetaData for all Packages available to contributors. -- stahnma * I've been trying to get a better definition of the problem ; I understand the issue, but use-cases etc would be nice ; we need a clear stance on EPEL not stepping on RHN provided material and a way to hopefully enforce it * might be a good start to at least have a package list of RHEL4 and RHEL5 online somewhere * mandate for the Steering Committee * nirik will ask FESCo (which happened in between) * push quicker to stable * see section "most important happenings" * Free discussion around EPEL * Quotes: "I want a pony" and "the weather sucks " * stahnma> "I am trying to get some more #rhel and #rhn people involved here in EPEL "; are there any other channels/mailing lists where we should ask interested people to join us in the meetings? * stahnma> "can anyone write for RH magazine? " stahnma will evaluate and would happily write it; but maybe mether or someone else is preparing one already? * nirik is working on clamav; comments on his post appreciated; "and solving the problems with the packaging and compatibility with dag/rpmforge would be good"; on the other hand it's good if stuff is similar in Fedora and EPEL === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-September/msg00006.html == Stats == === General === Number of EPEL Contributors: unknown -- looks like we'll have it next again next week! === EPEL 5 === Number of source packages: 628 Number of binary packages: 1196 There are 29 new Packages: * amtterm | Serial-over-lan (sol) client for Intel AMT * dfu-programmer | A Device Firmware Update based USB programmer for Atmel chips * dstat | Versatile resource statistics tool * erlang | General-purpose programming language and runtime environment * iftop | Command line tool that displays bandwidth usage on an interface * jhead | Tool for displaying EXIF data embedded in JPEG images * perl-CGI-Simple | Simple totally OO CGI interface that is CGI.pm compliant * perl-CGI-Untaint | Process CGI input parameters * perl-Class-Trigger | Mixin to add / call inheritable triggers * perl-Class-Whitehole | Base class to treat unhandled method calls as errors * perl-Date-Simple | Simple date object for perl * perl-Exporter-Lite | Lightweight exporting of variables * perl-OLE-Storage_Lite | Simple Class for OLE document interface * perl-Spreadsheet-WriteExcel | Write formatted text and numbers to a cross-platform Excel binary file * perl-SQL-Abstract | Generate SQL from Perl data structures * perl-Tie-DBI | Tie hashes to DBI relational databases * perl-UNIVERSAL-exports | Lightweight, universal exporting of variables * perl-UNIVERSAL-moniker | Real world naming for classes * pexpect | Pure Python Expect-like module * php-extras | Additional PHP modules from the standard PHP distribution * php-pecl-memcache | Extension to work with the Memcached caching daemon * python-boto | A simple lightweight interface to Amazon Web Services * rootsh | Shell wrapper for auditing * shapelib | API in "C" for Shapefile handling * xbase | XBase compatible database library and tools * xbiso | ISO extraction utility for xdvdfs images * xbsql | A SQL wrapper for xbase * xclip | Command line clipboard grabber * yum-cron | Files needed to run yum updates as a cron job === EPEL 4 === Number of source packages: 413 Number of binary packages: 827 There are 30 new Packages: * createrepo | Creates a common metadata repository * gmrun | Lightweight "Run program" dialog box with search history and tab completion * iftop | Command line tool that displays bandwidth usage on an interface * pdns | A modern, advanced and high performance authoritative-only nameserver * perl-CGI-Simple | Simple totally OO CGI interface that is CGI.pm compliant * perl-CGI-Untaint | Process CGI input parameters * perl-Class-Trigger | Mixin to add / call inheritable triggers * perl-Class-Whitehole | Base class to treat unhandled method calls as errors * perl-Date-Simple | Simple date object for perl * perl-Exporter-Lite | Lightweight exporting of variables * perl-OLE-Storage_Lite | Simple Class for OLE document interface * perl-Spreadsheet-WriteExcel | Write formatted text and numbers to a cross-platform Excel binary file * perl-SQL-Abstract | Generate SQL from Perl data structures * perl-String-CRC32 | Perl interface for cyclic redundancy check generation * perl-Tie-DBI | Tie hashes to DBI relational databases * perl-UNIVERSAL-exports | Lightweight, universal exporting of variables * perl-UNIVERSAL-moniker | Real world naming for classes * pexpect | Pure Python Expect-like module * php-idn | PHP API for GNU LibIDN * python-boto | A simple lightweight interface to Amazon Web Services * python-elementtree | Fast XML parser and writer * python-urlgrabber | A high-level cross-protocol url-grabber * rootsh | Shell wrapper for auditing * shapelib | API in "C" for Shapefile handling * tidy | Utility to clean up and pretty print HTML/XHTML/XML * xbase | XBase compatible database library and tools * xbiso | ISO extraction utility for xdvdfs images * xbsql | A SQL wrapper for xbase * xclip | Command line clipboard grabber * yum | RPM installer/updater ---- ["CategoryEPELReports"] From orion at cora.nwra.com Wed Sep 5 21:50:52 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 05 Sep 2007 15:50:52 -0600 Subject: Pull perl-XML-DOM from EL-4 repo Message-ID: <46DF24BC.90608@cora.nwra.com> Can we *please* get perl-XML-DOM pulled from the EL-4 repo? I've asked everywhere I can think of, but no response. https://bugzilla.redhat.com/show_bug.cgi?id=249901 -- 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 mastahnke at gmail.com Wed Sep 5 23:48:43 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 5 Sep 2007 18:48:43 -0500 Subject: EPEL SIG Log -- 05 Sept 2007 Message-ID: <7874d9dd0709051648q2f7f87ebtbed61712ccca8c22@mail.gmail.com> [18:01] *** You set the channel topic to "EPEL Sig meeting". [18:01] afternoon stahnma (or evening or morning) [18:01] afternoon/evening [18:01] ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL [18:01] * nirik wonders if anyone else is around. ;) [18:02] me too [18:02] I thought the new time might work out better...we'll see [18:02] RobertScheck [18:03] mmcgrath: ? , Jeff_S, quaid? [18:04] ok [18:04] we don't have quarum [18:04] yeah, doesn't seem so. ;( [18:04] no voting tonight [18:04] not that anything was up on the table [18:04] *** You set the channel topic to "EPEL Meeting | push to stable easily -- knurd". [18:04] knurd is obviusly not here [18:04] but there has been discussion on list [18:05] yeah, it's the middle of his night. ;) [18:05] yup [18:05] are we making progress here? [18:05] I haven't kept up with it 100% [18:05] rsc: feel free to participate as much as you want [18:05] well, I think we decided to do monthly pushes of new packages only... [18:05] or anyone in the peanut gallery :) [18:05] pong [18:06] er [18:06] I have the info on how to do pushes now, but haven't had time to try one. [18:06] ok [18:06] monthly pushes for new packages? [18:06] yeah. [18:06] why only monthly? [18:06] to maintain stability [18:06] * mmcgrath was fine with quartly or whenever RH did it honestly. [18:06] stahnma: I am already EPEL maintainer, isn't that enough? [18:06] EL doesn't introduce new packages ad hoc [18:07] its not like we keep the testing repo private. [18:07] rsc sure is [18:07] well, we could possibly do more often, the thought is that it might be pretty time consuming [18:07] I just saw you popped in at the start of the meeting, and thought you might something to add (no worries) [18:07] stahnma: no problem. I'll shout, if there's something [18:08] right now while the repo is still growing pushing new packages into it seems to make sense [18:08] though using epel-testing also makes sense [18:08] btw, is there a real chance for getting koji for EPEL? [18:08] either way, as long as progress is being made on list, I think we can move on [18:08] rsc: not near term [18:08] moving on? [18:09] *** You set the channel topic to "EPEL Meeting | do more on the list and less in the meetings; "Power to the people with no delay." aka "Steering Committee's are slow and old style" -- all". [18:09] I think knurd snuck this one in here [18:09] It's a good reminder [18:09] lists don't have timezones to work around [18:09] yeah. It's hard to remember to make sure and reply to all the list stuff, but I think it's a good thing to try for... [18:09] I don't think there's a lot of comments on this one.... [18:10] we should also remember to send things to the list when they are talked about on irc or whatever. [18:10] *** You set the channel topic to "EPEL Meeting | MetaData for all Packages available to contributors. -- stahnma". [18:10] I had a little bit of time today to work on this [18:10] but didn't get very far [18:10] I will continue working on it tonight [18:10] one issue is that my enterprise account may not have access to all channels [18:11] it would be wonderful to get a real RHN account from RH for EPEL [18:11] or at least some representation with a direct link to RHEL/RHN [18:11] for what purpose? [18:11] to see what packages are stepping on items offered by RH [18:12] also, a new issue was brough up on list about pear/php stuff in EL4, since RH ships a moving AMP stack on RHEL [18:12] how does a maintainer build PHP packages in EL [18:13] the people I have spoken with in #rhel and #rhn about epel often sight concern over "stepping on RHN" [18:13] they are just like any other package... but yeah, no idea if they are already in some channel from RHEL [18:13] I'd be happy for us not to step on them, but it's not clear how we can find out if we are or not. [18:13] nirik: that's the issue. I will continue to look into it [18:14] I assume a solution is out there, and we may be making it more complicated than it really is [18:14] --> bpepple|lt has joined this channel (n=bpepple|@rrcs-70-61-160-147.central.biz.rr.com). [18:14] *** You set the channel topic to "EPEL Meeting | [:EPEL/CommunicationPlan:Communication plan] for enterprise customers/ISVs/IHVs -- stahnma, quaid". [18:14] sorry, I forgot to ask if we can move on [18:14] well, I would expect redhat has a way of determining if something is already offered by them or not. [18:14] (I'm new here) [18:14] :) [18:15] anyhow, yeah, move on [18:15] I have little updates on this. Again, figuring out the RHN conflicts will help the communcation/adoption of EPEL [18:15] my company is moving RHEL 5 builds to EPEL though :) [18:15] cool. [18:16] quaid isn't present, so that's all I have [18:16] this is looking like it coudl be quite a short meeting [18:16] * nirik would be ok with that. [18:16] job decription is also quaid [18:16] *** You set the channel topic to "EPEL Meeting | General Discussion". [18:17] * mmcgrath has nothing [18:17] I have a item or two real quickly... [18:17] dgilmore had mentioned he would like to step down from EPEL on the list [18:17] do we solicit for another spot to be filled? [18:18] I can bring it up on list [18:18] nirik: what do you have? [18:18] I have added epel4 and epel5 audit files in the fedora-security setup. I generated them by looking at the fc7 lists and putting in only those packages that exist in epel4 or epel5. Now comes the fun part of auditing everything to see what security updates we need/are missing. [18:18] I have slowly started on that. If anyone would like to help, let me know. [18:18] do you have any documentation describing the process? [18:18] I am not familiar with it [18:19] yeah, there is a readme and such, I can dig it up. [18:19] Basically we have a file that has each CVE listed and then if our package is vunerable or not. [18:19] I can try to help, but you can also solicit on list. [18:20] so something like: [18:20] CVE-2005-4803 version (graphviz, fixed 2.2.1) [18:20] so the graphviz in epel5 is newer than the version it was fixed in (2.2.1) so it's ok. [18:20] can that process be automated? [18:21] possibly, but it's pretty complex. [18:21] ok [18:21] There is newer version, there is backported patch, not vunlerable because it's a windows thing, etc. [18:21] ah yes, backporting [18:21] but we do need to track security well on EPEL. [18:21] that would make things hard [18:22] agreed [18:22] I can solicit the list... although it's currently in an area that requires you to be in the security team to check in changes. [18:22] ah [18:22] * stahnma is not on the security team [18:22] I can keep working on it too. [18:23] ok [18:23] any other business from anybody? [18:23] Also, a somewhat related item: [18:23] looking at security, I note there are a number of packages that have branches for epel, but don't seem to have been built. [18:23] I guess I can generate a list and bug people on the list about it. [18:24] I would assume some people are still waiting on deps [18:24] but it might be time to ping them [18:24] mediawiki has a el5 branch, but doesn't appear to be in the repo... for example. [18:24] yeah, and I would love it :) [18:24] bug reports are probably ok on that [18:24] libmodplug was another. I think there were some more too. [18:25] anyhow, just thought I would mention it. [18:25] * nirik has no more. [18:25] I will close meeting in 10 [18:25] I have something I'd like to ask about. [18:25] ok [18:25] I won't close :) [18:25] EPEL5 has lapack 3.1.1, but doesn't EL5 have lapack 3.0? [18:27] ok, I am not familiar with lapack [18:28] yeah, seems to be the case. ;( [18:28] AIUI, EPEL has not going to replace packages in the base EL set. [18:28] *was [18:28] this gets back to trying to make sure we don't step on RHEL [18:28] EL 5 has 3.0-37 [18:28] from what I can see in RHN [18:29] nirik, can shoudl this be filed as a bug with you? [18:29] well, I guess we need to just remove it... ;( [18:29] or more on the infrastructure side? [18:29] yeah, we should come up with a way to get repo requests done/tracked. [18:30] maybe we should also bring that up on list [18:30] perhaps we could setup a epel traq instance? mmcgrath ? [18:30] or use the same trac? [18:30] buhhh [18:30] yeah, or just use infrastructures... [18:30] :) [18:31] for what? when files need to be removed? [18:31] yeah, packages removed from the repo... [18:31] or general issues with epel infrastrcuture? [18:31] how is it done im fedora? [18:32] * stahnma isn't sure :) [18:32] mail to releng? [18:32] yes [18:33] are any epel-infrastructure people also in releng? [18:33] so we could just also make a epeleng alias? [18:33] who's the epel infrastructure people? [18:34] for epel we should probably email epel_signers-members at fp.o [18:34] jwb trumps me with his logic [18:34] that was a real question. but i think the answer is no [18:34] rel-eng is me, spot, rdieter, f13, jeremy, and warren [18:34] yeah, I don't know [18:35] there's no difference between the epel and normal fedora 'infrastructure' people. but epel doesn't have any release engineers. The closest thing is the signers. [18:35] ok [18:35] well, as long as a task gets handled in a timely maner, the process isn't all that important [18:35] yeah, but it would be good to have a process we can point people at... [18:35] hopefully these needs will rarely arise [18:35] true [18:36] so they don't just give up and it never gets done. [18:36] yes [18:36] should the official process just be to bring it up on epel-devel-list? [18:36] it seems easy enough, and probably effective [18:37] brb [18:37] so, for now, how about email to epel_signers-members@ ? [18:37] WORKSFORME [18:37] good catch on that ivazquez. [18:37] <-- kanarip has left this server (Remote closed the connection). [18:37] sure, that would be fine too... [18:38] --> kanarip has joined this channel (n=kanarip at fedora/kanarip). [18:38] ok [18:38] any other items? [18:38] * stahnma will close the meeting in 10 [18:38] -- MARK -- Meeting end [18:38] ivazquez: is there a bug filed on that lapack thing? If not we should so the maintainer knows whats going on. Todos: * Continue to investigate Metadata/package conflicts with RHN/EL and EPEL -- stahnma * Security setup for EPEL4-5, nirik will send out more information on list. -- nirik * How to notify the EPEL team if a package should be removed due to conflicting with EL. -- nirik * Evaluate meeting time again. Same people that are normally there, were there. Minus Knurd. From buildsys at fedoraproject.org Thu Sep 6 04:52:35 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 6 Sep 2007 00:52:35 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-06 Message-ID: <20070906045235.0E536152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 10 GeoIP-1.4.3-1.el5 NEW gkrellm-2.3.0-4.el5.1 : Multiple stacked system monitors in one process NEW gkrellm-volume-2.1.13-6.el5 : GKrellM volume plugin NEW hddtemp-0.3-0.14.beta15.el5 : Hard disk temperature tool NEW imlib-1.9.15-4.el5 : An image loading and rendering library for X11R6 NEW libcdio-0.78.2-2.el5 : CD-ROM input and control library NEW libmodplug-0.8.4-1.el5 : Modplug mod music file format library NEW libmpcdec-1.2.6-1.el5 : Musepack audio decoding library NEW perl-CGI-Untaint-date-1.00-3.el5 : Validate a date yum-cron-0.4-1.el5 Packages built and released for Fedora EPEL 4: 4 GeoIP-1.4.3-1.el4 libmpcdec-1.2.6-1.el4 NEW perl-CGI-Untaint-date-1.00-3.el4 : Validate a date NEW php-pecl-memcache-2.1.2-1.el4.1 : Extension to work with the Memcached caching daemon Changes in Fedora EPEL 5: GeoIP-1.4.3-1.el5 ----------------- * Wed Sep 05 2007 Michael Fleming 1.4.3-1 - New upstream release. - Fix GeoIPCity fetcher script - Update License tag gkrellm-2.3.0-4.el5.1 --------------------- * Wed Sep 05 2007 Ville Skytt? - 2.3.0-4.1 - Adapt to lm_sensors availability/setup in EL. * Wed Sep 05 2007 Ville Skytt? - 2.3.0-4 - Rewrite gkrellmd init script: better LSB compliance, hddtemp interoperability, avoidance of X error messages, general cleanup. * Tue Sep 04 2007 Ville Skytt? - 2.3.0-3 - Fix gnutls detection/build and use it instead of openssl. - Sync user and group creation with current Fedora guidelines. * Tue Aug 07 2007 Hans de Goede 2.3.0-2 - Update License tag for new Licensing Guidelines compliance gkrellm-volume-2.1.13-6.el5 --------------------------- * Tue Sep 04 2007 Ville Skytt? - 2.1.13-6 - Convert docs to UTF-8. * Thu Aug 16 2007 Ville Skytt? - 2.1.13-5 - License: GPLv2+ hddtemp-0.3-0.14.beta15.el5 --------------------------- * Wed Sep 05 2007 Ville Skytt? - 0.3-0.14.beta15 - Adjust server chkconfig start/stop priorities to start before gkrellmd, other cosmetic init script tweaks. - Mark hddtemp.db as %config(noreplace). imlib-1.9.15-4.el5 ------------------ * Thu Aug 09 2007 Paul Howarth 1:1.9.15-4 - re-clarify license as GNU Lesser General Public License v2 or later (LGPLv2+) * Wed Aug 08 2007 Paul Howarth 1:1.9.15-3 - redesign of enlightenment.org website removed imlib page, so URL changed to enlightenment.sourceforge.net where the original website lived (#251278) - clarify license as GNU Lesser General Public License v2 or later (LGPL+) libcdio-0.78.2-2.el5 -------------------- * Mon Jul 23 2007 Adrian Reber - 0.78.2-2 - updated to 0.78.2 (#221359) (this time for real) libmodplug-0.8.4-1.el5 ---------------------- * Wed Apr 04 2007 Ville Skytt? - 1:0.8.4-1 - 0.8.4. libmpcdec-1.2.6-1.el5 --------------------- * Wed Jun 06 2007 Rex Dieter 1.2.6-1 - libmpcdec-1.2.6 perl-CGI-Untaint-date-1.00-3.el5 -------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 1.00-3 - fix license tag yum-cron-0.4-1.el5 ------------------ * Mon Sep 03 2007 Alec Habig - 0.4-1 - Fix bug in cron.daily which was preventing updates from running - Integrate Frank's checkonly patches into the source Changes in Fedora EPEL 4: GeoIP-1.4.3-1.el4 ----------------- * Wed Sep 05 2007 Michael Fleming 1.4.3-1 - New upstream release. - Fix GeoIPCity fetcher script - Update License tag libmpcdec-1.2.6-1.el4 --------------------- * Wed Jun 06 2007 Rex Dieter 1.2.6-1 - libmpcdec-1.2.6 perl-CGI-Untaint-date-1.00-3.el4 -------------------------------- * Fri Aug 24 2007 Tom "spot" Callaway 1.00-3 - fix license tag php-pecl-memcache-2.1.2-1.el4.1 ------------------------------- * Sat Sep 01 2007 Remi Collet 2.1.2-1.el4.1 - specific spec for EL4 - memcache-php439.patch, see http://pecl.php.net/bugs/bug.php?id=11953 * Mon Aug 20 2007 Remi Collet 2.1.2-1 - initial RPM 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 Sep 6 11:05:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Sep 2007 13:05:52 +0200 Subject: yum-cron and CentOS Message-ID: <46DFDF10.4080002@leemhuis.info> Hi, z00dax in #centos-devel made me aware of a issue: EPEL5-testing contains a yum-cron package since a few days which replaces the package with the same name from CentOS-base. As we try to not conflict with CentOS-base I'd say we go the same route as we did for yum in EPEL4 -- ship the CentOS package with a lower EVR; then users that want to use the package on RHEL5 can use it while we don't disturb CenOS. Comments? Cu knurd From mmcgrath at redhat.com Thu Sep 6 13:08:52 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 06 Sep 2007 08:08:52 -0500 Subject: yum-cron and CentOS In-Reply-To: <46DFDF10.4080002@leemhuis.info> References: <46DFDF10.4080002@leemhuis.info> Message-ID: <46DFFBE4.9000002@redhat.com> Thorsten Leemhuis wrote: > Hi, > > z00dax in #centos-devel made me aware of a issue: EPEL5-testing contains > a yum-cron package since a few days which replaces the package with the > same name from CentOS-base. > > As we try to not conflict with CentOS-base I'd say we go the same route > as we did for yum in EPEL4 -- ship the CentOS package with a lower EVR; > then users that want to use the package on RHEL5 can use it while we > don't disturb CenOS. > > Comments? > Its a package in CentOS-base but not RHEL? -Mike From fedora at leemhuis.info Thu Sep 6 13:20:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Sep 2007 15:20:31 +0200 Subject: yum-cron and CentOS In-Reply-To: <46DFFBE4.9000002@redhat.com> References: <46DFDF10.4080002@leemhuis.info> <46DFFBE4.9000002@redhat.com> Message-ID: <46DFFE9F.6040203@leemhuis.info> On 06.09.2007 15:08, Mike McGrath wrote: > Thorsten Leemhuis wrote: >> z00dax in #centos-devel made me aware of a issue: EPEL5-testing contains >> a yum-cron package since a few days which replaces the package with the >> same name from CentOS-base. >> >> As we try to not conflict with CentOS-base I'd say we go the same route >> as we did for yum in EPEL4 -- ship the CentOS package with a lower EVR; >> then users that want to use the package on RHEL5 can use it while we >> don't disturb CenOS. >> >> Comments? > > Its a package in CentOS-base but not RHEL? > Yes: [root at dhcp-200 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5 (Tikanga) [root at dhcp-200 ~]# yum list yum* | grep cron [root at dhcp-200 ~]# http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/5.0/os/x86_64/CentOS/yum-cron-0.1-1.el5.centos.noarch.rpm One of course could argue "If CentOS wants to be 100% compatible to RHEL then they should not add something to their Base OS that's not strictly needed" -- but I suppose some people would send out the Nijas after someone that dares to say that. /me hides CU knurd From mmcgrath at redhat.com Thu Sep 6 13:23:17 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 06 Sep 2007 08:23:17 -0500 Subject: yum-cron and CentOS In-Reply-To: <46DFFE9F.6040203@leemhuis.info> References: <46DFDF10.4080002@leemhuis.info> <46DFFBE4.9000002@redhat.com> <46DFFE9F.6040203@leemhuis.info> Message-ID: <46DFFF45.7060501@redhat.com> Thorsten Leemhuis wrote: > On 06.09.2007 15:08, Mike McGrath wrote: > >> Thorsten Leemhuis wrote: >> >>> z00dax in #centos-devel made me aware of a issue: EPEL5-testing contains >>> a yum-cron package since a few days which replaces the package with the >>> same name from CentOS-base. >>> >>> As we try to not conflict with CentOS-base I'd say we go the same route >>> as we did for yum in EPEL4 -- ship the CentOS package with a lower EVR; >>> then users that want to use the package on RHEL5 can use it while we >>> don't disturb CenOS. >>> >>> Comments? >>> >> Its a package in CentOS-base but not RHEL? >> >> > > Yes: > > [root at dhcp-200 ~]# cat /etc/redhat-release > Red Hat Enterprise Linux Server release 5 (Tikanga) > [root at dhcp-200 ~]# yum list yum* | grep cron > [root at dhcp-200 ~]# > > http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/5.0/os/x86_64/CentOS/yum-cron-0.1-1.el5.centos.noarch.rpm > > One of course could argue "If CentOS wants to be 100% compatible to RHEL > then they should not add something to their Base OS that's not strictly > needed" -- but I suppose some people would send out the Nijas after > someone that dares to say that. > meh, I don't think we need to be in the business of telling CentOS what to do :) +1 to lower EVR I guess unless there's a compelling reason not to that I'm not thinking of. I wonder if we could get a list of all packages CentOS has added. If they've added them, odds are they're popular enough that we'll likely add them as well. -Mike From mastahnke at gmail.com Thu Sep 6 14:09:45 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 6 Sep 2007 09:09:45 -0500 Subject: yum-cron and CentOS In-Reply-To: <46DFFF45.7060501@redhat.com> References: <46DFDF10.4080002@leemhuis.info> <46DFFBE4.9000002@redhat.com> <46DFFE9F.6040203@leemhuis.info> <46DFFF45.7060501@redhat.com> Message-ID: <7874d9dd0709060709nba1f6fev8dd89f4180086903@mail.gmail.com> On 9/6/07, Mike McGrath wrote: > Thorsten Leemhuis wrote: > > On 06.09.2007 15:08, Mike McGrath wrote: > > > >> Thorsten Leemhuis wrote: > >> > >>> z00dax in #centos-devel made me aware of a issue: EPEL5-testing contains > >>> a yum-cron package since a few days which replaces the package with the > >>> same name from CentOS-base. > >>> > >>> As we try to not conflict with CentOS-base I'd say we go the same route > >>> as we did for yum in EPEL4 -- ship the CentOS package with a lower EVR; > >>> then users that want to use the package on RHEL5 can use it while we > >>> don't disturb CenOS. > >>> > >>> Comments? > >>> > >> Its a package in CentOS-base but not RHEL? > >> > >> > > > > Yes: > > > > [root at dhcp-200 ~]# cat /etc/redhat-release > > Red Hat Enterprise Linux Server release 5 (Tikanga) > > [root at dhcp-200 ~]# yum list yum* | grep cron > > [root at dhcp-200 ~]# > > > > http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/5.0/os/x86_64/CentOS/yum-cron-0.1-1.el5.centos.noarch.rpm > > > > One of course could argue "If CentOS wants to be 100% compatible to RHEL > > then they should not add something to their Base OS that's not strictly > > needed" -- but I suppose some people would send out the Nijas after > > someone that dares to say that. > > > > meh, I don't think we need to be in the business of telling CentOS what > to do :) > > +1 to lower EVR I guess unless there's a compelling reason not to that > I'm not thinking of. I wonder if we could get a list of all packages > CentOS has added. If they've added them, odds are they're popular > enough that we'll likely add them as well. +1. I will see if I can get a list. stahnma > > -Mike > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From mattdm at mattdm.org Thu Sep 6 17:36:28 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Sep 2007 13:36:28 -0400 Subject: yum-cron and CentOS In-Reply-To: <46DFFE9F.6040203@leemhuis.info> References: <46DFDF10.4080002@leemhuis.info> <46DFFBE4.9000002@redhat.com> <46DFFE9F.6040203@leemhuis.info> Message-ID: <20070906173628.GA14848@jadzia.bu.edu> On Thu, Sep 06, 2007 at 03:20:31PM +0200, Thorsten Leemhuis wrote: > One of course could argue "If CentOS wants to be 100% compatible to RHEL > then they should not add something to their Base OS that's not strictly > needed" -- but I suppose some people would send out the Nijas after > someone that dares to say that. This is historical: CentOS started when RHEL was still using up2date. Obviously, that wasn't an option, and neither was having *no* high-level package management system, so they replaced it with yum. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Thu Sep 6 17:52:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Sep 2007 19:52:46 +0200 Subject: yum-cron and CentOS In-Reply-To: <20070906173628.GA14848@jadzia.bu.edu> References: <46DFDF10.4080002@leemhuis.info> <46DFFBE4.9000002@redhat.com> <46DFFE9F.6040203@leemhuis.info> <20070906173628.GA14848@jadzia.bu.edu> Message-ID: <46E03E6E.3010407@leemhuis.info> On 06.09.2007 19:36, Matthew Miller wrote: > On Thu, Sep 06, 2007 at 03:20:31PM +0200, Thorsten Leemhuis wrote: >> One of course could argue "If CentOS wants to be 100% compatible to RHEL >> then they should not add something to their Base OS that's not strictly >> needed" -- but I suppose some people would send out the Nijas after >> someone that dares to say that. > > This is historical: CentOS started when RHEL was still using up2date. > Obviously, that wasn't an option, and neither was having *no* high-level > package management system, so they replaced it with yum. Which is exactly the reasons why my statement had a "that's not strictly needed" in it ;-) But yum is part of RHEL5 and yum-updatesd is as well. So I'd say yum-cron is not strictly needed. But let's not discuss this further. It's a academical discussion that doesn't lead to anything and is likely not worth to continue it. Cu knurd From smooge at gmail.com Thu Sep 6 17:53:35 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 6 Sep 2007 11:53:35 -0600 Subject: yum-cron and CentOS In-Reply-To: <46DFFE9F.6040203@leemhuis.info> References: <46DFDF10.4080002@leemhuis.info> <46DFFBE4.9000002@redhat.com> <46DFFE9F.6040203@leemhuis.info> Message-ID: <80d7e4090709061053k3f38f9dtef5f39fc017a01f9@mail.gmail.com> On 9/6/07, Thorsten Leemhuis wrote: > On 06.09.2007 15:08, Mike McGrath wrote: > > Thorsten Leemhuis wrote: > >> z00dax in #centos-devel made me aware of a issue: EPEL5-testing contains > >> a yum-cron package since a few days which replaces the package with the > >> same name from CentOS-base. > >> > >> As we try to not conflict with CentOS-base I'd say we go the same route > >> as we did for yum in EPEL4 -- ship the CentOS package with a lower EVR; > >> then users that want to use the package on RHEL5 can use it while we > >> don't disturb CenOS. > >> > >> Comments? > > > > Its a package in CentOS-base but not RHEL? > > > > Yes: > > [root at dhcp-200 ~]# cat /etc/redhat-release > Red Hat Enterprise Linux Server release 5 (Tikanga) > [root at dhcp-200 ~]# yum list yum* | grep cron > [root at dhcp-200 ~]# > > http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/5.0/os/x86_64/CentOS/yum-cron-0.1-1.el5.centos.noarch.rpm > > One of course could argue "If CentOS wants to be 100% compatible to RHEL > then they should not add something to their Base OS that's not strictly > needed" -- but I suppose some people would send out the Nijas after > someone that dares to say that. > > /me hides > yum-cron was added to CentOS-5 at the recommendation of the yum maintainer Seth Vidal. At that time yum-updatesd was blowing up to 256 MB at times which was enough to cause some boxes to go into swap heaven.. his recommendation was to just include yum-cron as it was what people expected to have. Shirt-ninja #200 -- 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 fedora at leemhuis.info Thu Sep 6 18:10:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Sep 2007 20:10:05 +0200 Subject: yum-cron and CentOS In-Reply-To: <80d7e4090709061053k3f38f9dtef5f39fc017a01f9@mail.gmail.com> References: <46DFDF10.4080002@leemhuis.info> <46DFFBE4.9000002@redhat.com> <46DFFE9F.6040203@leemhuis.info> <80d7e4090709061053k3f38f9dtef5f39fc017a01f9@mail.gmail.com> Message-ID: <46E0427D.20201@leemhuis.info> On 06.09.2007 19:53, Stephen John Smoogen wrote: > On 9/6/07, Thorsten Leemhuis wrote: > > yum-cron was added to CentOS-5 at the recommendation of the yum > maintainer Seth Vidal. At that time yum-updatesd was blowing up to 256 MB > at times which was enough to cause some boxes to go into swap heaven.. > his recommendation was to just include yum-cron as it was what people > expected to have. Okay, that's a good reason then ;-) Cu knurd From mastahnke at gmail.com Thu Sep 6 22:50:59 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 6 Sep 2007 17:50:59 -0500 Subject: yum-cron and CentOS In-Reply-To: <46E0427D.20201@leemhuis.info> References: <46DFDF10.4080002@leemhuis.info> <46DFFBE4.9000002@redhat.com> <46DFFE9F.6040203@leemhuis.info> <80d7e4090709061053k3f38f9dtef5f39fc017a01f9@mail.gmail.com> <46E0427D.20201@leemhuis.info> Message-ID: <7874d9dd0709061550p6dd4c105s69fd640398d423e3@mail.gmail.com> I spoke with z00dax on #centos-devel about a couple things. 1. For a list of packages/modified add from RHEL base on CentOS you can see http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.0 I read through it and only saw a few yum things jump out at me and I *think* they have all been addressed. 2. The CentOS folks seem to want to work together when packages require updates. This mostly is from CentOS Plus , Extras but also could apply to the base OS. So, if you're an EPEL maintainer and CentOS has a package, it wouldn't hurt to ping them with what/why you're updating. if there is a package that comes via centos, and someone thinks it needs an update / change / fix - we all gain by fixing it everywhere stahnma From fedora at leemhuis.info Fri Sep 7 04:57:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 07 Sep 2007 06:57:05 +0200 Subject: yum-cron and CentOS In-Reply-To: <7874d9dd0709061550p6dd4c105s69fd640398d423e3@mail.gmail.com> References: <46DFDF10.4080002@leemhuis.info> <46DFFBE4.9000002@redhat.com> <46DFFE9F.6040203@leemhuis.info> <80d7e4090709061053k3f38f9dtef5f39fc017a01f9@mail.gmail.com> <46E0427D.20201@leemhuis.info> <7874d9dd0709061550p6dd4c105s69fd640398d423e3@mail.gmail.com> Message-ID: <46E0DA21.7060903@leemhuis.info> On 07.09.2007 00:50, Michael Stahnke wrote: > > if there is a package that comes via centos, and someone > thinks it needs an update / change / fix - we all gain by fixing it > everywhere +1 -- BTW, is the yum-cron maintainer of this list? CU knurd From mastahnke at gmail.com Mon Sep 10 15:46:14 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Mon, 10 Sep 2007 10:46:14 -0500 Subject: EPEL Weekly Report Message-ID: <7874d9dd0709100846m7ada0aa5v47701e01480688b2@mail.gmail.com> = Weekly EPEL Summary = Week 36/2007 == Most important happenings == * EPEL SIG tried alternative meeting time (23:00 UTC). The participation was nearly identical to meetings taking place at the old time. More discussion will likely occur on how to engage more EPEL involvement. * Stahnma is still investigating the best way to deal with package information to ensure that EPEL is not stepping on packages from RHEL/RHN. Thus far a list of channels with package information is available at stahnma.fedorapeople.org/rhn. * Nirik is working on setting up the security groups for EPEL so updates can match be CVEs etc. * Nirik will send out information to the list on the best way to notify EPEL if a package needs to be pulled because it conflicts with RHEL/RHN content. * Some discussion with with CentOS developers. CentOS developers would like to have a bit more collaberation and ensure that if a package requires updating for EPEL that CentOS be made aware of it also. (See https://www.redhat.com/archives/epel-devel-list/2007-September/msg00021.html ) == EPEL SIG Meeting == === Attending === >From the Steering Committee: * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * stahnma (MichaelStahnke) Missing from the Steering Committee: * knurd (ThorstenLeemhuis) * dgilmore (DennisGilmore) * quaid (KarstenWade) * Jeff_S (Jeff Sheltren) Other Participants * jwb * ivazquez * rsc === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-September/msg00010.html == Stats == === General === Number of EPEL Contributors: unknown -- looks like we'll have it next again next week! === EPEL 5 === Number of source packages: 636 Number of binary packages: 1244 There are 37 new Packages: * amtterm | Serial-over-lan (sol) client for Intel AMT * dfu-programmer | A Device Firmware Update based USB programmer for Atmel chips * dstat | Versatile resource statistics tool * erlang | General-purpose programming language and runtime environment * gkrellm | Multiple stacked system monitors in one process * gkrellm-volume | GKrellM volume plugin * hddtemp | Hard disk temperature tool * iftop | Command line tool that displays bandwidth usage on an interface * imlib | An image loading and rendering library for X11R6 * jhead | Tool for displaying EXIF data embedded in JPEG images * libcdio | CD-ROM input and control library * libmodplug | Modplug mod music file format library * libmpcdec | Musepack audio decoding library * perl-CGI-Simple | Simple totally OO CGI interface that is CGI.pm compliant * perl-CGI-Untaint-date | Validate a date * perl-CGI-Untaint | Process CGI input parameters * perl-Class-Trigger | Mixin to add / call inheritable triggers * perl-Class-Whitehole | Base class to treat unhandled method calls as errors * perl-Date-Simple | Simple date object for perl * perl-Exporter-Lite | Lightweight exporting of variables * perl-OLE-Storage_Lite | Simple Class for OLE document interface * perl-Spreadsheet-WriteExcel | Write formatted text and numbers to a cross-platform Excel binary file * perl-SQL-Abstract | Generate SQL from Perl data structures * perl-Tie-DBI | Tie hashes to DBI relational databases * perl-UNIVERSAL-exports | Lightweight, universal exporting of variables * perl-UNIVERSAL-moniker | Real world naming for classes * pexpect | Pure Python Expect-like module * php-extras | Additional PHP modules from the standard PHP distribution * php-pecl-memcache | Extension to work with the Memcached caching daemon * python-boto | A simple lightweight interface to Amazon Web Services * rootsh | Shell wrapper for auditing * shapelib | API in "C" for Shapefile handling * xbase | XBase compatible database library and tools * xbiso | ISO extraction utility for xdvdfs images * xbsql | A SQL wrapper for xbase * xclip | Command line clipboard grabber * yum-cron | Files needed to run yum updates as a cron job === EPEL 4 === Number of source packages: 415 Number of binary packages: 847 There are 32 new Packages: * createrepo | Creates a common metadata repository * gmrun | Lightweight "Run program" dialog box with search history and tab completion * iftop | Command line tool that displays bandwidth usage on an interface * pdns | A modern, advanced and high performance authoritative-only nameserver * perl-CGI-Simple | Simple totally OO CGI interface that is CGI.pm compliant * perl-CGI-Untaint-date | Validate a date * perl-CGI-Untaint | Process CGI input parameters * perl-Class-Trigger | Mixin to add / call inheritable triggers * perl-Class-Whitehole | Base class to treat unhandled method calls as errors * perl-Date-Simple | Simple date object for perl * perl-Exporter-Lite | Lightweight exporting of variables * perl-OLE-Storage_Lite | Simple Class for OLE document interface * perl-Spreadsheet-WriteExcel | Write formatted text and numbers to a cross-platform Excel binary file * perl-SQL-Abstract | Generate SQL from Perl data structures * perl-String-CRC32 | Perl interface for cyclic redundancy check generation * perl-Tie-DBI | Tie hashes to DBI relational databases * perl-UNIVERSAL-exports | Lightweight, universal exporting of variables * perl-UNIVERSAL-moniker | Real world naming for classes * pexpect | Pure Python Expect-like module * php-idn | PHP API for GNU LibIDN * php-pecl-memcache | Extension to work with the Memcached caching daemon * python-boto | A simple lightweight interface to Amazon Web Services * python-elementtree | Fast XML parser and writer * python-urlgrabber | A high-level cross-protocol url-grabber * rootsh | Shell wrapper for auditing * shapelib | API in "C" for Shapefile handling * tidy | Utility to clean up and pretty print HTML/XHTML/XML * xbase | XBase compatible database library and tools * xbiso | ISO extraction utility for xdvdfs images * xbsql | A SQL wrapper for xbase * xclip | Command line clipboard grabber * yum | RPM installer/updater ---- ["CategoryEPELReports"] From buildsys at fedoraproject.org Mon Sep 10 22:00:31 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 10 Sep 2007 18:00:31 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-10 Message-ID: <20070910220031.21CD8152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 0 Packages built and released for Fedora EPEL testing/5: 23 NEW abcde-2.3.99.6-3.el5 : A Better CD Encoder NEW aspell-sk-0.52-3.el5 : Slovak dictionaries for Aspell NEW cd-discid-0.9-7.el5 : Utility to get CDDB discid information NEW cvs2cl-2.67-1.el5 : Generate ChangeLogs from CVS working copies NEW directfb-1.0.0-0.1.rc3.el5 : Graphics abstraction library for the Linux Framebuffer Device NEW gperiodic-2.0.10-1.el5 : Program for browsing the periodic table NEW gtk-qt-engine-0.70-5.20070811svn.el5 : A project allowing GTK to use Qt widget styles. NEW isync-1.0.3-3.el5 : Tool to synchronize IMAP4 and Maildir mailboxes NEW kasablanca-0.4.0.2-10.el5 : Graphical FTP client NEW lighttpd-1.4.18-1.el5 : Lightning fast webserver with light system requirements NEW mksh-31-1.el5 : MirBSD enhanced version of the Korn Shell NEW php-pear-DB-DataObject-1.8.7-1.el5 : An SQL Builder, Object Interface to Database Tables NEW php-pear-Pager-2.4.4-1.el5 : Data paging class NEW php-pecl-radius-1.2.5-1.el5 : Radius client library NEW php-pecl-xdebug-2.0.0-1.el5 : PECL package for debugging PHP scripts NEW phpMyAdmin-2.11.0-1.el5 : Web based MySQL browser written in php NEW plone-3.0-1.el5 : User friendly and powerful open source Content Management System NEW qgit-1.5.7-1.el5 : QGit is a git GUI repository browser NEW qucs-0.0.12-3.el5 : Circuit simulator NEW sipp-2.0.1-4.el5 : SIP test tool / traffic generator NEW svn2cl-0.9-1.el5 : Create a ChangeLog from a Subversion log NEW tomcat-native-1.1.10-1.el5 : Tomcat native library NEW zope-2.10.4-3.el5 : Web application server for flexible content management applications Packages built and released for Fedora EPEL 4: 0 Packages built and released for Fedora EPEL testing/4: 7 NEW graphviz-2.6-4.el4 : Graph Visualization Tools NEW isync-1.0.3-3.el4 : Tool to synchronize IMAP4 and Maildir mailboxes NEW mksh-31-1.el4 : MirBSD enhanced version of the Korn Shell NEW phpMyAdmin-2.11.0-1.el4 : Web based MySQL browser written in php NEW qgit-1.5.7-1.el4 : QGit is a git GUI repository browser NEW qucs-0.0.12-3.el4 : Circuit simulator NEW sipp-2.0.1-4.el4 : SIP test tool / traffic generator Changes in Fedora EPEL 5: Changes in Fedora EPEL testing/5: abcde-2.3.99.6-3.el5 -------------------- * Mon Aug 13 2007 Ville Skytt? - 2.3.99.6-3 - License: GPLv2+ - Add (empty) %build section. aspell-sk-0.52-3.el5 -------------------- * Thu Sep 06 2007 Jan ONDREJ (SAL) - 0.52-3 - changed requirement to aspell >= 12:0.60 because of there worldlist incompatibility - debug_package set to nil to prevent empty debuginfo package - configure is called with sh interpreter to prevent rpmlint errors * Thu Sep 06 2007 Jan ONDREJ (SAL) - 0.52-2 - added macros to Source tag - cleanups * Sun Aug 26 2007 Jan ONDREJ (SAL) - 0.52-1 - initial release - configure rename to reconfigure to skip rpmlint errors cd-discid-0.9-7.el5 ------------------- * Thu Aug 16 2007 Ville Skytt? - 0.9-7 - License: GPLv2+ - Add URL. cvs2cl-2.67-1.el5 ----------------- * Mon Aug 13 2007 Ville Skytt? - 2.67-1 - 2.67 + man page fix. - Fix spelling error in %description. - License: GPLv2+ directfb-1.0.0-0.1.rc3.el5 -------------------------- * Fri Feb 02 2007 Matthias Saou 1.0.0-0.1.rc3 - Update to 1.0.0-rc3. gperiodic-2.0.10-1.el5 ---------------------- * Sat Sep 08 2007 Eric Tanguy 2.0.10-1 - New upstream version gtk-qt-engine-0.70-5.20070811svn.el5 ------------------------------------ * Sat Aug 11 2007 Rex Dieter 0.70-5.20070811svn - gtk-qt-engine-20070811svn (revision 38) - License: GPLv2 isync-1.0.3-3.el5 ----------------- * Sun Sep 09 2007 Lubomir Kundrak 1.0.3-3 - Fix code for the case where open() is a macro. (thanks to Marek Mahut) - Cosmetic fixes. (#282261) (thanks to Till Maas) * Fri Sep 07 2007 Lubomir Kundrak 1.0.3-2 - Added dependency on OpenSSL for SSL/TLS support * Fri Sep 07 2007 Lubomir Kundrak 1.0.3-1 - Initial package kasablanca-0.4.0.2-10.el5 ------------------------- * Mon Aug 20 2007 Rex Dieter 0.4.0.2-10 - License: GPLv2+ - cosmetics lighttpd-1.4.18-1.el5 --------------------- * Mon Sep 10 2007 Matthias Saou 1.4.18-1 - Update to 1.4.18. - Include newly installed lighttpd-angel ("angel" process meant to always run as root and restart lighttpd when it crashes, spawn processes on SIGHUP), but it's in testing stage and must be run with -D for now. * Wed Sep 05 2007 Matthias Saou 1.4.17-1 - Update to 1.4.17. - Update defaultconf patch to match new example configuration. - Include patch to fix log file rotation with max-workers set (trac #902). - Add /var/run/lighttpd/ directory where to put fastcgi sockets. * Thu Aug 23 2007 Matthias Saou 1.4.16-3 - Add /usr/bin/awk build requirement, used to get LIGHTTPD_VERSION_ID. * Wed Aug 22 2007 Matthias Saou 1.4.16-2 - Rebuild to fix wrong execmem requirement on ppc32. mksh-31-1.el5 ------------- * Sat Sep 08 2007 Robert Scheck 31-1 - Upgrade to 31 * Tue Aug 28 2007 Robert Scheck 30-2 - Updated the license tag according to the guidelines php-pear-DB-DataObject-1.8.7-1.el5 ---------------------------------- * Sat Sep 08 2007 Christopher Stone 1.8.7-1 - Upstream sync - Update license file php-pear-Pager-2.4.4-1.el5 -------------------------- * Sat Sep 08 2007 Christopher Stone 2.4.4-1 - Upstream sync php-pecl-radius-1.2.5-1.el5 --------------------------- * Sat Sep 08 2007 Christopher Stone 1.2.5-1 - Upstream sync php-pecl-xdebug-2.0.0-1.el5 --------------------------- * Sat Sep 08 2007 Christopher Stone 2.0.0-1 - Upstream sync - Remove %{?beta} tags phpMyAdmin-2.11.0-1.el5 ----------------------- * Thu Sep 06 2007 Mike McGrath 2.11.0-1 - Upstream released new version - Altered sources file as required - Added proper license plone-3.0-1.el5 --------------- * Thu Aug 23 2007 Jonathan Steffan 3.0-1 - Moved plone install back to software_home - Updated to Plone 3.0 final release qgit-1.5.7-1.el5 ---------------- * Sat Sep 08 2007 Dan Horak 1.5.7-1 - update to upstream version 1.5.7 - fixes #268381 - update license tag qucs-0.0.12-3.el5 ----------------- * Sun Sep 09 2007 Eric Tanguy - 0.0.12-3 - Modifiy qucs.desktop BZ 283941 sipp-2.0.1-4.el5 ---------------- * Fri Sep 07 2007 Peter Lemenkov 2.0.1-4 - Removed .svn entries (close BZ #282431) - Added macro for builds for EL-4 svn2cl-0.9-1.el5 ---------------- * Sun Apr 08 2007 Ville Skytt? - 0.9-1 - 0.9. tomcat-native-1.1.10-1.el5 -------------------------- * Thu Sep 06 2007 Ville Skytt? - 1.1.10-1 - First Fedora build. * Mon Aug 20 2007 Ville Skytt? - 1.1.10-0.2 - License: ASL 2.0. zope-2.10.4-3.el5 ----------------- * Mon Sep 03 2007 Jonathan Steffan 2.10.4-3 - Updated Requires for libxml2-python and python-elementtree * Tue Aug 14 2007 Jonathan Steffan 2.10.4-2 - Added config patch Changes in Fedora EPEL 4: Changes in Fedora EPEL testing/4: graphviz-2.6-4.el4 ------------------ * Mon Sep 10 2007 Patrick "Jima" Laughton 2.6-4 - Bump-n-build to fix libperl.so dependency isync-1.0.3-3.el4 ----------------- * Sun Sep 09 2007 Lubomir Kundrak 1.0.3-3 - Fix code for the case where open() is a macro. (thanks to Marek Mahut) - Cosmetic fixes. (#282261) (thanks to Till Maas) * Fri Sep 07 2007 Lubomir Kundrak 1.0.3-2 - Added dependency on OpenSSL for SSL/TLS support * Fri Sep 07 2007 Lubomir Kundrak 1.0.3-1 - Initial package mksh-31-1.el4 ------------- * Sat Sep 08 2007 Robert Scheck 31-1 - Upgrade to 31 * Tue Aug 28 2007 Robert Scheck 30-2 - Updated the license tag according to the guidelines phpMyAdmin-2.11.0-1.el4 ----------------------- * Thu Sep 06 2007 Mike McGrath 2.11.0-1 - Upstream released new version - Altered sources file as required - Added proper license qgit-1.5.7-1.el4 ---------------- * Sat Sep 08 2007 Dan Horak 1.5.7-1 - update to upstream version 1.5.7 - fixes #268381 - update license tag qucs-0.0.12-3.el4 ----------------- * Sun Sep 09 2007 Eric Tanguy - 0.0.12-3 - Modifiy qucs.desktop BZ 283941 sipp-2.0.1-4.el4 ---------------- * Fri Sep 07 2007 Peter Lemenkov 2.0.1-4 - Removed .svn entries (close BZ #282431) - Added macro for builds for EL-4 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 Mon Sep 10 22:35:08 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 10 Sep 2007 16:35:08 -0600 Subject: EPEL Weekly Report In-Reply-To: <7874d9dd0709100846m7ada0aa5v47701e01480688b2@mail.gmail.com> References: <7874d9dd0709100846m7ada0aa5v47701e01480688b2@mail.gmail.com> Message-ID: <80d7e4090709101535j29ea494bra186260e9dd0533@mail.gmail.com> On 9/10/07, Michael Stahnke wrote: > = Weekly EPEL Summary = > > Week 36/2007 > > == Most important happenings == > > * EPEL SIG tried alternative meeting time (23:00 UTC). The > participation was nearly identical to meetings taking place at the old > time. More discussion will likely occur on how to engage more EPEL > involvement. > > > > == EPEL SIG Meeting == > > === Attending === > > >From the Steering Committee: > > > * mmcgrath (MikeMcGrath) > * nirik (KevinFenzi) > * stahnma (MichaelStahnke) > > Missing from the Steering Committee: > > * knurd (ThorstenLeemhuis) > * dgilmore (DennisGilmore) > * quaid (KarstenWade) > * Jeff_S (Jeff Sheltren) > > Other Participants > > * jwb > * ivazquez > * rsc > I can make Thursday/Fridays between 20:00->23:00. My time on Mon-Wed is pretty much booked these days. -- 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 florin at andrei.myip.org Tue Sep 11 17:38:07 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 11 Sep 2007 10:38:07 -0700 Subject: nagios is 2.9 but nrpe is 2.7 in the EPEL4 repo Message-ID: <46E6D27F.8020107@andrei.myip.org> Is it OK to use nrpe-2.7 with nagios-2.9? -- Florin Andrei http://florin.myip.org/ From mmcgrath at redhat.com Tue Sep 11 17:43:10 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 11 Sep 2007 12:43:10 -0500 Subject: nagios is 2.9 but nrpe is 2.7 in the EPEL4 repo In-Reply-To: <46E6D27F.8020107@andrei.myip.org> References: <46E6D27F.8020107@andrei.myip.org> Message-ID: <46E6D3AE.9020001@redhat.com> Florin Andrei wrote: > Is it OK to use nrpe-2.7 with nagios-2.9? > yes, they are on different release cycles. -Mike From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Sep 12 11:28:24 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 12 Sep 2007 13:28:24 +0200 Subject: EPEL build failures? Plague problem? Message-ID: <20070912132824.41f10233@python3.es.egwn.lan> Hi, I just rebuilt gkrellm-freq for EL-5, but the build "failed" for ppc. The build.log indicates that everything went fine, "exit 0" at the very end confirms this... Something is going wrong with plague? http://buildsys.fedoraproject.org/logs/fedora-5-epel/36278-gkrellm-freq-1.0-7.el5/ Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.5-71.fc7 Load : 0.55 0.62 0.63 From mmcgrath at redhat.com Wed Sep 12 13:12:15 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 12 Sep 2007 08:12:15 -0500 Subject: EPEL build failures? Plague problem? In-Reply-To: <20070912132824.41f10233@python3.es.egwn.lan> References: <20070912132824.41f10233@python3.es.egwn.lan> Message-ID: <46E7E5AF.5030107@redhat.com> Matthias Saou wrote: > Hi, > > I just rebuilt gkrellm-freq for EL-5, but the build "failed" for ppc. > The build.log indicates that everything went fine, "exit 0" at the very > end confirms this... > > Something is going wrong with plague? > > http://buildsys.fedoraproject.org/logs/fedora-5-epel/36278-gkrellm-freq-1.0-7.el5/ > Plague isn't moving the status beyond prepping (even though in reality the build does move on from there and completes). There is a check in plague to make sure that mock never exits during the prep status, if it does, regardless of how mock's exit code, then its a failed build. I've been adding some code here and there though I've not had much success. I'm still working on it but since it's hard to duplicate and my familiarity with plague isn't great it's taken longer then I'd hoped, please bare with me and continue to report these successful-failed builds. -Mike From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Sep 12 14:11:44 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 12 Sep 2007 16:11:44 +0200 Subject: EPEL build failures? Plague problem? In-Reply-To: <46E7E5AF.5030107@redhat.com> References: <20070912132824.41f10233@python3.es.egwn.lan> <46E7E5AF.5030107@redhat.com> Message-ID: <20070912161144.27ec20ed@python3.es.egwn.lan> Mike McGrath wrote : > Matthias Saou wrote: > > Hi, > > > > I just rebuilt gkrellm-freq for EL-5, but the build "failed" for ppc. > > The build.log indicates that everything went fine, "exit 0" at the very > > end confirms this... > > > > Something is going wrong with plague? > > > > http://buildsys.fedoraproject.org/logs/fedora-5-epel/36278-gkrellm-freq-1.0-7.el5/ > > > > Plague isn't moving the status beyond prepping (even though in reality > the build does move on from there and completes). There is a check in > plague to make sure that mock never exits during the prep status, if it > does, regardless of how mock's exit code, then its a failed build. I've > been adding some code here and there though I've not had much success. > I'm still working on it but since it's hard to duplicate and my > familiarity with plague isn't great it's taken longer then I'd hoped, > please bare with me and continue to report these successful-failed builds. You've mostly lost me here, but I guess the answer is "yes, something is going wrong with plague, and I'm trying to find out what" :-) What should I do? Try to trigger the build again? Or is it 100% reproducible for a given tag of a given package? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora release 7 (Moonshine) - Linux kernel 2.6.22.5-71.fc7 Load : 0.24 0.51 0.70 From mmcgrath at redhat.com Wed Sep 12 14:07:26 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 12 Sep 2007 09:07:26 -0500 Subject: EPEL build failures? Plague problem? In-Reply-To: <20070912161144.27ec20ed@python3.es.egwn.lan> References: <20070912132824.41f10233@python3.es.egwn.lan> <46E7E5AF.5030107@redhat.com> <20070912161144.27ec20ed@python3.es.egwn.lan> Message-ID: <46E7F29E.2020209@redhat.com> Matthias Saou wrote: > Mike McGrath wrote : > > >> Matthias Saou wrote: >> >>> Hi, >>> >>> I just rebuilt gkrellm-freq for EL-5, but the build "failed" for ppc. >>> The build.log indicates that everything went fine, "exit 0" at the very >>> end confirms this... >>> >>> Something is going wrong with plague? >>> >>> http://buildsys.fedoraproject.org/logs/fedora-5-epel/36278-gkrellm-freq-1.0-7.el5/ >>> >>> >> Plague isn't moving the status beyond prepping (even though in reality >> the build does move on from there and completes). There is a check in >> plague to make sure that mock never exits during the prep status, if it >> does, regardless of how mock's exit code, then its a failed build. I've >> been adding some code here and there though I've not had much success. >> I'm still working on it but since it's hard to duplicate and my >> familiarity with plague isn't great it's taken longer then I'd hoped, >> please bare with me and continue to report these successful-failed builds. >> > > You've mostly lost me here, but I guess the answer is "yes, something > is going wrong with plague, and I'm trying to find out what" :-) > > What should I do? Try to trigger the build again? Or is it 100% > reproducible for a given tag of a given package? > Oh, sorry :) Yeah just keep rebuilding until it succeeds. For each build that fails please add it to: https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/125 -Mike -Mike From buildsys at fedoraproject.org Wed Sep 12 23:16:19 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 12 Sep 2007 19:16:19 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-12 Message-ID: <20070912231619.D8ABB152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 1 lighttpd-1.4.18-1.el5 Changes in Fedora EPEL 5: lighttpd-1.4.18-1.el5 --------------------- * Mon Sep 10 2007 Matthias Saou 1.4.18-1 - Update to 1.4.18. - Include newly installed lighttpd-angel ("angel" process meant to always run as root and restart lighttpd when it crashes, spawn processes on SIGHUP), but it's in testing stage and must be run with -D for now. * Wed Sep 05 2007 Matthias Saou 1.4.17-1 - Update to 1.4.17. - Update defaultconf patch to match new example configuration. - Include patch to fix log file rotation with max-workers set (trac #902). - Add /var/run/lighttpd/ directory where to put fastcgi sockets. * Thu Aug 23 2007 Matthias Saou 1.4.16-3 - Add /usr/bin/awk build requirement, used to get LIGHTTPD_VERSION_ID. * Wed Aug 22 2007 Matthias Saou 1.4.16-2 - Rebuild to fix wrong execmem requirement on ppc32. 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 Wed Sep 12 23:21:42 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 12 Sep 2007 19:21:42 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-12 Message-ID: <20070912232142.721D9152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 8 eclipse-cdt-3.1.2-8.el5 NEW lyx-1.4.5.1-2.el5 : WYSIWYM (What You See Is What You Mean) document processor NEW mach-0.9.2-3.el5 : Make a chroot mksh-31c-1.el5 (!) nagios-2.9-1.el5 : INVALID rebuild, not published! python-memcached-1.39-1.el5 rpmlint-0.81-2.el5 zabbix-1.4.2-1.el5 Packages built and released for Fedora EPEL testing/4: 1 mksh-31c-1.el4 Changes in Fedora EPEL testing/5: eclipse-cdt-3.1.2-8.el5 ----------------------- * Mon Sep 10 2007 Jeff Johnston 3.1.2-8 - Resolves #274551 - Rebase autotools to 0.1.2 - Add check for failure to generate makefile and no makefile exists lyx-1.4.5.1-2.el5 ----------------- * Mon Sep 10 2007 Rex Dieter 1.4.5.1-2 - License: GPLv2+ - EPEL: drop aiksaurus support (until aiksaurus is available) mach-0.9.2-3.el5 ---------------- * Wed Sep 12 2007 Ville Skytt? - 0.9.2-3 - Set default flavour to "epel" for EPEL builds. * Sun Sep 09 2007 Ville Skytt? - 0.9.2-2 - Drop no longer needed (and failing) old ppc config bug workarounds. - Sync group creation scriptlet with current Fedora packaging guidelines. - Set default config to the "updates" flavour. * Sat Sep 08 2007 Thomas Vander Stichele - 0.9.2-1 - new release * Thu Aug 16 2007 Ville Skytt? - 0.9.1-3 - License: GPLv2+ mksh-31c-1.el5 -------------- * Wed Sep 12 2007 Robert Scheck 31c-1 - Upgrade to 31c - Added a buildrequirement to ed, added arc4random.c file * Tue Sep 11 2007 Robert Scheck 31b-1 - Upgrade to 31b - Use script to get %check happy (thanks to Thorsten Glaser) nagios-2.9-1.el5 ---------------- * Fri Jun 29 2007 Mike McGrath 2.9-1 - Upstream released 2.9 python-memcached-1.39-1.el5 --------------------------- * Tue Aug 14 2007 Sean Reifschneider 1.39-1 - Update to 1.39 upstream release. * Sat Aug 11 2007 Sean Reifschneider 1.38-1 - Update to 1.38 upstream release. rpmlint-0.81-2.el5 ------------------ * Tue Sep 11 2007 Ville Skytt? - 0.81-2 - Sync Fedora license list with Wiki rev 90. * Mon Sep 03 2007 Ville Skytt? - 0.81-1 - 0.81, fixes #239611, #240840, #241471, #244835. - Improve Fedora license check (Todd Zullinger). - Sync Fedora license list with Wiki rev 87. * Wed Aug 29 2007 Ville Skytt? - Sync Fedora license list with Wiki rev 84 (Todd Zullinger). * Thu Aug 16 2007 Ville Skytt? - 0.80-3 - Sync Fedora license list with Wiki rev 68. - Move pre-2006 changelog entries to CHANGES.package.old. * Tue Jul 31 2007 Tom "spot" Callaway - 0.80-2 - new fedora licensing scheme * Thu May 31 2007 Ville Skytt? - Filter hardcoded-library-path errors for /lib/udev. zabbix-1.4.2-1.el5 ------------------ * Tue Sep 11 2007 Dan Horak 1.4.2-1 - New upstream release Changes in Fedora EPEL testing/4: mksh-31c-1.el4 -------------- * Wed Sep 12 2007 Robert Scheck 31c-1 - Upgrade to 31c - Added a buildrequirement to ed, added arc4random.c file * Tue Sep 11 2007 Robert Scheck 31b-1 - Upgrade to 31b - Use script to get %check happy (thanks to Thorsten Glaser) For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From kevin at tummy.com Wed Sep 12 23:36:30 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 12 Sep 2007 17:36:30 -0600 Subject: Repository cleanups Message-ID: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> Greetings. I have just done some clean up on the EPEL stable repositories. In epel-4 (stable): perl-XML-DOM Removed (Removed because it provides perl-libxml-enno, which is already provided by a "core" RHEL package). bug #249901 The ctapi-cyberjack Removed (removed because it requires a dependency from ctapi-common thats not in stable). bug #279991 In epel-5 (stable): lapack Removed. (Removed because it conflicts with the RHEL "core" lapack package, and is even newer). Bug #279821 php-pear-PhpDocumentor Removed (Broken dependencies). Bug #280001. ctapi-cyberjack Removed. (removed because they require a dependency from ctapi-common thats not in stable). bug #279991 Also, lighttpd was pushed into EPEL-5 stable (Security update). NOTE: If anyone has security updates, please do notify the list and/or mail epel_signers-members at fedoraproject.org asking for your update to be pushed ASAP. Please let me know if anyone spots any problems with the current repositories. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Thu Sep 13 08:19:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 13 Sep 2007 10:19:25 +0200 Subject: Repository cleanups In-Reply-To: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> References: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> Message-ID: <46E8F28D.4020008@leemhuis.info> On 13.09.2007 01:36, Kevin Fenzi wrote: > Greetings. > > I have just done some clean up on the EPEL stable repositories. > [...] Many thx for that kevin! > Please let me know if anyone spots any problems with the current > repositories. That reminds me of something else: I haven't seen any "broken deps" report recently. Mike, Dennis, are they still running regularly? Are they running only for EPEL stable or also for EPEL testing (whcih they should IMHO)? Cu knurd From mmcgrath at redhat.com Thu Sep 13 13:11:14 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 13 Sep 2007 08:11:14 -0500 Subject: Repository cleanups In-Reply-To: <46E8F28D.4020008@leemhuis.info> References: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> <46E8F28D.4020008@leemhuis.info> Message-ID: <46E936F2.1010409@redhat.com> Thorsten Leemhuis wrote: > On 13.09.2007 01:36, Kevin Fenzi wrote: > >> Greetings. >> >> I have just done some clean up on the EPEL stable repositories. >> [...] >> > > Many thx for that kevin! > > >> Please let me know if anyone spots any problems with the current >> repositories. >> > > That reminds me of something else: I haven't seen any "broken deps" > report recently. Mike, Dennis, are they still running regularly? Are > they running only for EPEL stable or also for EPEL testing (whcih they > should IMHO)? > Right now only EPEL stable and they are running there are a couple broken deps in EPEL-[4-5] IIRC. -Mike From sheltren at cs.ucsb.edu Thu Sep 13 14:01:00 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Thu, 13 Sep 2007 10:01:00 -0400 Subject: Repository cleanups In-Reply-To: <46E936F2.1010409@redhat.com> References: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> <46E8F28D.4020008@leemhuis.info> <46E936F2.1010409@redhat.com> Message-ID: <22626E00-923C-4248-AD6A-2C68A0947C87@cs.ucsb.edu> On Sep 13, 2007, at 9:11 AM, Mike McGrath wrote: > Thorsten Leemhuis wrote: >> That reminds me of something else: I haven't seen any "broken deps" >> report recently. Mike, Dennis, are they still running regularly? Are >> they running only for EPEL stable or also for EPEL testing (whcih >> they >> should IMHO)? >> > > Right now only EPEL stable and they are running there are a couple > broken deps in EPEL-[4-5] IIRC. > > -Mike > Some people may hate me for this, but I think running the deps check on testing would be a good idea. Otherwise people may have broken packages there and not know it. Plus, if people get nagged enough, they may get motivated to fix things, import needed packages, etc. :) -Jeff From mmcgrath at redhat.com Thu Sep 13 14:43:12 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 13 Sep 2007 09:43:12 -0500 Subject: Repository cleanups In-Reply-To: <22626E00-923C-4248-AD6A-2C68A0947C87@cs.ucsb.edu> References: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> <46E8F28D.4020008@leemhuis.info> <46E936F2.1010409@redhat.com> <22626E00-923C-4248-AD6A-2C68A0947C87@cs.ucsb.edu> Message-ID: <46E94C80.4070601@redhat.com> Jeff Sheltren wrote: > On Sep 13, 2007, at 9:11 AM, Mike McGrath wrote: > >> Thorsten Leemhuis wrote: >>> That reminds me of something else: I haven't seen any "broken deps" >>> report recently. Mike, Dennis, are they still running regularly? Are >>> they running only for EPEL stable or also for EPEL testing (whcih they >>> should IMHO)? >>> >> >> Right now only EPEL stable and they are running there are a couple >> broken deps in EPEL-[4-5] IIRC. >> >> -Mike >> > > Some people may hate me for this, but I think running the deps check > on testing would be a good idea. Otherwise people may have broken > packages there and not know it. Plus, if people get nagged enough, > they may get motivated to fix things, import needed packages, etc. :) So we're doing two runs against EPEL-5 and EPEL-4 EPEL5-testing: Merges RHEL5, EPEL-5, EPEL-5-Testing EPEL5: Merges RHEL5, EPEL-5 EPEL4-testing: Merges RHEL4, EPEL-4, EPEL-4-Testing EPEL4: Merges RHEL4, EPEL-4 That seem sane to everyone? -Mike From fedora at leemhuis.info Thu Sep 13 15:37:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 13 Sep 2007 17:37:33 +0200 Subject: Repository cleanups In-Reply-To: <46E94C80.4070601@redhat.com> References: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> <46E8F28D.4020008@leemhuis.info> <46E936F2.1010409@redhat.com> <22626E00-923C-4248-AD6A-2C68A0947C87@cs.ucsb.edu> <46E94C80.4070601@redhat.com> Message-ID: <46E9593D.3060402@leemhuis.info> On 13.09.2007 16:43, Mike McGrath wrote: > Jeff Sheltren wrote: >> On Sep 13, 2007, at 9:11 AM, Mike McGrath wrote: >>> Thorsten Leemhuis wrote: >> Some people may hate me for this, but I think running the deps check >> on testing would be a good idea. Otherwise people may have broken >> packages there and not know it. Exactly (and that's why I brought the topic up). >> Plus, if people get nagged enough, >> they may get motivated to fix things, import needed packages, etc. :) +1 -- we also in the future try to keep the broken deps even in testing to a minimum. E.g. something like "if there is a package in testing that has broken deps for more then 7 days it's going to be removed." > So we're doing two runs against EPEL-5 and EPEL-4 > > EPEL5-testing: Merges RHEL5, EPEL-5, EPEL-5-Testing > EPEL5: Merges RHEL5, EPEL-5 > > EPEL4-testing: Merges RHEL4, EPEL-4, EPEL-4-Testing > EPEL4: Merges RHEL4, EPEL-4 > > That seem sane to everyone? Yes -- I think that's a must-have. BTW, how often do they run? Once a week iirc? Would it be much work to let cron them at least twice a week? Cu knurd From limb at jcomserv.net Thu Sep 13 15:14:43 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 13 Sep 2007 10:14:43 -0500 (CDT) Subject: Repository cleanups In-Reply-To: <46E9593D.3060402@leemhuis.info> References: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> <46E8F28D.4020008@leemhuis.info> <46E936F2.1010409@redhat.com> <22626E00-923C-4248-AD6A-2C68A0947C87@cs.ucsb.edu> <46E94C80.4070601@redhat.com> <46E9593D.3060402@leemhuis.info> Message-ID: <10721.65.192.24.164.1189696483.squirrel@mail.jcomserv.net> > On 13.09.2007 16:43, Mike McGrath wrote: >> Jeff Sheltren wrote: >>> On Sep 13, 2007, at 9:11 AM, Mike McGrath wrote: >>>> Thorsten Leemhuis wrote: >>> Some people may hate me for this, but I think running the deps check >>> on testing would be a good idea. Otherwise people may have broken >>> packages there and not know it. > > Exactly (and that's why I brought the topic up). > >>> Plus, if people get nagged enough, >>> they may get motivated to fix things, import needed packages, etc. :) > > +1 -- we also in the future try to keep the broken deps even in testing > to a minimum. E.g. something like "if there is a package in testing that > has broken deps for more then 7 days it's going to be removed." Where may I see what's in testing? I have a package that was moved there from broken deps but I've since resolved them for EPEL-5, and I'm curious where it sits. >> So we're doing two runs against EPEL-5 and EPEL-4 >> >> EPEL5-testing: Merges RHEL5, EPEL-5, EPEL-5-Testing >> EPEL5: Merges RHEL5, EPEL-5 >> >> EPEL4-testing: Merges RHEL4, EPEL-4, EPEL-4-Testing >> EPEL4: Merges RHEL4, EPEL-4 >> >> That seem sane to everyone? > > Yes -- I think that's a must-have. > > BTW, how often do they run? Once a week iirc? Would it be much work to > let cron them at least twice a week? > > Cu > knurd > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- novus ordo absurdum From kevin at tummy.com Thu Sep 13 16:40:38 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 13 Sep 2007 10:40:38 -0600 Subject: Repository cleanups In-Reply-To: <46E936F2.1010409@redhat.com> References: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> <46E8F28D.4020008@leemhuis.info> <46E936F2.1010409@redhat.com> Message-ID: <20070913104038.4ab3c714@ghistelwchlohm.scrye.com> On Thu, 13 Sep 2007 08:11:14 -0500 mmcgrath at redhat.com (Mike McGrath) wrote: > Thorsten Leemhuis wrote: > > On 13.09.2007 01:36, Kevin Fenzi wrote: > > > >> Greetings. > >> > >> I have just done some clean up on the EPEL stable repositories. > >> [...] > >> > > > > Many thx for that kevin! > > > > > >> Please let me know if anyone spots any problems with the current > >> repositories. > >> > > > > That reminds me of something else: I haven't seen any "broken deps" > > report recently. Mike, Dennis, are they still running regularly? Are > > they running only for EPEL stable or also for EPEL testing (whcih > > they should IMHO)? > > > > Right now only EPEL stable and they are running there are a couple > broken deps in EPEL-[4-5] IIRC. From what I can see there should now only be 1 broken dep in stable. I will try and take care of that very soon. It's graphviz, and I think it just needs to be blacklisted from being multilib in epel-4, since perl in RHEL4 is not multilib. > -Mike kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at tummy.com Thu Sep 13 16:43:11 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Thu, 13 Sep 2007 10:43:11 -0600 Subject: Repository cleanups In-Reply-To: <10721.65.192.24.164.1189696483.squirrel@mail.jcomserv.net> References: <20070912173630.05d8a1b1@ghistelwchlohm.scrye.com> <46E8F28D.4020008@leemhuis.info> <46E936F2.1010409@redhat.com> <22626E00-923C-4248-AD6A-2C68A0947C87@cs.ucsb.edu> <46E94C80.4070601@redhat.com> <46E9593D.3060402@leemhuis.info> <10721.65.192.24.164.1189696483.squirrel@mail.jcomserv.net> Message-ID: <20070913104311.7cd57397@ghistelwchlohm.scrye.com> On Thu, 13 Sep 2007 10:14:43 -0500 (CDT) limb at jcomserv.net ("Jon Ciesla") wrote: > > > On 13.09.2007 16:43, Mike McGrath wrote: > >> Jeff Sheltren wrote: > >>> On Sep 13, 2007, at 9:11 AM, Mike McGrath wrote: > >>>> Thorsten Leemhuis wrote: > >>> Some people may hate me for this, but I think running the deps > >>> check on testing would be a good idea. Otherwise people may have > >>> broken packages there and not know it. > > > > Exactly (and that's why I brought the topic up). > > > >>> Plus, if people get nagged enough, > >>> they may get motivated to fix things, import needed packages, > >>> etc. :) > > > > +1 -- we also in the future try to keep the broken deps even in > > testing to a minimum. E.g. something like "if there is a package in > > testing that has broken deps for more then 7 days it's going to be > > removed." Yeah, I would like to see runs against testing as well. In addition to the other reasons, it would be very nice to get everything fixed before 5.1 comes out so we can cleanly move things over to the stable repo. > > Where may I see what's in testing? I have a package that was moved > there from broken deps but I've since resolved them for EPEL-5, and > I'm curious where it sits. You should be able to look in http://download.fedora.redhat.com/pub/epel/testing/ 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 Thu Sep 13 23:18:21 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 13 Sep 2007 19:18:21 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-13 Message-ID: <20070913231821.22952152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 1 qgit-1.5.7-1.el5 Packages built and released for Fedora EPEL testing/5: 7 bacula-2.0.3-10.el5 NEW dbench-3.04-6.el5 : Filesystem load benchmarking tool NEW gcin-1.3.4-2.el5 : Input method for Traditional Chinese mach-0.9.2-3.el5.1 mod_security-2.1.3-1.el5 NEW perl-Geo-IP-1.28-3.el5 : Efficient Perl bindings for the GeoIP location database NEW php-pear-HTML-QuickForm-advmultiselect-1.4.0-1.el5 : Element for HTML_QuickForm that emulate a multi-select Packages built and released for Fedora EPEL 4: 1 qgit-1.5.7-1.el4 Packages built and released for Fedora EPEL testing/4: 2 mod_security-2.1.3-1.el4 NEW perl-Geo-IP-1.28-3.el4 : Efficient Perl bindings for the GeoIP location database Changes in Fedora EPEL 5: qgit-1.5.7-1.el5 ---------------- * Sat Sep 08 2007 Dan Horak 1.5.7-1 - update to upstream version 1.5.7 - fixes #268381 - update license tag Changes in Fedora EPEL testing/5: bacula-2.0.3-10.el5 ------------------- * Thu Sep 13 2007 Andreas Thienemann 2.0.3-10 - Applied restore fix to sd. #288981 dbench-3.04-6.el5 ----------------- * Tue Sep 11 2007 Rahul Sundaram - 3.04-6 - Drop redundant version macro * Tue Sep 11 2007 Rahul Sundaram - 3.04-5 - Fix version. Dropped BR on glibc-headers * Tue Sep 11 2007 Rahul Sundaram - 3.04-4 - Fixed docs * Tue Sep 11 2007 Rahul Sundaram - 3.04-3 - Fixed description, man page location, timestamps, BR and license tag gcin-1.3.4-2.el5 ---------------- * Tue Apr 17 2007 Chung-Yen Chang - 1.3.4-2 - disable i18n and do not make po mach-0.9.2-3.el5.1 ------------------ * Thu Sep 13 2007 Ville Skytt? - 0.9.2-3.1 - Patch to default to CentOS configs also when built on RHEL. mod_security-2.1.3-1.el5 ------------------------ * Thu Sep 13 2007 Michael Fleming 2.1.3-1 - New upstream release - Update License tag per guidelines perl-Geo-IP-1.28-3.el5 ---------------------- * Mon Sep 03 2007 Michael Fleming 1.28-4 - Fix %patch invocation to help avoid a bogus interpreter issue - First build for Extras * Sun Aug 26 2007 Michael Fleming 1.28-3 - Actually apply the patch :-) - Apply consistency in macro usage - Remove explicit GeoIP dependency as it should be pulled in automagically - Patch to example/netspeed to avoid bogus interpreter - Update License to match current Fedora guidelines. php-pear-HTML-QuickForm-advmultiselect-1.4.0-1.el5 -------------------------------------------------- * Tue Aug 21 2007 Remi Collet 1.4.0-1 - Take ownership for this, update to 1.4.0 - Change licence from PHP to BSD Changes in Fedora EPEL 4: qgit-1.5.7-1.el4 ---------------- * Sat Sep 08 2007 Dan Horak 1.5.7-1 - update to upstream version 1.5.7 - fixes #268381 - update license tag Changes in Fedora EPEL testing/4: mod_security-2.1.3-1.el4 ------------------------ * Thu Sep 13 2007 Michael Fleming 2.1.3-1 - New upstream release - Update License tag per guidelines perl-Geo-IP-1.28-3.el4 ---------------------- * Mon Sep 03 2007 Michael Fleming 1.28-4 - Fix %patch invocation to help avoid a bogus interpreter issue - First build for Extras * Sun Aug 26 2007 Michael Fleming 1.28-3 - Actually apply the patch :-) - Apply consistency in macro usage - Remove explicit GeoIP dependency as it should be pulled in automagically - Patch to example/netspeed to avoid bogus interpreter - Update License to match current Fedora guidelines. 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 Fri Sep 14 23:45:58 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 14 Sep 2007 19:45:58 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-14 Message-ID: <20070914234558.5E07F152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 1 cacti-0.8.6j-8.el5 Packages built and released for Fedora EPEL testing/5: 8 duplicity-0.4.3-1.el5 (!) nagios-2.9-1.el5 : INVALID rebuild, not published! php-pear-PhpDocumentor-1.3.2-2.el5 NEW python-GnuPGInterface-0.3.2-2.el5 : A Python module to interface with GnuPG python-setuptools-0.6c7-1.el5 NEW pyzor-0.4.0-11.el5 : Pyzor collaborative spam filtering system NEW rubygem-rake-0.7.3-2.el5 : Ruby based make-like utility NEW rubygems-0.9.4-1.el5 : The Ruby standard for packaging ruby libraries Packages built and released for Fedora EPEL 4: 1 cacti-0.8.6j-8.el4 Packages built and released for Fedora EPEL testing/4: 4 duplicity-0.4.3-1.el4 NEW python-GnuPGInterface-0.3.2-2.el4 : A Python module to interface with GnuPG python-setuptools-0.6c7-1.el4 NEW pyzor-0.4.0-11.el4 : Pyzor collaborative spam filtering system Changes in Fedora EPEL 5: cacti-0.8.6j-8.el5 ------------------ * Fri Sep 14 2007 Mike McGrath - 0.8.6j-8 - Fix for CVE-2007-3112 bz#243592 * Sat Sep 08 2007 Mike McGrath - 0.8.6j-6 - rebuild Changes in Fedora EPEL testing/5: duplicity-0.4.3-1.el5 --------------------- * Sat Sep 15 2007 Robert Scheck 0.4.3-1 - Upgrade to 0.4.3 (#265701) - Updated the license tag according to the guidelines nagios-2.9-1.el5 ---------------- * Fri Jun 29 2007 Mike McGrath 2.9-1 - Upstream released 2.9 php-pear-PhpDocumentor-1.3.2-2.el5 ---------------------------------- * Tue Jun 12 2007 Konstantin Ryabitsev - 1.3.2-2 - Require parent n-v-r instead of php-pear(pear-name) in phpdoc for simplicity python-GnuPGInterface-0.3.2-2.el5 --------------------------------- * Mon Sep 03 2007 Robert Scheck 0.3.2-2 - Updated source URL to match with the guidelines (#265381) - Use get_python_lib() macro according to the policy (#265381) * Wed Aug 29 2007 Robert Scheck 0.3.2-1 - Upgrade to 0.3.2 - Initial spec file for Fedora and Red Hat Enterprise Linux python-setuptools-0.6c7-1.el5 ----------------------------- * Fri Sep 14 2007 Konstantin Ryabitsev - 0.6c7-1 - Upstream 0.6c7 - Provide python-setuptools-devel to make packagers' lives easier pyzor-0.4.0-11.el5 ------------------ * Sat Dec 23 2006 Jason L Tibbitts III - 0.4.0-11 - Rebuild with Python 2.5. rubygem-rake-0.7.3-2.el5 ------------------------ * Thu Aug 23 2007 David Lutterkort - 0.7.3-2 - Fix license tag - Remove bogus shebangs in lib/ and test/ rubygems-0.9.4-1.el5 -------------------- * Fri Jul 27 2007 David Lutterkort - 0.9.4-1 - Conditionalize so it builds on RHEL4 Changes in Fedora EPEL 4: cacti-0.8.6j-8.el4 ------------------ * Fri Sep 14 2007 Mike McGrath - 0.8.6j-8 - Fix for CVE-2007-3112 bz#243592 * Sat Sep 08 2007 Mike McGrath - 0.8.6j-6 - rebuild Changes in Fedora EPEL testing/4: duplicity-0.4.3-1.el4 --------------------- * Sat Sep 15 2007 Robert Scheck 0.4.3-1 - Upgrade to 0.4.3 (#265701) - Updated the license tag according to the guidelines python-GnuPGInterface-0.3.2-2.el4 --------------------------------- * Mon Sep 03 2007 Robert Scheck 0.3.2-2 - Updated source URL to match with the guidelines (#265381) - Use get_python_lib() macro according to the policy (#265381) * Wed Aug 29 2007 Robert Scheck 0.3.2-1 - Upgrade to 0.3.2 - Initial spec file for Fedora and Red Hat Enterprise Linux python-setuptools-0.6c7-1.el4 ----------------------------- * Fri Sep 14 2007 Konstantin Ryabitsev - 0.6c7-1 - Upstream 0.6c7 - Provide python-setuptools-devel to make packagers' lives easier pyzor-0.4.0-11.el4 ------------------ * Sat Dec 23 2006 Jason L Tibbitts III - 0.4.0-11 - Rebuild with Python 2.5. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dan at danny.cz Sat Sep 15 07:47:01 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 15 Sep 2007 09:47:01 +0200 Subject: problem with building Zabbix on EL4/x86_64 Message-ID: <1189842421.4314.6.camel@eagle.danny.cz> Hello, I have problems with building Zabbix 1.4.2 on (only) EL4/x86_64. For an unknown reason, configure is saying that it cannot find net-snmp libraries even when net-snmp-devel is installed and the build on i386 and ppc is done. Details can be found at http://buildsys.fedoraproject.org/logs/fedora-4-epel/36268-zabbix-1.4.2-1.el4/ Can somebody do a local (or mock) build and send me the config.log (or its relevant part), so I can see what's wrong? Thanks Dan From ville.skytta at iki.fi Sat Sep 15 08:14:26 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 15 Sep 2007 11:14:26 +0300 Subject: problem with building Zabbix on EL4/x86_64 In-Reply-To: <1189842421.4314.6.camel@eagle.danny.cz> References: <1189842421.4314.6.camel@eagle.danny.cz> Message-ID: <200709151114.26704.ville.skytta@iki.fi> On Saturday 15 September 2007, Dan Hor?k wrote: > Hello, > I have problems with building Zabbix 1.4.2 on (only) EL4/x86_64. For an > unknown reason, configure is saying that it cannot find net-snmp > libraries even when net-snmp-devel is installed and the build on i386 > and ppc is done. Details can be found at > http://buildsys.fedoraproject.org/logs/fedora-4-epel/36268-zabbix-1.4.2-1.e >l4/ Can somebody do a local (or mock) build and send me the config.log (or > its relevant part), so I can see what's wrong? configure:10557: gcc -o conftest -O2 -g -pipe -m64 -I/usr/include/mysql -g -pipe -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -I/usr/include/rpm -I/usr/include/rpm -I. -I/usr/include/net-snmp -L/usr/lib64 -L/usr/lib64conftest.c -lnetsnmp -lm -lresolv >&5 /usr/lib64/libnetsnmp.so: undefined reference to `EVP_DigestInit' /usr/lib64/libnetsnmp.so: undefined reference to `EVP_DigestFinal' /usr/lib64/libnetsnmp.so: undefined reference to `EVP_DigestFinal_ex' /usr/lib64/libnetsnmp.so: undefined reference to `AES_set_encrypt_key' /usr/lib64/libnetsnmp.so: undefined reference to `EVP_md5' /usr/lib64/libnetsnmp.so: undefined reference to `HMAC' /usr/lib64/libnetsnmp.so: undefined reference to `EVP_MD_CTX_cleanup' /usr/lib64/libnetsnmp.so: undefined reference to `SSLeay' /usr/lib64/libnetsnmp.so: undefined reference to `EVP_sha1' /usr/lib64/libnetsnmp.so: undefined reference to `EVP_MD_CTX_init' /usr/lib64/libnetsnmp.so: undefined reference to `EVP_DigestUpdate' /usr/lib64/libnetsnmp.so: undefined reference to `RAND_bytes' /usr/lib64/libnetsnmp.so: undefined reference to `DES_cbc_encrypt' /usr/lib64/libnetsnmp.so: undefined reference to `DES_ncbc_encrypt' /usr/lib64/libnetsnmp.so: undefined reference to `DES_key_sched' /usr/lib64/libnetsnmp.so: undefined reference to `AES_cfb128_encrypt' collect2: ld returned 1 exit status From dan at danny.cz Sat Sep 15 08:56:21 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Sat, 15 Sep 2007 10:56:21 +0200 Subject: problem with building Zabbix on EL4/x86_64 In-Reply-To: <200709151114.26704.ville.skytta@iki.fi> References: <1189842421.4314.6.camel@eagle.danny.cz> <200709151114.26704.ville.skytta@iki.fi> Message-ID: <1189846581.4314.11.camel@eagle.danny.cz> Ville Skytt? p??e v So 15. 09. 2007 v 11:14 +0300: > On Saturday 15 September 2007, Dan Hor?k wrote: > > Hello, > > I have problems with building Zabbix 1.4.2 on (only) EL4/x86_64. For an > > unknown reason, configure is saying that it cannot find net-snmp > > libraries even when net-snmp-devel is installed and the build on i386 > > and ppc is done. Details can be found at > > http://buildsys.fedoraproject.org/logs/fedora-4-epel/36268-zabbix-1.4.2-1.e > >l4/ Can somebody do a local (or mock) build and send me the config.log (or > > its relevant part), so I can see what's wrong? > > configure:10557: gcc -o > conftest -O2 -g -pipe -m64 -I/usr/include/mysql -g -pipe -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -I/usr/include/rpm -I/usr/include/rpm -I. -I/usr/include/net-snmp -L/usr/lib64 -L/usr/lib64conftest.c -lnetsnmp -lm -lresolv > >&5 > /usr/lib64/libnetsnmp.so: undefined reference to `EVP_DigestInit' > /usr/lib64/libnetsnmp.so: undefined reference to `EVP_DigestFinal' > /usr/lib64/libnetsnmp.so: undefined reference to `EVP_DigestFinal_ex' > /usr/lib64/libnetsnmp.so: undefined reference to `AES_set_encrypt_key' > /usr/lib64/libnetsnmp.so: undefined reference to `EVP_md5' > /usr/lib64/libnetsnmp.so: undefined reference to `HMAC' > /usr/lib64/libnetsnmp.so: undefined reference to `EVP_MD_CTX_cleanup' > /usr/lib64/libnetsnmp.so: undefined reference to `SSLeay' > /usr/lib64/libnetsnmp.so: undefined reference to `EVP_sha1' > /usr/lib64/libnetsnmp.so: undefined reference to `EVP_MD_CTX_init' > /usr/lib64/libnetsnmp.so: undefined reference to `EVP_DigestUpdate' > /usr/lib64/libnetsnmp.so: undefined reference to `RAND_bytes' > /usr/lib64/libnetsnmp.so: undefined reference to `DES_cbc_encrypt' > /usr/lib64/libnetsnmp.so: undefined reference to `DES_ncbc_encrypt' > /usr/lib64/libnetsnmp.so: undefined reference to `DES_key_sched' > /usr/lib64/libnetsnmp.so: undefined reference to `AES_cfb128_encrypt' > collect2: ld returned 1 exit status Thanks, Ville. So it requires libcrypto. Interesting :-) Dan From dennis at ausil.us Mon Sep 17 03:36:02 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 16 Sep 2007 22:36:02 -0500 Subject: EPEL and Fedora Extras build system down Message-ID: <200709162236.16142.dennis@ausil.us> Hi All, The main build hub for the plague build system is currently down. It will remain down until we can get someone to look at it in the morning. Sorry for the short notice. 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 dcbw at redhat.com Mon Sep 17 11:58:15 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 17 Sep 2007 07:58:15 -0400 Subject: EPEL and Fedora Extras build system down In-Reply-To: <200709162236.16142.dennis@ausil.us> References: <200709162236.16142.dennis@ausil.us> Message-ID: <1190030295.1148.16.camel@xo-3E-67-34.localdomain> On Sun, 2007-09-16 at 22:36 -0500, Dennis Gilmore wrote: > Hi All, > > The main build hub for the plague build system is currently down. It will > remain down until we can get someone to look at it in the morning. Sorry for > the short notice. Something with plague or a hardware/os fault? Dan From skvidal at fedoraproject.org Mon Sep 17 11:58:31 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 17 Sep 2007 07:58:31 -0400 Subject: EPEL and Fedora Extras build system down In-Reply-To: <1190030295.1148.16.camel@xo-3E-67-34.localdomain> References: <200709162236.16142.dennis@ausil.us> <1190030295.1148.16.camel@xo-3E-67-34.localdomain> Message-ID: <1190030311.2602.40.camel@cutter> On Mon, 2007-09-17 at 07:58 -0400, Dan Williams wrote: > On Sun, 2007-09-16 at 22:36 -0500, Dennis Gilmore wrote: > > Hi All, > > > > The main build hub for the plague build system is currently down. It will > > remain down until we can get someone to look at it in the morning. Sorry for > > the short notice. > > Something with plague or a hardware/os fault? hardware/os. -sv From fedora at leemhuis.info Mon Sep 17 17:15:17 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 17 Sep 2007 19:15:17 +0200 Subject: Log from last weeks EPEL SIG meeting (20070912) Message-ID: <46EEB625.30401@leemhuis.info> Reminder: next meeting on Wednesday (20070919) at 23:00 UTC in #fedora-meeting 00:00:56 Hi everybody; who's around? 00:01:07 --- knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:01:11 Meeting ping dgilmore, Jeff_S, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:01:17 * 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:01:30 * f13 peeks in 00:01:45 * knurd has a cold and should be in bed... 00:02:11 knurd: pushing should be easier now 00:02:27 dgilmore, yeah, I've read about it in my inbox 00:02:38 dgilmore, does it work like Michael expected it now? 00:02:52 knurd: it seems to yes 00:03:03 dgilmore, great 00:03:30 dgilmore, btw, the current repo is "5" 00:03:47 the plan was to have "5.0" and "5.1" repos and let 5 point to the current one 00:03:54 dgilmore, should that still be possible to do? 00:04:16 having "5.0" and "5.1" repos would make it possible for users to stick to 5.0 00:04:25 if they don#t want to upgreade yet to 5.1 00:04:27 --> sharkcz () has joined #fedora-meeting 00:04:41 given that Red Hat has an update model that is like that, this is probably a good idea. 00:04:55 knurd: they should be symlinks to 5 00:04:58 btw, I supose there is no public official date when RHEl 5.1 is going to be released? 00:04:58 Red Hat has an update model that will allow you to stay on say 5.0 and get only critical updates built for 5.0. 00:05:06 knurd: I don't think so 00:05:26 --> trashy (n=trashy at fedora/trashy) has joined #fedora-meeting 00:05:33 dgilmore, no, that does not work if there is something in the normal repo then that requires stuff from 5.1 00:05:39 so we need 5.0 and 5.1 repos 00:05:47 knurd: we can not do that 00:05:49 and just link from 5 -> latest (e.g. 5.1 soon) 00:05:58 dgilmore, why not? 00:06:01 we do not have the resources to offer something like that 00:06:20 resources as in "hard-disk space"? 00:06:27 it's just for some months 00:06:31 we could hardlink the files 00:06:42 and remove the 5.0 directory when RHEL drops 5.0 completely 00:06:50 as in hard disk space and scripst that hardlink and set multiple repositories 00:06:57 you'd need multiple scm branches too 00:07:03 one for each point release. 00:07:04 * nirik is here now finally. 00:07:05 RH ourselves builds something on 5.0 if it is meant for both 5.0 and 5.1 00:07:13 f13, well, I don#t think we need to update the old branches 00:07:18 f13, that is to much work for epel 00:07:23 knurd: you do if htere is a security issue 00:07:35 knurd: it will blow up the world we dont have resouces to do such a thing 00:07:56 * mmcgrath tends to agree with dgilmore. 00:08:02 dgilmore, it's in the guidelines 00:08:03 for motnhs 00:08:07 centos doesn't do that either, do they? 00:08:12 why didn#t you speak up once about it 00:08:12 nirik: they don't. 00:08:28 nirik, they have different directories for their releases as well 00:08:40 knurd: I had assumed we would keep a single tree and create symlinks for releases 00:08:58 * quaid is here, had to come back from an unexpected reboot 00:08:59 dgilmore, http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee336393aec81cf6fc90543c0f2277 00:09:05 nirik, mmcgrath read that as well 00:09:07 they only build against the current tho I thought and the others were symlinks to the current 00:09:16 that's why we agreed on months ago 00:09:35 nirik: thats my take on it also 00:09:47 * nirik reads 00:09:51 --- knurd has changed the topic to: EPEL Meeting | RHEL / EPEL 5.1 -- unassigned 00:09:55 knurd: they keep the old trees around but they don't have anything in them. 00:09:58 http://mirror.steadfast.net/centos/4.4/readme 00:00:02 yeah, that was my understanding too. ;( Sorry if I misread/misunderstood the written guideline... 00:00:05 I thought they keept the old tree around for some weeks/months 00:00:21 anyways it is not really my problem since i am no longer part of the EPEL SIG 00:00:23 so users that don#t want to update yet don#t run into issues 00:00:29 knurd: the problem here is that someone (and its going to have to be a person) will need to track the trees if some packages have a different destination at different times. 00:00:43 dgilmore, well, I wanted you opinion in general 00:00:48 they'll need to make decisions on what rpms end up where and when. 00:12:05 mmcgrath, we would just keep the 5.0 tree around for some months 00:12:11 no updates anymore 00:12:13 for what purpose? 00:12:21 for users that are not yet on 5.1 00:12:27 or don#t want to go there yet 00:12:47 for example as yum-utils is iirc in 5.1 00:13:02 we are oing to delete it in epel soon (I suppose) 00:13:08 but they could just use the symlinked 5.1 repo. If there was some dependency that was in 5.1 and not 5.0 it would error or pull in the upgrade? 00:13:17 but users still on 5.0 would run into broken deps problems then 00:13:55 well, seems I'm the only one htat thinks that we do it like that 00:14:04 so let's ignore the issue for now 00:14:20 it's not that important (but I think it would be nice to have and shouldn#t be to much work to realize) 00:14:20 knurd: we might bring it up on list... if we were confused, there might be others as well... 00:14:31 yeah, maybe 00:14:34 so the specific use case is people who do not or cannot upgrade to 5.1 but still want to use epel for a few months. 00:14:40 --> mcepl () has joined #fedora-meeting 00:14:43 mmcgrath, yes 00:15:12 then the expectation is that they would upgrade after a few months? and not just always stay on 5.0 00:15:15 and to do that we'll have to create a directory full of hard links, decide when it should expire, update our scripts to point to the new location but possibly have it do security updates to 5.0. 00:15:43 I guess my concern is, if its on our mirror I would consider it supported so if I'm using 5.0, I'd expect it to be up to date until it disappears. 00:15:59 yeah, we should take it to the list for input. 00:16:09 mmcgrath, k 00:16:52 I suppose I'll do that then 00:16:56 * knurd moves on 00:17:03 --- knurd has changed the topic to: EPEL Meeting | push to stable easily -- knurd/nirik/dgilmore 00:17:19 dgilmore, I suppose that I can remove that from the schedule for now? 00:17:20 so the scripts are all setup now? 00:17:31 nirik, seems so 00:17:35 * nirik hasn't had time to remove things that need to be removed... will try and do that today. 00:17:47 dgilmore said they are working as expected now as far as he knows 00:17:48 also there are some security updates that need to push direct to stable 00:17:58 I don't think we've fully tested the test -> stable part yet have we? 00:18:09 mmcgrath, not sure 00:18:33 yeah, I don't think we have. 00:18:53 well, someone should 00:19:10 nirik, are those packages that should go to testing a good testbed? 00:19:11 I guess I can setup a mirror repo here, add in the security updates and make sure it's ok, delete the broken dep packages, and then if all looks ok try a push 00:19:42 which packages? built but not in testing? 00:19:54 nirik, wouldn#t it be easier for those security updates to just diff "requirements of old and new package"? 00:19:57 --> llaumgui () has joined #fedora-meeting 00:19:58 those should be identical 00:20:21 nirik, not sure; are those "security updates that need to push direct to stable" build already or in testing? 00:20:52 I suppose we need to do the real testing -> stable move soon as well 00:20:55 well, for example, thttpd is one... I think it's built but not in testing yet. So, it would need to go from nothing to stable, bypassing testing. 00:21:13 RHEL 5.1 is planed for this quarter iirc 00:21:49 I will try and clean up things and test pushing tonight... 00:21:54 nirik, did you get instructions from michael about the new commands? 00:22:07 yeah, in that orig email you forwarded I think. 00:22:13 e.g. how to push to stable directly or how to move from testing to stable 00:22:16 nirik, k 00:22:19 so how about this: 00:22:24 yeah, if they work I can do it. :) 00:22:31 we create a backup on the master repo 00:22:34 try the push script 00:22:48 and abort if it does stupid things? 00:23:24 well, I think the way it works is that it works on a copy until the final sync, then it syncs to the real repo... 00:23:40 so in theory we can copy back if the script messes up. 00:23:47 I can make a backup copy tho too. 00:24:17 as long as their is space for it. 00:24:35 --> knurd_ (n=thl at fedora/thl) has joined #fedora-meeting 00:25:15 sorry, the machine with "knurd" on it just crashed afaics 00:25:17 knurd_: :) 00:25:24 knurd, nirik: can one of you document that in the wiki 00:25:41 "that" -> what michael send us? 00:25:49 knurd: yes 00:26:11 sure... anywhere sound good, or just a new page? 00:26:27 nirik, can you take care of it? 00:26:31 sure. will do now. 00:26:34 nirik, thx 00:27:02 <-- knurd has quit (Read error: 104 (Connection reset by peer)) 00:27:11 nirik, so can you try to move a pacakge from testing to stable? 00:27:18 and one from needsign directly to stable? 00:27:23 so we know that it works? 00:27:26 --- knurd_ is now known as knurd 00:27:33 sure. What package from testing should be moved to stable? 00:28:13 are there maybe two security updates in needsign? 00:28:18 then push one to testing 00:28:24 and from there to stable right after? 00:28:29 and the other one directly? 00:28:50 yeah, I can't recall, but I think there might be another one or two 00:28:55 can try that 00:29:03 nirik, that would be great 00:29:06 thx for your help 00:29:16 also, there are package s that need to be removed... 00:29:21 nirik rocks the house. 00:29:34 * knurd has really not enought time atm 00:29:35 --> fab__ () has joined #fedora-meeting 00:29:43 should get better in two weeks again 00:29:47 ha. I wish I had more time to figure out the scripts and have been able to get things going sooner. 00:30:00 --- knurd is now known as knurd_ 00:30:14 --> knurd (n=thl at fedora/thl) has joined #fedora-meeting 00:30:35 * knurd_ moves on 00:30:40 --- knurd_ has changed the topic to: EPEL Meeting | RHEL / EPEL 5.1 -- unassigned 00:30:43 forgot something 00:30:49 RHEL 5.1 is likely out soon 00:30:52 we don#t know when 00:30:56 --> linux_geek () has joined #fedora-meeting 00:31:14 so I suppose we need to do the EPEL testing -> stable move a week or two after 5.1 is out 00:31:26 is that fine for everybody? 00:31:47 yeah, sounds good. Again, we will want to make sure there are no broken deps, etc. 00:31:50 that sounds reasonable. 00:32:08 nirik, yeah, I suppose we should leave those broken deps in testing 00:32:10 Also, there are a few packages that are pulled into 5.1 that were in EPEL. We will want to tell maintaners to dead.package them? 00:32:18 nirik, good idea 00:33:09 * knurd moves on for real then again 00:33:17 --- knurd has changed the topic to: EPEL Meeting | do more on the list and less in the meetings; "Power to the people with no delay." aka "Steering Committee's are slow and old style" -- all 00:33:41 I suppose we really somehow need to discuss this on the list and then just start it 00:33:44 <-- kital has quit (Read error: 104 (Connection reset by peer)) 00:33:46 and see how it goes 00:33:52 and fine-tune it while doing it 00:34:00 It'd be nice if we had an official way to make decisions on the list. 00:34:21 --> kital (n=Joerg_Si at fedora/kital) has joined #fedora-meeting 00:34:37 mmcgrath, yeah, agreed 00:35:12 like in "if no one objects within some days it's considered accepted?" 00:35:20 <-- enemy99 has quit (Remote closed the connection) 00:35:34 BTW, I inserted this rule into RH's processes for adding a new package to RHEL. 00:35:39 yeah. 00:35:53 something like "Check EPEL to be sure your new package is newer" 00:36:05 warren: excellent. 00:36:11 warren, thx 00:36:34 also "smooth upgrade from EPEL" 00:36:40 mmcgrath, I'd say let's discuss that on the list 00:36:49 * knurd has to leave soon for some minutes 00:36:51 * tux_440volt will be back soon: Gone away for now. 00:37:17 does that sounds sane? 00:37:32 e.g. discuss on the list how to do more things on the list? 00:37:39 sure. ;) 00:37:54 --- knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:38:09 if there anything else we need to discuss today? 00:38:10 knurd, mmcgrath, dgilmore: http://fedoraproject.org/wiki/EPEL/EPEL_repositoryinfo (feel free to correct/add/etc) 00:38:28 Generic Job Description? Communication plan] for enterprise customers/ISVs/IHVs? 00:38:37 or shall we try to finish those on hte list as well? 00:38:55 knurd: yeah, especially since the meetings have just been the few of us. 00:39:07 k 00:39:08 so are we sticking with the alternate meeting time? it didn't seem to help much last week except that knurd wasn't able to make it. 00:39:29 nirik, I'd say we try antoher two or three weeks and decide afterwards 00:39:32 ok 00:39:56 k, anything else? 00:40:09 nope 00:40:27 * knurd will close the meeting in 30 00:41:02 * nirik has nothing. 00:41:16 * knurd will close the meeting in 10 00:41:27 -- MARK -- Meeting end 00:41:27 --- knurd has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule 00:41:31 thx everyone 00:41:40 thanks knurd 00:41:40 <-- knurd_ has quit ("knurd again") 00:41:59 * knurd afk for a few minutes 00:42:07 --> enemy99 () has joined #Fedora-Meeting 00:42:08 thanks knurd From fedora at leemhuis.info Mon Sep 17 18:00:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 17 Sep 2007 20:00:26 +0200 Subject: EPEL report week 37 2007 Message-ID: <46EEC0BA.3040807@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week37 (/me still suffered from a cold/has a headache - I hope I didn't do even more typos then I usually do already when I wrote the report due to that...) = Weekly EPEL Summary = Week 37/2007 == Most important happenings == * push scripts improved (see below) == EPEL SIG Meeting == === Attending === * dgilmore (DennisGilmore) * knurd (ThorstenLeemhuis) * mmcgrath (MikeMcGrath) * Jeff_S (Jeff Sheltren) * nirik (KevinFenzi) * stahnma (MichaelStahnke) * f13 (Jesse Keating) * warren (Warren Togami) === Summary === * pushing * dglimore, nirik and mschwendt further improved and simplified pushing directly to stable and moving a package from testing to stable; thx guys, especially mschwendt! * nirik will test them * repo layout * the plan written at http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee336393aec81cf6fc90543c0f2277 was to have directories for each release (e.g. have 5.0 as main repo now and a symlink from 5 pointing to it; when 5.1 ships run "cp -al 5.0 5.1" and adjust the "5" link to point to 5.1 instead; some weeks or months later remove the 5.0 dir to save the space; 5.0 btw would not be maintained anymore, we just leave it around for some weeks/months). This would allow people still on EL5.0 (for example those using derivates that do not ship 5.1 some weeks after RH does) to use EPEL5.0 without running into dependency issues that might arise when a package from EPEL5.1 depends on something from EL5.1; * seems lots of people forgot about that plan never realized it full effects; do we still want that stuff? or in a modified way maybe? * RHEL 5.1 * will likely be out soon; we don't know exactly when; thus the estimated EPEL testing -> stable move that is pushed in parallel will likely be a week (or two?) after EL 5.1 is out * do more on the list and less in the meetings; "Power to the people with no delay." aka "Steering Committee's are slow and old style" -- all * some discussion how to exactly do this; more discussions to follow the list * RH relations * warren: BTW, I inserted this rule into RH's processes for adding a new package to RHEL. Something like "Check EPEL to be sure your new package is newer" * Free discussion around EPEL * sticking with the alternate meeting time? we try another two or three weeks and decide afterwards === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-September/msg00006.html == Stats == === General === Number of EPEL Contributors 6 We welcome 6 new contributors: candyz joshuadf lkundrak ondrejj salimma sundaram === EPEL 5 === Number of source packages: 655 Number of binary packages: 1261 There are 18 new Packages: * abcde | A Better CD Encoder * aspell-sk | Slovak dictionaries for Aspell * cd-discid | Utility to get CDDB discid information * cvs2cl | Generate ChangeLogs from CVS working copies * dbench | Filesystem load benchmarking tool * directfb | Graphics abstraction library for the Linux Framebuffer Device * gcin | Input method for Traditional Chinese * gtk-qt-engine | A project allowing GTK to use Qt widget styles. * isync | Tool to synchronize IMAP4 and Maildir mailboxes * kasablanca | Graphical FTP client * lyx | WYSIWYM (What You See Is What You Mean) document processor * mach | Make a chroot * python-GnuPGInterface | A Python module to interface with GnuPG * pyzor | Pyzor collaborative spam filtering system * rubygem-rake | Ruby based make-like utility * rubygems | The Ruby standard for packaging ruby libraries * svn2cl | Create a ChangeLog from a Subversion log * tomcat-native | Tomcat native library === EPEL 4 === Number of source packages: 418 Number of binary packages: 850 There are 3 new Packages: * isync | Tool to synchronize IMAP4 and Maildir mailboxes * python-GnuPGInterface | A Python module to interface with GnuPG * pyzor | Pyzor collaborative spam filtering system ---- ["CategoryEPELReports"] From kevin at tummy.com Mon Sep 17 20:29:51 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Mon, 17 Sep 2007 14:29:51 -0600 Subject: clamav Message-ID: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> On Mon, 27 Aug 2007, Dag Wieers wrote: >On Mon, 27 Aug 2007, Kevin Fenzi wrote: > >> Since Enrico never intended to maintain clamav in EPEL, he has >> formally orphaned clamav in EL-4 and EL-5. >> >> Is there anyone out there that would be willing to take it on? >> >> Preferably someone who likes/understands Enrico's package setup so >> you >> can stay in sync with Fedora versions? >> >> If no one steps up soon, I might be able to take it over, but I would >> be quite likely to radically change the packaging. >Before you do, let's discuss how we can make things compatible in order >to help existing users :) ok. Sorry for getting behind on this... It doesn't look like anyone wants to step up and maintain the current package in EPEL. Would you be interested in maintaining your package in EPEL? Or failing that, would you be willing to let me use your package and just keep it in sync with your version upstream? Obviously, there would need to be testing to confirm that it upgrades the old 0.88.x version currently in EPEL correctly, but I can work on that if you don't mind me basing on your package. Any other thoughts or ideas? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Mon Sep 17 22:00:44 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 17 Sep 2007 16:00:44 -0600 Subject: clamav In-Reply-To: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> Message-ID: <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> On 9/17/07, Kevin Fenzi wrote: > On Mon, 27 Aug 2007, Dag Wieers wrote: > > >On Mon, 27 Aug 2007, Kevin Fenzi wrote: > > > >> Since Enrico never intended to maintain clamav in EPEL, he has > >> formally orphaned clamav in EL-4 and EL-5. > >> > >> Is there anyone out there that would be willing to take it on? > >> > >> Preferably someone who likes/understands Enrico's package setup so > >> you > >> can stay in sync with Fedora versions? > >> > >> If no one steps up soon, I might be able to take it over, but I would > >> be quite likely to radically change the packaging. > > >Before you do, let's discuss how we can make things compatible in order > >to help existing users :) > > ok. Sorry for getting behind on this... > > It doesn't look like anyone wants to step up and maintain the current > package in EPEL. > Actually I would be interested in doing it in the form you mentioned below. I thought it was moving behind the scenes from the last email you quoted above. I could be a co-maintainer as I have not maintained anything to this date. > Would you be interested in maintaining your package in EPEL? > > Or failing that, would you be willing to let me use your package and > just keep it in sync with your version upstream? > > Obviously, there would need to be testing to confirm that it upgrades > the old 0.88.x version currently in EPEL correctly, but I can work on > that if you don't mind me basing on your package. > > Any other thoughts or ideas? > > kevin > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > -- 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 kevin at tummy.com Tue Sep 18 16:30:15 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Tue, 18 Sep 2007 10:30:15 -0600 Subject: clamav In-Reply-To: <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> Message-ID: <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> On Mon, 17 Sep 2007 16:00:44 -0600 smooge at gmail.com ("Stephen John Smoogen") wrote: > > It doesn't look like anyone wants to step up and maintain the > > current package in EPEL. > > > > Actually I would be interested in doing it in the form you mentioned > below. I thought it was moving behind the scenes from the last email > you quoted above. I could be a co-maintainer as I have not maintained > anything to this date. Excellent. I think with packages like clamav that have lots of security updates in their history it would be good to have a number of (co)maintainers of the package. That way someone would always be around to push security updates... The more the better. Let's see what Dag thinks of us being able to use his package and go from there. > > > Would you be interested in maintaining your package in EPEL? > > > > Or failing that, would you be willing to let me use your package and > > just keep it in sync with your version upstream? > > > > Obviously, there would need to be testing to confirm that it > > upgrades the old 0.88.x version currently in EPEL correctly, but I > > can work on that if you don't mind me basing on your package. > > > > Any other thoughts or ideas? > > > > kevin kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin at tummy.com Tue Sep 18 16:39:50 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Tue, 18 Sep 2007 10:39:50 -0600 Subject: EPEL report week 37 2007 In-Reply-To: <46EEC0BA.3040807@leemhuis.info> References: <46EEC0BA.3040807@leemhuis.info> Message-ID: <20070918103950.337bf015@ghistelwchlohm.scrye.com> On Mon, 17 Sep 2007 20:00:26 +0200 fedora at leemhuis.info (Thorsten Leemhuis) wrote: ... snip... > * repo layout > > * the plan written at > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee336393aec81cf6fc90543c0f2277 > was to have directories for each release (e.g. have 5.0 as main repo > now and a symlink from 5 pointing to it; when 5.1 ships run "cp -al > 5.0 5.1" and adjust the "5" link to point to 5.1 instead; some weeks > or months later remove the 5.0 dir to save the space; 5.0 btw would > not be maintained anymore, we just leave it around for some > weeks/months). This would allow people still on EL5.0 (for example > those using derivates that do not ship 5.1 some weeks after RH does) > to use EPEL5.0 without running into dependency issues that might > arise when a package from EPEL5.1 depends on something from EL5.1; > > * seems lots of people forgot about that plan never realized it > full effects; do we still want that stuff? or in a modified way maybe? yeah, I didn't realize that was the full plan. Not sure why I didn't see that before. My concern with this is that the older repo will not be getting security updates, and that people will be depending on it not realizing it will go away. Not sure giving them a few weeks would assist any. People who don't want to update probibly won't update in a few weeks if there is no reason for them to do so. I propose the following instead. When 5.1 is released: - mv 5.0 to 5.1 - link 5 and 5.0 to 5.1 This does mean that if there is something in 5.1 thats a new dependency, 5.0 users will need to upgrade or not use that package. However, it means that security/big bugfixes will keep going in that repo, and that if there are no new dependencies, folks running 5.0 can keep using the repo. I don't think we have the manpower to maintain repos for each minor release. Also, aren't minor releases supposed to be ABI compatible? > * RHEL 5.1 > > * will likely be out soon; we don't know exactly when; thus the > estimated EPEL testing -> stable move that is pushed in parallel will > likely be a week (or two?) after EL 5.1 is out Do we want to try and push new stable packages out to the repo before 5.1 at some point here? I know we talked about doing monthly pushes of stable new packages from testing->stable. Also, I would really like to see the testing repo free of dependency issues before 5.1 is out. That would allow us to push everything in there into stable without problem. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mastahnke at gmail.com Wed Sep 19 01:32:40 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 18 Sep 2007 20:32:40 -0500 Subject: EPEL report week 37 2007 In-Reply-To: <20070918103950.337bf015@ghistelwchlohm.scrye.com> References: <46EEC0BA.3040807@leemhuis.info> <20070918103950.337bf015@ghistelwchlohm.scrye.com> Message-ID: <7874d9dd0709181832n113bd910k55eeac78be37fbc2@mail.gmail.com> On 9/18/07, Kevin Fenzi wrote: > On Mon, 17 Sep 2007 20:00:26 +0200 > fedora at leemhuis.info (Thorsten Leemhuis) wrote: > > ... snip... > > > * repo layout > > > > * the plan written at > > http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#head-a98bce5283ee336393aec81cf6fc90543c0f2277 > > was to have directories for each release (e.g. have 5.0 as main repo > > now and a symlink from 5 pointing to it; when 5.1 ships run "cp -al > > 5.0 5.1" and adjust the "5" link to point to 5.1 instead; some weeks > > or months later remove the 5.0 dir to save the space; 5.0 btw would > > not be maintained anymore, we just leave it around for some > > weeks/months). This would allow people still on EL5.0 (for example > > those using derivates that do not ship 5.1 some weeks after RH does) > > to use EPEL5.0 without running into dependency issues that might > > arise when a package from EPEL5.1 depends on something from EL5.1; > > > > * seems lots of people forgot about that plan never realized it > > full effects; do we still want that stuff? or in a modified way maybe? > > yeah, I didn't realize that was the full plan. Not sure why I didn't > see that before. > > My concern with this is that the older repo will not be getting > security updates, and that people will be depending on it not realizing > it will go away. Not sure giving them a few weeks would assist any. > People who don't want to update probibly won't update in a few weeks if > there is no reason for them to do so. > > I propose the following instead. > > When 5.1 is released: > > - mv 5.0 to 5.1 > - link 5 and 5.0 to 5.1 > > This does mean that if there is something in 5.1 thats a new > dependency, 5.0 users will need to upgrade or not use that package. > However, it means that security/big bugfixes will keep going in that > repo, and that if there are no new dependencies, folks running 5.0 can > keep using the repo. > > I don't think we have the manpower to maintain repos for each minor > release. Also, aren't minor releases supposed to be ABI compatible? I completely agree. We don't have the manpower, or maintainer power to do this any other way. (And yes they should be ABI compatible). > > > * RHEL 5.1 > > > > * will likely be out soon; we don't know exactly when; thus the > > estimated EPEL testing -> stable move that is pushed in parallel will > > likely be a week (or two?) after EL 5.1 is out > > Do we want to try and push new stable packages out to the repo before > 5.1 at some point here? I know we talked about doing monthly pushes of > stable new packages from testing->stable. > > Also, I would really like to see the testing repo free of dependency > issues before 5.1 is out. That would allow us to push everything in > there into stable without problem. > > kevin > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > > From sundaram at fedoraproject.org Wed Sep 19 12:20:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 19 Sep 2007 17:50:04 +0530 Subject: RHEL 5.1 new packages and EPEL conflicts Message-ID: <46F113F4.7020906@fedoraproject.org> Hi I noticed that yum-utils is now in EPEL. I removed it from the wishlist when I saw that RHEL 5.1 beta is including this package but it has gone in anyway. The list of new packages included in RHEL 5.1 beta is available in the announcement at http://thread.gmane.org/gmane.linux.redhat.release.tikanga.beta/844 yum-utils would have to be removed or version adjusted from atleast EPEL 5 so as to not conflict with RHEL 5.1 when it's released. I haven't done a comprehensive check so there might be other similar packages in the list. Just a quick heads up. Rahul From kevin at tummy.com Wed Sep 19 16:30:38 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 19 Sep 2007 10:30:38 -0600 Subject: RHEL 5.1 new packages and EPEL conflicts In-Reply-To: <46F113F4.7020906@fedoraproject.org> References: <46F113F4.7020906@fedoraproject.org> Message-ID: <20070919103038.6b3aa590@ghistelwchlohm.scrye.com> On Wed, 19 Sep 2007 17:50:04 +0530 sundaram at fedoraproject.org (Rahul Sundaram) wrote: > Hi > > I noticed that yum-utils is now in EPEL. I removed it from the > wishlist when I saw that RHEL 5.1 beta is including this package but > it has gone in anyway. > > The list of new packages included in RHEL 5.1 beta is available in > the announcement at > > http://thread.gmane.org/gmane.linux.redhat.release.tikanga.beta/844 > > yum-utils would have to be removed or version adjusted from atleast > EPEL 5 so as to not conflict with RHEL 5.1 when it's released. I > haven't done a comprehensive check so there might be other similar > packages in the list. Just a quick heads up. I did a check of all the packages in the beta announcement back when it came out. The following are packages in epel-5 that are going to be in RHEL-5.1: yum-utils dnsmasq python-imaging perl-TimeDate All of the RHEL-5.1 packages are newer than the ones in epel-5, so upgrades should work fine. I think once 5.1 is out those packages should be dead.packaged in epel-5 and we just go on with the ones in RHEL-5.1... Does anyone spot anything I missed with this? > Rahul kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jos at xos.nl Wed Sep 19 16:59:07 2007 From: jos at xos.nl (Jos Vos) Date: Wed, 19 Sep 2007 18:59:07 +0200 Subject: RHEL 5.1 new packages and EPEL conflicts In-Reply-To: <20070919103038.6b3aa590@ghistelwchlohm.scrye.com> References: <46F113F4.7020906@fedoraproject.org> <20070919103038.6b3aa590@ghistelwchlohm.scrye.com> Message-ID: <20070919165907.GA14773@jasmine.xos.nl> On Wed, Sep 19, 2007 at 10:30:38AM -0600, Kevin Fenzi wrote: > python-imaging This one was already in RHEL 5.0. > perl-TimeDate This has already been released as update for 5.0. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From kevin at tummy.com Wed Sep 19 23:01:48 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 19 Sep 2007 17:01:48 -0600 Subject: RHEL 5.1 new packages and EPEL conflicts In-Reply-To: <20070919165907.GA14773@jasmine.xos.nl> References: <46F113F4.7020906@fedoraproject.org> <20070919103038.6b3aa590@ghistelwchlohm.scrye.com> <20070919165907.GA14773@jasmine.xos.nl> Message-ID: <20070919170148.19c93431@ghistelwchlohm.scrye.com> On Wed, 19 Sep 2007 18:59:07 +0200 jos at xos.nl (Jos Vos) wrote: > On Wed, Sep 19, 2007 at 10:30:38AM -0600, Kevin Fenzi wrote: > > > python-imaging > > This one was already in RHEL 5.0. > > > perl-TimeDate > > This has already been released as update for 5.0. Ah ha. Good catch. I didn't look deeply enough. I have filed bugs to ask the maintainers of these 2 packages to mark the epel-5 branch with a 'dead.package' so it's clear they are no longer shipped in epel. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Thu Sep 20 02:06:56 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 19 Sep 2007 21:06:56 -0500 (CDT) Subject: RHEL 5.1 new packages and EPEL conflicts In-Reply-To: <20070919103038.6b3aa590@ghistelwchlohm.scrye.com> References: <46F113F4.7020906@fedoraproject.org> <20070919103038.6b3aa590@ghistelwchlohm.scrye.com> Message-ID: On Wed, 19 Sep 2007, Kevin Fenzi wrote: > dnsmasq Huh. Wonder who's maintaining that for RHEL. Jima From fedora at leemhuis.info Thu Sep 20 04:40:18 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Sep 2007 06:40:18 +0200 Subject: RHEL 5.1 new packages and EPEL conflicts In-Reply-To: <20070919165907.GA14773@jasmine.xos.nl> References: <46F113F4.7020906@fedoraproject.org> <20070919103038.6b3aa590@ghistelwchlohm.scrye.com> <20070919165907.GA14773@jasmine.xos.nl> Message-ID: <46F1F9B2.8000405@leemhuis.info> On 19.09.2007 18:59, Jos Vos wrote: > On Wed, Sep 19, 2007 at 10:30:38AM -0600, Kevin Fenzi wrote: > >> python-imaging > This one was already in RHEL 5.0. And it's on purpose in EPEL as it's missing in RHEL5.0-Server iirc, thus we ship it in EPEL (with a lower EVR iirc) to make sure people running server don't run into broken deps. So we should not remove it yet -- but the package should be part of RHEL5.1-Server afaik, thus we can remove it after that one it out. Cu knurd From jkeating at redhat.com Thu Sep 20 11:26:04 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 20 Sep 2007 07:26:04 -0400 Subject: RHEL 5.1 new packages and EPEL conflicts In-Reply-To: References: <46F113F4.7020906@fedoraproject.org> <20070919103038.6b3aa590@ghistelwchlohm.scrye.com> Message-ID: <20070920072604.1bc362d1@localhost.localdomain> On Wed, 19 Sep 2007 21:06:56 -0500 (CDT) Jima wrote: > Huh. Wonder who's maintaining that for RHEL. We use it for virt-manager, so Daniel Veillard owns it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jamatos at fc.up.pt Thu Sep 20 11:31:29 2007 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Thu, 20 Sep 2007 12:31:29 +0100 Subject: RHEL 5.1 new packages and EPEL conflicts In-Reply-To: <46F1F9B2.8000405@leemhuis.info> References: <46F113F4.7020906@fedoraproject.org> <20070919165907.GA14773@jasmine.xos.nl> <46F1F9B2.8000405@leemhuis.info> Message-ID: <200709201231.29606.jamatos@fc.up.pt> On Thursday 20 September 2007 05:40:18 Thorsten Leemhuis wrote: > So we should not remove it yet -- but the package should be part of > RHEL5.1-Server afaik, thus we can remove it after that one it out. > > Cu > knurd I will only act on that bug report after that happens. -- Jos? Ab?lio From mastahnke at gmail.com Wed Sep 19 22:14:25 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 19 Sep 2007 17:14:25 -0500 Subject: Meeting cancel for tonight Message-ID: <7874d9dd0709191514p7a96d66co8f9372f770d93f05@mail.gmail.com> I just got back from vacation and am not caught up with DayJob. I spoke with a few members of the SIG in #epel and a few couldn't make it. I am cancelling the EPEL meeting this evening/day/whatever. Next week with knurd leading. stahnma ps. feel free to work on any initiatives and send updates to list. From buildsys at fedoraproject.org Fri Sep 21 21:40:13 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 21 Sep 2007 17:40:13 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-21 Message-ID: <20070921214013.D04141BDB7@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 14 NEW awstats-6.7-1.el5 : Advanced Web Statistics cacti-0.8.6j-9.el5 (!) ctapi-common-1.1-3.el5 : INVALID rebuild, not published! ctapi-cyberjack-3.0.4-1.el5 ganymed-ssh2-210-5.el5 gcin-1.3.4-3.el5 NEW haproxy-1.3.12.2-3.el5 : HA-Proxy is a TCP/HTTP reverse proxy for high availability environments NEW kaffeine-0.8.5-4.el5 : Xine-based media player NEW nut-2.2.0-4.el5 : Network UPS Tools plone-3.0.1-1.el5 python-memcached-1.40-2.el5 svnkit-1.1.4-1.el5 NEW xine-lib-1.1.8-4.el5 : Xine library zabbix-1.4.2-3.el5 Packages built and released for Fedora EPEL testing/4: 7 cacti-0.8.6j-9.el4 (!) ctapi-common-1.1-3.el4 : INVALID rebuild, not published! ctapi-cyberjack-3.0.4-1.el4 NEW haproxy-1.3.12.2-4.el4 : HA-Proxy is a TCP/HTTP reverse proxy for high availability environments mercurial-0.9.4-4.el4 NEW nut-2.2.0-3.2.el4 : Network UPS Tools zabbix-1.4.2-3.el4 Changes in Fedora EPEL testing/5: awstats-6.7-1.el5 ----------------- * Tue Sep 18 2007 Tim Jackson 6.7-1 - initial import to EPEL-5, from Fedora cacti-0.8.6j-9.el5 ------------------ * Fri Sep 21 2007 Mike McGrath - 0.8.6j-9 - Added rest of official patches ctapi-common-1.1-3.el5 ---------------------- * Sat Aug 04 2007 Frank B?ttner - 1.1-3 - fix creation of the group and don't remove it ctapi-cyberjack-3.0.4-1.el5 --------------------------- * Mon Sep 17 2007 Frank B?ttner - 3.0.4-1 - update to 3.0.4 ganymed-ssh2-210-5.el5 ---------------------- * Mon Sep 10 2007 Robert Marcano 210-5 - Build for all supported arquitectures * Wed Aug 29 2007 Fedora Release Engineering - 210-4 - Rebuild for selinux ppc32 issue. gcin-1.3.4-3.el5 ---------------- * Thu Sep 20 2007 Chung-Yen Chang - 1.3.4-3 - update license field to LGPLv2 - add im-chooser to require haproxy-1.3.12.2-3.el5 ---------------------- * Fri Sep 21 2007 Jeremy Hinegardner - 1.3.12.2-3 - added pcre as Requires dependency * Thu Sep 20 2007 Jeremy Hinegardner - 1.3.12.2-2 - update License field * Thu Sep 20 2007 Jeremy Hinegardner - 1.3.12.2-1 - update to 1.3.12.2 - remove the upstream patch * Tue Sep 18 2007 Jeremy Hinegardner - 1.3.12.1-1 - switch to 1.3.12.1 branch - add patch from upstream with O'Reilly licensing updates. - convert ISO-8859-1 doc files to UTF-8 kaffeine-0.8.5-4.el5 -------------------- * Wed Sep 19 2007 Ville Skytt? - 0.8.5-4 - Avoid autotools re-run after configure (unclean upstream tarball?) * Sat Aug 25 2007 Rex Dieter 0.8.5-3 - respin (BuildID) nut-2.2.0-4.el5 --------------- * Wed Sep 19 2007 Tomas Smetana 2.2.0-4 - fix manpages encodings - run ldconfig after client (un)install * Thu Sep 06 2007 Tomas Smetana 2.2.0-3 - fix wrong libssl flags in devel, fix devel package dependencies plone-3.0.1-1.el5 ----------------- * Fri Sep 14 2007 Jonathan Steffan 3.0.1-1 - Update to Plone 3.0.1 python-memcached-1.40-2.el5 --------------------------- * Tue Sep 18 2007 Sean Reifschneider 1.40-2 - Adding setuptools to the buildreqs. * Tue Sep 18 2007 Sean Reifschneider 1.40-1 - Update to 1.40 upstream release. svnkit-1.1.4-1.el5 ------------------ * Mon Sep 10 2007 Robert Marcano - 1.1.4-1 - Update to upstream 1.1.4 - Build for all supported arquitectures * Wed Aug 29 2007 Fedora Release Engineering - 1.1.2-4 - Rebuild for selinux ppc32 issue. xine-lib-1.1.8-4.el5 -------------------- * Wed Sep 19 2007 Ville Skytt? - 1.1.8-4 - Fix "--without wavpack" build. * Sat Sep 15 2007 Ville Skytt? - 1.1.8-3 - Move XCB plugins to the main package. - Make aalib, caca, pulseaudio, jack, and wavpack support optional at build time in preparation for the first EPEL build. * Sun Sep 09 2007 Aurelien Bompard 1.1.8-2 - remove the dependency from -extras to -arts, and use Obsoletes to provide an upgrade path * Thu Aug 30 2007 Ville Skytt? - 1.1.8-1 - 1.1.8, "open" patch applied upstream. - Build XCB plugins by default for Fedora 8+ only. * Sat Aug 25 2007 Aurelien Bompard 1.1.7-3 - Split the aRts plugin into its own subpackage zabbix-1.4.2-3.el5 ------------------ * Thu Sep 20 2007 Dan Horak 1.4.2-3 - Fix paths (/usr/bin -> /usr/sbin) in init scripts (#297061) - Add a patch to clean a warning during compile - Add a patch to fix cpu load computations Changes in Fedora EPEL testing/4: cacti-0.8.6j-9.el4 ------------------ * Fri Sep 21 2007 Mike McGrath - 0.8.6j-9 - Added rest of official patches ctapi-common-1.1-3.el4 ---------------------- * Sat Aug 04 2007 Frank B?ttner - 1.1-3 - fix creation of the group and don't remove it ctapi-cyberjack-3.0.4-1.el4 --------------------------- * Mon Sep 17 2007 Frank B?ttner - 3.0.4-1 - update to 3.0.4 haproxy-1.3.12.2-4.el4 ---------------------- * Fri Sep 21 2007 Jeremy Hinegardner - 1.3.12.2-4 * update compile flags for different location of pcre.h on EL-4 * Fri Sep 21 2007 Jeremy Hinegardner - 1.3.12.2-3 - added pcre as Requires dependency * Thu Sep 20 2007 Jeremy Hinegardner - 1.3.12.2-2 - update License field * Thu Sep 20 2007 Jeremy Hinegardner - 1.3.12.2-1 - update to 1.3.12.2 - remove the upstream patch * Tue Sep 18 2007 Jeremy Hinegardner - 1.3.12.1-1 - switch to 1.3.12.1 branch - add patch from upstream with O'Reilly licensing updates. - convert ISO-8859-1 doc files to UTF-8 mercurial-0.9.4-4.el4 --------------------- * Thu Sep 20 2007 Neal Becker - 0.9.4-4 - remove /usr/share/contrib stuff for now * Thu Sep 20 2007 Neal Becker - 0.9.4-3 - Fix mercurial-install-contrib.patch (/usr/share/mercurial->/usr/share/mercurial/contrib) * Wed Aug 29 2007 Jonathan Shapiro - 0.9.4-2 - update to 0.9.4-2 - install contrib directory - set up required path for hgk - install man5 man pages * Thu Aug 23 2007 Neal Becker - 0.9.4-1 - update to 0.9.4 * Wed Jan 03 2007 Jeremy Katz - 0.9.3-1 - update to 0.9.3 - remove asciidoc files now that we have them as manpages * Mon Dec 11 2006 Jeremy Katz - 0.9.2-1 - update to 0.9.2 nut-2.2.0-3.2.el4 ----------------- * Wed Sep 19 2007 Tomas Smetana 2.2.0-3.2 - fix building of cgi package on x86_64 * Wed Sep 19 2007 Tomas Smetana 2.2.0-3.1 - fix manpages encodings - run ldconfig after client (un)install - remove hal support for EL4 * Thu Sep 06 2007 Tomas Smetana 2.2.0-3 - fix wrong libssl flags in devel, fix devel package dependencies zabbix-1.4.2-3.el4 ------------------ * Thu Sep 20 2007 Dan Horak 1.4.2-3 - Fix paths (%_bindir -> %_sbindir) in init scripts (#297061) - Add a patch to clean a warning during compile - Add a patch to fix cpu load computations * Sat Sep 15 2007 Dan Horak 1.4.2-2 - Add a patch required for finding net-snmp libs on x86_64 * Tue Sep 11 2007 Dan Horak 1.4.2-1 - New upstream release - built without WWW monitoring support due old libcurl For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From greg at runlevel7.ca Fri Sep 21 23:39:44 2007 From: greg at runlevel7.ca (Greg Swallow) Date: Fri, 21 Sep 2007 16:39:44 -0700 Subject: bugzilla rpms in testing/4 Message-ID: <46F45640.2060901@runlevel7.ca> I haven't really been following along to know if the plan is to wait for RHEL 4.6 to come out to move the bugzilla rpms from testing to stable, is it? Why I ask is because it looks like RHEL 4.6 will support bugzilla 3.0 if the newer version of perl-DBI is then available as it says in this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=250261 Maybe worth waiting for? Or would the EPEL policies allow updating to bugzilla 3.0 if 2.2 was already in "stable"? Greg From dag at wieers.com Sat Sep 22 01:01:41 2007 From: dag at wieers.com (Dag Wieers) Date: Sat, 22 Sep 2007 03:01:41 +0200 (CEST) Subject: clamav In-Reply-To: <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> Message-ID: On Tue, 18 Sep 2007, Kevin Fenzi wrote: > On Mon, 17 Sep 2007 16:00:44 -0600 > smooge at gmail.com ("Stephen John Smoogen") wrote: > > > > It doesn't look like anyone wants to step up and maintain the > > > current package in EPEL. > > > > > > > Actually I would be interested in doing it in the form you mentioned > > below. I thought it was moving behind the scenes from the last email > > you quoted above. I could be a co-maintainer as I have not maintained > > anything to this date. > > Excellent. I think with packages like clamav that have lots of security > updates in their history it would be good to have a number of > (co)maintainers of the package. That way someone would always be around > to push security updates... > > The more the better. > > Let's see what Dag thinks of us being able to use his package and go > from there. I have no problem helping out or discussing the SPEC file. I am pretty sure that a lot of improvements can be made and flow back. I also have no problem if the RPMforge SPEC files are to be used by other projects, and I know some people have done this. I do not feel that the SPEC files contain anything 'special'. In fact, I would not be surprised if people can come up with (almost) exactly the same SPEC file for a project. So I don't feel the need to add a license or copyright, you can think of the SPEC file as being in the public domain. In fact, I prefer that people use existing SPEC files and improve on them so that at least different packages have the same basis (and naming). I welcome feedback and ideas, but can understand to need for control and authority within a seperate project. -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From dag at wieers.com Sat Sep 22 04:50:04 2007 From: dag at wieers.com (Dag Wieers) Date: Sat, 22 Sep 2007 06:50:04 +0200 (CEST) Subject: Log from last weeks EPEL SIG meeting (20070912) In-Reply-To: <46EEB625.30401@leemhuis.info> References: <46EEB625.30401@leemhuis.info> Message-ID: On Mon, 17 Sep 2007, Thorsten Leemhuis wrote: > 00:35:34 BTW, I inserted this rule into RH's processes for adding a new package to RHEL. > 00:35:53 something like "Check EPEL to be sure your new package is newer" I would like to comment on this one. It would be important to add that epoch-inflation is undesirable/unwanted. I know that in some cases it cannot be avoided, but still I would hate to see Red Hat ship some older release with a higher (non-zero) epoch for convenience when they at least could see if the EPEL version would pass QA testing. -- -- 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 Sat Sep 22 11:00:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 22 Sep 2007 13:00:41 +0200 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> Message-ID: <46F4F5D9.8030002@leemhuis.info> CCing Fedora-Advisory Board On 22.09.2007 03:01, Dag Wieers wrote: > [...] I also have no problem if the RPMforge SPEC files are to be > used by other projects, and I know some people have done this. I do > not feel that the SPEC files contain anything 'special'. In fact, I > would not be surprised if people can come up with (almost) exactly > the same SPEC file for a project. So I don't feel the need to add a > license or copyright, you can think of the SPEC file as being in the > public domain. > > In fact, I prefer that people use existing SPEC files and improve on > them so that at least different packages have the same basis (and > naming). I welcome feedback and ideas, but can understand to need for > control and authority within a seperate project. +1 to this and I also have no problem if my spec files are used by other projects. I also would prefer if they are used that way and that improvements flow from one project to the other and vice versa. Using the pkgdb and the cvs-commits list it's easy for outsiders to already follow them -- I you want watchcommits access to some of my packages just let me know. I cannot speak for other peoples spec files and I suspect some packagers won't agree with the "SPEC files are public domain" statement -- making the license of the spec files explicit (a Wiki page that says "All our Fedora RPM SPEC files are free software and public domain if not otherwise specified in the spec file" might be enough already) in Fedora-land (EPEL, Fedora) would be best for all, as external projects (RPMForge, RPMFusion, Linva, freshrpms, ) than would be on the safe side if they use them. @FESCo, at Board, you have the power to do that -- are you willing to do something like that? Currently it's a bit a grey area IMHO and that sucks. tia! Cu knurd From fedora at leemhuis.info Sat Sep 22 16:03:31 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 22 Sep 2007 18:03:31 +0200 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <46F4F5D9.8030002@leemhuis.info> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> Message-ID: <46F53CD3.7010705@leemhuis.info> Seems I missed to CC Fedora-Advisory Board, thus sending this again. Sorry for the trouble epel-devel-list. On 22.09.2007 13:00, Thorsten Leemhuis wrote: > CCing Fedora-Advisory Board > > On 22.09.2007 03:01, Dag Wieers wrote: >> [...] I also have no problem if the RPMforge SPEC files are to be >> used by other projects, and I know some people have done this. I do >> not feel that the SPEC files contain anything 'special'. In fact, I >> would not be surprised if people can come up with (almost) exactly >> the same SPEC file for a project. So I don't feel the need to add a >> license or copyright, you can think of the SPEC file as being in the >> public domain. >> >> In fact, I prefer that people use existing SPEC files and improve on >> them so that at least different packages have the same basis (and >> naming). I welcome feedback and ideas, but can understand to need for >> control and authority within a seperate project. > > +1 to this and I also have no problem if my spec files are used by other > projects. I also would prefer if they are used that way and that > improvements flow from one project to the other and vice versa. Using > the pkgdb and the cvs-commits list it's easy for outsiders to already > follow them -- I you want watchcommits access to some of my packages > just let me know. > > I cannot speak for other peoples spec files and I suspect some packagers > won't agree with the "SPEC files are public domain" statement -- making > the license of the spec files explicit (a Wiki page that says "All our > Fedora RPM SPEC files are free software and public domain if not > otherwise specified in the spec file" might be enough already) in > Fedora-land (EPEL, Fedora) would be best for all, as external projects > (RPMForge, RPMFusion, Linva, freshrpms, ) than would be > on the safe side if they use them. > > @FESCo, at Board, you have the power to do that -- are you willing to do > something like that? Currently it's a bit a grey area IMHO and that > sucks. tia! > > Cu > knurd > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > > _______________________________________________ > fedora-advisory-board mailing list > fedora-advisory-board at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-advisory-board > From tibbs at math.uh.edu Sat Sep 22 16:12:56 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Sep 2007 11:12:56 -0500 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <46F4F5D9.8030002@leemhuis.info> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> I cannot speak for other peoples spec files and I suspect some TL> packagers won't agree with the "SPEC files are public domain" TL> statement You can be certain of it; for whatever reason, jpackage specfiles carry a block of license text, and they've been incorporated verbatim into Fedora. Which I honestly don't think should have been allowed, but nobody seemed to care when I raised the issue. I certainly agree that the issue begs clarification. - J< From jwboyer at jdub.homelinux.org Sat Sep 22 16:29:43 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 22 Sep 2007 11:29:43 -0500 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <46F4F5D9.8030002@leemhuis.info> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> Message-ID: <20070922112943.015b937c@vader.jdub.homelinux.org> On Sat, 22 Sep 2007 13:00:41 +0200 Thorsten Leemhuis wrote: > CCing Fedora-Advisory Board > > On 22.09.2007 03:01, Dag Wieers wrote: > > [...] I also have no problem if the RPMforge SPEC files are to be > > used by other projects, and I know some people have done this. I do > > not feel that the SPEC files contain anything 'special'. In fact, I > > would not be surprised if people can come up with (almost) exactly > > the same SPEC file for a project. So I don't feel the need to add a > > license or copyright, you can think of the SPEC file as being in the > > public domain. > > > > In fact, I prefer that people use existing SPEC files and improve on > > them so that at least different packages have the same basis (and > > naming). I welcome feedback and ideas, but can understand to need for > > control and authority within a seperate project. > > +1 to this and I also have no problem if my spec files are used by other > projects. I also would prefer if they are used that way and that > improvements flow from one project to the other and vice versa. Using > the pkgdb and the cvs-commits list it's easy for outsiders to already > follow them -- I you want watchcommits access to some of my packages > just let me know. > > I cannot speak for other peoples spec files and I suspect some packagers > won't agree with the "SPEC files are public domain" statement -- making > the license of the spec files explicit (a Wiki page that says "All our > Fedora RPM SPEC files are free software and public domain if not > otherwise specified in the spec file" might be enough already) in > Fedora-land (EPEL, Fedora) would be best for all, as external projects > (RPMForge, RPMFusion, Linva, freshrpms, ) than would be > on the safe side if they use them. > > @FESCo, at Board, you have the power to do that -- are you willing to do > something like that? Currently it's a bit a grey area IMHO and that > sucks. tia! I don't think you really want them to be considered public domain. You actually have to expressly say "This spec file is public domain" before that becomes true, otherwise it still holds a copyright by default. That's a lot of spec files to edit for no real gain. Personally, I consider spec files to be contributions to Fedora per the CLA. And since the Distribution as a whole is licensed under the GPLv2, the spec files are likely licensed under that too. (I AM NOT A LAWYER AND TAKING LEGAL ADVICE FROM ME WOULD BE VERY STUPID) Overall, I think it's just fine for the spec files to be used in other projects. The Board would ultimately have the call here. It's above FESCo. josh From luis at tieguy.org Sat Sep 22 16:37:35 2007 From: luis at tieguy.org (Luis Villa) Date: Sat, 22 Sep 2007 12:37:35 -0400 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> Message-ID: <2cb10c440709220937mc996cd7o4eeda12754469643@mail.gmail.com> On 22 Sep 2007 11:12:56 -0500, Jason L Tibbitts III wrote: > >>>>> "TL" == Thorsten Leemhuis writes: > > TL> I cannot speak for other peoples spec files and I suspect some > TL> packagers won't agree with the "SPEC files are public domain" > TL> statement (disclaimer: IANALY) At least under US copyright law, it isn't at all clear that spec files are copyrightable. When there are very few (or effectively one) way of expressing a particular idea, courts typically will find that there is no copyright protection for the expression(s) of the idea. This is known as 'merger doctrine', since the idea is said to be 'merged' with the expression of the idea. I'd suggest that most specfiles probably are like this- there are only so many ways to list which files need to be packaged, what the deps are, etc., and they mostly derive from known facts rather than creative choice on the part of the specfile author. (Dag, who obviously knows a hell of a lot more about specfiles than I do, seems to agree with me, but YMMV.) That said, it wouldn't hurt for Fedora to expressly note that they think that specfiles are not copyrighted/copyrightable, so that there is no confusion. Luis (again, disclaimer: IANALY) From fedora at leemhuis.info Sun Sep 23 17:07:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 23 Sep 2007 19:07:09 +0200 Subject: changes in the wiki to improve workflow Message-ID: <46F69D3D.50105@leemhuis.info> Hi all! I worked a bit in the wiki in the hope to improve the EPEL SIG workflow and to make the "do more on the lists" and "less in the meetings" a bit easier for everyone. I created special "tasks" pages for bigger EPEL tasks on our todo-list. For example: * http://fedoraproject.org/wiki/EPEL/Tasks/Rhel51 We should collect information here what needs to be prepared for the EPEL5 repo to be prepared once EL51 gets shipped. That page doesn't contain much info, but it's a start * http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData This is a old topic that has seen some process, but not much. Seems different people expect different things from this -- this page hopefully helps to sort that out and realize it afterwards. As many simple steps are not worth the overhead of a dedicated Wiki page I created http://fedoraproject.org/wiki/EPEL/Tasks/Misc to be used to collect small and easy tasks (e.g. those that can be described with a few words and should be realized within one or two weeks) to make sure they are not forgotten. In addition I even created http://fedoraproject.org/wiki/EPEL/Tasks/LongTerm to make sure some ideas for the long term are not forgotten as well. Note that *everyone* is allowed and hereby *encouraged* to edit those pages / add new tasks. I hope that way informations are written down there and don't get lost in the noise of a list (which is more often the case then I'd like). The task owners should keep a close eye on the pages (?) and make sure they are up2date. I'd be really glad if all owners of the task that have a dedicated page can give a weekly status update on the pages itself -- that way we avoid the "whats the latest status of " in the meetings and the writer of the weekly report can just include it in the repo, thus everyone knows what up and if tasks are moving. The schedule page collects the most crucial informations from the different pages and collects them to give a easier overview: http://fedoraproject.org/wiki/EPEL/Schedule#Tasks The topics for a meeting will be written to http://fedoraproject.org/wiki/EPEL/Schedule#TopicsForThisWeek -- but I'll try to send them to the list again more often ahead of the meeting. Questions? Comments? CU knurd (?) -- hint: subscribe to the page -- or even to all pages below EPEL/Tasks to know where work is being done From fedora at leemhuis.info Mon Sep 24 13:57:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 24 Sep 2007 15:57:39 +0200 Subject: EPEL report week 38 2007 Message-ID: <46F7C253.6040804@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week38 = Weekly EPEL Summary = Week 38/2007 == Most important happenings == * [:ThorstenLeemhuis:knurd] redesigned the schedule page in the wiki and created special "task" pages for each epel-todo-list task -- he hopes to improve the workflow. See his [https://www.redhat.com/archives/epel-devel-list/2007-September/msg00076.html announcement] for more details == EPEL SIG Meeting == Meting was canceld this week. Next meeting: 20070926 at 17:00 UTC in #fedora-meeting == Stats == === General === Number of EPEL Contributors 1 We welcome 1 new contributors: tsmetana === EPEL 5 === Number of source packages: 660 Number of binary packages: 1278 There are 5 new Packages: * awstats | Advanced Web Statistics * haproxy | HA-Proxy is a TCP/HTTP reverse proxy for high availability environments * kaffeine | Xine-based media player * nut | Network UPS Tools * xine-lib | Xine library === EPEL 4 === Number of source packages: 420 Number of binary packages: 856 There are 2 new Packages: * haproxy | HA-Proxy is a TCP/HTTP reverse proxy for high availability environments * nut | Network UPS Tools ---- ["CategoryEPELReports"] From buildsys at fedoraproject.org Mon Sep 24 18:41:53 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 24 Sep 2007 14:41:53 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-24 Message-ID: <20070924184153.D64C215212D@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 8 bugzilla-3.0.2-0.el5 NEW fedora-package-config-smart-5-1.el5 : Fedora EPEL configuration files for the Smart package manager NEW gkrellm-freq-1.0-7.el5 : CPU frequency display plugin for GKrellM NEW jack-audio-connection-kit-0.103.0-4.el5 : The Jack Audio Connection Kit NEW libid3tag-0.15.1b-4.el5 : ID3 tag manipulation library php-pear-MDB2-Driver-mysql-1.4.1-2.el5 NEW smart-0.51-49.el5 : Next generation package handling tool trac-bazaar-plugin-0.2-5.20070829bzr182.el5 Packages built and released for Fedora EPEL testing/4: 1 mercurial-0.9.4-8.el4 Changes in Fedora EPEL testing/5: bugzilla-3.0.2-0.el5 -------------------- * Mon Sep 24 2007 John Berninger - 3.0.2-0 - update to 3.0.2 - bz 299981 fedora-package-config-smart-5-1.el5 ----------------------------------- * Sun Sep 23 2007 Ville Skytt? - 5-1 - Initial EL-5 version based on Fedora's 6-8. - Add empty %build section. - License: GPL+ gkrellm-freq-1.0-7.el5 ---------------------- * Wed Sep 12 2007 Matthias Saou 1.0-7 - Fix License field, it's actually GPL+ which is okay for GPLv3 gkrellm. jack-audio-connection-kit-0.103.0-4.el5 --------------------------------------- * Tue Sep 04 2007 Andy Shevchenko 0.103.0-4 - fix Source Forge's URL scheme libid3tag-0.15.1b-4.el5 ----------------------- * Mon Aug 06 2007 Ville Skytt? - 0.15.1b-4 - License: GPLv2+ php-pear-MDB2-Driver-mysql-1.4.1-2.el5 -------------------------------------- * Sat Sep 22 2007 Christopher Stone 1.4.1-2 - Update Requires smart-0.51-49.el5 ----------------- * Sat Sep 22 2007 Ville Skytt? - 0.51-49 - 0.51; autofs, ccache, and autotools (partially) patches addressed upstream. * Sat Sep 08 2007 Ville Skytt? - 0.50-48 - KSmartTray desktop entry fixes. - License: GPLv2+ trac-bazaar-plugin-0.2-5.20070829bzr182.el5 ------------------------------------------- * Sat Sep 22 2007 Toshio Kuratomi - 0.2-5.20070829bzr182 - Patches to fix RSS feed in timeline view. * Wed Aug 29 2007 Toshio Kuratomi - 0.2-4.20070829bzr182 - Update license tag to reflect GPLv2+. - New update from upstream that clarifies license and makes setuptools build a correct tarball. * Sun Aug 12 2007 Toshio Kuratomi - 0.2-3.20070712bzr180 - Update license tag to reflect GPLv2 only. Changes in Fedora EPEL testing/4: mercurial-0.9.4-8.el4 --------------------- * Sat Sep 22 2007 Neal Becker - 0.9.4-8 - Just cp contrib tree. - Revert install -O2 * Thu Sep 20 2007 Neal Becker - 0.9.4-7 - Change setup.py install to -O2 to get bytecompile on EL-4 * Thu Sep 20 2007 Neal Becker - 0.9.4-6 - Revert last change. * Thu Sep 20 2007 Neal Becker - 0.9.4-5 - Use %ghost on contrib, otherwise EL-4 build fails For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dlutter at redhat.com Mon Sep 24 18:54:37 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 24 Sep 2007 11:54:37 -0700 Subject: Pushing updates to EPEL Message-ID: <1190660077.2973.8.camel@localhost.localdomain> I built a couple of packages 9 days ago, but htey are still sitting in plague with status 'needsign' ... am I missing an additional step ? What else do I need to do to get the packages added to/updated in EPEL ? David From mmcgrath at redhat.com Mon Sep 24 19:00:50 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 24 Sep 2007 14:00:50 -0500 Subject: Pushing updates to EPEL In-Reply-To: <1190660077.2973.8.camel@localhost.localdomain> References: <1190660077.2973.8.camel@localhost.localdomain> Message-ID: <46F80962.4070707@redhat.com> David Lutterkort wrote: > I built a couple of packages 9 days ago, but htey are still sitting in > plague with status 'needsign' ... am I missing an additional step ? What > else do I need to do to get the packages added to/updated in EPEL ? > > I think you're talking about the rubygem packages? If so they have been pushed to the testing repo: http://download.fedora.redhat.com/pub/epel/testing/5/i386/rubygem-rake-0.7.3-2.el5.noarch.rpm -Mike From smooge at gmail.com Mon Sep 24 20:54:09 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 24 Sep 2007 14:54:09 -0600 Subject: FYI: Revelation and other pygtk2 apps in EL-5 Message-ID: <80d7e4090709241354i18c5d40ala5f442c194ed6f1f@mail.gmail.com> Just an FYI for other people looking at this. Revelation and supposedly other apps that use pygtk2 will generate tracebacks in 5.0 due to a bug in the shipped version of pygtk2 (2.10.1). The fix showed somewhere between it and 2.10.4 which is what I needed to get the application working. I am going to try and figure out what patch does it so that hopefully it is a 5.2 fix (or a CentOS-We-Fix-Other-Broken-Code-For-Free repo until 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 fedora at leemhuis.info Tue Sep 25 04:40:23 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 25 Sep 2007 06:40:23 +0200 Subject: FYI: Revelation and other pygtk2 apps in EL-5 In-Reply-To: <80d7e4090709241354i18c5d40ala5f442c194ed6f1f@mail.gmail.com> References: <80d7e4090709241354i18c5d40ala5f442c194ed6f1f@mail.gmail.com> Message-ID: <46F89137.6070200@leemhuis.info> On 24.09.2007 22:54, Stephen John Smoogen wrote: > Just an FYI for other people looking at this. Revelation and > supposedly other apps that use pygtk2 will generate tracebacks in 5.0 > due to a bug in the shipped version of pygtk2 (2.10.1). This is https://bugzilla.redhat.com/show_bug.cgi?id=242652 > The fix showed > somewhere between it and 2.10.4 which is what I needed to get the > application working. I am going to try and figure out what patch does > it so that hopefully it is a 5.2 fix An that's: https://bugzilla.redhat.com/show_bug.cgi?id=237077#c4 BTW: I appreciate your efforts to get the fix into 5.2, as the chances realize this hopefully get bigger if more people yell ;-) CU knurd From dag at wieers.com Tue Sep 25 05:19:24 2007 From: dag at wieers.com (Dag Wieers) Date: Tue, 25 Sep 2007 07:19:24 +0200 (CEST) Subject: FYI: Revelation and other pygtk2 apps in EL-5 In-Reply-To: <80d7e4090709241354i18c5d40ala5f442c194ed6f1f@mail.gmail.com> References: <80d7e4090709241354i18c5d40ala5f442c194ed6f1f@mail.gmail.com> Message-ID: On Mon, 24 Sep 2007, Stephen John Smoogen wrote: > Just an FYI for other people looking at this. Revelation and > supposedly other apps that use pygtk2 will generate tracebacks in 5.0 > due to a bug in the shipped version of pygtk2 (2.10.1). The fix showed > somewhere between it and 2.10.4 which is what I needed to get the > application working. I am going to try and figure out what patch does > it so that hopefully it is a 5.2 fix (or a > CentOS-We-Fix-Other-Broken-Code-For-Free repo until then). This is a very big PITA for me too (and has been since RHEL 5 release). This bug however caused people to think about using Revelation for storing passwords (some sort of lock-in), ways to migrate away from Revelation, new Revelation development and the long-expected command line access to Revelation files. -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From tcallawa at redhat.com Tue Sep 25 20:59:46 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 25 Sep 2007 16:59:46 -0400 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <46F4F5D9.8030002@leemhuis.info> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> Message-ID: <1190753986.4114.4.camel@localhost.localdomain> On Sat, 2007-09-22 at 13:00 +0200, Thorsten Leemhuis wrote: > @FESCo, at Board, you have the power to do that -- are you willing to do > something like that? Currently it's a bit a grey area IMHO and that > sucks. tia! The CLA covers this: http://fedoraproject.org/wiki/Legal/Licenses/CLA "2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on behalf of the Project, and to recipients of software distributed by the Project: * (a) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your Contribution and such derivative works; and, * (b) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable (subject to Section 3) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer your Contribution and derivative works thereof, where such license applies only to those patent claims licensable by you that are necessarily infringed by your Contribution alone or by combination of your Contribution with the work to which you submitted the Contribution. Except for the license granted in this section, you reserve all right, title and interest in and to your Contributions." Short answer: All Fedora spec files get these rights. Anyone downloading them gets them too. ~spot From fedora at leemhuis.info Wed Sep 26 04:47:00 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 26 Sep 2007 06:47:00 +0200 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <1190753986.4114.4.camel@localhost.localdomain> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> Message-ID: <46F9E444.9090807@leemhuis.info> On 25.09.2007 22:59, Tom "spot" Callaway wrote: > On Sat, 2007-09-22 at 13:00 +0200, Thorsten Leemhuis wrote: > >> @FESCo, at Board, you have the power to do that -- are you willing to do >> something like that? Currently it's a bit a grey area IMHO and that >> sucks. tia! > > The CLA covers this: > > http://fedoraproject.org/wiki/Legal/Licenses/CLA > > "2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on > behalf of the Project, and to recipients of software distributed by the > Project: > * (a) a perpetual, non-exclusive, worldwide, fully paid-up, > royalty free, irrevocable copyright license to reproduce, > prepare derivative works of, publicly display, publicly perform, > sublicense, and distribute your Contribution and such derivative > works; and, > * (b) a perpetual, non-exclusive, worldwide, fully paid-up, > royalty free, irrevocable (subject to Section 3) patent license > to make, have made, use, offer to sell, sell, import, and > otherwise transfer your Contribution and derivative works > thereof, where such license applies only to those patent claims > licensable by you that are necessarily infringed by your > Contribution alone or by combination of your Contribution with > the work to which you submitted the Contribution. Except for the > license granted in this section, you reserve all right, title > and interest in and to your Contributions." > > Short answer: All Fedora spec files get these rights. Anyone downloading > them gets them too. And the latter is not obvious to anyone downloading the software. He often will not even be aware of a "Contributor Grant of License" that contributors make with the software provider, as he just wants to use the software and don't contribute to it. It's like a contract that one makes with the author of software "foo" that states that all contributions to foo are Free Software. But then foo get shipped without any license and the users of foo cannot be sure if it's free software (thus it would be unshippable in Fedora!). Further: As IANAL I read stuff like "a perpetual, non-exclusive, worldwide, fully paid-up [...] sublicense, and distribute your Contribution and such derivative works [...]" and wonder "that gives RH a lot of rights -- even to distribute it as non-free software" (afaics an IANAL). So who says it's free software if I just download a SPEC file from CVS or a SRPM from the web? IOW: We should obey our own guidelines that at http://fedoraproject.org/wiki/Packaging/ReviewGuidelines say: "If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it." I think we don't need to include it in the spec files, but clarifying it is IMHO really needed and not a big deal. So could the Board please put it on its agenda? Cu knurd From fedora at leemhuis.info Wed Sep 26 10:53:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 26 Sep 2007 12:53:30 +0200 Subject: Plan for todays (20070926) EPEL SIG meeting Message-ID: <46FA3A2A.10204@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 today, Wednesday at 17:00 UTC in #fedora-meeting on irc.freenode.org. /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData -- stahnma /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Rhel51 -- unassigned /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/KojiAndBodhiForEpel -- unassigned /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- yum-cron -- knurd /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- do more on the list and less in the meetings; "Power to the people with no delay." aka "make Steering Committee nearly unimportant" and "new schedule page" -- knurd /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/CommunicationPlan -- stahnma, quaid /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription -- quaid /topic EPEL SIG Meeting | Free discussion around EPEL 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 status update on the list and in the wiki on the individual task pages (linked from the schedule page: http://fedoraproject.org/wiki/EPEL/Schedule ). 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 Wed Sep 26 10:55:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 26 Sep 2007 12:55:25 +0200 Subject: yum-cron (was: Re: Plan for todays (20070926) EPEL SIG meeting) In-Reply-To: <46FA3A2A.10204@leemhuis.info> References: <46FA3A2A.10204@leemhuis.info> Message-ID: <46FA3A9D.9060404@leemhuis.info> On 26.09.2007 12:53, Thorsten Leemhuis wrote: > /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Misc > -- yum-cron -- knurd I filed #303131 and the package maintainer contacted me in private. He'll get in contact with the CentOS maintainer of yum-cron. Then we decide how to exactly solve the problem to make EPEL not replace yum-cron from CentOS. CU knurd From fedora at leemhuis.info Wed Sep 26 10:57:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 26 Sep 2007 12:57:21 +0200 Subject: task pages in the wiki (Re: Plan for todays (20070926) EPEL SIG meeting) In-Reply-To: <46FA3A2A.10204@leemhuis.info> References: <46FA3A2A.10204@leemhuis.info> Message-ID: <46FA3B11.3060207@leemhuis.info> On 26.09.2007 12:53, Thorsten Leemhuis wrote: > /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Misc > -- do more on the list and less in the meetings; "Power to the people > with no delay." aka "make Steering Committee nearly unimportant" and > "new schedule page" -- knurd Do you guys like what I did in the wiki? Here you can see it again in case you lost the URL: http://fedoraproject.org/wiki/EPEL/Schedule#Tasks Cu knurd From jwboyer at jdub.homelinux.org Wed Sep 26 14:14:45 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 26 Sep 2007 09:14:45 -0500 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> Message-ID: <20070926091445.7d71a7d6@weaponx.rchland.ibm.com> On Wed, 26 Sep 2007 10:05:44 -0400 (EDT) Max Spevack wrote: > On Wed, 26 Sep 2007, Thorsten Leemhuis wrote: > > > On 25.09.2007 22:59, Tom "spot" Callaway wrote: > >> On Sat, 2007-09-22 at 13:00 +0200, Thorsten Leemhuis wrote: > >> > >>> @FESCo, at Board, you have the power to do that -- are you willing to do > >>> something like that? Currently it's a bit a grey area IMHO and that > >>> sucks. tia! > >> > >> The CLA covers this: > >> > >> http://fedoraproject.org/wiki/Legal/Licenses/CLA > >> > >> "2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on > >> behalf of the Project, and to recipients of software distributed by the > >> Project: > >> * (a) a perpetual, non-exclusive, worldwide, fully paid-up, > >> royalty free, irrevocable copyright license to reproduce, > >> prepare derivative works of, publicly display, publicly perform, > >> sublicense, and distribute your Contribution and such derivative > >> works; and, > >> * (b) a perpetual, non-exclusive, worldwide, fully paid-up, > >> royalty free, irrevocable (subject to Section 3) patent license > >> to make, have made, use, offer to sell, sell, import, and > >> otherwise transfer your Contribution and derivative works > >> thereof, where such license applies only to those patent claims > >> licensable by you that are necessarily infringed by your > >> Contribution alone or by combination of your Contribution with > >> the work to which you submitted the Contribution. Except for the > >> license granted in this section, you reserve all right, title > >> and interest in and to your Contributions." > >> > >> Short answer: All Fedora spec files get these rights. Anyone downloading > >> them gets them too. > > > > And the latter is not obvious to anyone downloading the software. He > > often will not even be aware of a "Contributor Grant of License" that > > contributors make with the software provider, as he just wants to use > > the software and don't contribute to it. > > > > It's like a contract that one makes with the author of software "foo" > > that states that all contributions to foo are Free Software. But then > > foo get shipped without any license and the users of foo cannot be sure > > if it's free software (thus it would be unshippable in Fedora!). > > > > Further: As IANAL I read stuff like "a perpetual, non-exclusive, > > worldwide, fully paid-up [...] sublicense, and distribute your > > Contribution and such derivative works [...]" and wonder "that gives RH > > a lot of rights -- even to distribute it as non-free software" (afaics > > an IANAL). So who says it's free software if I just download a SPEC file > > from CVS or a SRPM from the web? > > > > IOW: We should obey our own guidelines that at > > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > > say: "If the source package does not include license text(s) as a > > separate file from upstream, the packager SHOULD query upstream to > > include it." I think we don't need to include it in the spec files, but > > clarifying it is IMHO really needed and not a big deal. > > > > So could the Board please put it on its agenda? > > What is the decision that you are looking for here, Thorsten? A > statement that the Fedora spec files are just as redistributable as all > the rest of our source code (ie: that the spec files are GPL'd just like > the source?) > > I must confess I don't really understand the fundamental question of > this thread. It would never even OCCUR to me to think that our spec > files aren't as Free as everything else. > > But if you can help me understand what you want, I will try to make that > thing happen. A declaration of what license (if any) the spec files are under globally. Spot is right in that they are covered by the CLA, but I don't consider that to be straight forward for people consuming downstream. It's also complicated by the fact that nothing disallows people from adding their own license to the spec file. The end goal is simply to allow others to take the Fedora spec files and use them in other projects. josh From jkeating at redhat.com Wed Sep 26 14:26:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 26 Sep 2007 10:26:17 -0400 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <20070926091445.7d71a7d6@weaponx.rchland.ibm.com> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> <20070926091445.7d71a7d6@weaponx.rchland.ibm.com> Message-ID: <20070926102617.70ad9ebb@redhat.com> On Wed, 26 Sep 2007 09:14:45 -0500 Josh Boyer wrote: > A declaration of what license (if any) the spec files are under > globally. Spot is right in that they are covered by the CLA, but I > don't consider that to be straight forward for people consuming > downstream. It's also complicated by the fact that nothing disallows > people from adding their own license to the spec file. > > The end goal is simply to allow others to take the Fedora spec files > and use them in other projects. Also we should probably make a decision project wise as to if allowing spec files in Fedora to be explicitly licensed (see jpp spec files) and if so how that interacts with the global license of all spec files. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Wed Sep 26 14:35:52 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 26 Sep 2007 09:35:52 -0500 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <20070926102617.70ad9ebb@redhat.com> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> <20070926091445.7d71a7d6@weaponx.rchland.ibm.com> <20070926102617.70ad9ebb@redhat.com> Message-ID: <20070926093552.3bdc4aa3@weaponx.rchland.ibm.com> On Wed, 26 Sep 2007 10:26:17 -0400 Jesse Keating wrote: > On Wed, 26 Sep 2007 09:14:45 -0500 > Josh Boyer wrote: > > > A declaration of what license (if any) the spec files are under > > globally. Spot is right in that they are covered by the CLA, but I > > don't consider that to be straight forward for people consuming > > downstream. It's also complicated by the fact that nothing disallows > > people from adding their own license to the spec file. > > > > The end goal is simply to allow others to take the Fedora spec files > > and use them in other projects. > > Also we should probably make a decision project wise as to if allowing > spec files in Fedora to be explicitly licensed (see jpp spec files) and > if so how that interacts with the global license of all spec files. Perhaps. Though you'll be opening yourself up for lots of interesting "you stole my licensed spec file!" debates if you disallow it. The jpp folks added the licensing explicitly because of Fedora contributors doing that. josh From mspevack at redhat.com Wed Sep 26 14:05:44 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 26 Sep 2007 10:05:44 -0400 (EDT) Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <46F9E444.9090807@leemhuis.info> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> Message-ID: On Wed, 26 Sep 2007, Thorsten Leemhuis wrote: > On 25.09.2007 22:59, Tom "spot" Callaway wrote: >> On Sat, 2007-09-22 at 13:00 +0200, Thorsten Leemhuis wrote: >> >>> @FESCo, at Board, you have the power to do that -- are you willing to do >>> something like that? Currently it's a bit a grey area IMHO and that >>> sucks. tia! >> >> The CLA covers this: >> >> http://fedoraproject.org/wiki/Legal/Licenses/CLA >> >> "2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on >> behalf of the Project, and to recipients of software distributed by the >> Project: >> * (a) a perpetual, non-exclusive, worldwide, fully paid-up, >> royalty free, irrevocable copyright license to reproduce, >> prepare derivative works of, publicly display, publicly perform, >> sublicense, and distribute your Contribution and such derivative >> works; and, >> * (b) a perpetual, non-exclusive, worldwide, fully paid-up, >> royalty free, irrevocable (subject to Section 3) patent license >> to make, have made, use, offer to sell, sell, import, and >> otherwise transfer your Contribution and derivative works >> thereof, where such license applies only to those patent claims >> licensable by you that are necessarily infringed by your >> Contribution alone or by combination of your Contribution with >> the work to which you submitted the Contribution. Except for the >> license granted in this section, you reserve all right, title >> and interest in and to your Contributions." >> >> Short answer: All Fedora spec files get these rights. Anyone downloading >> them gets them too. > > And the latter is not obvious to anyone downloading the software. He > often will not even be aware of a "Contributor Grant of License" that > contributors make with the software provider, as he just wants to use > the software and don't contribute to it. > > It's like a contract that one makes with the author of software "foo" > that states that all contributions to foo are Free Software. But then > foo get shipped without any license and the users of foo cannot be sure > if it's free software (thus it would be unshippable in Fedora!). > > Further: As IANAL I read stuff like "a perpetual, non-exclusive, > worldwide, fully paid-up [...] sublicense, and distribute your > Contribution and such derivative works [...]" and wonder "that gives RH > a lot of rights -- even to distribute it as non-free software" (afaics > an IANAL). So who says it's free software if I just download a SPEC file > from CVS or a SRPM from the web? > > IOW: We should obey our own guidelines that at > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > say: "If the source package does not include license text(s) as a > separate file from upstream, the packager SHOULD query upstream to > include it." I think we don't need to include it in the spec files, but > clarifying it is IMHO really needed and not a big deal. > > So could the Board please put it on its agenda? What is the decision that you are looking for here, Thorsten? A statement that the Fedora spec files are just as redistributable as all the rest of our source code (ie: that the spec files are GPL'd just like the source?) I must confess I don't really understand the fundamental question of this thread. It would never even OCCUR to me to think that our spec files aren't as Free as everything else. But if you can help me understand what you want, I will try to make that thing happen. --Max From mspevack at redhat.com Wed Sep 26 14:34:44 2007 From: mspevack at redhat.com (Max Spevack) Date: Wed, 26 Sep 2007 10:34:44 -0400 (EDT) Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <20070926091445.7d71a7d6@weaponx.rchland.ibm.com> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> <20070926091445.7d71a7d6@weaponx.rchland.ibm.com> Message-ID: On Wed, 26 Sep 2007, Josh Boyer wrote: > A declaration of what license (if any) the spec files are under > globally. Spot is right in that they are covered by the CLA, but I > don't consider that to be straight forward for people consuming > downstream. It's also complicated by the fact that nothing disallows > people from adding their own license to the spec file. > > The end goal is simply to allow others to take the Fedora spec files > and use them in other projects. Ok. I've asked Mark Webbink to clarify this for me explicitly, so that we can remove the confusion. I'll post back here when I hear from him. thanks, Max From rc040203 at freenet.de Wed Sep 26 15:01:46 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 26 Sep 2007 17:01:46 +0200 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <20070926091445.7d71a7d6@weaponx.rchland.ibm.com> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> <20070926091445.7d71a7d6@weaponx.rchland.ibm.com> Message-ID: <1190818906.2982.48.camel@mccallum.corsepiu.local> On Wed, 2007-09-26 at 09:14 -0500, Josh Boyer wrote: > On Wed, 26 Sep 2007 10:05:44 -0400 (EDT) > A declaration of what license (if any) the spec files are under > globally. Spot is right in that they are covered by the CLA, 1. The CLA is a bilateral contract. It is invisible to arbitrary users wanting to use these specs. 2. The CLA's applicability is controversial (compatibiltiy) wrt. some licenses, esp. GPL'ed packages. Fundamental question would be: Is an rpm a derivative work of the "original works"? > but I > don't consider that to be straight forward for people consuming > downstream. It's also complicated by the fact that nothing disallows > people from adding their own license to the spec file. Further questions arise from Fedora maintainers reusing/modifying upstream specs and/or specs from other origins (e.g. other distros). They can be covered by other copyrights/licenses (e.g. the GPL). > The end goal is simply to allow others to take the Fedora spec files > and use them in other projects. Ralf From fedora at leemhuis.info Wed Sep 26 17:02:38 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 26 Sep 2007 19:02:38 +0200 Subject: task pages in the wiki (Re: Plan for todays (20070926) EPEL SIG meeting) In-Reply-To: <46FA3B11.3060207@leemhuis.info> References: <46FA3A2A.10204@leemhuis.info> <46FA3B11.3060207@leemhuis.info> Message-ID: <46FA90AE.4030908@leemhuis.info> On 26.09.2007 12:57, Thorsten Leemhuis wrote: > On 26.09.2007 12:53, Thorsten Leemhuis wrote: >> /topic EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Misc >> -- do more on the list and less in the meetings; "Power to the people >> with no delay." aka "make Steering Committee nearly unimportant" and >> "new schedule page" -- knurd > Do you guys like what I did in the wiki? Here you can see it again in > case you lost the URL: > http://fedoraproject.org/wiki/EPEL/Schedule#Tasks >From #epel (beautified) --- someone> I need to really understand what we need to accomplish in that space. Yeah, I saw that page, (looks nice) [...] me> I just try to collect the informations in one place; e.g. what the task is about; what we want; what we archived already; what we still want to or need to do; me> especially this foobar stuff for me is a bit confusing; some people afaics want foo and bar, others baz; so we IMHO should try to sort out what we want, than start realizing it, adjust it again if needed and finish sooner or later someone> you have all these plans, like finishing things :) me> ;-) --- I other words: the pages are a bit meant for purposes like tracking status and progress as well as some background informations people that are not familiar with the task (yet) need if they want what that task is about. HTH CU knurd From mattdm at mattdm.org Wed Sep 26 17:34:51 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 26 Sep 2007 13:34:51 -0400 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> Message-ID: <20070926173451.GA27189@jadzia.bu.edu> On Wed, Sep 26, 2007 at 10:05:44AM -0400, Max Spevack wrote: > What is the decision that you are looking for here, Thorsten? A > statement that the Fedora spec files are just as redistributable as all > the rest of our source code (ie: that the spec files are GPL'd just like > the source?) I think the right thing to do is to make sure spec files are always such that they have no more restrictions than the upstream code that they build (even if the upstream license allows relicensing in a more strict way). In fact, I'd really like to encourage spec-files-as-public-domain. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dag at wieers.com Wed Sep 26 17:42:47 2007 From: dag at wieers.com (Dag Wieers) Date: Wed, 26 Sep 2007 19:42:47 +0200 (CEST) Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <20070926173451.GA27189@jadzia.bu.edu> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> <20070926173451.GA27189@jadzia.bu.edu> Message-ID: On Wed, 26 Sep 2007, Matthew Miller wrote: > On Wed, Sep 26, 2007 at 10:05:44AM -0400, Max Spevack wrote: > > What is the decision that you are looking for here, Thorsten? A > > statement that the Fedora spec files are just as redistributable as all > > the rest of our source code (ie: that the spec files are GPL'd just like > > the source?) > > I think the right thing to do is to make sure spec files are always such > that they have no more restrictions than the upstream code that they build > (even if the upstream license allows relicensing in a more strict way). > > In fact, I'd really like to encourage spec-files-as-public-domain. Me too. I cannot see much value in SPEC files and 2 persons can end up making the exact SPEC file. What is required to make something public domain ? Is it sufficient to add a file in a directory, or do I need to add a line on top ? If so, I have no problem to put that information in every SPEC file. -- -- 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 Wed Sep 26 17:52:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 26 Sep 2007 19:52:39 +0200 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: <20070926173451.GA27189@jadzia.bu.edu> References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> <20070926173451.GA27189@jadzia.bu.edu> Message-ID: <46FA9C67.8090700@leemhuis.info> On 26.09.2007 19:34, Matthew Miller wrote: > > In fact, I'd really like to encourage spec-files-as-public-domain. +1 CU knurd From fedora at leemhuis.info Wed Sep 26 17:53:20 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 26 Sep 2007 19:53:20 +0200 Subject: permission to use spec files in other projects (Was Re: clamav) In-Reply-To: References: <20070917142951.09287d9b@ghistelwchlohm.scrye.com> <80d7e4090709171500g74dbd3cbh82d1b751538fba50@mail.gmail.com> <20070918103015.2daac3f9@ghistelwchlohm.scrye.com> <46F4F5D9.8030002@leemhuis.info> <1190753986.4114.4.camel@localhost.localdomain> <46F9E444.9090807@leemhuis.info> <20070926091445.7d71a7d6@weaponx.rchland.ibm.com> Message-ID: <46FA9C90.6080408@leemhuis.info> On 26.09.2007 16:34, Max Spevack wrote: > On Wed, 26 Sep 2007, Josh Boyer wrote: > >> A declaration of what license (if any) the spec files are under >> globally. Spot is right in that they are covered by the CLA, but I >> don't consider that to be straight forward for people consuming >> downstream. It's also complicated by the fact that nothing disallows >> people from adding their own license to the spec file. >> >> The end goal is simply to allow others to take the Fedora spec files >> and use them in other projects. Yeah, exactly that. > Ok. I've asked Mark Webbink to clarify this for me explicitly, so that > we can remove the confusion. I'll post back here when I hear from him. Thanks for your work Max. CU knurd From gilboad at gmail.com Thu Sep 27 07:10:52 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 27 Sep 2007 09:10:52 +0200 Subject: RFE: EPEL-testing (disabled) in epel-release? Message-ID: <1190877052.30409.3.camel@gilboa-home-dev.localdomain> Hello all, As the title suggest, will it be possible to ship a new epel-release RPM with epel-testing support? (As in fedora-update-testing, it should be disabled by default). This should add much needed testing to new package releases. - Gilboa From fedora at leemhuis.info Thu Sep 27 07:35:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 27 Sep 2007 09:35:49 +0200 Subject: RFE: EPEL-testing (disabled) in epel-release? In-Reply-To: <1190877052.30409.3.camel@gilboa-home-dev.localdomain> References: <1190877052.30409.3.camel@gilboa-home-dev.localdomain> Message-ID: <46FB5D55.1040600@leemhuis.info> On 27.09.2007 09:10, Gilboa Davara wrote: > > As the title suggest, will it be possible to ship a new epel-release RPM > with epel-testing support? (As in fedora-update-testing, it should be > disabled by default). > This should add much needed testing to new package releases. Good idea (I actually though we did that). But why not ship a separate epel-testing-release package with testing enabled? Then people just need to install that one using yum and don't have to modify configuration files (which also avoids rpmnew-files as well). CU knurd From opensource at till.name Thu Sep 27 12:17:55 2007 From: opensource at till.name (Till Maas) Date: Thu, 27 Sep 2007 14:17:55 +0200 Subject: RFE: EPEL-testing (disabled) in epel-release? In-Reply-To: <46FB5D55.1040600@leemhuis.info> References: <1190877052.30409.3.camel@gilboa-home-dev.localdomain> <46FB5D55.1040600@leemhuis.info> Message-ID: <200709271418.02356.opensource@till.name> On Do September 27 2007, Thorsten Leemhuis wrote: > But why not ship a separate epel-testing-release package with testing > enabled? Then people just need to install that one using yum and don't > have to modify configuration files (which also avoids rpmnew-files as > well). The advantage of an disabled testing repo configuration is, that one can easily install/update a single package from there with "yum --enablerepo updates-testing update foo" without installing all packages from testing. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dennis at ausil.us Thu Sep 27 12:22:45 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 27 Sep 2007 07:22:45 -0500 Subject: RFE: EPEL-testing (disabled) in epel-release? In-Reply-To: <1190877052.30409.3.camel@gilboa-home-dev.localdomain> References: <1190877052.30409.3.camel@gilboa-home-dev.localdomain> Message-ID: <200709270722.45512.dennis@ausil.us> Once upon a time Thursday 27 September 2007, Gilboa Davara wrote: > Hello all, > > As the title suggest, will it be possible to ship a new epel-release RPM > with epel-testing support? (As in fedora-update-testing, it should be > disabled by default). > This should add much needed testing to new package releases. > it is already there Dennis From fedora at leemhuis.info Thu Sep 27 12:30:37 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 27 Sep 2007 14:30:37 +0200 Subject: RFE: EPEL-testing (disabled) in epel-release? In-Reply-To: <200709271418.02356.opensource@till.name> References: <1190877052.30409.3.camel@gilboa-home-dev.localdomain> <46FB5D55.1040600@leemhuis.info> <200709271418.02356.opensource@till.name> Message-ID: <46FBA26D.1070606@leemhuis.info> On 27.09.2007 14:17, Till Maas wrote: > On Do September 27 2007, Thorsten Leemhuis wrote: > >> But why not ship a separate epel-testing-release package with testing >> enabled? Then people just need to install that one using yum and don't >> have to modify configuration files (which also avoids rpmnew-files as >> well). > > The advantage of an disabled testing repo configuration is, that one can > easily install/update a single package from there with "yum --enablerepo > updates-testing update foo" without installing all packages from testing. Good point. /me wonders if we could do both at the same time... Cu knurd From buildsys at fedoraproject.org Thu Sep 27 13:01:02 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 27 Sep 2007 09:01:02 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-27 Message-ID: <20070927130102.B58AD15212D@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 6 NEW amavisd-new-2.4.5-1.el5 : Email filter with virus scanner and spamassassin support facter-1.3.8-1.el5 NEW optipng-0.5.5-1.el5 : A PNG optimizer and converter NEW python-fedora-0.2.90.19-1.el5 : Python modules for talking to Fedora Infrastructure Services python-iniparse-0.2.2-1.el5 xine-lib-1.1.8-5.el5 Packages built and released for Fedora EPEL testing/4: 1 facter-1.3.8-1.el4 Changes in Fedora EPEL testing/5: amavisd-new-2.4.5-1.el5 ----------------------- * Thu Feb 22 2007 Steven Pritchard 2.4.5-1 - Update to 2.4.5. facter-1.3.8-1.el5 ------------------ * Mon Sep 24 2007 David Lutterkort - 1.3.8-1 - Update license tag - Copy all of lib/ into ruby_sitelibdir optipng-0.5.5-1.el5 ------------------- * Tue Feb 06 2007 Till Maas - 0.5.5-1 - Version bump python-fedora-0.2.90.19-1.el5 ----------------------------- * Tue Sep 25 2007 Toshio Kuratomi - 0.2.90.19-1 - New upstream release with a FAS2 unicode fix. * Mon Sep 24 2007 Toshio Kuratomi - 0.2.90.18-3 - Fix the Source URL. Should be fedorapeople rather than fedoraproject. * Fri Sep 21 2007 Toshio Kuratomi - 0.2.90.18-2 - BR: python-setuptools-devel as this has been split in the new versions. * Tue Sep 18 2007 Toshio Kuratomi - 0.2.90.18-1 - Update to version wih handling of control-center-maint bugzilla address. * Tue Sep 18 2007 Toshio Kuratomi - 0.2.90.17-2 - Minor touchups to description and URL. * Mon Sep 17 2007 Toshio Kuratomi - 0.2.90.17-1 - Update to 0.2.90.17. - Build separate packages for pieces useful on clients and only on the server. * Mon Sep 10 2007 Toshio Kuratomi - 0.2.90.16-1 - Bugfix to fasLDAP module. * Fri Sep 07 2007 Toshio Kuratomi - 0.2.90.15-1 - Make the fasLDAP module more OO. - Bugfixes. - Update the install line. python-iniparse-0.2.2-1.el5 --------------------------- * Tue Sep 25 2007 Tim Lauridsen - 0.2.2-1 - Updated to release 0.2.2 - removed patch to to fix problems with out commented lines, included in upstream source * Wed Sep 12 2007 Tim Lauridsen - 0.2.1-4 - Added some logic to get the right python-setuptools buildrequeres - based on the fedora version, to make the same spec file useful in - all fedora releases. * Mon Sep 10 2007 Tim Lauridsen - 0.2.1-3 - Added patch from upstream svn to fix problems with out commented lines. * Tue Aug 28 2007 Tim Lauridsen - 0.2.1-2 - Changed BuildRequires python-setuptools to python-setuptools-devel xine-lib-1.1.8-5.el5 -------------------- * Sun Sep 23 2007 Ville Skytt? - 1.1.8-5 - Enable JACK support by default for all distros. Changes in Fedora EPEL testing/4: facter-1.3.8-1.el4 ------------------ * Mon Sep 24 2007 David Lutterkort - 1.3.8-1 - Update license tag - Copy all of lib/ into ruby_sitelibdir For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From mastahnke at gmail.com Thu Sep 27 13:51:35 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 27 Sep 2007 08:51:35 -0500 Subject: RFE: EPEL-testing (disabled) in epel-release? In-Reply-To: <200709270722.45512.dennis@ausil.us> References: <1190877052.30409.3.camel@gilboa-home-dev.localdomain> <200709270722.45512.dennis@ausil.us> Message-ID: <7874d9dd0709270651u4e3d1a9cs3953d07295e07705@mail.gmail.com> On 9/27/07, Dennis Gilmore wrote: > Once upon a time Thursday 27 September 2007, Gilboa Davara wrote: > > Hello all, > > > > As the title suggest, will it be possible to ship a new epel-release RPM > > with epel-testing support? (As in fedora-update-testing, it should be > > disabled by default). > > This should add much needed testing to new package releases. > > > it is already there > > Dennis I thought it was. I like solving problems before they happen. :) > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From gilboad at gmail.com Thu Sep 27 15:00:20 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 27 Sep 2007 17:00:20 +0200 Subject: RFE: EPEL-testing (disabled) in epel-release? In-Reply-To: <200709270722.45512.dennis@ausil.us> References: <1190877052.30409.3.camel@gilboa-home-dev.localdomain> <200709270722.45512.dennis@ausil.us> Message-ID: <1190905220.30409.37.camel@gilboa-home-dev.localdomain> On Thu, 2007-09-27 at 07:22 -0500, Dennis Gilmore wrote: > Once upon a time Thursday 27 September 2007, Gilboa Davara wrote: > > Hello all, > > > > As the title suggest, will it be possible to ship a new epel-release RPM > > with epel-testing support? (As in fedora-update-testing, it should be > > disabled by default). > > This should add much needed testing to new package releases. > > > it is already there > > Dennis Found it... Thanks, -Gilboa "Knocks his head against the wall a couple of times for missing it" Davara. From florin at andrei.myip.org Thu Sep 27 16:18:45 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 27 Sep 2007 09:18:45 -0700 Subject: add to wishlist: rsyslog Message-ID: <46FBD7E5.5010209@andrei.myip.org> Somebody who can edit the wishlist page - please add rsyslog to the list: http://www.rsyslog.com/ It looks like Fedora is moving towards rsyslog, it's already in the development tree, it would be nice to have it in EPEL. Thanks, -- Florin Andrei http://florin.myip.org/ From sundaram at fedoraproject.org Thu Sep 27 16:26:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 27 Sep 2007 21:56:25 +0530 Subject: add to wishlist: rsyslog In-Reply-To: <46FBD7E5.5010209@andrei.myip.org> References: <46FBD7E5.5010209@andrei.myip.org> Message-ID: <46FBD9B1.8080004@fedoraproject.org> Florin Andrei wrote: > Somebody who can edit the wishlist page - please add rsyslog to the list: > > http://www.rsyslog.com/ > > It looks like Fedora is moving towards rsyslog, it's already in the > development tree, it would be nice to have it in EPEL. Done. Rahul From fedora at leemhuis.info Thu Sep 27 17:58:58 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 27 Sep 2007 19:58:58 +0200 Subject: Log from this weeks (200700926) EPEL SIG Meeting Message-ID: <46FBEF62.1040906@leemhuis.info> 00:01:20 < knurd> | Hi everybody; who's around for the EPEL meeting? 00:01:20 * | knurd likes to remind everyone that the schedule for todays meeting as well as a list of all open tasks can be found on http://fedoraproject.org/wiki/EPEL/Schedule 00:01:20 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:01:23 * | nirik looks around to see if there is an epel meeting. 00:01:34 --> | kwizart has joined #fedora-meeting 00:01:36 --> | kwizart is Unknown 00:01:42 * | mmcgrath here 00:02:01 * | nirik is here. 00:03:05 < knurd> | stahnma said he might miss te meeting 00:03:06 * | marek - Marek Mahut present. 00:03:27 * | quaid is here for a few minutes 00:03:30 < knurd> | well, let's start 00:03:44 * | knurd reshuffles the topic list 00:03:51 --- | knurd has changed the topic to: EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription -- quaid 00:03:57 < knurd> | quaid, what's the status of this? 00:04:14 < knurd> | nobody complained on the list 00:04:36 < knurd> | so should we just say "this is it now" to finally get that relized and off the todo-list? 00:04:56 * | nirik pulls up the link to look at it. 00:04:59 < quaid> | um, homm 00:05:11 < quaid> | yep, that was it; no complaints, it's therefore done. 00:05:27 < quaid> | and can always be updated :) 00:05:28 * | abadger1999 sits in the bleachers 00:05:42 * | quaid doesn't think a ratification is needed to update it, so let it be wikiified 00:05:46 < knurd> | that okay for everybody? 00:05:51 < knurd> | quaid, +1 00:05:55 < nirik> | +1 from me 00:06:00 < mmcgrath> | +1 00:06:30 < knurd> | k, settled then 00:06:41 < quaid> | coo' 00:06:48 < knurd> | quaid, will you put the links on the front page and everywhere else where needed? 00:07:26 <-- | couf has quit (Read error: 110 (Connection timed out)) 00:07:28 --- | knurd has changed the topic to: EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/CommunicationPlan -- stahnma, quaid 00:07:35 < knurd> | quaid, same proceedure? 00:08:55 < knurd> | lala 00:08:56 < quaid> | yep 00:09:08 < knurd> | that fine for everyone? 00:09:09 < quaid> | I think I passed that one to the list for review, don't recall any further comments 00:09:38 < quaid> | I'm not likely to do any wiki relinking or stuff this week 00:09:42 < knurd> | quaid, that matches my memory 00:09:48 < quaid> | maybe leave me a new task for next week? 00:10:05 < knurd> | quaid, will do 00:10:21 < knurd> | anyway, no complains on http://fedoraproject.org/wiki/EPEL/CommunicationPlan? then I consider it accepted 00:10:33 * | nirik reads. 00:10:38 < knurd> | we of couse can easily modify it later in any case without the meeting/list overhead 00:10:57 < nirik> | yeah, seems ok to me. 00:11:21 < knurd> | k, accepted then 00:11:31 --- | knurd has changed the topic to: EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Rhel51 -- unassigned 00:11:38 < knurd> | I added that task 00:11:50 < knurd> | there are some preparations we likely should do 00:12:09 < knurd> | e.g. -- remove yum-utils as it is now in RHEL? 00:12:11 < nirik> | fixing broken deps in testing? 00:12:23 < knurd> | or just leave it in EPEL for some more weeks until CentOS catches up? 00:12:26 < knurd> | nirik, that as well 00:12:39 < mmcgrath> | I think someone suggested 1 week or 2 weeks wait, I think either is fine. 00:12:40 < knurd> | nirik, you seem to be taking care of it in parts already 00:12:55 < mmcgrath> | and regarding yum-utils and python-imaging, I think those should be removed. 00:12:56 < knurd> | can you put that task on your plate? I'll help where needed 00:13:01 < nirik> | I would say we should file bugs against each of the packages that got pulled into rhel to dead.package their cvs and then we can remove them from the repo(s) 00:13:24 < mmcgrath> | though, perhaps, they're not doing any harm just sitting there and not updated (protect the e-v-r) 00:13:24 < nirik> | sure. 00:13:25 < knurd> | mmcgrath, will CentOS catch up withing 1 or 2 weeks? 00:13:34 < knurd> | mmcgrath, four weeks might be safer 00:13:43 < nirik> | catch up? meaning release 5.1? or ? 00:13:44 < mmcgrath> | not sure, what harm would come of it if they didn't? 00:14:06 --- | couf_ is now known as couf 00:14:08 * | knurd thinks about it 00:14:36 < knurd> | mmcgrath, stuff that might depend on yum-utils would create broken deps 00:14:48 < mmcgrath> | k 00:14:51 < knurd> | (at least is yum-utils is not in centos -- don't know) 00:15:05 < f13> | might I suggest that you leave the package in the repo until CentOS catches up, then drop them? 00:15:07 < knurd> | nirik, bugs sound fine 00:15:08 < mmcgrath> | if we're going to block on CentOS lets not pick a date, we'll let them do that. 00:15:13 < f13> | obviously you wouldn't do any new releases of them. 00:15:24 * | nirik is confused... we are talking about yum-utils? or 5.1? 00:15:24 < knurd> | mmcgrath, f13, yeah, sounds fine 00:15:32 < knurd> | there is also scientific linux 00:15:51 < knurd> | nirik, we are talking about when to remove yum-utils once 5.1 is out 00:16:21 < nirik> | ok. Is centos going to remove theirs as well? 00:16:52 < f13> | I would imagine so 00:16:54 < mmcgrath> | nirik: did centos add yum-utils? 00:16:56 < knurd> | nirik, I suppose they will switch to the one from RHEL? 00:17:13 < nirik> | Well, they have yum-utils in their extras repo. 00:17:29 < nirik> | note that they ship their own yum version, so not sure if they will switch to the RHEL one. 00:17:38 < knurd> | nirik, well, if it becomes a part of RHEL 5.1 it will be in centos-base 5.1 afaik 00:17:57 < nirik> | yeah, dunno. 00:18:10 < knurd> | well, let's simply wait and see 00:18:13 < nirik> | In any case waiting sounds fine to me. 00:18:13 < knurd> | and decide later 00:18:34 < knurd> | but somebody should take care of this and oher issues for 5.1 00:18:39 < knurd> | any volunteers? 00:19:07 < nirik> | I'm happy to work on bugging people about broken deps and trying to work on the repo. 00:19:13 < knurd> | e.g. put stuff like what we just discussed on the wiki page to make sure we get back to it when it happens 00:19:28 < knurd> | s/it happens/later/ 00:19:35 < nirik> | I can try and do that... 00:19:46 < knurd> | nirik, k; can we own that task together then? 00:19:54 * | nirik looks at the clock, hoping days would start being 30 hours each. 00:19:59 < nirik> | knurd: sounds good. 00:20:06 < knurd> | nirik, many thx 00:20:13 --- | knurd has changed the topic to: EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData -- stahnma 00:20:23 < knurd> | stahnma is not around 00:20:31 < knurd> | I sugest we skip this topic 00:20:42 --- | knurd has changed the topic to: EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/KojiAndBodhiForEpel -- unassigned 00:20:49 < nirik> | sounds fine. I think it keeps needing more defintion of what it is. 00:20:55 < knurd> | nirik, +1 00:21:04 < knurd> | nirik, one reasons why I created the task pages 00:21:16 < knurd> | so we have a place to put that defintion ;-) 00:21:20 < nirik> | yep. 00:21:26 < knurd> | back to bodhi und koji 00:21:39 < knurd> | I think we all agree that we want to switch to them in the long run? 00:21:51 < nirik> | so this is blocked on koji being able to hide RHEL binaries, right? 00:22:03 < knurd> | nirik, this is the most important blocker yes 00:22:18 < knurd> | I suppose other problems might show up 00:22:26 < knurd> | but that one needs to be solved first 00:22:27 < nirik> | should we file a RFE or the like so at least we can see if the koji folks have it on the radar? 00:22:39 < knurd> | nirik, stuff like that 00:22:48 < knurd> | not sure if dgilmore has it on his radar 00:23:09 < knurd> | but a RFE would be a good start 00:23:41 < knurd> | and a owner for that task would help as well -- then koji developers know whom to contact in case of questions 00:23:42 <-- | llaumgui has quit (Connection timed out) 00:23:54 < nirik> | I'm happy to file a bug... I have no knowledge of koji internals tho, so I can't really work on coding anything. 00:24:18 < knurd> | nirik, k; can you put that # into the wiki please? and CC me? tia! 00:24:24 < nirik> | ok. 00:24:29 --- | knurd has changed the topic to: EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- yum-cron -- knurd 00:24:53 < knurd> | skipping that if that's okay for eveybody -- things are in hte works again 00:25:00 < knurd> | I gave a update on the list 00:25:07 --- | knurd has changed the topic to: EPEL SIG Meeting | http://fedoraproject.org/wiki/EPEL/Tasks/Misc -- do more on the list and less in the meetings; "Power to the people with no delay." aka "make Steering Committee nearly unimportant" and "new schedule page" -- knurd 00:25:22 < knurd> | do you guys like what I did to the schedule page in the wiki? 00:25:51 < mmcgrath> | how does doing things on the list take anything away from the steering committee? 00:25:52 < nirik> | yeah, sounds fine to me. 00:26:24 < mmcgrath> | or is that part of the power to the people part :) 00:26:27 * | mmcgrath takes a look at the wiki 00:26:30 < knurd> | mmcgrath, more like in "if nobody complains on the list (or in the IRC meetings) its simply considered accepted" 00:26:39 < mmcgrath> | ah 00:26:43 < mmcgrath> | +1 from me 00:27:00 < knurd> | it's just a general idea IMHO 00:27:10 < knurd> | we just need to find way to realize that idea 00:27:20 < knurd> | the new stuff in the wiki is a first step for me 00:27:38 < knurd> | I hope we do more, but I don#t know yet exactly what to do 00:27:43 < knurd> | suggestions welcomed 00:27:49 --> | llaumgui (LLaumgui) has joined #fedora-meeting 00:27:50 --> | hircus (Michel Salim) has joined #fedora-meeting 00:28:24 * | knurd will move on if nobody wants to say more about this topic 00:28:38 --- | knurd has changed the topic to: EPEL SIG Meeting | Free discussion around EPEL 00:28:43 < knurd> | k, anything else? 00:29:09 < nirik> | I have a few quick items... 00:29:31 < knurd> | shot 00:29:35 < nirik> | I have almost caught up on security checking for epel... 00:30:07 < knurd> | nirik, great work, thx 00:30:09 < nirik> | there are some packages that were never built, but have branches. Might be good if we could gather a list of those and ping maintainers to build or work on deps to build 00:30:45 < nirik> | finally, did we ever determine about pushing from testing->stable more often? Or should I bring that up on the list again? 00:31:06 < knurd> | we said about every four weeks for pushing from testing->stable 00:31:15 < knurd> | but I had expected 5.1 would show up soon 00:31:24 < knurd> | so I thought we just wait for that this time 00:31:34 < nirik> | yeah, agreed. 00:31:44 < knurd> | "October" was the last date I heard for 5.1 00:31:56 --> | agoode (Adam Goode) has joined #fedora-meeting 00:32:08 < nirik> | I heard there were issues due to the main kernel being xen now or something... but it was all 3rd hand. 00:32:09 < knurd> | package with branches missing in EPEL > list & ping sounds like a good idea to me 00:32:27 < nirik> | mmcgrath: did you have a chance to automate the broken deps report for epel? 00:32:56 < mmcgrath> | Not for testing, I'll double check whats going on with that now that you mention it. 00:32:57 < dgilmore> | knurd: have what? 00:33:02 < knurd> | maybe some of the people from RH could give some inofficial hints so we know what's up? quaid, mmcgrath, warren? 00:33:36 < knurd> | dgilmore, talking with koji developer about improving koji in the long run so we can use it for EPEL 00:33:52 < quaid> | knurd: not if we like keeping our jobs :) 00:33:56 < mmcgrath> | knurd: the last news I heard was a month ago or so and it was just that there was a 5.1 coming :) 00:34:05 < quaid> | isn't there an 'official' word updated somewhere? 00:34:12 < quaid> | 5.1 list or something? 00:34:20 * | mmcgrath isn't sure. 00:34:32 * | knurd is not on rhel5-list 00:34:40 < dgilmore> | knurd: they have no resources to do it 00:34:50 < dgilmore> | it is maked as a nice to have thing 00:34:51 < knurd> | quaid, I don't want to have a real date, just a rough estimate 00:34:53 < knurd> | ;-) 00:34:58 < dgilmore> | but far from being on the radar 00:35:09 < mmcgrath> | knurd: I'll say sometime after today and before January 2028 :) 00:35:09 < knurd> | dgilmore, is there a RFE about it somewhere? 00:35:17 < dgilmore> | knurd: not that i know of 00:35:18 * | knurd slaps mmcgrath :-) 00:35:18 < quaid> | knurd: "any time after today"? 00:35:26 < warren> | knurd, I heard from an article "October" 00:35:27 < dgilmore> | only disccusions on it 00:35:49 < knurd> | warren, I read that in an article as well 00:35:51 < mmcgrath> | warren: do you know who's call that is? 00:36:01 < knurd> | dgilmore, nirik, well having a RFE can#t hurt 00:36:07 < knurd> | dgilmore, nirik plans to file one 00:36:27 < dgilmore> | knurd: thats fine 00:36:37 < dgilmore> | hosted.fp.o would be the correct place 00:36:38 < knurd> | thx for your support dgilmore 00:36:59 < warren> | mmcgrath, even if I did know the planned release day, we aren't allowed to talk about it. 00:37:09 < dgilmore> | i wish i had time to do the work myself 00:37:12 < nirik> | https://hosted.fedoraproject.org/projects/koji/ticket/49 (feel free to update/add info if I said something wrong there) 00:37:25 < knurd> | so, shall we wait for 5.1? 00:37:34 < knurd> | or simply start to clean up deps now 00:37:49 < nirik> | in testing? starting now is good. 00:37:52 < knurd> | and then just do the testing-> stable move ahead of 5.1? 00:37:58 < knurd> | nirik, yeah, testing 00:38:06 <-- | rdieter has quit (Remote closed the connection) 00:38:16 < knurd> | mmcgrath, are the dep scripts running for testing these days? 00:38:16 < nirik> | well, I think we should start asap... then we can decide if we want to just move ahead of 5.1 or wait... 00:38:31 < mmcgrath> | knurd: I don't think they are, I'll do that now. 00:38:31 < nirik> | but we need to get them fixed first 00:38:36 < knurd> | nirik, yeah, you're likely right 00:38:41 < knurd> | mmcgrath, many thx 00:39:17 < knurd> | nirik, let's see what comes out the dep script and decide on hte list then how to eactly move on 00:39:22 < knurd> | does that sounds like a plan? 00:39:45 < nirik> | sure. sounds good. 00:39:54 < knurd> | k 00:39:56 < nirik> | there is still one issue in the stable repo... with multilib. 00:39:58 < knurd> | anything else? 00:40:02 < knurd> | nirik, ? 00:40:12 < nirik> | dgilmore: did you have a chance to look at that? does mschwents changes/suggestions look sane? 00:40:29 < nirik> | oh, next week: meeting at alternate time? or this time? 00:40:48 < dgilmore> | nirik: i have not yet looked 00:41:05 < knurd> | did he send more improvments? what kind of? 00:41:21 < knurd> | nirik, I'd say we give the alternate time one more chance next week 00:41:41 < nirik> | well, some changes to Config_EPEL.py... basically some of the multilib blacklist doesn't seem right... 00:41:42 <-- | londo has quit ("Konversation terminated!") 00:41:52 --> | rdieter (Rex Dieter) has joined #fedora-meeting 00:42:07 < knurd> | why do we F7-style multilib in RHEL4 in any case? 00:42:09 < nirik> | for example in epel4, graphviz has a broken dep in x86_64. 00:42:11 < knurd> | is that wise? 00:42:38 < knurd> | in FC3 (which EL4 is based on) we IMHO multilibed only selected packages 00:42:39 < nirik> | and it should be blacklisted. It is, but it should be listed as 'graphviz-devel' thats blacklisted, not graphviz 00:43:04 < f13> | multilib /hard/. 00:43:06 < nirik> | dunno the history. 00:43:15 < dgilmore> | knurd: in FC-3 we dod not offer multilib at all 00:43:17 < knurd> | nirik, maybe I did add graphviz and not graphviz-devel 00:43:20 < knurd> | not sure 00:43:29 < dgilmore> | s/dod/did/ 00:43:30 < knurd> | dgilmore, extras not, but core did iirc 00:43:31 < nirik> | the graphviz one is the only one I know that causes broken deps. 00:43:48 < dgilmore> | knurd: we are using extras multilibing logic 00:43:53 < f13> | dgilmore: FE-3 maybe? 00:44:00 < f13> | I'm pretty sure FC-3 did multilib 00:44:03 < f13> | oh I see that's sorted out 00:44:11 < knurd> | dgilmore, I think that can be switched off completely 00:44:25 < knurd> | as FE5 iirc also did not use multilib 00:44:30 < knurd> | or was it FE4? 00:44:40 < nirik> | I think we should s/graphviz-devel/graphviz/ in the config and leave it at that. 00:44:42 < knurd> | of FE5 did only the whitelist multilib 00:44:46 < knurd> | nirik, +1 00:44:52 < nirik> | since we have already been doing multilib, less changes better. 00:44:54 * | mmcgrath brb 00:44:55 < dgilmore> | knurd: except we have already offered it. 00:45:03 < dgilmore> | nirik: thats probably sane 00:45:06 < knurd> | dgilmore, good point 00:45:12 < nirik> | dgilmore: yeah, so pulling it would be bad. agreed. 00:45:22 < knurd> | yeah 00:45:34 < knurd> | so we just blacklist what needs to be blacklisted 00:45:36 < knurd> | k 00:45:38 < knurd> | anything else? 00:45:55 < nirik> | knurd: shall I make that change? or you want to? I can fwd you the email from mschwent if you like. 00:46:06 < knurd> | nirik, feel free to do it 00:46:11 < nirik> | ok 00:46:20 * | nirik has nothing else. 00:46:24 < knurd> | nirik, seems you are already more familar with the scripts than I am... 00:46:35 * | knurd will close the meeting in 45 00:47:06 * | knurd will close the meeting in 15 00:47:23 < knurd> | -- MARK -- Meeting end From jos at xos.nl Thu Sep 27 18:10:45 2007 From: jos at xos.nl (Jos Vos) Date: Thu, 27 Sep 2007 20:10:45 +0200 Subject: add to wishlist: rsyslog In-Reply-To: <46FBD9B1.8080004@fedoraproject.org> References: <46FBD7E5.5010209@andrei.myip.org> <46FBD9B1.8080004@fedoraproject.org> Message-ID: <20070927181045.GC22736@jasmine.xos.nl> On Thu, Sep 27, 2007 at 09:56:25PM +0530, Rahul Sundaram wrote: > >It looks like Fedora is moving towards rsyslog, it's already in the > >development tree, it would be nice to have it in EPEL. > > Done. I already use it (1.18.0-1) on a RHEL5 system, seems to work ok. The package has to be adapted on a few places to allow it to be installed along with sysklogd (I guess that should be the goal?). What I did: - Provides and Obsoletes lines have to be disabled. - Chang "2345" to "-" in the init script (not started by default) - Comment out all line in the logrotate file (conflicts with sysklogd). - Don't execute the migration stuff (mv's) in %post. Then it can be installed together with sysklogd and when someone wants to enable it, one has to do: - chkconfig syslog off - chkconfig rsyslog on - comment out lines in syslog logrotate file - uncomment lines in rsyslog logrotate file -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From florin at andrei.myip.org Thu Sep 27 22:55:59 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 27 Sep 2007 15:55:59 -0700 Subject: add to wishlist: rsyslog In-Reply-To: <20070927181045.GC22736@jasmine.xos.nl> References: <46FBD7E5.5010209@andrei.myip.org> <46FBD9B1.8080004@fedoraproject.org> <20070927181045.GC22736@jasmine.xos.nl> Message-ID: <46FC34FF.5000104@andrei.myip.org> Jos Vos wrote: > On Thu, Sep 27, 2007 at 09:56:25PM +0530, Rahul Sundaram wrote: > >>> It looks like Fedora is moving towards rsyslog, it's already in the >>> development tree, it would be nice to have it in EPEL. >> Done. > > I already use it (1.18.0-1) on a RHEL5 system, seems to work ok. We're testing the 1.19.2-1.el4.rf from http://dries.ulyssis.org/rpm/ on RHEL4 32 bit. So far so good. > The package has to be adapted on a few places to allow it to be installed > along with sysklogd (I guess that should be the goal?). What I did: Today I grabbed the latest rsyslog-1.19.6-2.fc8.src.rpm from Fedora Development and rebuilt it on RHEL4 32bit. Seems to work fine after very summary testing. Perhaps that should be the reference used for EPEL? Anyway, mainstream just released 1.19.8 today. I did notice it does not chkconfig off the syslog service after it's installed. -- Florin Andrei http://florin.myip.org/ From sundaram at fedoraproject.org Thu Sep 27 22:58:32 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 28 Sep 2007 04:28:32 +0530 Subject: add to wishlist: rsyslog In-Reply-To: <20070927181045.GC22736@jasmine.xos.nl> References: <46FBD7E5.5010209@andrei.myip.org> <46FBD9B1.8080004@fedoraproject.org> <20070927181045.GC22736@jasmine.xos.nl> Message-ID: <46FC3598.50801@fedoraproject.org> Jos Vos wrote: > On Thu, Sep 27, 2007 at 09:56:25PM +0530, Rahul Sundaram wrote: > >>> It looks like Fedora is moving towards rsyslog, it's already in the >>> development tree, it would be nice to have it in EPEL. >> Done. > > I already use it (1.18.0-1) on a RHEL5 system, seems to work ok. > > The package has to be adapted on a few places to allow it to be installed > along with sysklogd (I guess that should be the goal?) Would you be interested in being a EPEL contributor? Rahul From jos at xos.nl Thu Sep 27 23:07:55 2007 From: jos at xos.nl (Jos Vos) Date: Fri, 28 Sep 2007 01:07:55 +0200 Subject: add to wishlist: rsyslog In-Reply-To: <46FC34FF.5000104@andrei.myip.org> References: <46FBD7E5.5010209@andrei.myip.org> <46FBD9B1.8080004@fedoraproject.org> <20070927181045.GC22736@jasmine.xos.nl> <46FC34FF.5000104@andrei.myip.org> Message-ID: <20070927230755.GA25391@jasmine.xos.nl> On Thu, Sep 27, 2007 at 03:55:59PM -0700, Florin Andrei wrote: > Today I grabbed the latest rsyslog-1.19.6-2.fc8.src.rpm from Fedora > Development and rebuilt it on RHEL4 32bit. Seems to work fine after very > summary testing. > Perhaps that should be the reference used for EPEL? Anyway, mainstream > just released 1.19.8 today. Does EPEL have rules about what packages EPEL packages can be based on? I mean: should EPEL packages be based only on non-test Fedora src.rpm's? This would mean that EPEL package for rsyslog can be released after F8 is released. > I did notice it does not chkconfig off the syslog service after it's > installed. Question is what to do when adding a package (rsyslog) that in fact obsoletes a regular RHEL5 package (sysklogd). Personally, I would opt for what I did: make sure installing the (rsyslog) package does not affect anything related to regular RHEL5 packages (sysklogd) and let the sysadmin do the config work afterwards (in this case doing two chkconfig commands and editting two logrotate files). P.S. Sorry if I raise issues that are already decided in EPEL guidelines. Feel free to point me at the relevant docs :-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jos at xos.nl Thu Sep 27 23:14:24 2007 From: jos at xos.nl (Jos Vos) Date: Fri, 28 Sep 2007 01:14:24 +0200 Subject: add to wishlist: rsyslog In-Reply-To: <46FC3598.50801@fedoraproject.org> References: <46FBD7E5.5010209@andrei.myip.org> <46FBD9B1.8080004@fedoraproject.org> <20070927181045.GC22736@jasmine.xos.nl> <46FC3598.50801@fedoraproject.org> Message-ID: <20070927231424.GB25391@jasmine.xos.nl> On Fri, Sep 28, 2007 at 04:28:32AM +0530, Rahul Sundaram wrote: > Would you be interested in being a EPEL contributor? Maybe... :-) -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From fedora at leemhuis.info Fri Sep 28 04:37:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 28 Sep 2007 06:37:49 +0200 Subject: add to wishlist: rsyslog In-Reply-To: <20070927230755.GA25391@jasmine.xos.nl> References: <46FBD7E5.5010209@andrei.myip.org> <46FBD9B1.8080004@fedoraproject.org> <20070927181045.GC22736@jasmine.xos.nl> <46FC34FF.5000104@andrei.myip.org> <20070927230755.GA25391@jasmine.xos.nl> Message-ID: <46FC851D.7080802@leemhuis.info> On 28.09.2007 01:07, Jos Vos wrote: > On Thu, Sep 27, 2007 at 03:55:59PM -0700, Florin Andrei wrote: > >> Today I grabbed the latest rsyslog-1.19.6-2.fc8.src.rpm from Fedora >> Development and rebuilt it on RHEL4 32bit. Seems to work fine after very >> summary testing. >> Perhaps that should be the reference used for EPEL? Anyway, mainstream >> just released 1.19.8 today. > > Does EPEL have rules about what packages EPEL packages can be based on? > I mean: should EPEL packages be based only on non-test Fedora src.rpm's? > [...] Fedora IMHO for EPEL is kind of "testing ground" (just like it is for RHEL). Having similar Specs used in EPEL and Fedora also makes exchanging bugfixes a whole lot easier. Thus it IMHO would be best for all if the EPEL spec file is based on the Fedora one. But that's not a hard requirement. >> I did notice it does not chkconfig off the syslog service after it's >> installed. > Question is what to do when adding a package (rsyslog) that in fact > obsoletes a regular RHEL5 package (sysklogd). One of the (in parts unwritten IIRC) rules is: don't disturb the distribution we build for (e.g. RHEL in this case). So obsoleting is a no go. > Personally, I would opt > for what I did: make sure installing the (rsyslog) package does not > affect anything related to regular RHEL5 packages (sysklogd) and let > the sysadmin do the config work afterwards (in this case doing two > chkconfig commands and editting two logrotate files). That should be fine. CU knurd From buildsys at fedoraproject.org Fri Sep 28 12:00:51 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 28 Sep 2007 08:00:51 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-09-28 Message-ID: <20070928120051.69C7D15212D@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL testing/5: 5 lyx-1.4.5.1-3.el5 NEW mathml-fonts-1.0-21.el5 : Mathematical symbol fonts NEW wavpack-4.41-1.el5 : A completely open audiocodec xine-lib-1.1.8-6.el5 yumex-2.0.2-1.el5 Packages built and released for Fedora EPEL testing/4: 1 NEW wavpack-4.41-1.el4 : A completely open audiocodec Changes in Fedora EPEL testing/5: lyx-1.4.5.1-3.el5 ----------------- * Thu Sep 27 2007 Rex Dieter 1.4.5.1-3 - epel: drop Requires(hint): wv (until wv is available) * Mon Sep 10 2007 Rex Dieter 1.4.5.1-2 - License: GPLv2+ - epel: drop aiksaurus support (until aiksaurus is available) mathml-fonts-1.0-21.el5 ----------------------- * Fri Jun 09 2006 Rex Dieter 1.0-21 - update to BaKoMa4Lyx-1.1 (includes eufm10.ttf) - update %description wavpack-4.41-1.el5 ------------------ * Sat May 12 2007 Peter Lemenkov 4.41-1 - Version 4.41 - Removed unnecessary --with-pic xine-lib-1.1.8-6.el5 -------------------- * Thu Sep 27 2007 Ville Skytt? - 1.1.8-6 - Enable wavpack support by default for all distros. yumex-2.0.2-1.el5 ----------------- * Fri Sep 28 2007 Tim Lauridsen - 2.0.2-1 - Release 2.0.2 Changes in Fedora EPEL testing/4: wavpack-4.41-1.el4 ------------------ * Sat May 12 2007 Peter Lemenkov 4.41-1 - Version 4.41 - Removed unnecessary --with-pic 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 Sun Sep 30 02:45:37 2007 From: dag at wieers.com (Dag Wieers) Date: Sun, 30 Sep 2007 04:45:37 +0200 (CEST) Subject: FYI: Revelation and other pygtk2 apps in EL-5 In-Reply-To: References: <80d7e4090709241354i18c5d40ala5f442c194ed6f1f@mail.gmail.com> Message-ID: On Tue, 25 Sep 2007, Dag Wieers wrote: > On Mon, 24 Sep 2007, Stephen John Smoogen wrote: > > > Just an FYI for other people looking at this. Revelation and > > supposedly other apps that use pygtk2 will generate tracebacks in 5.0 > > due to a bug in the shipped version of pygtk2 (2.10.1). The fix showed > > somewhere between it and 2.10.4 which is what I needed to get the > > application working. I am going to try and figure out what patch does > > it so that hopefully it is a 5.2 fix (or a > > CentOS-We-Fix-Other-Broken-Code-For-Free repo until then). > > This is a very big PITA for me too (and has been since RHEL 5 release). > > This bug however caused people to think about using Revelation for storing > passwords (some sort of lock-in), ways to migrate away from Revelation, > new Revelation development and the long-expected command line access to > Revelation files. I have made temporary test packages available for those people that need them. You can find these from: http://dag.wieers.com/rpm/packages/pygtk2/ If we have to wait another 4 months, I need a solution... and maybe so do you ? -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors]