From buildsys at fedoraproject.org Fri Jun 1 05:45:23 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 1 Jun 2007 01:45:23 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-01 Message-ID: <20070601054523.C5B5D152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 3 dwatch-0.1.1-3.el5 NEW perl-Net-IPv6Addr-0.2-3.el5 : Perl module to check validity of IPv6 addresses NEW remind-03.00.24-3.el5 : A sophisticated calendar and alarm program Packages built and released for Fedora EPEL 4: 3 dwatch-0.1.1-3.el4 NEW perl-Net-IPv6Addr-0.2-3.el4 : Perl module to check validity of IPv6 addresses NEW remind-03.00.24-3.el4 : A sophisticated calendar and alarm program Changes in Fedora EPEL 5: dwatch-0.1.1-3.el5 ------------------ * Thu May 31 2007 Bernard Johnson - 0.1.1-3 - take junk out of default config file and just reference man page - change man page from dwatch(5) to dwatch.conf(5) - give a more complex example in dwatch.conf(5) man page perl-Net-IPv6Addr-0.2-3.el5 --------------------------- * Mon May 28 2007 Sindre Pedersen Bj?rdal - 0.2-3 - Fix license - Add explicit Requires on perl(Math::Base85) - Add missing BRs * Sat May 12 2007 Sindre Pedersen Bj?rdal - 0.2-2 - Add missing perl-Math-Base85 BR * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.2-1 - Initial build remind-03.00.24-3.el5 --------------------- * Wed May 23 2007 Ray Van Dolson - 03.00.24-3 - Fixed permissions on www/* to be 0644. * Mon May 07 2007 Ray Van Dolson - 03.00.24-2 - Added www to documentation. A sample web application I do not feel is suitable for inclusion into the actual RPM. * Thu May 03 2007 Ray Van Dolson - 03.00.24-2 - Using integer only release numbers. - Preserve timestamps on manpages. - Added %check - Removed README from documentation and added ACKNOWLEDGEMENTS Changes in Fedora EPEL 4: dwatch-0.1.1-3.el4 ------------------ * Thu May 31 2007 Bernard Johnson - 0.1.1-3 - take junk out of default config file and just reference man page - change man page from dwatch(5) to dwatch.conf(5) - give a more complex example in dwatch.conf(5) man page perl-Net-IPv6Addr-0.2-3.el4 --------------------------- * Mon May 28 2007 Sindre Pedersen Bj?rdal - 0.2-3 - Fix license - Add explicit Requires on perl(Math::Base85) - Add missing BRs * Sat May 12 2007 Sindre Pedersen Bj?rdal - 0.2-2 - Add missing perl-Math-Base85 BR * Sat May 05 2007 Sindre Pedersen Bj?rdal - 0.2-1 - Initial build remind-03.00.24-3.el4 --------------------- * Wed May 23 2007 Ray Van Dolson - 03.00.24-3 - Fixed permissions on www/* to be 0644. * Mon May 07 2007 Ray Van Dolson - 03.00.24-2 - Added www to documentation. A sample web application I do not feel is suitable for inclusion into the actual RPM. * Thu May 03 2007 Ray Van Dolson - 03.00.24-2 - Using integer only release numbers. - Preserve timestamps on manpages. - Added %check - Removed README from documentation and added ACKNOWLEDGEMENTS For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Sun Jun 3 13:17:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 03 Jun 2007 15:17:49 +0200 Subject: EPEL report week 21, 2007 Message-ID: <4662BF7D.60308@leemhuis.info> = Weekly EPEL Summary = Week 22/2007 == Most important happenings == * MikeMcGrath, MaxSpevack and ThorstenLeemhuis meet Dag Wieers, AxelThimm, Lance Davis, Ralph Angenendt and some other CentOS guys on LinuxTag; we talked a bit (round about 100 Minutes iirc) about cooperation and communication; I'd say it was a good chat and I suppose we understand each others positions better. Repotags were discussed as well; but I'll bring that topic up over the next few days for EPEL separately. == EPEL SIG Meeting == No meeting this week due to MikeMcGrath and ThorstenLeemhuis on LinuxTag in another meeting and thus afk. === General === Number of EPEL Contributors 81 We welcome 1 new contributors: rayvd_AT_bludgeon.org === EPEL 5 === Number of source packages: 299 Number of binary packages: 480 There are 7 new Packages: * dwatch | A program that watches over other programs * ettercap | Network traffic sniffer/analyser, NCURSES interface version * gmrun | Lightweight "Run program" dialog box with search history and tab completion * perl-Net-IPv6Addr | Perl module to check validity of IPv6 addresses * perl-Net-Server | Extensible, general Perl server engine * remind | A sophisticated calendar and alarm program * vym | View your mind === EPEL 4 === Number of source packages: 201 Number of binary packages: 378 There are 7 new Packages: * dwatch | A program that watches over other programs * ettercap | Network traffic sniffer/analyser, NCURSES interface version * fontforge | Outline and bitmap font editor * perl-Net-IPv6Addr | Perl module to check validity of IPv6 addresses * perl-Net-Server | Extensible, general Perl server engine * remind | A sophisticated calendar and alarm program * wine | A Windows 16/32/64 bit emulator ---- ["CategoryEPELReports"] From buildsys at fedoraproject.org Tue Jun 5 13:09:07 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 5 Jun 2007 09:09:07 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-05 Message-ID: <20070605130907.2E7C1152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 17 NEW bottlerocket-0.04c-1.el5 : Utilities to use the FireCracker X10 kit bugzilla-3.0-2.el5 NEW bwidget-1.8.0-1.el5 : Extended widget set for Tk NEW calcurse-1.8-2.el5 : Text-based personal organizer NEW clearsilver-0.10.4-4.el5 : Fast and powerful HTML templating system NEW mod_fcgid-2.1-1.el5 : Apache2 module for high-performance server-side scripting NEW onesixtyone-0.3.2-3.el5 : An efficient SNMP scanner NEW perl-MailTools-1.77-1.el5 : Various mail-related perl modules perl-SOAP-Lite-0.68-5.el5 php-pear-HTTP-Request-1.4.1-1.el5 phpPgAdmin-4.1.2-1.el5 NEW postgresql-pgpool-II-1.1-1.el5 : Pgpool is a connection pooling/replication server for PostgreSQL NEW trac-0.10.3.1-2.el5 : Enhanced wiki and issue tracking system NEW trac-webadmin-0.1.2-0.3.dev_r4429.el5 : Web interface for administration of Trac wine-0.9.38-2.el5 NEW wine-docs-0.9.38-1.el5 : Documentation for wine yumex-1.9.8-2.0.el5 Packages built and released for Fedora EPEL 4: 11 NEW bottlerocket-0.04c-1.el4 : Utilities to use the FireCracker X10 kit NEW bwidget-1.8.0-1.el4 : Extended widget set for Tk NEW calcurse-1.8-2.el4 : Text-based personal organizer NEW clearsilver-0.10.3-3.el4.1 : Fast and powerful HTML templating system NEW onesixtyone-0.3.2-3.el4 : An efficient SNMP scanner NEW perl-MailTools-1.77-1.el4 : Various mail-related perl modules phpPgAdmin-4.1.2-1.el4 NEW postgresql-pgpool-II-1.1-1.el4 : Pgpool is a connection pooling/replication server for PostgreSQL NEW trac-0.9.3-2.el4 : Enhanced wiki and issue tracking system NEW trac-webadmin-0.1.2-0.3.dev_r4429.el4 : Web interface for administration of Trac wine-0.9.38-1.el4 Changes in Fedora EPEL 5: bottlerocket-0.04c-1.el5 ------------------------ * Sat May 26 2007 Sindre Pedersen Bj?rdal - 0.04c-1 - Initial build bugzilla-3.0-2.el5 ------------------ * Fri May 18 2007 John Berninger - 3.0-2 - update Requires for bz's 241037, 241206 bwidget-1.8.0-1.el5 ------------------- * Thu Oct 19 2006 Wart 1.8.0-1 - Update to 1.8.0 - Remove patch that was accepted upstream calcurse-1.8-2.el5 ------------------ * Wed May 30 2007 Nigel Jones 1.8-2 - Minor touchups to spec file * Wed May 23 2007 Nigel Jones 1.8-1 - Initial SPEC file clearsilver-0.10.4-4.el5 ------------------------ * Fri Jun 01 2007 Jeffrey C. Ollie - 0.10.4-4 - Minor cleanups * Fri Jun 01 2007 Jesse Keating - 0.10.4-3.1 - Disable java subpackages on el4 mod_fcgid-2.1-1.el5 ------------------- * Fri Feb 16 2007 Paul Howarth 2.1-1 - Update to 2.1 - Update documentation and patches - Rename some source files to reduce chances of conflicting names - Include SharememPath directive in conf file to avoid unfortunate upstream default location onesixtyone-0.3.2-3.el5 ----------------------- * Wed May 23 2007 Sindre Pedersen Bj?rdal - 0.3.2-3 - Add patch to really call proper flags, promise * Tue May 22 2007 Sindre Pedersen Bj?rdal - 0.3.2-2 - Change make to really call proper flags perl-MailTools-1.77-1.el5 ------------------------- * Fri May 11 2007 Paul Howarth 1.77-1 - Update to 1.77 perl-SOAP-Lite-0.68-5.el5 ------------------------- * Fri Jun 01 2007 Mike McGrath - 0.86-5 - Release bump php-pear-HTTP-Request-1.4.1-1.el5 --------------------------------- * Sat Jun 02 2007 Christopher Stone 1.4.1-1 - Upstream sync (bz #242212) - Use sed instead of dos2unix phpPgAdmin-4.1.2-1.el5 ---------------------- * Fri Jun 01 2007 Devrim Gunduz 4.1.2-1 - Update to 4.1.2 - Fix for Red Hat Bugzilla #241489 postgresql-pgpool-II-1.1-1.el5 ------------------------------ * Sat Jun 02 2007 Devrim Gunduz 1.1-1 - Update to 1.1 - added --disable-rpath configure parameter. - Chowned sample conf files, so that they can work with pgpoolAdmin. trac-0.10.3.1-2.el5 ------------------- * Mon Mar 12 2007 Jeffrey C. Ollie - 0.10.3.1-2 - Switch requires back to python-sqlite trac-webadmin-0.1.2-0.3.dev_r4429.el5 ------------------------------------- * Sat Jun 02 2007 Jesse Keating - 0.1.2-0.3.dev_r4429 - and python-setuptools * Sat Jun 02 2007 Jesse Keating - 0.1.2-0.2.dev_r4429 - We require trac to run. * Fri Jun 01 2007 Jesse Keating - 0.1.2-0.1.dev_r4429 - Initial build wine-0.9.38-2.el5 ----------------- * Sun Jun 03 2007 Andreas Bierfert 0.9.38-2 - allow full opt flags again - set ExclusiveArch to i386 for koji to only build i386 * Sat Jun 02 2007 Andreas Bierfert 0.9.38-1 - version upgrade (#242087) - fix menu problem (#220723) - fix BR - clean up desktop file section * Wed May 23 2007 Andreas Bierfert 0.9.37-1 - version upgrade - add BR for xcursor (#240648) - add desktop entry for wineboot (#240683) - add mime handler for msi files (#240682) - minor cleanups wine-docs-0.9.38-1.el5 ---------------------- * Sun Jun 03 2007 Andreas Bierfert 0.9.38-1 - version upgrade yumex-1.9.8-2.0.el5 ------------------- * Mon Jun 04 2007 Tim Lauridsen - 1.9.8-2.0 - Development Release 1.9.8-2.0 - Forgot to update changelog * Mon Jun 04 2007 Tim Lauridsen - 1.9.8-1.0 - Development Release 1.9.8-1.0 Changes in Fedora EPEL 4: bottlerocket-0.04c-1.el4 ------------------------ * Sat May 26 2007 Sindre Pedersen Bj?rdal - 0.04c-1 - Initial build bwidget-1.8.0-1.el4 ------------------- * Thu Oct 19 2006 Wart 1.8.0-1 - Update to 1.8.0 - Remove patch that was accepted upstream calcurse-1.8-2.el4 ------------------ * Wed May 30 2007 Nigel Jones 1.8-2 - Minor touchups to spec file * Wed May 23 2007 Nigel Jones 1.8-1 - Initial SPEC file clearsilver-0.10.3-3.el4.1 -------------------------- * Thu Jun 01 2006 Jesse Keating - 0.10.3-3.1 - Disable java subpackages on el4 onesixtyone-0.3.2-3.el4 ----------------------- * Wed May 23 2007 Sindre Pedersen Bj?rdal - 0.3.2-3 - Add patch to really call proper flags, promise * Tue May 22 2007 Sindre Pedersen Bj?rdal - 0.3.2-2 - Change make to really call proper flags perl-MailTools-1.77-1.el4 ------------------------- * Fri May 11 2007 Paul Howarth 1.77-1 - Update to 1.77 phpPgAdmin-4.1.2-1.el4 ---------------------- * Fri Jun 01 2007 Devrim Gunduz 4.1.2-1 - Update to 4.1.2 - Fix for Red Hat Bugzilla #241489 postgresql-pgpool-II-1.1-1.el4 ------------------------------ * Sat Jun 02 2007 Devrim Gunduz 1.1-1 - Update to 1.1 - added --disable-rpath configure parameter. - Chowned sample conf files, so that they can work with pgpoolAdmin. trac-0.9.3-2.el4 ---------------- * Tue Jan 10 2006 Joost Soeterbroek - 0.9.3-2 - removed trac.fcgi (bugzilla #174546, comment #11) - applied patch (bugzilla #174546, attachment id=123008) trac-webadmin-0.1.2-0.3.dev_r4429.el4 ------------------------------------- * Sat Jun 02 2007 Jesse Keating - 0.1.2-0.3.dev_r4429 - and python-setuptools * Sat Jun 02 2007 Jesse Keating - 0.1.2-0.2.dev_r4429 - We require trac to run. * Fri Jun 01 2007 Jesse Keating - 0.1.2-0.1.dev_r4429 - Initial build wine-0.9.38-1.el4 ----------------- * Sat Jun 02 2007 Andreas Bierfert 0.9.38-1 - version upgrade (#242087) - fix menu problem (#220723) - fix BR - clean up desktop file section * Wed May 23 2007 Andreas Bierfert 0.9.37-1 - version upgrade - add BR for xcursor (#240648) - add desktop entry for wineboot (#240683) - add mime handler for msi files (#240682) - minor cleanups 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 Tue Jun 5 18:34:39 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 05 Jun 2007 20:34:39 +0200 Subject: Plan for tomorrows EPEL SIG meeting Message-ID: <4665ACBF.9030000@leemhuis.info> Hi all, find below the list of topics that are likely to come up in the next EPEL SIG meeting that's scheduled for tomorrow, Wednesday at 17:00 UTC in #fedora-extras on irc.freenode.org. /topic EPEL Meeting -- repotags -- all /topic EPEL Meeting -- EPEL mock configs in Fedora's mock package -- dglimore /topic EPEL Meeting -- comps.xml for EPEL -- ? /topic EPEL Meeting -- bodhi/testing repo/final repo layout -- nirik/lmacken /topic EPEL Meeting -- vacant seat in the steering committee ## every two weeks /topic EPEL Meeting -- finish the wiki docs and remove the warnings -- quaid You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, but we'll most likely will if we don't run out of time). You can also propose topics at the end of the meeting itself. If your name/nick is on above list please give a update. That way all the interested parties know what up ahead of the meeting; that will avoid long delays and "status update monologues in the meeting. Thanks! CU thl From fedora at leemhuis.info Tue Jun 5 18:36:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 05 Jun 2007 20:36:41 +0200 Subject: Plan for tomorrows EPEL SIG meeting In-Reply-To: <4665ACBF.9030000@leemhuis.info> References: <4665ACBF.9030000@leemhuis.info> Message-ID: <4665AD39.2090405@leemhuis.info> On 05.06.2007 20:34, Thorsten Leemhuis wrote: > [...] > /topic EPEL Meeting -- repotags -- all Just FYI; the EPEL Steering Committee still has this on it's plate and is working something out currently in private discussions, as that's easier ;-) It of course will get discussed on the list sooner or later before being ratified. CU knurd From mastahnke at gmail.com Tue Jun 5 19:17:05 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 5 Jun 2007 14:17:05 -0500 Subject: Plan for tomorrows EPEL SIG meeting In-Reply-To: <4665AD39.2090405@leemhuis.info> References: <4665ACBF.9030000@leemhuis.info> <4665AD39.2090405@leemhuis.info> Message-ID: <7874d9dd0706051217i197fd3b0r654f7870a5bcff64@mail.gmail.com> I plan on wirting a wiki template for requesting a contributer to get their packages into EPEL or allowing someone else to be a co-maintainer if they choose not to be part of EPEL. Hopefully tonight. (I know I have said I would do that for a while). stahnma From mastahnke at gmail.com Wed Jun 6 00:35:41 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Tue, 5 Jun 2007 19:35:41 -0500 Subject: Plan for tomorrows EPEL SIG meeting In-Reply-To: <7874d9dd0706051217i197fd3b0r654f7870a5bcff64@mail.gmail.com> References: <4665ACBF.9030000@leemhuis.info> <4665AD39.2090405@leemhuis.info> <7874d9dd0706051217i197fd3b0r654f7870a5bcff64@mail.gmail.com> Message-ID: <7874d9dd0706051735y6f1419ael6b046949a2c0a92e@mail.gmail.com> I worte up a quick draft. It has a few holes in it still. Feel free to add/remove/change whatever. I would like to start getting the "will package X be in EPEL" questions taken care of soon. http://fedoraproject.org/wiki/MichaelStahnke/Draft-EPELPackageRequest stahnma From fedora at leemhuis.info Sun Jun 10 17:22:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 10 Jun 2007 19:22:40 +0200 Subject: Log from this weeks (week 23; meeting 20070606) EPEL SIG meeting Message-ID: <466C3360.9090907@leemhuis.info> 00:00 * | mmcgrath lurks 00:01 * | knurd at the keyboard now 00:01 * | stahnma is in the house 00:01 < stahnma> | and sounds less cool... for saying that 00:01 < knurd> | Meeting ping dgilmore, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:01 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:01 < knurd> | Hi everybody; who's around? 00:01 * | mmcgrath here 00:02 --> | jbowes (James Bowes) has joined #fedora-meeting 00:02 < knurd> | quaid mentioned he has a app't at the dentist 00:02 < stahnma> | I might have to cut out early 00:02 < stahnma> | again, i will wish for a new time 00:02 < knurd> | stahnma, might be a good idea to bring that up again 00:03 < knurd> | stahnma, but the problems remain the same 00:03 < stahnma> | ok, I will start on linst 00:03 < stahnma> | list 00:03 < knurd> | or shall we switch back to the weekends? 00:03 < stahnma> | yeah, really wednesdays are even worse for me than any other weekday 00:03 < knurd> | stahnma, we maybe should wait with it until we are seven again 00:03 * | Jeff_S here now.. 00:03 * | nirik is back... was getting coffee. 00:04 < stahnma> | knurd: that's fine 00:04 < knurd> | k, let's start slowly 00:04 --- | knurd has changed the topic to: EPEL Meeting -- repotags -- all 00:04 < knurd> | as I said on the list 00:04 < stahnma> | I propse we do whatever it takes to get past this issue and start working on something new 00:04 < knurd> | we are discussing in private now how to move on 00:05 < knurd> | stahnma, well, some people would like to get past this issue by continuing without repotags, while others want them 00:05 < nirik> | stahnma: +1 00:05 < knurd> | I could for the "want repotags" group these days 00:05 < knurd> | as that seems to be what the contributors want 00:06 < knurd> | even if it from a techincal statpoin is something where people have different opinions if they solve or create problems 00:06 * | nirik really has stopped caring. If we can find a easy way to add them now we can always drop them later. 00:06 --> | glezos (Dimitris Glezos) has joined #fedora-meeting 00:06 < knurd> | nirik, +1 00:06 < stahnma> | nirik: +1 00:06 < nirik> | they cause us problems because the issue never goes away. I hope that adding them will at least do that... 00:06 < knurd> | we just need to put in in words over the next few days somehow 00:06 < Jeff_S> | Yes, it may be nice to enable them for now and see what other "better" things we could do in the future... 00:06 < knurd> | Jeff_S, +1 00:06 < f13> | christ, how many times are you going to bring this up and how many times are we all going to say that we don't want them, please go away? 00:07 < nirik> | always and forever... 00:07 < f13> | are you just hoping to play meeting bingo and find the one time that enough people are absent so it'll pass? 00:07 < knurd> | f13, no, we are discussing it in private currently 00:07 < nirik> | so in that case can we move on in this meeting instead of talking about it again? 00:08 < knurd> | nirik, +1 00:08 < stahnma> | +1 00:08 < knurd> | I was just about to do that 00:08 --- | knurd has changed the topic to: EPEL Meeting -- EPEL mock configs in Fedora's mock package -- dglimore 00:08 < knurd> | has anybody proper and tested config files already? 00:08 < knurd> | I wrote some weeks ago and posted them to the list 00:08 < nirik> | I have some here I have been using... I could try cleaning them up and posting them... 00:08 < knurd> | nirik, that would be great! 00:08 < nirik> | f13: any news on a mock update? 00:08 < knurd> | nirik, thx 00:09 < f13> | soon woudl be good, need to do a mock update for Fedora 7. Clark is back from vacation so any moment now. 00:09 < knurd> | nirik, the ones I send should be in the archives 00:09 < Jeff_S> | knurd: I've been using my own local ones, but I'll make a note to test yours out and post to the list 00:09 < knurd> | Jeff_S, mine should work for x86_64 and i386 00:09 < nirik> | f13: it would be good to get valid epel4/5 in there... I can assist. 00:09 < knurd> | there is no ppc yet 00:09 < knurd> | and we need to fix the epel4 configs as well 00:09 < Jeff_S> | knurd: OK I can test both i386 and x86_64, so I will do that... 00:09 * | dgilmore is here 00:09 < f13> | nirik: just submit them in a bug against mock in Fedora Hosted Projects product in Bugzilla. 00:09 < knurd> | nirik and Jeff_S, could you work that out over the next few days? 00:10 < nirik> | f13: will do 00:10 < knurd> | hi dgilmore, 00:10 < Jeff_S> | knurd: yep 00:10 < knurd> | dgilmore, or did you look into the mock configs already? nirik and Jeff_S volunteered to take care of it 00:10 < dgilmore> | knurd: i have not had time 00:11 < dgilmore> | its on my list to get done this week 00:11 < knurd> | dgilmore, np; then let leave it for those two 00:11 --- | knurd has changed the topic to: EPEL Meeting -- comps.xml for EPEL -- ? 00:11 < dgilmore> | i want to talk with the CentOS guys as they had some issue with us pointing at them 00:11 < dgilmore> | we need to setup a comps.xml file for us 00:11 < stahnma> | I will volunteer to help with comps.xml,but I am noob at it 00:11 < dgilmore> | knurd: ill get one started 00:11 < nirik> | oh? bummer... it would be good to get it into mock sooner rather than later tho. 00:12 * | rdieter goes to lurk in the rablle seats... 00:12 < dgilmore> | nirik: yeah it was breifly mentioned to me 00:12 < knurd> | dgilmore, thx; I suppose it might be the easiest to just use the fe-6 one as a base? 00:12 < f13> | well. 00:12 < dgilmore> | knurd: that was my plan 00:12 < f13> | you may want to look at the comps used for CentOS 00:12 < f13> | for the base groupings 00:13 < f13> | then yeah, other comps files for the package content 00:13 * | knurd is no comps expert 00:13 < dgilmore> | f13: ill look at what they did 00:13 < knurd> | dgilmore, thx 00:13 * | knurd moves on 00:14 --- | knurd has changed the topic to: EPEL Meeting -- bodhi/testing repo/final repo layout -- nirik/lmacken 00:14 < knurd> | does anyone know if anything happends in this area? 00:14 < knurd> | this area or koji for EPEL? 00:14 < nirik> | well, it would be good to move epel to koji, then it can use bodhi. 00:14 < dgilmore> | knurd: for it to happen when need to move to koji 00:15 < dgilmore> | for that to happen i have some technical koji issues to resolve 00:15 < knurd> | someone wanted to look into it 00:15 < nirik> | yeah, like the rhel binary issue. 00:15 < knurd> | mbrown? 00:15 < knurd> | or what was the nick? 00:15 < dgilmore> | nirik: :) yeah 00:15 < dgilmore> | knurd: we cant dod it 00:15 < dgilmore> | do 00:15 < knurd> | dgilmore, yeah, I hear aboutthat in the last meeting 00:16 < nirik> | so, alternately perhaps we can get bodhi to talk to plague-server... 00:16 < dgilmore> | knurd: we have to be able to make koji hide the RHEL binaries so that they are not made publicly avaliable 00:16 < nirik> | lmacken: what is the possiblility of that if you are around? 00:16 < lmacken> | nirik: hi 00:16 * | lmacken reads backlog 00:16 < knurd> | dgilmore, as I said, someone wanted to make this work 00:16 < dgilmore> | nirik: some major recoding 00:16 < stahnma> | I thouht lmacken said talking to Plague was possible 00:16 < knurd> | dgilmore, it was discussed in the last meeting two weeks ago iirc 00:16 < dgilmore> | i missed that 00:16 < lmacken> | ah, I think so.. mmcgrath said he had something up his sleeve for talking with plague 00:16 < lmacken> | iirc 00:16 < knurd> | dgilmore, np, happens, that why I tell you :) 00:17 < knurd> | well, can somebody take this task on his plate and coordinate the different efforts and tasks? 00:17 < nirik> | yeah, so if it's easy/doable/possible to have bodhi talk to plague, that would be the better short term way to go. Otherwise we have to wait for koji. ;( 00:17 < dgilmore> | knurd: im going to be looking at koji for setting up secondary archs so i wont have time to do it 00:18 --> | llaumgui (LLaumgui) has joined #fedora-meeting 00:18 < lmacken> | well... 00:18 < lmacken> | after last week, bodhi is heavily tied into koji/mash 00:18 < dgilmore> | lmacken: thats what i thought 00:18 < lmacken> | i removed most of the old push-style code 00:18 * | nirik suspected, but thought asking couldn't hurt. 00:18 < dgilmore> | it would take some major rewriting to make it work with plague now 00:19 < lmacken> | mashing the repos and then trying to squeeze stuff into it (other than updateinfo), would be a serious pain. 00:19 < lmacken> | dgilmore: yeah 00:19 < knurd> | not worth the effort I'd say 00:19 < nirik> | ok, so we need to try and move koji forward. Who would be the one to deal with that? mbonnet ? 00:19 < lmacken> | koji is the way to go 00:19 < knurd> | so let's target koji for EPEL first 00:19 < knurd> | and then bodhi 00:19 < dgilmore> | nirik: i imagine its a low priority thing for mbonnet 00:19 < dgilmore> | though i have discussed it with him 00:20 < nirik> | yeah. 00:20 < knurd> | can somebody ask mbonnet for a status update 00:20 < knurd> | then we can evaluate how to move on 00:20 < dgilmore> | what we need is to be able to mark builds as private so they dont show up anywhere 00:20 --> | fab (Fabrice Bellet) has joined #fedora-meeting 00:20 < dgilmore> | its a fairly major undertaking 00:20 * | mmcgrath wonders if we'll get backlash for that. 00:21 < mmcgrath> | its not very open of us. 00:21 < nirik> | so should we consider building with centos then? 00:21 < stahnma> | I certainly don't like it 00:21 < knurd> | nirik, then we can't build for ppc 00:21 < dgilmore> | mmcgrath: its also useful for Security embargoed builds 00:21 < knurd> | dgilmore, +1 00:21 < Jeff_S> | dgilmore: don't we want all EPEL builds public, but only have the RH base+Updates private? 00:21 < mmcgrath> | dgilmore: ahh, thats true. 00:21 < dgilmore> | Jeff_S: yes thats what we need to do 00:21 < dgilmore> | EPEL will be free and open 00:21 < stahnma> | ++ 00:21 < knurd> | +1 00:22 < dgilmore> | We cant make the RHEL binaries free and publicly available 00:22 < Jeff_S> | dgilmore: sorry I misunderstood you before :) OK 00:22 < knurd> | dgilmore, can you talk to mbonnet about his short term plans and report the findings? 00:22 < dgilmore> | so its a nice feature for the buildsys but its very invasive 00:22 < knurd> | that would be the next step for now 00:23 < knurd> | he said two weeks ago that it wouldn't be that hard to realize 00:23 < dgilmore> | knurd: last i talked with him it was not even on the radar to be done 00:23 < dgilmore> | i will follow up with him 00:23 < knurd> | dgilmore, many thx 00:23 * | knurd will move on 00:24 --- | knurd has changed the topic to: EPEL Meeting -- vacant seat in the steering committee 00:24 < knurd> | I suppose we still want to solve the repotags stuff first? 00:24 < nirik> | has anyone expressed interest in the seat? 00:24 < stahnma> | I dunno, has anyone spoken up? 00:25 < Jeff_S> | I wrote knurd to let him know I was interested 00:25 --> | lancelan (Lance Davis) has joined #fedora-meeting 00:25 --> | lancelan (Lance Davis) has joined #fedora-meeting 00:25 --> | lancelan (Lance Davis) has joined #fedora-meeting 00:25 --> | lancelan (Lance Davis) has joined #fedora-meeting 00:25 < knurd> | well, there was some confusion; we have two volunteers, but one stepped back for now until the repotags issue is solved 00:25 < knurd> | and well, Jeff_S is the other one ;-) 00:25 < knurd> | let's solve the repotags issue first (over the next week), and solve this afterwards 00:26 < knurd> | Jeff_S, that okay for you? 00:26 < Jeff_S> | knurd: sure 00:26 --- | knurd has changed the topic to: EPEL Meeting -- finish the wiki docs and remove the warnings -- quaid 00:26 < knurd> | skipping, quaid not around 00:26 --- | knurd has changed the topic to: EPEL Meeting -- template for requesting a contributer to get 00:26 < knurd> | their packages into EPEL 00:26 --- | knurd has changed the topic to: EPEL Meeting -- template for requesting a contributer to get their packages into EPEL 00:26 < knurd> | stahnma, sorry, I did not look at this 00:27 < knurd> | but I think it's a good idea 00:27 < stahnma> | it's ok 00:27 < knurd> | shall we discuss it on the list in the next days? 00:27 < stahnma> | I just drafted something up 00:27 < stahnma> | sure 00:27 < knurd> | stahnma, k, thx 00:27 < stahnma> | I think a couple portions could be clearer 00:27 --- | knurd has changed the topic to: EPEL Meeting -- free discussions 00:27 < stahnma> | plz review 00:27 --- | knurd has changed the topic to: EPEL Meeting -- free discussion 00:27 < knurd> | stahnma, will do! 00:27 < knurd> | so, anything else to discuss? 00:27 < stahnma> | I saw that some packages were announced as built 00:28 < stahnma> | but didn't show up in a repo 00:28 < stahnma> | like trac 00:28 < stahnma> | is that normal? 00:28 < nirik> | which repo were you checking? might not have mirrored out yet? 00:28 < knurd> | it takes an hour until packagers hit the public servers 00:28 < knurd> | did you look right after the report was send? 00:28 < stahnma> | maybe I was too amitious 00:28 < stahnma> | not sure 00:29 < stahnma> | if I do yum list available today, I still don't see trac 00:29 < nirik> | Odd. I see it on my mirror at least. 00:29 < f13> | Trac was built days ago 00:30 < knurd> | I can see it on d.f.o 00:30 < stahnma> | hmm 00:30 < stahnma> | maybe my yum data is hosed 00:30 < knurd> | http://redhat.download.fedoraproject.org/pub/epel/5/i386/trac-0.10.3.1-2.el5.noarch.rpm 00:30 < stahnma> | yeah, that's it 00:30 < stahnma> | :( 00:30 < stahnma> | sorry 00:30 < knurd> | np, things happen :) 00:30 < knurd> | anything else? 00:31 < stahnma> | nope 00:31 * | nirik has nothing. 00:31 * | knurd will close the meeting in n 00:31 * | knurd will close the meeting in 30 00:32 * | knurd will close the meeting in 10 00:32 < knurd> | -- MARK -- Meeting end 00:32 --- | knurd has changed the topic to: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting From fedora at leemhuis.info Sun Jun 10 17:48:57 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 10 Jun 2007 19:48:57 +0200 Subject: EPEL report week 23, 2007 Message-ID: <466C3989.5020607@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week23 = Weekly EPEL Summary = Week 23/2007 == Most important happenings == No major happenings. == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) (partly) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * dgilmore (DennisGilmore) * stahnma (MichaelStahnke) Missing from the Steering Committee: * quiad (KarstenWade) (had fun at the dentist) Others that participated the meeting: Jeff_S, rdieter f13 === Summary === * some discussions about a new meeting time; we'll talk about it when we are full again * repotags -- all; the steering committee talks about it in private currently if and (mainly) how to do them; we mainly need to put in in words * EPEL mock configs in Fedora's mock package; nirik and Jeff_S will look into this over the next few days * comps.xml for EPEL -- dgilmore will get one started; stahnma volunteered to help * bodhi/testing repo/final repo layout -- bodhi needs koji these days, so EPEL needs to switch to koji to use bodhi (which we want for several reasons); dgimore will talk to mbonnet about a timeframe to use koji (which needs adjustments) for EPEL * vacant seat in the steering committee -- Jeff_S self nominated; but we want to solve the repotags issue first (over the next week), and fill the vacant seat afterwards * template for requesting a contributer to get their packages into EPEL -- idea is welcomed, further discussion on the list appreciated === Full meeting log === See https://www.redhat.com/archives/epel-devel-list/2007-June/msg00007.html == Stats == === General === Number of EPEL Contributors 86 We welcome 5 new contributors: devrim_AT_CommandPrompt.com, jbowes_AT_redhat.com, jwboyer_AT_jdub.homelinux.org, mricon_AT_gmail.com, notting_AT_redhat.com === EPEL 5 === Number of source packages: 310 Number of binary packages: 497 There are 36 new Packages: * arp-scan | Scanning and fingerprinting tool * bottlerocket | Utilities to use the FireCracker X10 kit * bugzilla | Bug tracking system * bwidget | Extended widget set for Tk * calcurse | Text-based personal organizer * clearsilver | Fast and powerful HTML templating system * dwatch | A program that watches over other programs * ettercap | Network traffic sniffer/analyser, NCURSES interface version * gammu | Command Line utility to work with mobile phones * gmrun | Lightweight "Run program" dialog box with search history and tab completion * graphviz | Graph Visualization Tools * halberd | Tool to discover HTTP load balancers * jasper | Implementation of the JPEG-2000 standard, Part 1 * mod_fcgid | Apache2 module for high-performance server-side scripting * ncarg | A Fortran and C based software package for scientific visualization * netcdf | Libraries for the Unidata network Common Data Form (NetCDF v3) * onesixtyone | An efficient SNMP scanner * perl-Affix-Infix2Postfix | Perl extension for converting from infix notation to postfix notation * perl-Image-Math-Constrain | Scaling math used in image size constraining (such as thumbnails) * perl-MailTools | Various mail-related perl modules * perl-Math-Base85 | Perl extension for base 85 numbers, as referenced by RFC 1924 * perl-Net-IPv6Addr | Perl module to check validity of IPv6 addresses * perl-Net-Pcap | Interface to pcap(3) LBL packet capture library * perl-Net-Server | Extensible, general Perl server engine * perl-Nmap-Parser | Parse nmap scan data with perl * perl-Proc-Daemon | Run Perl program as a daemon process * php-pear-Net-Ping | Execute ping * php-pear-Net-Traceroute | Execute traceroute * plone | User friendly and powerful open source Content Management System * postgresql-pgpool-II | Pgpool is a connection pooling/replication server for PostgreSQL * remind | A sophisticated calendar and alarm program * trac | Enhanced wiki and issue tracking system * trac-webadmin | Web interface for administration of Trac * vym | View your mind * zope | Web application server for flexible content management applications === EPEL 4 === Number of source packages: 210 Number of binary packages: 392 There are 9 new Packages: * bottlerocket | Utilities to use the FireCracker X10 kit * bwidget | Extended widget set for Tk * calcurse | Text-based personal organizer * clearsilver | Fast and powerful HTML templating system * onesixtyone | An efficient SNMP scanner * perl-MailTools | Various mail-related perl modules * postgresql-pgpool-II | Pgpool is a connection pooling/replication server for PostgreSQL * trac | Enhanced wiki and issue tracking system * trac-webadmin | Web interface for administration of Trac ---- ["CategoryEPELReports"] From cmc at math.hmc.edu Mon Jun 11 21:45:53 2007 From: cmc at math.hmc.edu (C.M. Connelly) Date: Mon, 11 Jun 2007 14:45:53 -0700 Subject: Results of LinuxTag Meetings? Message-ID: <11070.1181598353@vosill.math.hmc.edu> Hi, Folks, Last I had heard, several people from EPEL, CentOS, and the other repos were going to meet at LinuxTag to see if meeting in person would help resolve some of the confusion, misunderstandings, mistrust, and other issues that haven't seemed to be resolvable via e-mail/IRC. How did those meetings go? Were any conclusions reached? From last week's steering committee meeting transcript, it sounds like the whole repotags issue appears to be moving ahead, which seems like a good step forward. Can we look forward to better relations between EPEL and the other repos on other fronts as well? Thanks! Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc at math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From buildsys at fedoraproject.org Tue Jun 12 03:13:48 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 11 Jun 2007 23:13:48 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-11 Message-ID: <20070612031348.BEDD5152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 45 NEW akode-2.0.1-5.el5.1 : Audio-decoding framework dbmail-2.2.5-2.el5 NEW digitemp-3.5.0-1.el5 : Dallas Semiconductor 1-wire device reading console application NEW exiv2-0.14-1.el5 : Exif and Iptc metadata manipulation library NEW factory-2.0.5-11.el5 : C++ class library for multivariate polynomial data NEW fltk-1.1.8-0.3.r5750.el5 : C++ user interface toolkit NEW gc-6.8-3.el5 : C++ Garbage Collector NEW glump-0.9.11-3.el5 : A small web application to glue files from multiple sources NEW kannel-1.4.1-2.el5 : WAP and SMS gateway NEW kflickr-0.8-3.el5 : Standalone Flickr Uploader for KDE NEW libfac-2.0.5-8.el5 : An extension to Singular-factory NEW libksba-1.0.1-1.el5 : X.509 library NEW Macaulay2-0.9.95-4.el5 : System for algebraic geometry and commutative algebra NEW maxima-5.12.0-3.el5 : Symbolic Computation Program NEW nikto-1.36-3.el5 : Web server scanner NEW ntl-5.4-5.el5.1 : High-performance algorithms for vectors, matrices, and polynomials otrs-2.1.7-1.el5 NEW perl-Convert-BinHex-1.119-5.el5 : Macintosh BinHex extractor library for Perl NEW perl-GD-2.35-2.el5 : Perl interface to the GD graphics library NEW perl-GDGraph-1.44-1.el5 : Graph generation package for Perl NEW perl-GDTextUtil-0.86-8.el5 : Text utilities for use with GD NEW perl-IO-stringy-2.110-5.el5 : I/O on in-core objects like strings and arrays for Perl NEW perl-MIME-tools-5.420-3.el5 : Modules for parsing and creating MIME entities in Perl php-pear-Console-Table-1.0.7-1.el5 php-pear-Log-1.9.11-1.el5 NEW php-pear-PhpDocumentor-1.3.2-1.el5 : The complete documentation solution for PHP php-pecl-zip-1.8.10-1.el5 NEW python-gammu-0.20-1.el5 : Python bindings for Gammu NEW python-genshi-0.4.1-1.el5 : Toolkit for stream-based generation of output for the web NEW python-imaging-1.1.6-3.el5 : Python's own image processing library NEW python-IPy-0.53-2.el5 : Python module for handling IPv4 and IPv6 Addresses and Networks NEW python-kid-0.9.5-1.el5 : Kid - A simple and pythonic XML template language NEW python-pgsql-0.9.5-2.el5 : Enhanced python interface to PostgreSQL python-setuptools-0.6c6-1.el5 NEW redet-8.22-4.el5 : Regular expression development and execution tool NEW redet-doc-8.21-1.el5 : Documentation for redet NEW sbcl-1.0.6-1.el5 : Steel Bank Common Lisp NEW SDL_image-1.2.5-4.el5 : Image loading library for SDL NEW SDL_mixer-1.2.7-2.el5 : Simple DirectMedia Layer - Sample Mixer Library NEW SDL_net-1.2.6-2.el5 : SDL portable network library NEW SDL_ttf-2.0.8-3.el5 : Simple DirectMedia Layer TrueType Font library specto-0.2.0-4.el5 NEW xar-1.5-1.el5 : The eXtensible ARchiver NEW xdg-utils-1.0.1-3.el5 : Basic desktop integration functions NEW xforms-1.0.90-8.el5 : XForms toolkit library Packages built and released for Fedora EPEL 4: 15 NEW digitemp-3.5.0-1.el4 : Dallas Semiconductor 1-wire device reading console application NEW nikto-1.36-3.el4 : Web server scanner NEW perl-Convert-BinHex-1.119-5.el4 : Macintosh BinHex extractor library for Perl NEW perl-IO-stringy-2.110-5.el4 : I/O on in-core objects like strings and arrays for Perl NEW python-IPy-0.53-2.el4 : Python module for handling IPv4 and IPv6 Addresses and Networks NEW python-pgsql-0.9.5-2.el4 : Enhanced python interface to PostgreSQL python-setuptools-0.6c6-1.el4 NEW redet-8.22-4.el4 : Regular expression development and execution tool NEW redet-doc-8.21-1.el4 : Documentation for redet NEW SDL_image-1.2.4-2.el4 : Image loading library for SDL NEW SDL_mixer-1.2.6-8.el4 : Simple DirectMedia Layer - Sample Mixer Library NEW SDL_net-1.2.6-2.el4 : SDL portable network library NEW SDL_ttf-2.0.8-3.el4 : Simple DirectMedia Layer TrueType Font library specto-0.2.0-4.el4 NEW xar-1.5-1.el4 : The eXtensible ARchiver Changes in Fedora EPEL 5: akode-2.0.1-5.el5.1 ------------------- * Mon Feb 12 2007 Rex Dieter 2.0.1-5 - enable pulseaudio support (fedora only) - Requires: akode-pulseaudio (f7+) - make libsamplerate support fedora only dbmail-2.2.5-2.el5 ------------------ * Tue Jun 05 2007 Bernard Johnson 2.2.5-2 - fix %setup directory * Tue Jun 05 2007 Bernard Johnson 2.2.5-1 - 2.2.5 - change method of restarting daemons to that suggested in dbmail bug #600 * Wed May 23 2007 Bernard Johnson 2.2.5-0.1.rc3 - update to svn 2.2.5rc3 - remove unneccessary patches - make sqlite default driver for better out of the box experience digitemp-3.5.0-1.el5 -------------------- * Sun Jan 07 2007 Robert Scheck 3.5.0-1 - Upgrade to 3.5.0 - Initial spec file for Fedora and Red Hat Enterprise Linux exiv2-0.14-1.el5 ---------------- * Mon Apr 02 2007 Rex Dieter 0.14-1 - exiv2-0.14 factory-2.0.5-11.el5 -------------------- * Mon Dec 18 2006 Rex Dieter 2.0.5-11 - -devel -> -static fltk-1.1.8-0.3.r5750.el5 ------------------------ * Sun Apr 29 2007 Rex Dieter 1.1.8-0.3.r5750 - *really* fix --rpath issue, using non-empty patch this time (#238284) gc-6.8-3.el5 ------------ * Mon Dec 11 2006 Rex Dieter 6.8-3 - Obsoletes/Provides: libgc(-devel) (rpmforge compatibility) glump-0.9.11-3.el5 ------------------ * Sat Jun 09 2007 Jeffrey C. Ollie - 0.9.11-3 - Clean up tab/space confusion - Remove the buildroot at the beginning of the install kannel-1.4.1-2.el5 ------------------ * Mon Oct 16 2006 Matthias Saou 1.4.1-2 - Make sure we keep sqlite2 support for FC5 and below. kflickr-0.8-3.el5 ----------------- * Mon May 14 2007 Michael Stahnke - 0.8-3 - Final touch-up for review bug # 237355 * Mon May 14 2007 Michael Stahnke - 0.8-2 - Minor fix for bug # 237355 libfac-2.0.5-8.el5 ------------------ * Mon Dec 18 2006 Rex Dieter 2.0.5-8 - -devel -> -static libksba-1.0.1-1.el5 ------------------- * Fri Dec 01 2006 Rex Dieter 1.0.1-1 - libksba-1.0.1 Macaulay2-0.9.95-4.el5 ---------------------- * Mon Jan 15 2007 Rex Dieter 0.9.95-4 - Ob/Pr: Macaulay2-doc, not -docs (#222609) maxima-5.12.0-3.el5 ------------------- * Tue May 29 2007 Rex Dieter 5.12.0-3 - ExclusiveArch: %ix86 -> i386 (for koji) * Tue May 29 2007 Rex Dieter 5.12.0-2 - respin for sbcl-1.0.6 nikto-1.36-3.el5 ---------------- * Wed May 30 2007 Sindre Pedersen Bj?rdal - 1.36-3 - Add sed magic to really replace nikto-1.36-config.patch * Mon May 28 2007 Sindre Pedersen Bj?rdal - 1.36-2 - Remove libwhisker Requires - Replace configfile patch with sed magic - Update License - Add database-license.txt to %doc ntl-5.4-5.el5.1 --------------- * Mon Dec 18 2006 Rex Dieter 5.4-5 - -devel -> -static otrs-2.1.7-1.el5 ---------------- * Wed Jun 06 2007 Mike McGrath 2.1.7-1 - Upstream released new version perl-Convert-BinHex-1.119-5.el5 ------------------------------- * Thu Mar 08 2007 Paul Howarth 1.119-5 - add perl(ExtUtils::MakeMaker) buildreq - use tabs rather than spaces perl-GD-2.35-2.el5 ------------------ * Sun Oct 08 2006 Jose Pedro Oliveira - 2.35-2 - Removed a duplicate file (bdf_scripts/bdf2gdfont.PLS). perl-GDGraph-1.44-1.el5 ----------------------- * Sat May 05 2007 Jose Pedro Oliveira - 1:1.44-1 - Update to 1.44. perl-GDTextUtil-0.86-8.el5 -------------------------- * Fri Sep 08 2006 Jose Pedro Oliveira - 0.86-8 - Rebuild for FC6. perl-IO-stringy-2.110-5.el5 --------------------------- * Wed Apr 18 2007 Paul Howarth 2.110-5 - buildrequire perl(ExtUtils::MakeMaker) perl-MIME-tools-5.420-3.el5 --------------------------- * Tue Apr 17 2007 Paul Howarth 5.420-3 - Buildrequire perl(ExtUtils::MakeMaker) - Fix argument order for find with -depth php-pear-Console-Table-1.0.7-1.el5 ---------------------------------- * Wed May 02 2007 Remi Collet 1.0.7-1 - update to 1.0.7 php-pear-Log-1.9.11-1.el5 ------------------------- * Wed May 02 2007 Remi Collet 1.9.11-1 - update to 1.9.11 php-pear-PhpDocumentor-1.3.2-1.el5 ---------------------------------- * Sun Jun 10 2007 Konstantin Ryabitsev - 1.3.2-1 - Upstream 1.3.2 - Update the spec to the latest php-pear spec standards - Drop obsoleted patch php-pecl-zip-1.8.10-1.el5 ------------------------- * Thu Jun 07 2007 Remi Collet 1.8.10-1 - update to 1.8.10 python-gammu-0.20-1.el5 ----------------------- * Wed May 23 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.20-1 - Updated release. - fixed permission on examples files. - added gammu as require (need it to work with wammu package). python-genshi-0.4.1-1.el5 ------------------------- * Sat Jun 09 2007 Jeffrey C. Ollie - 0.4.1-1 - Update to 0.4.1 python-imaging-1.1.6-3.el5 -------------------------- * Sun Apr 29 2007 Nils Philippsen - 1.1.6-3 - add sane subpackage, split off tk subpackage (#238252) - add sane-types patch - use -b for patches to save original files - correct groups python-IPy-0.53-2.el5 --------------------- * Tue Jun 05 2007 Matt Domsch 0.53-2 - simple cleanups per Fedora package review, with thanks to Nigel Jones. python-kid-0.9.5-1.el5 ---------------------- * Sun Jan 28 2007 Konstantin Ryabitsev - 0.9.5-1 - Upstream 0.9.5 - Drop the py-def patch python-pgsql-0.9.5-2.el5 ------------------------ * Thu Jun 07 2007 Konstantin Ryabitsev - 0.9.5-2 - Set license according to what rpmlint wants python-setuptools-0.6c6-1.el5 ----------------------------- * Sun Jun 10 2007 Konstantin Ryabitsev - 0.6c6-1 - Upstream 0.6c6 - Require python-devel (#240707) redet-8.22-4.el5 ---------------- * Sat Jun 09 2007 Nigel Jones 8.22-4 - + Dep on desktop-file-utils - Minor touch up for .desktop file * Tue Jun 05 2007 Nigel Jones 8.22-3 - Use kregexpeditor.png for now (until I find a better unique one) * Fri Jun 01 2007 Nigel Jones 8.22-2 - Add .desktop file * Wed May 23 2007 Nigel Jones 8.22-1 - Initial SPEC file redet-doc-8.21-1.el5 -------------------- * Wed May 23 2007 Nigel Jones 8.21-1 - Initial SPEC file sbcl-1.0.6-1.el5 ---------------- * Tue May 29 2007 Rex Dieter 1.0.6-1 - sbcl-1.0.6 SDL_image-1.2.5-4.el5 --------------------- * Tue Dec 19 2006 Brian Pepple - 1.2.5-4 - Disable run-time loading of libs. (#219902) SDL_mixer-1.2.7-2.el5 --------------------- * Thu Aug 31 2006 Brian Pepple - 1.2.7-2 - Rebuild for FC6. SDL_net-1.2.6-2.el5 ------------------- * Thu Aug 31 2006 Brian Pepple - 1.2.6-2 - Rebuild for FC6. SDL_ttf-2.0.8-3.el5 ------------------- * Sat Jun 09 2007 Nigel Jones - 2.0.8-3 - Bump for EL-5 specto-0.2.0-4.el5 ------------------ * Wed Jun 06 2007 Xavier Lamien - 0.2.0-4 - Rebuilt for CVS. xar-1.5-1.el5 ------------- * Wed May 30 2007 Matthias Saou 1.5-1 - Update to 1.5. - Include patch to remove rpath. - Include patch to fix file modes, and get the lib properly stripped. xdg-utils-1.0.1-3.el5 --------------------- * Mon Apr 23 2007 Rex Dieter 1.0.1-3 - add htmlview,links to browser fallbacks xforms-1.0.90-8.el5 ------------------- * Tue Aug 29 2006 Rex Dieter 1.0.90-8 - fc6 respin Changes in Fedora EPEL 4: digitemp-3.5.0-1.el4 -------------------- * Sun Jan 07 2007 Robert Scheck 3.5.0-1 - Upgrade to 3.5.0 - Initial spec file for Fedora and Red Hat Enterprise Linux nikto-1.36-3.el4 ---------------- * Wed May 30 2007 Sindre Pedersen Bj?rdal - 1.36-3 - Add sed magic to really replace nikto-1.36-config.patch * Mon May 28 2007 Sindre Pedersen Bj?rdal - 1.36-2 - Remove libwhisker Requires - Replace configfile patch with sed magic - Update License - Add database-license.txt to %doc perl-Convert-BinHex-1.119-5.el4 ------------------------------- * Thu Mar 08 2007 Paul Howarth 1.119-5 - add perl(ExtUtils::MakeMaker) buildreq - use tabs rather than spaces perl-IO-stringy-2.110-5.el4 --------------------------- * Wed Apr 18 2007 Paul Howarth 2.110-5 - buildrequire perl(ExtUtils::MakeMaker) python-IPy-0.53-2.el4 --------------------- * Tue Jun 05 2007 Matt Domsch 0.53-2 - simple cleanups per Fedora package review, with thanks to Nigel Jones. python-pgsql-0.9.5-2.el4 ------------------------ * Thu Jun 07 2007 Konstantin Ryabitsev - 0.9.5-2 - Set license according to what rpmlint wants python-setuptools-0.6c6-1.el4 ----------------------------- * Sun Jun 10 2007 Konstantin Ryabitsev - 0.6c6-1 - Upstream 0.6c6 - Require python-devel (#240707) redet-8.22-4.el4 ---------------- * Sat Jun 09 2007 Nigel Jones 8.22-4 - + Dep on desktop-file-utils - Minor touch up for .desktop file * Tue Jun 05 2007 Nigel Jones 8.22-3 - Use kregexpeditor.png for now (until I find a better unique one) * Fri Jun 01 2007 Nigel Jones 8.22-2 - Add .desktop file * Wed May 23 2007 Nigel Jones 8.22-1 - Initial SPEC file redet-doc-8.21-1.el4 -------------------- * Wed May 23 2007 Nigel Jones 8.21-1 - Initial SPEC file SDL_image-1.2.4-2.el4 --------------------- * Sat Jun 09 2007 Nigel Jones - 1.2.4-2 - Bump for EL-4 SDL_mixer-1.2.6-8.el4 --------------------- * Sat Jun 09 2007 Nigel Jones - 1.2.6-8 - SDL_mixer 1.2.6 is latest that will build for EL-4 SDL_net-1.2.6-2.el4 ------------------- * Thu Aug 31 2006 Brian Pepple - 1.2.6-2 - Rebuild for FC6. SDL_ttf-2.0.8-3.el4 ------------------- * Sat Jun 09 2007 Nigel Jones - 2.0.8-3 - Base EL-4 package from FC-6 branch specto-0.2.0-4.el4 ------------------ * Wed Jun 06 2007 Xavier Lamien - 0.2.0-4 - Rebuilt for CVS. xar-1.5-1.el4 ------------- * Wed May 30 2007 Matthias Saou 1.5-1 - Update to 1.5. - Include patch to remove rpath. - Include patch to fix file modes, and get the lib properly stripped. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Tue Jun 12 03:42:22 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 11 Jun 2007 22:42:22 -0500 Subject: wither akode build #33994 (epel-5) Message-ID: <466E161E.3030101@math.unl.edu> According to the mail I received, this build succeeded, but I don't see this in the epel-5 repo (yet). ??? -- Rex -------------- next part -------------- An embedded message was scrubbed... From: buildsys at fedoraproject.org Subject: Build Result: 33994 - akode on fedora-5-epel Date: Wed, 6 Jun 2007 12:04:26 -0400 (EDT) Size: 991 URL: From dennis at ausil.us Tue Jun 12 03:24:09 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 11 Jun 2007 22:24:09 -0500 Subject: wither akode build #33994 (epel-5) In-Reply-To: <466E161E.3030101@math.unl.edu> References: <466E161E.3030101@math.unl.edu> Message-ID: <200706112224.09757.dennis@ausil.us> Once upon a time Monday 11 June 2007, Rex Dieter wrote: > According to the mail I received, this build succeeded, but I don't see > this in the epel-5 repo (yet). ??? It is there now. I just did a push. Dennis From Axel.Thimm at ATrpms.net Tue Jun 12 05:08:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 12 Jun 2007 07:08:55 +0200 Subject: Results of LinuxTag Meetings? In-Reply-To: <11070.1181598353@vosill.math.hmc.edu> References: <11070.1181598353@vosill.math.hmc.edu> Message-ID: <20070612050855.GB13280@neu.nirvana> On Mon, Jun 11, 2007 at 02:45:53PM -0700, C.M. Connelly wrote: > > Hi, Folks, > > Last I had heard, several people from EPEL, CentOS, and the other > repos were going to meet at LinuxTag to see if meeting in person > would help resolve some of the confusion, misunderstandings, > mistrust, and other issues that haven't seemed to be resolvable > via e-mail/IRC. > > How did those meetings go? Were any conclusions reached? We had a 1 1/2 h meeting, but there were no conclusions as such, but it was nice to meet all people and attach faces and voices to the email addresses. And yes, people in real life are really nice. Personally I tried to discuss the high-level cooperation/compatibility willingness existing, but no matter how often I tried to pull into this direction the discussion wouldn't follow. It was too much about the R.I.P. repotags again. > From last week's steering committee meeting transcript, it sounds > like the whole repotags issue appears to be moving ahead, which > seems like a good step forward. You think so? After the repotag fiasco I went through a lot of pain to strip them of, so the damage is done. Also the issue showed the real weakness of repotags: It takes just one non-conforming repo to kill them. > Can we look forward to better relations between EPEL and the other > repos on other fronts as well? I really hope so, but adding repotags to epel will not help anymore in this - it's too late, repotags are dead and the pain has been inflicted, in fact for me the revival of repotags would imply the same transition pain again. We need much higher level manifests like for example http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration?action=recall&rev=1 -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Tue Jun 12 16:38:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 12 Jun 2007 18:38:41 +0200 Subject: Plan for tomorrows EPEL SIG meeting Message-ID: <466ECC11.9060506@leemhuis.info> Hi all, find below the list of topics that are likely to come up in the next EPEL SIG meeting that's scheduled for tomorrow, Wednesday at 17:00 UTC in #fedora-extras on irc.freenode.org. /topic EPEL Meeting -- repotags -- all /topic EPEL Meeting -- EPEL mock configs in Fedora's mock package -- /topic EPEL Meeting -- comps.xml for EPEL -- dglimore nirik and Jeff_S /topic EPEL Meeting -- bodhi/testing repo/final repo layout -- nirik/lmacken /topic EPEL Meeting -- finish the wiki docs and remove the warnings by end of may -- quaid /topic EPEL Meeting -- Communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid /topic EPEL 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 update. That way all the interested parties know what up ahead of the meeting; that will avoid long delays and "status update monologues in the meeting. Thanks! CU thl P.S.: I'm on vacation ATM, but I should be there tomorrow From fedora at leemhuis.info Tue Jun 12 16:58:51 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 12 Jun 2007 18:58:51 +0200 Subject: Voting proposal for tomorrows meeting: Repotags in EPEL Message-ID: <466ED0CB.7090200@leemhuis.info> Hi! I'd like to get the repotags issue of the table. The Steering Committee talked about it, but no consensus could be found. But I'd really find some agreement tomorrow to get things moving again. So I'd suggest we put this up for voting: ---- == Proposal for the use of repotags for EPEL == The EPEL Steering Committee hereby issues that it wants to use a ".epel" repotag for all newly build packages in the EPEL repositories for EL4 and EL5. We hereby like to ask the Packaging Committee to bless the use of repotags for EPEL. If such a blessing occurred we'd further kindly ask the Packaging Committee for suggestions how to technical realize repotags in EPEL. The EPEL steering committee is of course willing to help with that; the EPEL Steering Committee receives the right to veto the technical solution from the Packaging Committee, but expects not to use that veto right.. ---- EOF Can we agree on this? Or does anyone want something different? Any addition/modifications? Cu thl From limb at jcomserv.net Tue Jun 12 17:07:33 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 12 Jun 2007 12:07:33 -0500 (CDT) Subject: Voting proposal for tomorrows meeting: Repotags in EPEL In-Reply-To: <466ED0CB.7090200@leemhuis.info> References: <466ED0CB.7090200@leemhuis.info> Message-ID: <34729.65.192.24.164.1181668053.squirrel@mail.jcomserv.net> +1 > Hi! > > I'd like to get the repotags issue of the table. The Steering Committee > talked about it, but no consensus could be found. But I'd really find > some agreement tomorrow to get things moving again. > > So I'd suggest we put this up for voting: > > ---- > == Proposal for the use of repotags for EPEL == > > The EPEL Steering Committee hereby issues that it wants to use a ".epel" > repotag for all newly build packages in the EPEL repositories for EL4 > and EL5. > > We hereby like to ask the Packaging Committee to bless the use of > repotags for EPEL. > > If such a blessing occurred we'd further kindly ask the Packaging > Committee for suggestions how to technical realize repotags in EPEL. The > EPEL steering committee is of course willing to help with that; the EPEL > Steering Committee receives the right to veto the technical solution > from the Packaging Committee, but expects not to use that veto right.. > > ---- EOF > > Can we agree on this? Or does anyone want something different? Any > addition/modifications? > > Cu > thl > > > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > -- novus ordo absurdum From sheltren at cs.ucsb.edu Tue Jun 12 17:29:35 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 12 Jun 2007 13:29:35 -0400 Subject: Plan for tomorrows EPEL SIG meeting In-Reply-To: <466ECC11.9060506@leemhuis.info> References: <466ECC11.9060506@leemhuis.info> Message-ID: <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> On Jun 12, 2007, at 12:38 PM, Thorsten Leemhuis wrote: > > /topic EPEL Meeting -- EPEL mock configs in Fedora's mock package -- I have tested out the configs you sent to the list: https://www.redhat.com/archives/epel-devel-list/2007-May/msg00081.html And they are working fine for me. -Jeff From Michael_E_Brown at dell.com Wed Jun 13 02:23:26 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 12 Jun 2007 21:23:26 -0500 Subject: volunteer searched: get mock configs for EPEL into the mock package In-Reply-To: <4645E8C8.5060206@leemhuis.info> References: <46421896.1020906@leemhuis.info> <46422D16.7060204@nobugconsulting.ro> <4642A515.6050401@leemhuis.info> <20070511173252.GA13627@humbolt.us.dell.com> <4645E8C8.5060206@leemhuis.info> Message-ID: <20070613022325.GE8637@humbolt.us.dell.com> On Sat, May 12, 2007 at 06:18:16PM +0200, Thorsten Leemhuis wrote: > I tried the i386 and the x86_64 one and they worked fine afaics. > > Note: I changed the URL from http://mirror.centos.org in the > fedora-4*epel files to http://mirrorlist.centos.org in the new ones, as > that's what CentOS uses in CentOS 5. these have been added to the git repo. They should be part of 0.7.1 when it gets released. (I want to give 0.7.0 a couple days in the wild to simmer since there hasnt been a release in a while.) -- Michael From sheltren at cs.ucsb.edu Wed Jun 13 11:48:17 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 13 Jun 2007 07:48:17 -0400 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> Message-ID: <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> On Jun 12, 2007, at 1:29 PM, Jeff Sheltren wrote: > On Jun 12, 2007, at 12:38 PM, Thorsten Leemhuis wrote: >> >> /topic EPEL Meeting -- EPEL mock configs in Fedora's mock package -- > > I have tested out the configs you sent to the list: > https://www.redhat.com/archives/epel-devel-list/2007-May/msg00081.html > At one point a while back I was building something for el5 x86_64, and I ran into a problem of yum pulling in i386 packages (from the x86_64 core repo). Talking to people in #centos-devel, I got the following exclude line from Johnny Hughes (slightly modified) for the mock config: exclude=[a-zA-Z]*.i?86 g[^l]*.i?86 glib2*.i?86 glib-*.i?86 glib.i?86 Is this something that we should include in the x86_64 config for EL5? I see that the fedora x86_64 config has something similar. -Jeff From rdieter at math.unl.edu Wed Jun 13 12:21:05 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 13 Jun 2007 07:21:05 -0500 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> Message-ID: Jeff Sheltren wrote: > At one point a while back I was building something for el5 x86_64, > and I ran into a problem of yum pulling in i386 packages (from the > x86_64 core repo). Talking to people in #centos-devel, I got the > following exclude line from Johnny Hughes (slightly modified) for the > mock config: > exclude=[a-zA-Z]*.i?86 g[^l]*.i?86 glib2*.i?86 glib-*.i?86 glib.i?86 I've always used simply, exclude=*.i?86 why the extra fuss and complexity? -- Rex From fedora at leemhuis.info Wed Jun 13 12:39:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Jun 2007 14:39:09 +0200 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> Message-ID: <466FE56D.6030205@leemhuis.info> On 13.06.2007 14:21, Rex Dieter wrote: > Jeff Sheltren wrote: > >> At one point a while back I was building something for el5 x86_64, >> and I ran into a problem of yum pulling in i386 packages (from the >> x86_64 core repo). Talking to people in #centos-devel, I got the >> following exclude line from Johnny Hughes (slightly modified) for the >> mock config: >> exclude=[a-zA-Z]*.i?86 g[^l]*.i?86 glib2*.i?86 glib-*.i?86 glib.i?86 > > I've always used simply, > exclude=*.i?86 > why the extra fuss and complexity? Can't remember, but there is a reason; that's why /etc/mock/fedora-6-x86_64-core.cfg also has exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86 g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86 *-devel.i? 86 CU thl From sheltren at cs.ucsb.edu Wed Jun 13 12:41:36 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 13 Jun 2007 08:41:36 -0400 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> Message-ID: On Jun 13, 2007, at 8:21 AM, Rex Dieter wrote: > Jeff Sheltren wrote: > >> At one point a while back I was building something for el5 x86_64, >> and I ran into a problem of yum pulling in i386 packages (from the >> x86_64 core repo). Talking to people in #centos-devel, I got the >> following exclude line from Johnny Hughes (slightly modified) for the >> mock config: >> exclude=[a-zA-Z]*.i?86 g[^l]*.i?86 glib2*.i?86 glib-*.i?86 glib.i?86 > > I've always used simply, > exclude=*.i?86 > why the extra fuss and complexity? > > -- Rex > I'm really not sure. What I got from Johnny seems to be what is used in the Fedora configs: exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86 g [abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86 *-devel.i?86 I simplified the regexes a bit to get what I pasted in my previous mail, but honestly I don't know why not just exclude all i?86 packages. Are there possibly packages that we need that are not excluded by that line? Either way, I think we need to have some sort of exclude for the x86_64 config or we end up with yum errors due to conflicting x86_64/ i?86 packages. -Jeff From Michael_E_Brown at dell.com Wed Jun 13 14:18:43 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 13 Jun 2007 09:18:43 -0500 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> Message-ID: <20070613141843.GJ8637@humbolt.us.dell.com> On Wed, Jun 13, 2007 at 08:41:36AM -0400, Jeff Sheltren wrote: > I simplified the regexes a bit to get what I pasted in my previous > mail, but honestly I don't know why not just exclude all i?86 > packages. Are there possibly packages that we need that are not > excluded by that line? > > Either way, I think we need to have some sort of exclude for the > x86_64 config or we end up with yum errors due to conflicting x86_64/ > i?86 packages. The current EPEL 5 mock config has no exclude list. Can you please send me what you would like to see? -- Michael From sheltren at cs.ucsb.edu Wed Jun 13 14:29:31 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 13 Jun 2007 10:29:31 -0400 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <20070613141843.GJ8637@humbolt.us.dell.com> References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> <20070613141843.GJ8637@humbolt.us.dell.com> Message-ID: <37D2701D-A147-4FB9-82FD-CFC210413A6E@cs.ucsb.edu> On Jun 13, 2007, at 10:18 AM, Michael E Brown wrote: > On Wed, Jun 13, 2007 at 08:41:36AM -0400, Jeff Sheltren wrote: >> I simplified the regexes a bit to get what I pasted in my previous >> mail, but honestly I don't know why not just exclude all i?86 >> packages. Are there possibly packages that we need that are not >> excluded by that line? >> >> Either way, I think we need to have some sort of exclude for the >> x86_64 config or we end up with yum errors due to conflicting x86_64/ >> i?86 packages. > > The current EPEL 5 mock config has no exclude list. Can you please > send > me what you would like to see? > -- > Michael > Hi Michael, maybe we can get this decided in the meeting today. I'll send an updated EL5 mock config to you and the list once we determine exactly what we need to exclude :) By the way, can you tell from git/cvs who added the exclude lines initially to the Fedora config(s)? Thanks, Jeff From Michael_E_Brown at dell.com Wed Jun 13 15:45:49 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 13 Jun 2007 10:45:49 -0500 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <37D2701D-A147-4FB9-82FD-CFC210413A6E@cs.ucsb.edu> References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> <20070613141843.GJ8637@humbolt.us.dell.com> <37D2701D-A147-4FB9-82FD-CFC210413A6E@cs.ucsb.edu> Message-ID: <20070613154548.GL8637@humbolt.us.dell.com> On Wed, Jun 13, 2007 at 10:29:31AM -0400, Jeff Sheltren wrote: > On Jun 13, 2007, at 10:18 AM, Michael E Brown wrote: > > >On Wed, Jun 13, 2007 at 08:41:36AM -0400, Jeff Sheltren wrote: > >>I simplified the regexes a bit to get what I pasted in my previous > >>mail, but honestly I don't know why not just exclude all i?86 > >>packages. Are there possibly packages that we need that are not > >>excluded by that line? > >> > >>Either way, I think we need to have some sort of exclude for the > >>x86_64 config or we end up with yum errors due to conflicting x86_64/ > >>i?86 packages. > > > >The current EPEL 5 mock config has no exclude list. Can you please > >send > >me what you would like to see? > >-- > >Michael > > > > Hi Michael, maybe we can get this decided in the meeting today. I'll > send an updated EL5 mock config to you and the list once we determine > exactly what we need to exclude :) Quickly. I have 0.7.1 ready to go as we hit a bug in 0.7.0. We will be releaseing 0.7.1 sometime today in the next couple hours. Current configs that were posted a couple weeks ago (sans exclude=) are current staged for 0.7.1. > By the way, can you tell from git/cvs who added the exclude lines > initially to the Fedora config(s)? That would require more git-fu than I currently possess. -- Michael From fedora at leemhuis.info Wed Jun 13 15:55:46 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Jun 2007 17:55:46 +0200 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <20070613154548.GL8637@humbolt.us.dell.com> References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> <20070613141843.GJ8637@humbolt.us.dell.com> <37D2701D-A147-4FB9-82FD-CFC210413A6E@cs.ucsb.edu> <20070613154548.GL8637@humbolt.us.dell.com> Message-ID: <46701382.3070802@leemhuis.info> On 13.06.2007 17:45, Michael E Brown wrote: > On Wed, Jun 13, 2007 at 10:29:31AM -0400, Jeff Sheltren wrote: >> On Jun 13, 2007, at 10:18 AM, Michael E Brown wrote: > >> Hi Michael, maybe we can get this decided in the meeting today. I'll >> send an updated EL5 mock config to you and the list once we determine >> exactly what we need to exclude :) > Quickly. I have 0.7.1 ready to go as we hit a bug in 0.7.0. We will be > releaseing 0.7.1 sometime today in the next couple hours. > > Current configs that were posted a couple weeks ago (sans exclude=) are > current staged for 0.7.1. Please just add the exclude line as it is found in /etc/mock/fedora-6-x86_64-core.cfg to the x86_64 config files for EPEL-4 and EPEL5 ; e.g. this line exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86 g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86 *-devel.i?86 Thanks! Cu thl From sheltren at cs.ucsb.edu Wed Jun 13 15:56:46 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 13 Jun 2007 11:56:46 -0400 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <20070613154548.GL8637@humbolt.us.dell.com> References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> <20070613141843.GJ8637@humbolt.us.dell.com> <37D2701D-A147-4FB9-82FD-CFC210413A6E@cs.ucsb.edu> <20070613154548.GL8637@humbolt.us.dell.com> Message-ID: <68CE3C5A-D431-4167-A4FC-F73851A73780@cs.ucsb.edu> On Jun 13, 2007, at 11:45 AM, Michael E Brown wrote: >> >> Hi Michael, maybe we can get this decided in the meeting today. I'll >> send an updated EL5 mock config to you and the list once we determine >> exactly what we need to exclude :) > > Quickly. I have 0.7.1 ready to go as we hit a bug in 0.7.0. We will be > releaseing 0.7.1 sometime today in the next couple hours. > > Current configs that were posted a couple weeks ago (sans exclude=) > are > current staged for 0.7.1. > Hi Michael, if you have to push a 0.7.1 today, I'd lean towards simply copying the exclude line from a fedora x86_64 mock config and re-using that in the EL5 x86_64 config. That "works for me", and it's an improvement over the behavior without having an exclude line. If anyone sees any problem with this, please respond soon so Michael can get the update pushed :) -Jeff From Michael_E_Brown at dell.com Wed Jun 13 16:03:38 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 13 Jun 2007 11:03:38 -0500 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <68CE3C5A-D431-4167-A4FC-F73851A73780@cs.ucsb.edu> References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> <20070613141843.GJ8637@humbolt.us.dell.com> <37D2701D-A147-4FB9-82FD-CFC210413A6E@cs.ucsb.edu> <20070613154548.GL8637@humbolt.us.dell.com> <68CE3C5A-D431-4167-A4FC-F73851A73780@cs.ucsb.edu> Message-ID: <20070613160337.GM8637@humbolt.us.dell.com> On Wed, Jun 13, 2007 at 11:56:46AM -0400, Jeff Sheltren wrote: > On Jun 13, 2007, at 11:45 AM, Michael E Brown wrote: > >> > >>Hi Michael, maybe we can get this decided in the meeting today. I'll > >>send an updated EL5 mock config to you and the list once we determine > >>exactly what we need to exclude :) > > > >Quickly. I have 0.7.1 ready to go as we hit a bug in 0.7.0. We will be > >releaseing 0.7.1 sometime today in the next couple hours. > > > >Current configs that were posted a couple weeks ago (sans exclude=) > >are > >current staged for 0.7.1. > > > > Hi Michael, if you have to push a 0.7.1 today, I'd lean towards > simply copying the exclude line from a fedora x86_64 mock config and > re-using that in the EL5 x86_64 config. That "works for me", and > it's an improvement over the behavior without having an exclude line. > > If anyone sees any problem with this, please respond soon so Michael > can get the update pushed :) Will do. Let me know if you guys want something different and I'll get it ready for 0.7.2. -- Michael From Michael_E_Brown at dell.com Wed Jun 13 16:10:29 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 13 Jun 2007 11:10:29 -0500 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <46701382.3070802@leemhuis.info> References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> <20070613141843.GJ8637@humbolt.us.dell.com> <37D2701D-A147-4FB9-82FD-CFC210413A6E@cs.ucsb.edu> <20070613154548.GL8637@humbolt.us.dell.com> <46701382.3070802@leemhuis.info> Message-ID: <20070613161029.GN8637@humbolt.us.dell.com> On Wed, Jun 13, 2007 at 05:55:46PM +0200, Thorsten Leemhuis wrote: > > > On 13.06.2007 17:45, Michael E Brown wrote: > > On Wed, Jun 13, 2007 at 10:29:31AM -0400, Jeff Sheltren wrote: > >> On Jun 13, 2007, at 10:18 AM, Michael E Brown wrote: > > > >> Hi Michael, maybe we can get this decided in the meeting today. I'll > >> send an updated EL5 mock config to you and the list once we determine > >> exactly what we need to exclude :) > > Quickly. I have 0.7.1 ready to go as we hit a bug in 0.7.0. We will be > > releaseing 0.7.1 sometime today in the next couple hours. > > > > Current configs that were posted a couple weeks ago (sans exclude=) are > > current staged for 0.7.1. > > Please just add the exclude line as it is found in > /etc/mock/fedora-6-x86_64-core.cfg > to the x86_64 config files for EPEL-4 and EPEL5 ; e.g. this line > > exclude=[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefhijklmnopqrstuvwxyz]*.i*86 > g[abcdefghijkmnopqrstuvwxyz]*.i?86 glib2.i?86 glib.i?86 *-devel.i?86 In fedora-6-x86_64-core.cfg, there is another exclude as well: [local] name=local baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-6-extras/ exclude=*.i386 *.ppc I added the same to the epel configs. (Are you guys even using plague for EPEL 5?) Pushed and will be in 0.7.1. -- Michael From sheltren at cs.ucsb.edu Wed Jun 13 16:21:51 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 13 Jun 2007 12:21:51 -0400 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <20070613161029.GN8637@humbolt.us.dell.com> References: <466ECC11.9060506@leemhuis.info> <33C4AEA1-9A5D-4093-9B66-54B3F92E7B2D@cs.ucsb.edu> <94F38F99-712F-400B-8011-72C13D28D97B@cs.ucsb.edu> <20070613141843.GJ8637@humbolt.us.dell.com> <37D2701D-A147-4FB9-82FD-CFC210413A6E@cs.ucsb.edu> <20070613154548.GL8637@humbolt.us.dell.com> <46701382.3070802@leemhuis.info> <20070613161029.GN8637@humbolt.us.dell.com> Message-ID: <7DCD6EE0-1942-47B4-8C21-AE9842A45930@cs.ucsb.edu> On Jun 13, 2007, at 12:10 PM, Michael E Brown wrote: > > In fedora-6-x86_64-core.cfg, there is another exclude as well: > > [local] > name=local > baseurl=http://buildsys.fedoraproject.org/plague-results/ > fedora-6-extras/ > exclude=*.i386 *.ppc > > I added the same to the epel configs. (Are you guys even using plague > for EPEL 5?) > > Pushed and will be in 0.7.1. > -- > Michael > Great, thanks for your help. The plague exclude *should* work, but we'll see what happens! Yes, we're using plague for the time being, but planning to move over to koji once some other stuff gets worked out... -Jeff From fedora at leemhuis.info Wed Jun 13 18:04:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Jun 2007 20:04:59 +0200 Subject: Log from todays meeting Message-ID: <467031CB.7020904@leemhuis.info> 00:00 < knurd> | Meeting ping dgilmore, knurd, mmcgrath, nirik, stahnma, quaid and everyone interested in EPEL -- EPEL meeting in #fedora-meeting now! 00:00 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:00 < knurd> | Hi everybody; who's around? 00:00 * | Jeff_S here 00:00 * | nirik is here. 00:00 * | dgilmore is here 00:00 --> | notting (Bill Nottingham) has joined #fedora-meeting 00:00 * | mmcgrath is here 00:01 < knurd> | no quaid yet, but let's start 00:01 --- | knurd has changed the topic to: EPEL Meeting -- repotags -- all 00:01 < knurd> | so, the never ending story :) 00:01 < knurd> | feelings? 00:01 < knurd> | opinions on the last proposal? 00:02 < nirik> | did you see axel's email to the list about it? 00:02 < knurd> | opinions on Axels mail where he said "but adding repotags to epel will not help anymore in this - it's too late, repotags are dead and the pain has been inflicted, in fact for me the revival of repotags would imply the same transition pain again." 00:02 < knurd> | nirik, yeah, saw it 00:02 < knurd> | but I read it after I send the last proposal out 00:03 < nirik> | I really just want the issue to go away... I would be fine with pushing the proposal forward or just dropping it (again). 00:03 < knurd> | I'm wondering if we should try a different route: ask the FPC for a official statement if repotags are fine for them 00:03 < knurd> | (in general) 00:04 < knurd> | get that answer from their next week meeting 00:04 < knurd> | and we decide how to move on next week 00:04 < knurd> | I'm unsure 00:04 < knurd> | even I would likely vote "+/- 0" for my own proposal currently 00:04 * | quaid is aqui 00:05 < knurd> | other opinions? 00:05 < nirik> | ok, anyone else? opinions? votes? 00:05 < mmcgrath> | knurd: we really need to just decide and move on. 00:05 < spot> | we're not going to give that statement. 00:05 < spot> | just as an FYI 00:05 < nirik> | I lean toward just dropping the subject... moving on with our lives. 00:05 < knurd> | spot, ohh, I didn#t expect you would be around 00:05 < knurd> | spot, why? 00:05 < spot> | if you really want repotags vote on it, and we'll figure out how to implement them. 00:05 < Jeff_S> | I support your proposal, but with the idea that we can use that in the meantime and work on other (better?) ways of co-existance with other repos going forward 00:06 < dgilmore> | knurd: all i can say is drop it 00:06 < spot> | its not our domain to decide whether they're ok or not, thats FESCo 00:06 < dgilmore> | currently i would vote -100 00:06 < knurd> | spot, would you share your opnion on repotags? 00:07 < spot> | I don't know what technical problem they solve. 00:07 < dgilmore> | spot: none 00:07 < spot> | They clutter up the namespace. 00:07 < knurd> | dag tried to explain one two me, and it made a bit of sense 00:07 < nirik> | they allow end users to trivially see what repo packages are causing them conflicts/problems... or so the theory goes. 00:07 < knurd> | say there is clamav in both epel and dags repo 00:07 < dgilmore> | i dont know how any sane person can expect to mix repos providing the same packages and get a consistent and sane result 00:07 < knurd> | with different sub-packages 00:07 --> | smooge (Stephen J Smoogen) has joined #fedora-meeting 00:08 < spot> | i'd tend to agree that mixing repos with the same packagesets == BOOM 00:08 < spot> | and repotags won't resolve that. 00:08 --> | Karl_le_Rouge (Karl) has joined #fedora-meeting 00:08 < knurd> | then it can happen that a clamav subpacakge from epel tracks in the clamav main pacakge from dag 00:08 < Jeff_S> | knurd: yeah, repotags don't solve that issue 00:08 < knurd> | as long as there is no strict version-release dep 00:08 < spot> | all it will do is make the remains of your system more identifiable 00:08 < knurd> | and a repotag could make that strong version-release dep 00:09 < spot> | knurd: if the subpackages don't already have that strict version-release dep, it won't matter. 00:09 --> | danieldk (Daniel de Kok) has joined #fedora-meeting 00:09 < spot> | and if they do, the likely hood of the same e:n-v-r in both repos? 00:10 < spot> | I think you guys need to decide whether third-party repo simultaneous operation is a goal. 00:10 < spot> | If it is a goal of EPEL, then repotags are only part of a much bigger effort that needs to be undertaken. 00:10 < knurd> | third-party repo simultaneous operation is not a goal afics 00:10 < spot> | If it isn't, then repotags don't really have a point. 00:10 --> | Foolish (Sindre Pedersen Bjordal) has joined #fedora-meeting 00:11 < spot> | That's just my opinion. :) 00:11 < knurd> | thx spot 00:11 --> | stahnma (Michael Stahnke) has joined #fedora-meeting 00:11 < knurd> | I must say: I don't know how to move on 00:12 < mmcgrath> | knurd: After the in person meeting I thought we were going to do repo tags but if axel himself doesn't want them now I'm not sure what good we accomplish by turning them on. 00:12 < nirik> | ok, so can we move on now? or is there any more dead horse beating we need to do? 00:12 < stahnma> | sorry, IM late 00:12 < knurd> | okay, so lets somehow vote 00:13 < knurd> | A=no repotags; B=investigate repotags further; C=undecided 00:13 * | knurd votes C 00:13 --> | RemiFedora (Unknown) has joined #fedora-meeting 00:14 < mmcgrath> | B and C both imply that we're not moving on. I strongly feel the repo tags discussion does more harm by continuing to dicsuss it then either implementing it or disallowing it would. 00:14 < dgilmore> | A 00:14 * | quaid votes C with a clear statement, "Sorry, didn't mean to piss in anyone's breakfast cereal, we pledge to be more careful in the future." 00:14 < stahnma> | +1 quaid 00:14 <-- | rdieter_away has quit (Read error: 104 (Connection reset by peer)) 00:14 < knurd> | in case anyone is wondering: I'm interest in all opinions 00:14 --> | rdieter (Rex Dieter) has joined #fedora-meeting 00:15 < nirik> | mmcgrath: yeah, I want this to find a end... somehow. 00:15 < stahnma> | agreed 00:15 < quaid> | unless we can make "A=no repotags currently" or something, so we aren't having to reverse even more decisions 00:15 < knurd> | so people not in the steering committee can share their opinion by saying A, B or C, too 00:15 * | nirik votes A I guess. 00:15 < knurd> | quaid, "A=no repotags (as the case currently)" 00:16 < knurd> | quaid, so going for A would just end that topic as long as nobody brings it up again 00:16 < stahnma> | A 00:16 < quaid> | knurd: yeah 00:16 < quaid> | Cheers, Jeff. 00:16 < stahnma> | if that's the case, A 00:16 --- | rdieter is now known as rdieter_away 00:16 * | quaid pastes strangeness from his buffer, sorry 00:16 < f13> | oh! it's the weekly repotag conversation again. 00:16 * | Jeff_S votes D - go ahead with the proposal and start looking for alternatives as well 00:16 < quaid> | f13: don't kick a puppy when it's down! 00:16 < f13> | seriously, who do we have to shoot to get this topic dropped like we do every week? 00:16 < Jeff_S> | quaid: cheers ;) 00:17 < nirik> | f13: yes, it's a standing item it seems anymore. 00:17 * | mmcgrath notes 15 minute mark 00:17 < knurd> | okay; thl and quaid voted C; stahnma dgilmore and nirik A 00:17 < stahnma> | any other votings ? or move on? 00:17 < knurd> | mmcgrath ? 00:17 < quaid> | you have to ask/ 00:17 < smooge> | ok now that I have typed all the stuff in the wrong window 00:18 < Jeff_S> | everyone see #epel for smooge's ideas... 00:18 < smooge> | sorry 00:19 < f13> | I have no vote, but I"d vote A like always 00:19 < f13> | (and I'd vote that way in FESCo too FYI) 00:19 < smooge> | The main issues I deal on a volunteer support level are people who have followed a lot of Howto's and have multiple repo's or dont know they have multiple repos because their ISP was too nice 00:19 < nirik> | someone mentioned that this discussion did in fact happen with fedora.us/early fedora-extras days and was shot down there... just FYI... 00:20 * | knurd still waits for mmcgrath's vote 00:20 < smooge> | Yes.. there was a lot of discussion back then 00:20 < mmcgrath> | knurd: we're just waiting on me? 00:20 < mmcgrath> | why? 00:20 < knurd> | I didn#t see a A, B or C (or something else) 00:21 < knurd> | or did I miss it? 00:21 < mmcgrath> | A 00:21 < nirik> | smooge: I understand that this would give you more info, but I think that info can be gotten pretty easily other ways... 00:21 < knurd> | mmcgrath, k, thx 00:21 < smooge> | and it was put off of saying clearly that the group then was working with the older packaging community or not. Instead it was a sort of quiet no we are not while saying we will take it up later 00:21 <-- | RedKarl has quit (Connection timed out) 00:21 < knurd> | that makes four A (continue with no repotags) two C (undecided) and Jeff_S as potential steering committee member as "D" (proposal by thl) 00:22 --- | rdieter_away is now known as rdieter 00:22 < Jeff_S> | knurd: if you want my vote in terms of A/B/C, I suppose B would be the closest 00:22 < knurd> | Jeff_S, noted 00:22 < knurd> | so, that means no repotags 00:22 < nirik> | Jeff_S: splitter! :) 00:22 < f13> | for real this time? 00:22 < quaid> | smooge: as Axel said on list, maybe we need to handle this stuff at a higher level -- agree to work together with other repos, and work out shared scripts/tools that help in tech support. 00:22 < knurd> | or does anyone change his opinion after smooge's comments? 00:23 < nirik> | f13: well, until next meeting I bet. ;) 00:23 < mmcgrath> | quaid: I don't know how we can do that though, I think we need to work with axel and dag and co on much lower levels. The manitainers. 00:23 < knurd> | f13, I suppose there will be cries on the list 00:23 < mmcgrath> | its the packages that are incompatible. 00:23 < stahnma> | I have agreed with his comments, but am so tired of this, I just want to move on. Especially since Axel already said they are not worth it anymore. 00:24 < f13> | there is clearly a need to better identify where packages came from. repo tags aren't the solution IMHO 00:24 < smooge> | Ok, could there be a public reasoning statement about this to make it final. Basically, that EPEL is not meant to work with other repo's and that mixing/matching repo's is considered too much of a support burden for EPEL volunteers. 00:24 < stahnma> | hopefully a better techincal solution will be found soon and we can lead the way with that 00:24 --> | mdomsch (Matt_Domsch) has joined #fedora-meeting 00:24 < quaid> | smooge: +1 00:24 < mmcgrath> | smooge: don't confuse repo tags with collaborating with other repos. 00:24 < f13> | making it easier to pick out the gpg key would be best, hard to fake. %PACKAGER is a also usable, fakeable, but usable. 00:24 < knurd> | mmcgrath, +1 00:24 < smooge> | A web-page etc that says that will be a better line than the silent treatment that came out of fedora.us 00:24 < mmcgrath> | smooge: would you ask axel to do the same? He's not using repo tags. 00:25 < nirik> | perhaps we could get everyone to use yum-priorities. ;) But thats for another day... 00:26 * | knurd waits for 1 minute idle time before moving on to the next topic 00:26 < smooge> | mmcgrath, I could do so.. but his reasoning statement is that EPEL told him to get stuffed 00:26 < smooge> | one more second please knurd 00:26 < knurd> | smooge, that's why I said "one minute idle time" 00:26 < lancelan> | I am surprised that you have listened to axel ... 00:26 < mmcgrath> | If we told him to get stuffed, why have we been discussing it for 3 months? 00:27 < mmcgrath> | lancelan: he's the only one that bothered joining the SIG. That means a lot (to me at least) 00:27 < lancelan> | I thought that Dag gave good reason for repotags ... 00:27 < lancelan> | but hey - if you guys dont intend for folks to be able to mix repos then the discussion is pointless :) 00:28 < mmcgrath> | lancelan: I still didn't follow what he was talking about but then Axel goes on the list and says he doesn't want repo tags. 00:28 < smooge> | mmcgrath, the issue is that there is a big ego and communication gap going on... and this is a layer 8 problem that precludes any co-operation 00:28 < mmcgrath> | so I'm getting mixed signals from the other repos and it pisses me off because I thought we came to an agreement. 00:28 < lancelan> | well the main point was in mixed repo - even with stuff like priorities etc going on 00:28 < lancelan> | I th0ught anyway :) 00:29 < f13> | lancelan: Dag gave reasons why identifying where a package came from would be handy. repodtags are a hacky way of accomplising that goal (kind of), but not one that FEdora is willing to use. We'd rather find a more robust solution to the problem. 00:29 * | notting is confused. we have repo tags already. %{DISTRIBUTION} and %{PACKAGER} 00:29 < mmcgrath> | smooge: the problem is that in the dag and axel world, the guys that run the show are also THEE packagers. Thats not the case in EPEL. I firmly believe that to fix this problem the packages have to change. And the EPEL SIG just can't do that. 00:29 < f13> | notting: +1 00:29 < smooge> | mmcgrath, and we get mixed signals from the EPEL group and Fedora people.. some say that EPEL is doing this, others say that. 00:30 < lancelan> | well it seems to me that the fedora camp is firmly entrenched against repotags ... 00:30 < mmcgrath> | lancelan: but would you say "the fedora camp is firmly entrenched against 3rd party repos" ? 00:30 < lancelan> | and that something else _may- come along in the future 00:30 < smooge> | mmcgrath, so we end up with everyone taking the message that they want to hear or not to hear and just more and more conflicts 00:30 < knurd> | smooge, one of the downsides of a real community project with lots of volunteers afaics :-/ 00:31 < quaid> | minute has passed 00:31 < lancelan> | mmcgrath, I thought that was said before ... 00:31 < smooge> | knurd, I agree but at some point an organization has to take a stand and people have to fall to one side or the other.. otherwise nothing gets done 00:31 < mmcgrath> | smooge: but you're binding repo tags and collaboration and thats a fallacy. 00:32 < knurd> | smooge, your have a point, but well, it's a quite controversial topic.... 00:32 < mmcgrath> | repo tags will not fix the clamav problems, dag working with the clamav packager will. And that has nothing to do with the SIG. 00:32 < mmcgrath> | or the clamav packager working with dag will. 00:33 <-- | rwmjones has quit ("Closed connection") 00:33 * | knurd will move on soon if nothing happens anymore 00:33 < smooge> | mmcgrath, since I have joined it has been mentioned on both sides as being part of collaboration at some point or another. 00:33 < lancelan> | I actually dont like repotags - and agree that yum/rpm should be able to indicate repo - but they dont ... 00:33 < smooge> | I would like to see a definition in the end of what is collaboration and what can be done if anything to meet it 00:33 < mmcgrath> | smooge: but collaboration does not mean "do what the other guy says" 00:34 < lancelan> | unless of course you specifically ask 00:34 < f13> | lancelan: they can, but it requires more query flags. Now whether or not those query flags are made more prominent, or... 00:34 < mmcgrath> | knurd: what else is on the schedule today? 00:34 < f13> | lancelan: (: 00:34 < lancelan> | f13, sure, some user tools to show stuff would be good - and they are coming in to yum ... 00:35 <-- | londo has quit (Read error: 110 (Connection timed out)) 00:35 < knurd> | does anybody really think opinions will cahnge if we discuss this further? 00:35 < wwoods> | rpm -qi isn't that hard 00:35 < lancelan> | I would actually like to see mixed repos - but yum isnt clever enough yet IMHO 00:35 < f13> | smooge: working with 3rd party repos is going to be pretty hard in any case. THe EPEL project cannot reference nor link to these 3rd party repos for software, as those repos host illegal content. SO we have to package everything we want in EPEL proper, which immediatly creates 'conflicts' with these 3rd party repos. 00:35 < knurd> | otherwise I suggest we move on 00:35 < knurd> | f13, +1 00:35 < f13> | smooge: if these repos would just drop the illegal content then it would be much easier. 00:35 < lancelan> | f13 - define illegal for me please :) 00:35 < smooge> | f13, but it might not be illegal where they are 00:36 < f13> | smooge: and that doesn't matter to us 00:36 < Jeff_S> | f13: kbs extras has something RH would consider "illegal"? 00:36 < dgilmore> | lancelan: illegal in the US mp3 dvd etc 00:36 < f13> | Jeff_S: what is 'kbs' ? 00:36 < dgilmore> | Jeff_S: he only built Fedora Extras for RHEL 00:36 < Jeff_S> | sorry, centos.karan.org 00:36 < f13> | ah. 00:36 < Jeff_S> | dgilmore: yes, exactly 00:36 < f13> | in that case, it would be obsolete 00:37 < f13> | as we want to use the same infrastructure framwork and people to do the builds. 00:37 < Jeff_S> | I'm just saying that you're making quite a blanket statement 00:37 < dgilmore> | Jeff_S: AFAIKT he has not updated any packages since we dropped FC-3 support 00:37 < f13> | Fedora Packager Joe can't get to the source control for kbs, to fix things, or whatever. 00:37 < smooge> | Jeff_S, its ok.. this I have learned is f13's normal mode of talking in meetings. 00:37 * | Jeff_S ignores it then 00:38 < notting> | actually, speaking of centos, do we have whomever's doing the /extras/ stuff on the main centos mirrors working in epel? 00:38 < f13> | Jeff_S: the people that are complaining loudly about 'interoperability' with 3rd parties are the ones that are carrying things we can't reference. 00:39 < nirik> | notting: not the Xfce people at least.... They are using my Xfce specs tho, so if I push Xfce for EPEL it should be fine as long as we keep the centos-extras in step. 00:39 < knurd> | notting, I don't think there are much people that are working in Fedora and Centos Extras 00:39 < f13> | Jeff_S: so yes, I'm blanket stating that working with "3rd party" is going to be difficult on many levels. As we found with FEdora itself, just having an official 3rd party was a lot of unnecessary trouble. 00:39 < Jeff_S> | notting: it is a small group of people AFAIK, and I think the answer is no to most or all of them 00:39 < smooge> | notting, no. I understand that there are contractual issues with them signing the Fedora License stuff 00:39 < notting> | *sigh* 00:39 < mmcgrath> | notting: we tried though. 00:40 < Jeff_S> | f13: well if it is necessary or not is debatable IMO 00:40 < nirik> | smooge: if you know who the people(s) that are doing the Xfce for centos-extras are, I would love a contact email... I haven't been able to figure out who it is. 00:40 < Jeff_S> | f13: but, yes, it is trouble, that much is clear 00:40 < stahnma> | I think I have to get to a work meeting 00:40 < stahnma> | so, I am parting early 00:41 < Jeff_S> | bye stahnma 00:41 < knurd> | shall we move on with the other topics of the EPEL meeting? 00:41 < knurd> | by stahnma 00:41 < Jeff_S> | knurd: I would like that 00:41 < smooge> | knurd, I have spoken my piece on this 00:41 < knurd> | smooge, thx for your input 00:41 --> | donavan (CtrlProxy User) has joined #fedora-meeting 00:41 < knurd> | so let's move on 00:41 --- | knurd has changed the topic to: EPEL Meeting -- EPEL mock configs in Fedora's mock package 00:42 < knurd> | seems it has happened 00:42 < knurd> | does anyone know if the EPEL4 configs have been updated? 00:42 * | mmcgrath hasn't done it 00:42 < mmcgrath> | dgilmore: ? 00:42 < Jeff_S> | I haven't gotten around to figuring out git yet... 00:42 < knurd> | s/mirror.centos.org/mirrorlist.centos.org/ 00:42 < quaid> | Dennis fell asleep 00:42 < Jeff_S> | knurd: I think that has been fixed, but I'm not positive 00:43 < knurd> | Jeff_S, okay, can you keep an eye on it if it really has been fixed when the new package comes out? 00:43 < f13> | we have a mock update coming out soon 00:43 < knurd> | that would be enought for now afaics 00:43 < f13> | I _think_ it has epel configs 00:43 < f13> | you can check the git tree though 00:43 < f13> | git://git.fedoraproject.org/git/hosted/mock 00:43 < Jeff_S> | knurd: yes, I'll check to see if he's sent it through koji yet 00:43 < knurd> | Jeff_S, thx 00:43 < f13> | well, there was some bugs found, so we're fixing those 00:43 < Jeff_S> | f13: can that be accessed via http somehow? 00:43 --- | knurd has changed the topic to: EPEL Meeting -- comps.xml for EPEL -- dglimore 00:43 < f13> | yes 00:44 < Jeff_S> | f13: yeah, Michael mailed the epel list earlier today 00:44 < f13> | git clone http://git.fedoraproject.org/git/hosted/mock 00:44 < f13> | or jsut browse http://git.fedoraproject.org 00:44 < Jeff_S> | f13: yes, the 2nd option is what I meant, thanks 00:44 < knurd> | dgilmore, are you still around? 00:44 < dgilmore> | knurd: yeah sorry 00:45 < knurd> | dgilmore, np 00:45 < knurd> | any progress on teh compx.xml stuff? 00:45 < dgilmore> | knurd: there was a post that epel configs will be in mock 0.7.1 00:45 < smooge> | ok on mock configs.. will EPEL just be focusing on EL4 and EL5? Will it be doing anyting for EL-BRIC? 00:45 < knurd> | smooge, BRIC? 00:45 < dgilmore> | knurd: i started i need to clean up some of the packages not in EPEL 00:46 < Jeff_S> | knurd: the updated EL4 configs look good in the git repo, so they should get pushed w/ the newest mock package 00:46 < smooge> | RHEL-BRIC a 2 year desktop offering that RH is supposed to be doing 00:46 < dgilmore> | smooge: we are only looking at EL4- and 5 00:46 < dgilmore> | we have no current plans to do 2.1 or 3 00:46 < knurd> | smooge, ohh, that one, sorry, i didn#t know that acronym yet 00:46 < f13> | smooge: that's not RHEL 00:46 < dgilmore> | but if there is demand and people to do work there is no reason we cant 00:46 < f13> | rather, that's Red Hat Global Desktop 00:46 < f13> | and no, I don't think RHGD is a good target for EPEL 00:47 < f13> | (yet) 00:47 < smooge> | f13, sorry.. the RH marketing literature put them together 00:47 < f13> | well, RHGD is based on RHEL, but we're not calling it RHEL (: 00:47 < smooge> | so I was confused 00:47 < f13> | tell me about it 00:47 < f13> | *sigh* 00:47 < knurd> | dgilmore, shall we talk about the comps.xml stuff fiurther next week? 00:47 < quaid> | smooge: if you have a pointer to that marketing lit, let me know 00:48 < knurd> | dgilmore, or do you need help with it? 00:48 < smooge> | quaid, sorry it was in the Summit stuff I was reading. They were mentioning about the offerings and I must have mixed/matched in my head like a bad techie 00:48 < quaid> | smooge: no worries, you weren't the only person 00:48 < smooge> | on the mock/build infrastructure, I have a question focused for 3rd party groups 00:48 < smooge> | is this a good time for it or another section? 00:49 < knurd> | please wait until the free discussion section 00:49 --- | knurd has changed the topic to: EPEL Meeting -- bodhi/testing repo/final repo layout/ koji for epel 00:49 < knurd> | did anybody ( dgilmore ? ) talk to mbonnert? 00:49 < dgilmore> | knurd: well part of it is making sure the groups are sane and that we have the packages 00:50 < dgilmore> | Ill check something into cvs soon and then post to the list asking people to look over it 00:50 < knurd> | dgilmore, thx 00:50 < dgilmore> | knurd: i spoke to him 00:50 < dgilmore> | no timeframe yet 00:50 * | dgilmore does not have the cycles to work on it 00:50 < knurd> | k, I suppose we have to live with that for now 00:50 --- | knurd has changed the topic to: EPEL Meeting -- finish the wiki docs and remove the warnings by end of may 00:51 < knurd> | quaid, ? 00:51 < knurd> | lala 00:51 < knurd> | I sometimes think we need to make the status updates mail based 00:51 < quaid> | *sing* 00:51 < knurd> | they take to much time in the meetings 00:51 < quaid> | eek, that was end of May? 00:52 < quaid> | sorry for the delay 00:52 < knurd> | quaid, that once was the plan :-) 00:52 < quaid> | I actually have it up in my to-do list as a high priority, so I should be able to by end of week 00:52 < knurd> | quaid, k, thx 00:52 < quaid> | yeah, well, plan and then the wind blows 00:52 --- | knurd has changed the topic to: EPEL Meeting -- Free discussion around EPEL 00:52 < knurd> | quaid, happens :-) 00:52 < quaid> | question on that is -- we are generally ready to be all announced? 00:52 < knurd> | smooge, shoot 00:53 < nirik> | we need bodhi I think before that... which needs koji. 00:53 < smooge> | Ok is the infrastructure done in a way that can be duplicated by 3rd parties. When I worked for US Government.. we could not directly pull stuff from any non-RH RHN provided repo without rebuilding the packages ourselves 00:54 < smooge> | So basically Ihad a small mock system that rebuilt various extras items that were needed on the RHEL system 00:54 < knurd> | smooge, it should be possible to duplicate it 00:54 < knurd> | smooge, we just use open souce tools for it 00:54 < dgilmore> | smooge: right now its all done in plague 00:54 < nirik> | yeah, everything should be available... 00:54 < Jeff_S> | smooge: yeah, it's all just mock under the hood anyway 00:54 < knurd> | plague (soon koji) with mock and stuff like that 00:55 < quaid> | there however is no guide/how-to yet, right? 00:55 < smooge> | the issues are the build parameters and such that can be fed underneath the cooker 00:55 < mmcgrath> | smooge: I'll put it this way, anyone that can't duplicate it should come talk to us so we can correct that :) 00:55 < dgilmore> | smooge: one of our goals is the same as fedora. use only open source tools 00:55 < knurd> | smooge, it's all in the spec files afaik 00:55 < knurd> | smooge, we don#t use magic "--with foo" stuff 00:55 < dgilmore> | smooge: standard mock settings 00:55 < smooge> | Ok from experience with the RHEL rebuild there were various things that needed to be fed to get packages to 'match' via libraries and such 00:56 < smooge> | I wanted to make sure that if these were done.. it was documented in 'meta-spec' files or some such 00:56 < f13> | smooge: well you're going to run into the same things that centos and oracle run into 00:56 < f13> | the public RHEL binaries aren't the result of every package built against the GA package 00:56 < knurd> | smooge, it should be possible without to much hassle (you know, there are always some bugs on the way....) 00:57 < f13> | so the GA packages were built against packages that may have been older than what is in GA 00:57 < f13> | to extend this... 00:57 < smooge> | f13, I know with the RHEL that is the case.. but RH-EPEL I wanted to know if that was the case or if I needed to tell my Gov replacement he was cool with what was there 00:57 < f13> | if EPEL builds using RHEL binaries, the results may actually be different than EPEL packages built against CentOS binaries. 00:58 < mmcgrath> | smooge: I'm actually writing a RHM article right now about how people can duplicate our environment. 00:58 < f13> | and EPEL builds built against "GA" epel builds may be different than the GA epel builds. 00:59 < f13> | it's just due to how build systems work, well sane ones (although some people will differ). Building a package doesn't automatically make every package that is associated with it rebuild as well, ad infinium. 00:59 < f13> | you're always going to have cases where the "released" package wasn't built with the "released" tree 00:59 < smooge> | Ok thanks.. the guys at LANL will be happy about that.. they need to build stuff against 1.0,2.1,3,4,5 (1.0 being RHL6.2) 00:59 < knurd> | k, anything else? 01:00 * | knurd will close the meeting in 30 01:01 * | knurd will close the meeting in 10 01:01 < knurd> | -- MARK -- Meeting end 01:01 --- | knurd has changed the topic to: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel -- Meetings often get logged -- see schedule in the wiki for next meeting 01:01 < knurd> | thx everyone 01:01 <-- | RemiFedora has quit ("A bient?t...") From fedora at leemhuis.info Wed Jun 13 18:11:45 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 13 Jun 2007 20:11:45 +0200 Subject: No repotags (was: Re: Log from todays meeting) In-Reply-To: <467031CB.7020904@leemhuis.info> References: <467031CB.7020904@leemhuis.info> Message-ID: <46703361.7030001@leemhuis.info> /me again On 13.06.2007 20:04, Thorsten Leemhuis wrote: > 00:00 < knurd> | Meeting ping dgilmore, knurd, mmcgrath, nirik, > stahnma, quaid and everyone interested in EPEL -- EPEL meeting in > #fedora-meeting now! > 00:00 --- | knurd has changed the topic to: EPEL Sig meeting > -- Meeting rules at > http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- > Init process Just want to highlight this: the decision once again (for the third time (?) IIRC) was to not do repotags in EPEL. See the log for all the details; it's the first topic in the meeting and was discussed in the first 40 minutes. CU thl (?) -- and I suppose the EPEL Steering Committee doesn't want to touch the topic again; if you think the EPEL Steering Committee did a bad decisions you are of course free to go to higher Committee's like FESCo or the Fedora Board. But I suppose we all have to find some way to live with this decision now. From ruben at rubenkerkhof.com Wed Jun 13 20:43:57 2007 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Wed, 13 Jun 2007 22:43:57 +0200 Subject: Log from todays meeting In-Reply-To: <467031CB.7020904@leemhuis.info> References: <467031CB.7020904@leemhuis.info> Message-ID: <2DF3542D-EB58-44DF-BB87-2D9A30904288@rubenkerkhof.com> On 13-jun-2007, at 20:04, Thorsten Leemhuis wrote: > 00:42 < knurd> | does anyone know if the EPEL4 configs have been > updated? > 00:42 * | mmcgrath hasn't done it > 00:42 < mmcgrath> | dgilmore: ? > 00:42 < Jeff_S> | I haven't gotten around to figuring out git > yet... > 00:42 < knurd> | s/mirror.centos.org/mirrorlist.centos.org/ > 00:42 < quaid> | Dennis fell asleep > 00:42 < Jeff_S> | knurd: I think that has been fixed, but I'm not > positive > 00:43 < knurd> | Jeff_S, okay, can you keep an eye on it if it > really has been fixed when the new package comes out? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239981 Ruben From cmc at math.hmc.edu Wed Jun 13 22:21:55 2007 From: cmc at math.hmc.edu (C.M. Connelly) Date: Wed, 13 Jun 2007 15:21:55 -0700 Subject: Results of LinuxTag Meetings? In-Reply-To: <20070612050855.GB13280@neu.nirvana> References: <11070.1181598353@vosill.math.hmc.edu> <20070612050855.GB13280@neu.nirvana> Message-ID: <23252.1181773315@vosill.math.hmc.edu> "CMC" == Claire Connelly "AT" == Axel Thimm CMC> From last week's steering committee meeting transcript, CMC> it sounds like the whole repotags issue appears to be CMC> moving ahead, which seems like a good step forward. AT> You think so? After the repotag fiasco I went through a AT> lot of pain to strip them of, so the damage is done. Also AT> the issue showed the real weakness of repotags: It takes AT> just one non-conforming repo to kill them. Well, based on the transcript from today's IRC meeting, I guess I totally misread things. CMC> Can we look forward to better relations between EPEL and CMC> the other repos on other fronts as well? AT> I really hope so, but adding repotags to epel will not AT> help anymore in this - it's too late, repotags are dead AT> and the pain has been inflicted, in fact for me the AT> revival of repotags would imply the same transition pain AT> again. Obviously repotags are dead, but what about other forms of cooperation (if there are any)? AT> We need much higher level manifests like for example AT> http://fedoraproject.org/wiki/PackageMaintainers/RepositoryCollaboration?action=recall&rev=1 I thought this document was brilliant. Alas, it doesn't seem to be catching on. From the sounds of things, EPEL is going in several directions that make it less than useful for our needs, which means that putting any work into it is going to be a waste of my time. Is there another list where the rest of the repository folks (CentOS, AT RPMS, RPM Forge, et al.) are going to get together so those of us giving up on EPEL can keep track of what's happening between them and maybe contribute there? Thanks, Claire *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc at math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From sheltren at cs.ucsb.edu Thu Jun 14 00:19:53 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 13 Jun 2007 20:19:53 -0400 Subject: Results of LinuxTag Meetings? In-Reply-To: <23252.1181773315@vosill.math.hmc.edu> References: <11070.1181598353@vosill.math.hmc.edu> <20070612050855.GB13280@neu.nirvana> <23252.1181773315@vosill.math.hmc.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 13, 2007, at 6:21 PM, C.M. Connelly wrote: > > From the sounds of things, EPEL is going in several directions > that make it less than useful for our needs, Hi Claire, out of curiosity, what are your needs? ie. What would you like to see from an Enterprise package repo? - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGcImpKe7MLJjUbNMRApldAKDOO+Cv7PAsfC66aPOY2hRt5MNe4QCgqEa5 nzSESUhuWv4UVR0IknD6ttc= =8HbX -----END PGP SIGNATURE----- From dennis at ausil.us Thu Jun 14 02:29:50 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 13 Jun 2007 21:29:50 -0500 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <20070613160337.GM8637@humbolt.us.dell.com> References: <466ECC11.9060506@leemhuis.info> <68CE3C5A-D431-4167-A4FC-F73851A73780@cs.ucsb.edu> <20070613160337.GM8637@humbolt.us.dell.com> Message-ID: <200706132129.54953.dennis@ausil.us> Once upon a time Wednesday 13 June 2007, Michael E Brown wrote: > On Wed, Jun 13, 2007 at 11:56:46AM -0400, Jeff Sheltren wrote: > > On Jun 13, 2007, at 11:45 AM, Michael E Brown wrote: > > >>Hi Michael, maybe we can get this decided in the meeting today. I'll > > >>send an updated EL5 mock config to you and the list once we determine > > >>exactly what we need to exclude :) > > > > > >Quickly. I have 0.7.1 ready to go as we hit a bug in 0.7.0. We will be > > >releaseing 0.7.1 sometime today in the next couple hours. > > > > > >Current configs that were posted a couple weeks ago (sans exclude=) > > >are > > >current staged for 0.7.1. > > > > Hi Michael, if you have to push a 0.7.1 today, I'd lean towards > > simply copying the exclude line from a fedora x86_64 mock config and > > re-using that in the EL5 x86_64 config. That "works for me", and > > it's an improvement over the behavior without having an exclude line. > > > > If anyone sees any problem with this, please respond soon so Michael > > can get the update pushed :) > > Will do. > > Let me know if you guys want something different and I'll get it ready > for 0.7.2. the exclude is because some packages require glibc.i386 in the 64 bit chroot to build. gdb gcc and a few others -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mailing-lists at hughesjr.com Thu Jun 14 10:55:35 2007 From: mailing-lists at hughesjr.com (Johnny Hughes) Date: Thu, 14 Jun 2007 05:55:35 -0500 Subject: Mock Configs [Was: Re: Plan for tomorrows EPEL SIG meeting] In-Reply-To: <200706132129.54953.dennis@ausil.us> References: <466ECC11.9060506@leemhuis.info> <68CE3C5A-D431-4167-A4FC-F73851A73780@cs.ucsb.edu> <20070613160337.GM8637@humbolt.us.dell.com> <200706132129.54953.dennis@ausil.us> Message-ID: <1181818535.5096.19.camel@myth.home.local> On Wed, 2007-06-13 at 21:29 -0500, Dennis Gilmore wrote: > Once upon a time Wednesday 13 June 2007, Michael E Brown wrote: > > On Wed, Jun 13, 2007 at 11:56:46AM -0400, Jeff Sheltren wrote: > > > On Jun 13, 2007, at 11:45 AM, Michael E Brown wrote: > > > >>Hi Michael, maybe we can get this decided in the meeting today. I'll > > > >>send an updated EL5 mock config to you and the list once we determine > > > >>exactly what we need to exclude :) > > > > > > > >Quickly. I have 0.7.1 ready to go as we hit a bug in 0.7.0. We will be > > > >releaseing 0.7.1 sometime today in the next couple hours. > > > > > > > >Current configs that were posted a couple weeks ago (sans exclude=) > > > >are > > > >current staged for 0.7.1. > > > > > > Hi Michael, if you have to push a 0.7.1 today, I'd lean towards > > > simply copying the exclude line from a fedora x86_64 mock config and > > > re-using that in the EL5 x86_64 config. That "works for me", and > > > it's an improvement over the behavior without having an exclude line. > > > > > > If anyone sees any problem with this, please respond soon so Michael > > > can get the update pushed :) > > > > Will do. > > > > Let me know if you guys want something different and I'll get it ready > > for 0.7.2. > > the exclude is because some packages require glibc.i386 in the 64 bit chroot > to build. gdb gcc and a few others Actually ... (3) i[3,4,5,6]86 things are potentially required in the x86_64 tree for building x86_64 RPMS: glibc.i386, glibc.i686, glibc-devel.i386. That exclude line does allow for all those to get called in when required, but blocks all other i386 arch content. It might not be "required" for EPEL (if you don't build any packages that need both 32 and 64 bit parts), but it is certainly required for Fedora and CentOS/RHEL base OSes if building in mock. Also, if koji uses the same "Stage" repo functionality as plague (I am not sure how koji does its "generated" repos {or even if it does self generated repos}), you might also need to exclude x86_64 rpms in the i386 mock configs. (In plague the Staged feature {at least in our setup) does one set of repo metadata that contains all i386, x86_64, and all other arches. This means that when solving deps, all arches can be looked at and potentially called out of arch) Again, this may or may not also be how koji does staged repos ... just food for thought. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at fedoraproject.org Thu Jun 14 12:20:04 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 14 Jun 2007 08:20:04 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-14 Message-ID: <20070614122004.76181152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 8 NEW bonnie++-1.03a-6.el5 : Filesystem and disk benchmark & burn-in suite (!) fltk-1.1.8-0.3.r5750.el5 : INVALID rebuild, not published! NEW ntfs-config-1.0-0.3.rc4.el5 : A front-end to Enable/disable NTFS write support NEW OpenEXR-1.4.0a-4.el5 : A high dynamic-range (HDR) image file format NEW openslp-1.2.1-6.el5 : Open implementation of Service Location Protocol V2 php-pear-PhpDocumentor-1.3.2-2.el5 NEW qgit-1.5.6-1.el5 : QGit is a git GUI repository browser yumex-1.9.9-1.0.el5 Packages built and released for Fedora EPEL 4: 2 NEW bonnie++-1.03a-3 : Bonnie++ filesystem and disk benchmark & burn-in suite NEW qgit-1.5.6-1.el4 : QGit is a git GUI repository browser Changes in Fedora EPEL 5: bonnie++-1.03a-6.el5 -------------------- * Thu Sep 14 2006 Warren Togami 0:1.03a-6 - rebuild for FC6 fltk-1.1.8-0.3.r5750.el5 ------------------------ * Sun Apr 29 2007 Rex Dieter 1.1.8-0.3.r5750 - *really* fix --rpath issue, using non-empty patch this time (#238284) ntfs-config-1.0-0.3.rc4.el5 --------------------------- * Tue Jun 12 2007 Xavier Lamien - 1.0-0.3.rc4 - Updated Release. * Sat May 19 2007 Xavier Lamien - 1.0-0.2.beta1 - fixed typo from dist tag. * Wed May 16 2007 Xavier Lamien - 1.0-0.1.beta1 - Updated Release. - Fixed missing mkinstalldir from Makefile. OpenEXR-1.4.0a-4.el5 -------------------- * Sat Oct 28 2006 Rex Dieter 1.4.0a-4 - Obsoletes/Provides: openexr(-devel) (rpmforge compatibility) openslp-1.2.1-6.el5 ------------------- * Tue Aug 29 2006 Rex Dieter 1.2.1-6 - fc6 respin 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 qgit-1.5.6-1.el5 ---------------- * Wed May 23 2007 Dan Horak 1.5.6-1 - update to upstream version 1.5.6 yumex-1.9.9-1.0.el5 ------------------- * Tue Jun 12 2007 Tim Lauridsen - 1.9.9-1.0 - Development Release 1.9.9-1.0 Changes in Fedora EPEL 4: bonnie++-1.03a-3 ---------------- * Mon Dec 20 2004 Ville Skytt? - 0:1.03a-3 - Let rpmbuild take care of stripping binaries. qgit-1.5.6-1.el4 ---------------- * Wed May 23 2007 Dan Horak 1.5.6-1 - update to upstream version 1.5.6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From cmc at math.hmc.edu Sat Jun 16 00:54:39 2007 From: cmc at math.hmc.edu (C.M. Connelly) Date: Fri, 15 Jun 2007 17:54:39 -0700 Subject: Results of LinuxTag Meetings? In-Reply-To: References: <11070.1181598353@vosill.math.hmc.edu> <20070612050855.GB13280@neu.nirvana> <23252.1181773315@vosill.math.hmc.edu> Message-ID: <2721.1181955279@vosill.math.hmc.edu> "CMC" == Claire Connelly "JS" == Jeff Sheltren CMC> From the sounds of things, EPEL is going in several CMC> directions that make it less than useful for our needs, JS> [...] out of curiosity, what are your needs? ie. What JS> would you like to see from an Enterprise package repo? We (the math department at Harvey Mudd College) have around fifty Linux systems, including faculty and staff desktops and laptops; a couple of labs used for research and teaching; and various servers, including a 16-core parallel machine and a small Beowulf cluster. (At the moment, these all run various releases of CentOS, mostly 3, although I'm hoping to get everything moved up to CentOS 5 by the start of the fall semester.) We're also the vanguard department on the Linux front, so some of what we learn feeds back into other departments, academic computing, and so on. Given that RHEL, and, thus, CentOS, is a bit stripped down, I have to obtain and install additional software to provide things that we need (e.g., mathematical software used for teaching or research), things that are really nice to have (e.g., a near-cutting-edge TeX system, nice print dialogs), and things that people insist on having (e.g., the ability to watch DVDs or listen to MP3s on their desktop or laptop machines; Flash; Adobe's awful Reader). Altogether, we have around 300 locally built packages per release, per architecture. Most of this additional software was already packaged by someone, and so I have been able to rebuild packages from Fedora or other repos (thanks, Dag!). Some of it, though, isn't packaged at all, and some of that will probably never show up in some repos because of licensing issues (or the lack of clear licenses, in the case of some of the weirder math software I've dealt with). Because much of this software is already packaged, having a single repo that contained well-packaged versions would be great. Having some level of quality assurance is a huge plus, along with active maintainers and a bug-tracking system. Being able to track stable but recent packages would also be cool. And not having to build or rebuild all these packages myself would, of course, be the best. When I first heard about EPEL, I thought that it sounded like it would be able to supply all the packages I've been rebuilding from Fedora. Dag's and Axel's involvement made me hope that I could supplement EPEL's packages with additional packages from RPMForge, ATrpms, and other repos. I would still have to build or rebuild some things myself, but I hoped that I could eliminate most of that work and be able to concentrate on the software that wasn't packaged (and, for the subset of that material that could be distributed, maybe even get those packages added to Fedora (and thus EPEL) so that the work I put in could be shared by others). But over time it seems like the people running the EPEL SIG are very much committed to the Fedora way of doing things, to the point of not being interested in cooperation with other third-party repos. Decisions are made within a bureaucratic framework that may or may not represent the actual views of any end users.[*] Even more recently, it has become clear that the EPEL folks are interested in maintaining their rebuilt Fedora packages for timeframes similar to or identical to those of the upstream enterprise-Linux distribution, rather than tracking current releases. At this point, I should probably mention that I don't think that there's anything fundamentally wrong with any of those attitudes or decisions. While some of us were hoping that EPEL would be something other than what it is, EPEL can be whatever its participants want it to be. Nothing says that EPEL has to be interoperable with anything else -- they're perfectly entitled to say that their package pool is the most complete and that they don't care about packages outside that pool. Similarly, I can see some use cases where having ``extra'' packages that are maintained for five or seven years without updates would be a desirable thing, although that isn't the best choice for *my* use cases (at least for the workstation side of things). So I'm sorry to see that EPEL won't be a solution for me, and that I will have to look elsewhere, or maybe, at worst, continue to do what I've been doing all along. And I'm sorry that EPEL has decided that cooperating with the existing non-Fedora community is not a goal that they want to pursue, as cooperation could have dramatically reduced the amount of duplicated effort in maintaining separate spec files, build systems, and so forth. On the positive side, EPEL's choices and the discussions that have resulted have probably helped to make some issues clearer to the rest of the folks doing packaging, and those insights might help those folks work better together to provide alternatives to EPEL that might be more suited for other use cases. Finally, if I'm wrong about one or more of my assertions about EPEL's goals, I apologize and expect to be corrected. My take here is based on my readings of the discussions on the mailing list and the transcripts of the steering committee meetings from IRC; there may well be additional information I'm not aware of, and I may be misreading some of the information available to me. Claire [*] As EPEL hasn't quite gotten off the ground, technically I suppose there aren't any end users, yet. But as a potential end-user, I know that the views of the steering committee don't correspond to my own. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Claire Connelly cmc at math.hmc.edu Systems Administrator (909) 621-8754 Department of Mathematics Harvey Mudd College *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From buildsys at fedoraproject.org Sat Jun 16 02:47:16 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 15 Jun 2007 22:47:16 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-15 Message-ID: <20070616024716.0B68E152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 6 NEW lua-5.1.2-1.el5 : Powerful light-weight programming language NEW mdsplib-0.11-3.el5 : METAR Decoder Software Package Library mock-0.7.1-1.el5 postgresql-pgpool-II-1.1.1-1.el5 python-psycopg2-2.0.6-1.el5 NEW python-TurboMail-2.0.4-1.el5 : Multi-threaded mail queue manager for TurboGears applications Packages built and released for Fedora EPEL 4: 6 bonnie++-1.03a-4.el4 NEW lua-5.0.3-1.el4 : A powerful light-weight programming language NEW mdsplib-0.11-3.el4 : METAR Decoder Software Package Library mock-0.7.1-1.el4 postgresql-pgpool-II-1.1.1-1.el4 python-psycopg2-2.0.6-1.el4 Changes in Fedora EPEL 5: lua-5.1.2-1.el5 --------------- * Mon Apr 02 2007 Hans de Goede 5.1.2-1 - New upstream release 5.1.2 - Fix use of rpath on x86_64 mdsplib-0.11-3.el5 ------------------ * Fri Jun 08 2007 Matthias Saou 0.11-3 - Include patch from Hans de Goede to build the lib as shared. mock-0.7.1-1.el5 ---------------- * Wed Jun 13 2007 Michael Brown - 0.7.1-1 - Fix problem with autocache where different users couldnt share same cache - Fix problem creating resolv.conf in rootfs - cleanup perms on rootfs /etc/ * Tue Jun 12 2007 Michael Brown - 0.7.1-1 - add EPEL 5 config files * Mon Jun 11 2007 Clark Williams - 0.7-1 - fixed bind mount problems - added code to allow multiple users to use --no-clean - merged mock-0-6-branch to head and changed version * Thu Jun 07 2007 Clark Williams - 0.6.17-1 - added F-7 config files (BZ#242276) - modified epel configs for changed mirrorlist location (BZ#239981) - added bind mount of /dev (BZ#236428) - added copy of /etc/resolv.conf to chroot (BZ#237663 and BZ#238101) postgresql-pgpool-II-1.1.1-1.el5 -------------------------------- * Fri Jun 15 2007 Devrim Gunduz 1.1.1-1 - Update to 1.1.1 python-psycopg2-2.0.6-1.el5 --------------------------- * Fri Jun 15 2007 - Devrim GUNDUZ 2.0.6-1 - Update to 2.0.6 python-TurboMail-2.0.4-1.el5 ---------------------------- * Fri Jun 15 2007 Luke Macken 2.0.4-1 - Latest upstream release - Add python-devel to BuildRequires Changes in Fedora EPEL 4: bonnie++-1.03a-4.el4 -------------------- * Thu Jun 14 2007 Rob Myers - 0:1.03a-4 - add dist tag - merge spec cleanups lua-5.0.3-1.el4 --------------- * Thu Jun 14 2007 Rob Myers - 5.0.3-1 - upgrade to 5.0.3 - add dist tag and rebuild mdsplib-0.11-3.el4 ------------------ * Fri Jun 08 2007 Matthias Saou 0.11-3 - Include patch from Hans de Goede to build the lib as shared. mock-0.7.1-1.el4 ---------------- * Wed Jun 13 2007 Michael Brown - 0.7.1-1 - Fix problem with autocache where different users couldnt share same cache - Fix problem creating resolv.conf in rootfs - cleanup perms on rootfs /etc/ * Tue Jun 12 2007 Michael Brown - 0.7.1-1 - add EPEL 5 config files * Mon Jun 11 2007 Clark Williams - 0.7-1 - fixed bind mount problems - added code to allow multiple users to use --no-clean - merged mock-0-6-branch to head and changed version * Thu Jun 07 2007 Clark Williams - 0.6.17-1 - added F-7 config files (BZ#242276) - modified epel configs for changed mirrorlist location (BZ#239981) - added bind mount of /dev (BZ#236428) - added copy of /etc/resolv.conf to chroot (BZ#237663 and BZ#238101) postgresql-pgpool-II-1.1.1-1.el4 -------------------------------- * Fri Jun 15 2007 Devrim Gunduz 1.1.1-1 - Update to 1.1.1 python-psycopg2-2.0.6-1.el4 --------------------------- * Fri Jun 15 2007 - Devrim GUNDUZ 2.0.6-1 - Update to 2.0.6 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 Sat Jun 16 15:23:17 2007 From: dag at wieers.com (Dag Wieers) Date: Sat, 16 Jun 2007 17:23:17 +0200 (CEST) Subject: Log from todays meeting In-Reply-To: <467031CB.7020904@leemhuis.info> References: <467031CB.7020904@leemhuis.info> Message-ID: On Wed, 13 Jun 2007, Thorsten Leemhuis wrote: > 00:24 < f13> | there is clearly a need to better identify where > packages came from. repo tags aren't the solution IMHO True, but any solution proposed will not hit RHEL until RHEL6. This is not Fedora where we can fix something for the next release a few months away. This Fedora mentality is really what is wrong with EPEL in my opinion. How many of you people are still using RHEL2.1 or RHEL3 ? RHEL5 is the RHEL3 of 2010. No customer is interested in RHEL5 now if it will be ignored like RHEL3 is today. > 00:24 < smooge> | Ok, could there be a public reasoning statement > about this to make it final. Basically, that EPEL is not meant to work > with other repo's and that mixing/matching repo's is considered too much > of a support burden for EPEL volunteers. Please do. Because that's what we have seen being discussed in the EPEL meetings, but on the list the same viewpoint has not been defended. In fact it has been rebutted many times. > 00:29 < f13> | lancelan: Dag gave reasons why identifying where > a package came from would be handy. repodtags are a hacky way of > accomplising that goal (kind of), but not one that FEdora is willing to > use. We'd rather find a more robust solution to the problem. So we won't have a solution for RHEL2.1, RHEL3, RHEL4 or RHEL5. Because looking at new development is excluding the currently supported distributions. I'm willing to look at any alternative if we have one, but I'm more interested to implement something that we can use today. And repotags have been that solution. f13 was not in the discussion at LinuxTag and apparently did not read some of my mails concerning repotags: http://www.redhat.com/archives/epel-devel-list/2007-May/msg00134.html http://www.redhat.com/archives/epel-devel-list/2007-May/msg00135.html repotags make the package-name unique, which is important for a depsolver to understand what packages belong together. > 00:29 * | notting is confused. we have repo tags already. > %{DISTRIBUTION} and %{PACKAGER} Those do not make a package unique. Welcome to the discussion. A depsolver does not use the information and even if it could be made to do that, we won't have it in RHEL2.1, RHEL3, RHEL4 or RHEL5. Please move any design work to RHEL6 in 2009. We are talking about the past and the presence. > 00:29 < mmcgrath> | smooge: the problem is that in the dag and axel > world, the guys that run the show are also THEE packagers. Thats not > the case in EPEL. I firmly believe that to fix this problem the > packages have to change. And the EPEL SIG just can't do that. No, packages do not have to change. In fact, there is no repotag in the authoritative SPEC file, they are added by the buildsystem. We _have_ discussed that and Thorsten said it was a possibility, welcome to the discussion. > 00:30 < lancelan> | well it seems to me that the fedora camp is > firmly entrenched against repotags ... > 00:30 < mmcgrath> | lancelan: but would you say "the fedora camp is > firmly entrenched against 3rd party repos" ? /me notes that EPEL is a 3rd party repository itself. > 00:31 < mmcgrath> | smooge: but you're binding repo tags and > collaboration and thats a fallacy. repotags are required for RHEL2.1 upto RHEL5 if you want to be able to mix repositories. If EPEL is against mixing repositories, please say so clearly. And then we move back to the fact that different RHEL/CentOS users want different things, like maturity or latest. Which cannot possibly live in the same repository (unless we fix Yum to understand it) and hence we move into a subject that EPEL is desperately ignoring. You'll have to mix repositories at some point because not all users want/need maturity. (whatever that is defined by) > 00:32 < mmcgrath> | repo tags will not fix the clamav problems, dag > working with the clamav packager will. And that has nothing to do with > the SIG. repotags would at least allow to upgrade from one version to another. Without repotags it wouldn't even be possible (as there may not be a distinction from RPM's point of view). I've explained this in our meeting and at least some people understood that repotags could help. It won't fix all problems, but I doubt there is one solution that fixes all problems. > 00:33 < smooge> | mmcgrath, since I have joined it has been > mentioned on both sides as being part of collaboration at some point or > another. > 00:33 < lancelan> | I actually dont like repotags - and agree that > yum/rpm should be able to indicate repo - but they dont ... > 00:33 < smooge> | I would like to see a definition in the end of > what is collaboration and what can be done if anything to meet it > 00:33 < mmcgrath> | smooge: but collaboration does not mean "do what > the other guy says" Please come up with a workable proposal then ? Don't just refuse the idea without even understanding what I have been explaining. And please understand that any workable proposal cannot touch RPM or Yum since we cannot replace those in RHEL5 and older. > 00:34 < lancelan> | unless of course you specifically ask > 00:34 < f13> | lancelan: they can, but it requires more query > flags. Now whether or not those query flags are made more prominent, or... Please, do not talk about future development. We've been there, no solution for the past and present. > 00:35 < knurd> | does anybody really think opinions will cahnge if > we discuss this further? > 00:35 < wwoods> | rpm -qi isn't that hard Oh, it makes a difference between replying with a solution straight away and having to ask for additional information. On IRC that often means, a solution or no solution. Besides, as soon as we have clamav packages with exactly the same EVNR, be sure that rpm -qi may not even give proper information, because clamav-0.90.2-3 and clamav-devel-0.90.2-3 could be from 2 DIFFERENT repositories. Querying one or the other may confuse you even more. > 00:35 < f13> | smooge: working with 3rd party repos is going to > be pretty hard in any case. THe EPEL project cannot reference nor link > to these 3rd party repos for software, as those repos host illegal > content. SO we have to package everything we want in EPEL proper, which > immediatly creates 'conflicts' with these 3rd party repos. So EPEL is a 3rd party repository that does not work well with other 3rd party repositories ? > 00:35 < f13> | smooge: if these repos would just drop the > illegal content then it would be much easier. What is illegal to you, is not illegal to me. I do not live in the US and I do not want to be bound to US law. Other countries may even be stricter than US law. It's not only problematic that US is lobbying for stricter laws all around the world, but using this forum and repositories to force US law on the rest of the world I find distasteful. > 00:38 < f13> | Jeff_S: the people that are complaining loudly > about 'interoperability' with 3rd parties are the ones that are carrying > things we can't reference. So, we finally found an excuse for no colaboration. At least that means I wil have more time for not trying. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From mmcgrath at redhat.com Sat Jun 16 15:36:17 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Sat, 16 Jun 2007 10:36:17 -0500 Subject: Log from todays meeting In-Reply-To: References: <467031CB.7020904@leemhuis.info> Message-ID: <46740371.7080109@redhat.com> Dag Wieers wrote: > So, we finally found an excuse for no colaboration. At least that means I > wil have more time for not trying. > Just curious, do atrpms, RPMForge, Centos Extras and KBS conflict? If not how do you guys keep them from conflicting? Is there a neutral mailing list we can create somewhere? -Mike From dag at wieers.com Sat Jun 16 15:50:11 2007 From: dag at wieers.com (Dag Wieers) Date: Sat, 16 Jun 2007 17:50:11 +0200 (CEST) Subject: Log from todays meeting In-Reply-To: <46740371.7080109@redhat.com> References: <467031CB.7020904@leemhuis.info> <46740371.7080109@redhat.com> Message-ID: On Sat, 16 Jun 2007, Mike McGrath wrote: > Dag Wieers wrote: > > So, we finally found an excuse for no colaboration. At least that means I > > wil have more time for not trying. > > Just curious, do atrpms, RPMForge, Centos Extras and KBS conflict? If not how > do you guys keep them from conflicting? > > Is there a neutral mailing list we can create somewhere? People use them together and report any problems. But I think what helps the most is that we carefully look what others have implemented before we duplicate any effort. CentOS does not introduce anything that is not compatible with RPMforge. Karan excludes everything from Extras that causes incompatibilities. I guess that's because people care about allowing users to enable their repository and incompatibility with someone else's repository is one way of driving users away. What's more, I often look at Fedora packages to know what I have to Obsolete/Provide to make those package somewhat compatible. But the effort should not be completely wasted on us IMO. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From buildsys at fedoraproject.org Sat Jun 16 16:33:51 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 16 Jun 2007 12:33:51 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-16 Message-ID: <20070616163351.5D9C9152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 3 NEW kodos-2.4.9-4.el5 : Visual regular expression editor NEW postgresql-pgpoolAdmin-1.0.0-6.el5 : PgpoolAdmin - web-based pgpool administration redet-doc-8.22-1.el5 Packages built and released for Fedora EPEL 4: 2 NEW postgresql-pgpoolAdmin-1.0.0-6.el4 : PgpoolAdmin - web-based pgpool administration redet-doc-8.22-1.el4 Changes in Fedora EPEL 5: kodos-2.4.9-4.el5 ----------------- * Sat Jun 16 2007 Konstantin Ryabitsev - 2.4.9-4 - Remove leftover useless Requires. * Sun Jun 10 2007 Konstantin Ryabitsev - 2.4.9-3 - Don't add X-Fedora to desktop-file-install - Don't run update-desktop-database, since there's no MimeType to worry about postgresql-pgpoolAdmin-1.0.0-6.el5 ---------------------------------- * Sat Jun 02 2007 Devrim Gunduz 1.0.0-6 - Fixes for bugzilla review #229323 redet-doc-8.22-1.el5 -------------------- * Sat Jun 16 2007 Nigel Jones 8.22-1 - Bring redet-doc up to par with redet - Patch0 (Makefile fixes) has been removed, personally I have no idea why it was even there, I wasn't using make! Changes in Fedora EPEL 4: postgresql-pgpoolAdmin-1.0.0-6.el4 ---------------------------------- * Sat Jun 02 2007 Devrim Gunduz 1.0.0-6 - Fixes for bugzilla review #229323 redet-doc-8.22-1.el4 -------------------- * Sat Jun 16 2007 Nigel Jones 8.22-1 - Bring redet-doc up to par with redet - Patch0 (Makefile fixes) has been removed, personally I have no idea why it was even there, I wasn't using make! For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From wolfy at nobugconsulting.ro Sat Jun 16 18:00:02 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 16 Jun 2007 21:00:02 +0300 Subject: Log from todays meeting In-Reply-To: <46740371.7080109@redhat.com> References: <467031CB.7020904@leemhuis.info> <46740371.7080109@redhat.com> Message-ID: <46742522.8080504@nobugconsulting.ro> On 06/16/2007 06:36 PM, Mike McGrath wrote: > Dag Wieers wrote: >> So, we finally found an excuse for no colaboration. At least that >> means I wil have more time for not trying. >> > > Just curious, do atrpms, RPMForge, Centos Extras and KBS conflict? For what it's worth, here is the situation of an admin who uses those 4 repos for a couple of years on around 200 of RH 7.x, C3, C4 machines (plus a dozen fedora>=FC1 (yes, I do have functional RH 7.2 and FC1 in production)). All of those systems are in an enterprise environment (as opposed to home/playground use), but most of the desktops have mp3/mplayer/pdf viewer/other goodies which make user life easier installed - never ever had any major issues with packages from rpmforge, centos extras and kbs. they have always played excellent together. As far as I remember I had maybe 2 or 3 conflicts during the last 5 years. Maybe the fact that I do not blindly install packages helps, but I am more then satisfied with what dag/thias/dries/karan have supplied. I will never be able to express my gratitude for them but I hope that somehow somewhere they know about it. - I've also used atrpms a couple of times and it also played nice. Centos recommends being cautious when using it and since it ships newer versions of Base stuff I think it is normal to be cautious in this case. But I am grateful that Axel saved my time suppling openswan and acl enabled kernels, newer versions of lm-sensors (for chipsets not supported by the standard kernel stack) or wifi support for my laptop which runs Centos 3 (and cannot run anything newer due to the EDA tools which are not supported on a newer OS) From Axel.Thimm at ATrpms.net Sun Jun 17 00:52:24 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 17 Jun 2007 02:52:24 +0200 Subject: Log from todays meeting In-Reply-To: <46740371.7080109@redhat.com> References: <467031CB.7020904@leemhuis.info> <46740371.7080109@redhat.com> Message-ID: <20070617005224.GD13629@neu.nirvana> On Sat, Jun 16, 2007 at 10:36:17AM -0500, Mike McGrath wrote: > Dag Wieers wrote: > >So, we finally found an excuse for no colaboration. At least that means I > >wil have more time for not trying. > > > > Just curious, do atrpms, RPMForge, Centos Extras and KBS conflict? If > not how do you guys keep them from conflicting? I usually check what exists (it's easy when you have a local mirror of everything) and divert any request to the matching repo. It's not something that has been proceduralized, but has grown as de facto behaviour over the course of the last years. Tim's recent manifesto intended for the intrarelation of all 3rd party repos posted on this list and transfered to the wiki would had been the first formalization proposal of how 3rd party repos work together. I really liked it and will pick it up in some way or another. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sun Jun 17 00:54:50 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 17 Jun 2007 02:54:50 +0200 Subject: Log from todays meeting In-Reply-To: <46742522.8080504@nobugconsulting.ro> References: <467031CB.7020904@leemhuis.info> <46740371.7080109@redhat.com> <46742522.8080504@nobugconsulting.ro> Message-ID: <20070617005450.GE13629@neu.nirvana> On Sat, Jun 16, 2007 at 09:00:02PM +0300, Manuel Wolfshant wrote: > - I've also used atrpms a couple of times and it also played nice. > Centos recommends being cautious when using it and since it ships newer > versions of Base stuff I think it is normal to be cautious in this case. > But I am grateful that Axel saved my time suppling openswan and acl > enabled kernels, newer versions of lm-sensors (for chipsets not > supported by the standard kernel stack) or wifi support for my laptop > which runs Centos 3 (and cannot run anything newer due to the EDA tools > which are not supported on a newer OS) Thanks Manuel! ATrpms gets hit that often and that hard for offering replacement packages that a kind word in retaliation justifies the effort spent on doing so. ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From smooge at gmail.com Mon Jun 18 17:09:01 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 18 Jun 2007 11:09:01 -0600 Subject: Log from todays meeting In-Reply-To: References: <467031CB.7020904@leemhuis.info> Message-ID: <80d7e4090706181009y69e23069mf938e23695deb713@mail.gmail.com> On 6/16/07, Dag Wieers wrote: > > 00:35 < f13> | smooge: if these repos would just drop the > > illegal content then it would be much easier. > > What is illegal to you, is not illegal to me. I do not live in the US and > I do not want to be bound to US law. Other countries may even be stricter > than US law. > > It's not only problematic that US is lobbying for stricter laws all around > the world, but using this forum and repositories to force US law on the > rest of the world I find distasteful. > Jesse just needs to take some classes in talking from his mouth versus other parts of his body. People employed directly or in-directly by a US company have to remember that their company is subject to US laws. Any work that they do that could be seen as Red Hat promoting the breaking of those laws can be enforced against the company. And unless you are a lawyer.. its hard to know when you are using your first amendment right as an individual or as a paid employee of XYZ corp. And yes I think it sucks, the laws suck, and the US acting like an Empire when ti cant pay its light bills sucks. -- 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 kwade at redhat.com Mon Jun 18 18:12:07 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 18 Jun 2007 11:12:07 -0700 Subject: Log from todays meeting In-Reply-To: References: <467031CB.7020904@leemhuis.info> <46740371.7080109@redhat.com> Message-ID: <1182190327.21966.243.camel@erato.phig.org> On Sat, 2007-06-16 at 17:50 +0200, Dag Wieers wrote: > I guess that's because people care about allowing users to enable their > repository and incompatibility with someone else's repository is one way > of driving users away. So true ... I see two potentially shining lights we can look to help illuminate our way, with the goal of helping our users: 1. Formalizing the third-party repo agreement (thanks Tim); and, yes, I think we all agree that EPEL is another third-party repo. 2. From that, figure out a way to send people to other repos for packages in a (somewhat) automated, culturally acceptable, process-integrated, and legal-for-those-employed-by-US-corporations. Fedora already is clear that, for example, we can refer people to fedoraforum.org as "a place to get answers" but *not* with a direct URL to how to install an illegal-in-the-US[1] package. So, similarly, EPEL could: * Make it easier to find compatible, other-repo packages * Agree not to package something that is already in another repo, instead referring to that repo and package in particular (cf. fedoraforum.org and pointing at not-illegal solutions there) * Similarly, where a package is *not* in EPEL because it is part of a RHEL layered product, we could still point people to where those packages are in other repos. It may not be considered "kind" to Red Hat, but that would be under the same bogus argument that people should pretend CentOS doesn't exist. The situation is going to arise where EPEL doesn't have a package for this reason, and we cannot just shrug our shoulders and point at a RHEL sale page. * Work with all repos on improvements to rpmfind.net, to make it easier for users to: - Find compatible packages - Identify when different repos are likely to conflict - Figure out the origin of a package they have installed This would allow us to use a common troubleshooting methodology for all of our users. I understand what Dag is saying about removing steps (i.e., having a repotag answers a common question without asking it), and my idea here is the opposite -- add a common step for all users, but one that answers multiple questions while troubleshooting. * Help define and advertise a common "meaning" for each repo -- "This one is steady, older packages; this one provides the latest possible packages; etc." Make it more obvious to users why they would choose one repo over another for realistic reasons. - Karsten [1] I'll encourage people to use nomenclature like this, if it helps, but I think we can agree that when Red Hat associates say "illegal" we are referring to what Smooge said -- trying to keep from getting our employer in hot water over US laws. -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Mon Jun 18 18:42:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 19 Jun 2007 00:12:16 +0530 Subject: Log from todays meeting In-Reply-To: <1182190327.21966.243.camel@erato.phig.org> References: <467031CB.7020904@leemhuis.info> <46740371.7080109@redhat.com> <1182190327.21966.243.camel@erato.phig.org> Message-ID: <4676D208.5010807@fedoraproject.org> Karsten Wade wrote: > * Agree not to package something that is already in another repo, > instead referring to that repo and package in particular (cf. > fedoraforum.org and pointing at not-illegal solutions there) Any package that is already in a third party repository? That would essentially force users to mix and match many repositories which I don't think we should be doing. If it is just for packages we don't for legal reasons then that's doable. Rahul From rdieter at math.unl.edu Mon Jun 18 18:21:53 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 18 Jun 2007 13:21:53 -0500 Subject: Log from todays meeting References: <467031CB.7020904@leemhuis.info> <46740371.7080109@redhat.com> <1182190327.21966.243.camel@erato.phig.org> Message-ID: Karsten Wade wrote: > So, similarly, EPEL could: ... > * Agree not to package something that is already in another repo, > instead referring to that repo and package in particular (cf. > fedoraforum.org and pointing at not-illegal solutions there) Currently not possible/practical in many cases, since by policy, epel packages current can't (Build)Requires anything outside of epel. -- Rex From kwade at redhat.com Tue Jun 19 02:35:33 2007 From: kwade at redhat.com (Karsten Wade) Date: Mon, 18 Jun 2007 19:35:33 -0700 Subject: Log from todays meeting In-Reply-To: References: <467031CB.7020904@leemhuis.info> <46740371.7080109@redhat.com> <1182190327.21966.243.camel@erato.phig.org> Message-ID: <1182220534.21966.287.camel@erato.phig.org> On Mon, 2007-06-18 at 13:21 -0500, Rex Dieter wrote: > Karsten Wade wrote: > > > > So, similarly, EPEL could: > ... > > * Agree not to package something that is already in another repo, > > instead referring to that repo and package in particular (cf. > > fedoraforum.org and pointing at not-illegal solutions there) > > Currently not possible/practical in many cases, since by policy, epel > packages current can't (Build)Requires anything outside of epel. Aren't there a sub-set of packages that are either: * Likely to have multiple versions in use (stable => edge), or * Stand-alone ? - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Tue Jun 19 11:55:07 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 19 Jun 2007 13:55:07 +0200 Subject: EPEL report week 24, 2007 Message-ID: <4677C41B.3060209@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week24 = Weekly EPEL Summary = Week 24/2007 == Most important happenings == The EPEL Steering Committee discussed the repotags issue once again and once again voted to not use repotags for EPEL. Some discussions started after that; see https://www.redhat.com/archives/epel-devel-list/2007-June/msg00041.html for their start. == EPEL SIG Meeting == === Attending === >From the Steering Committee: * knurd (ThorstenLeemhuis) (partly) * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * dgilmore (DennisGilmore) * stahnma (MichaelStahnke) * quiad (KarstenWade) (had fun at the dentist) Missing from the Steering Committee: nobody Others that participated the meeting: Jeff_S, smooge, notting, lancelan, f13, spot, === Summary === * lots of discussion around repotags again; see the full log for details; four votes against repotags, two people are undecided; so once again the decision is "no repotags" * EPEL mock configs in Fedora's mock package -- should be part of the latest release * comps.xml for EPEL -- dgilmore is working on it; he'll check something into cvs soon and then post to the list asking people to look over it * finish the wiki docs and remove the warnings by end of may ; quaid, puts in up on his to-do list as a high priority == Stats == === General === Number of EPEL Contributors 90 We welcome 4 new contributors: dan_AT_danny.cz, jafo-redhat_AT_tummy.com, jafo_AT_tummy.com, mmahut_AT_redhat.com, rob.myers_AT_gtri.gatech.edu, ville.skytta_AT_iki.fi === EPEL 5 === Number of source packages: 359 Number of binary packages: 578 There are 48 new Packages: * akode | Audio-decoding framework * bonnie++ | Filesystem and disk benchmark & burn-in suite * digitemp | Dallas Semiconductor 1-wire device reading console application * exiv2 | Exif and Iptc metadata manipulation library * factory | C++ class library for multivariate polynomial data * fltk | C++ user interface toolkit * gc | C++ Garbage Collector * glump | A small web application to glue files from multiple sources * kannel | WAP and SMS gateway * kflickr | Standalone Flickr Uploader for KDE * kodos | Visual regular expression editor * libfac | An extension to Singular-factory * libksba | X.509 library * lua | Powerful light-weight programming language * Macaulay2 | System for algebraic geometry and commutative algebra * maxima | Symbolic Computation Program * mdsplib | METAR Decoder Software Package Library * nikto | Web server scanner * ntfs-config | A front-end to Enable/disable NTFS write support * ntl | High-performance algorithms for vectors, matrices, and polynomials * OpenEXR | A high dynamic-range (HDR) image file format * openslp | Open implementation of Service Location Protocol V2 * perl-Convert-BinHex | Macintosh BinHex extractor library for Perl * perl-GDGraph | Graph generation package for Perl * perl-GD | Perl interface to the GD graphics library * perl-GDTextUtil | Text utilities for use with GD * perl-IO-stringy | I/O on in-core objects like strings and arrays for Perl * perl-MIME-tools | Modules for parsing and creating MIME entities in Perl * php-pear-PhpDocumentor | The complete documentation solution for PHP * postgresql-pgpoolAdmin | PgpoolAdmin - web-based pgpool administration * python-genshi | Toolkit for stream-based generation of output for the web * python-imaging | Python's own image processing library * python-IPy | Python module for handling IPv4 and IPv6 Addresses and Networks * python-kid | Kid - A simple and pythonic XML template language * python-pgsql | Enhanced python interface to PostgreSQL * qgit | QGit is a git GUI repository browser * redet-doc | Documentation for redet * redet | Regular expression development and execution tool * sbcl | Steel Bank Common Lisp * SDL_image | Image loading library for SDL * SDL_mixer | Simple DirectMedia Layer - Sample Mixer Library * SDL_net | SDL portable network library * SDL_ttf | Simple DirectMedia Layer TrueType Font library * xar | The eXtensible ARchiver * xdg-utils | Basic desktop integration functions * xforms | XForms toolkit library === EPEL 4 === Number of source packages: 230 Number of binary packages: 423 There are 19 new Packages: * bonnie++ | Filesystem and disk benchmark & burn-in suite * digitemp | Dallas Semiconductor 1-wire device reading console application * lua | A powerful light-weight programming language * mdsplib | METAR Decoder Software Package Library * mock | Builds packages inside chroots * nikto | Web server scanner * perl-Convert-BinHex | Macintosh BinHex extractor library for Perl * perl-IO-stringy | I/O on in-core objects like strings and arrays for Perl * postgresql-pgpoolAdmin | PgpoolAdmin - web-based pgpool administration * python-IPy | Python module for handling IPv4 and IPv6 Addresses and Networks * python-pgsql | Enhanced python interface to PostgreSQL * qgit | QGit is a git GUI repository browser * redet-doc | Documentation for redet * redet | Regular expression development and execution tool * SDL_image | Image loading library for SDL * SDL_mixer | Simple DirectMedia Layer - Sample Mixer Library * SDL_net | SDL portable network library * SDL_ttf | Simple DirectMedia Layer TrueType Font library * xar | The eXtensible ARchiver ---- ["CategoryEPELReports"] From fedora at leemhuis.info Tue Jun 19 12:45:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 19 Jun 2007 14:45:52 +0200 Subject: Proposal for final repolayout Message-ID: <4677D000.30005@leemhuis.info> Hi, seems we need koji modification to use bodhi, which likely itself might need some adjustments for proper EPEL support as well. Both things will take time to get realized as it seems other work is higher on peoples todo list atm. So I'd say EPEL should for the near future plan to continue to use plague together with the old Fedora Extras push scripts until we can switch to koji and bodhi; otherwise it might take a long time until we are ready to announce EPEL officially, which I'd like to avoid We just should make sure the repo layout is sane for the near future and can be used with bodihi later as well (Luke, that's why you are in the CC of this mail; if there is anything that would be hard to realize in bodihi let us know please). I'd like to propose round about this layout below http://redhat.download.fedoraproject.org/pub/epel/ stable/ 4/ -> 4.(current_version()) 4.1/ ... 4.5/ 5/ -> 5.(current_version()) 5.1/ ... testing/ 4/ 5/ rolling/ 4/ -> 4.(current_version()) 4.1/ ... 5/ -> 5.(current_version()) 5.1/ ... We currently have symbolic links from "4{AS,WS,ES}" to "4" and "5{Client,Server}" to "5" on the server as well; they should be there in the future as well, but I left them out of this scheme to not make things even more complicated to understand. Please ignore the "rolling" stuff as well; it seems some people would like to have a more "Fedora Extras" like EPEL with a bold update policy (always latest and greatest). I'd like to leave the path for this open in the long term, that why I'd say we should put the current EPEL stuff below "stable". How to realize the layout: have two different plague-targets per release; the default target is "testing/(release())"; that repo becomes the stable release automatically when RH ships a new quarterly update. If you want to get something into the stable repo for the current release use a special build target, from which the extras-push-scripts push into the proper dir directly. Comments? CU thl From buildsys at fedoraproject.org Wed Jun 20 04:57:36 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 20 Jun 2007 00:57:36 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-20 Message-ID: <20070620045736.BD46C152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 9 denyhosts-2.6-5.el5 NEW mksh-29f-1.el5 : MirBSD enhanced version of the Korn Shell NEW mod_security-2.1.1-1.el5 : Security module for the Apache HTTP Server perl-Net-Server-0.96-2.el5 NEW pfqueue-0.5.6-4.el5 : Queue manager for the Postfix/Exim Mail Transport Agents NEW postgresql-table_log-0.4.4-2.el5 : Log data changes in a PostgreSQL table qucs-0.0.12-2.el5 NEW tcptraceroute-1.5-0.1.beta7.el5 : A traceroute implementation using TCP packets wine-0.9.39-1.el5 Packages built and released for Fedora EPEL 4: 6 denyhosts-2.6-5.el4 NEW mksh-29f-1.el4 : MirBSD enhanced version of the Korn Shell perl-Net-Server-0.96-2.el4 NEW pfqueue-0.5.6-4.el4 : Queue manager for the Postfix/Exim Mail Transport Agents qucs-0.0.12-2.el4 wine-0.9.39-1.el4 Changes in Fedora EPEL 5: denyhosts-2.6-5.el5 ------------------- * Tue Jun 19 2007 Jason L Tibbitts III - 2.6-5 - Apply yet another regex.py fix from Jonathan Underwood to fix bug 244943. mksh-29f-1.el5 -------------- * Sun Jun 03 2007 Robert Scheck 29f-1 - Upgrade to 29f - Initial spec file for Fedora and Red Hat Enterprise Linux mod_security-2.1.1-1.el5 ------------------------ * Tue Jun 19 2007 Michael Fleming 2.1.1-1 - New upstream release - Drop ASCIIZ rule (fixed upstream) - Re-enable protocol violation/anomalies rules now that REQUEST_FILENAME is fixed upstream. perl-Net-Server-0.96-2.el5 -------------------------- * Mon Jun 18 2007 Kevin Fenzi - 0.96-2 - Only build using perl-IO-Multiplex in EL-5 pfqueue-0.5.6-4.el5 ------------------- * Mon Jun 18 2007 Michael Fleming 0.5.6-4 - Initial import into Fedora / EPEL - Fix Source URL * Wed Jun 13 2007 Michael Fleming 0.5.6-3.mf - Remove the rpath from binaries @ build time. postgresql-table_log-0.4.4-2.el5 -------------------------------- * Sun Jun 17 2007 - Devrim GUNDUZ 0.4.4-2 - Added Requires, per bugzilla review #244536 (Thanks Ruben) - Renamed README file, per bugzilla review #244536 * Sat Jun 16 2007 - Devrim GUNDUZ 0.4.4-1 - Initial RPM packaging for Fedora qucs-0.0.12-2.el5 ----------------- * Sun Jun 17 2007 Eric Tanguy - 0.0.12-2 - Add perl and iverilog as require * Sun Jun 17 2007 Eric Tanguy - 0.0.12-1 - Update to 0.0.12 * Sat May 05 2007 Eric Tanguy - 0.0.11-2 - Rebuild tcptraceroute-1.5-0.1.beta7.el5 ------------------------------- * Fri May 04 2007 Sindre Pedersen Bj?rdal - 1.5-0.1.beta7 - Initial build wine-0.9.39-1.el5 ----------------- * Sun Jun 17 2007 Andreas Bierfert - 0.9.39-1 - version upgrade - convert to utf8 (#244046) - fix mime entry (#243511) Changes in Fedora EPEL 4: denyhosts-2.6-5.el4 ------------------- * Tue Jun 19 2007 Jason L Tibbitts III - 2.6-5 - Apply yet another regex.py fix from Jonathan Underwood to fix bug 244943. mksh-29f-1.el4 -------------- * Sun Jun 03 2007 Robert Scheck 29f-1 - Upgrade to 29f - Initial spec file for Fedora and Red Hat Enterprise Linux perl-Net-Server-0.96-2.el4 -------------------------- * Mon Jun 18 2007 Kevin Fenzi - 0.96-2 - Only build using perl-IO-Multiplex in EL-5 pfqueue-0.5.6-4.el4 ------------------- * Mon Jun 18 2007 Michael Fleming 0.5.6-4 - Initial import into Fedora / EPEL - Fix Source URL * Wed Jun 13 2007 Michael Fleming 0.5.6-3.mf - Remove the rpath from binaries @ build time. qucs-0.0.12-2.el4 ----------------- * Sun Jun 17 2007 Eric Tanguy - 0.0.12-2 - Add perl and iverilog as require * Sun Jun 17 2007 Eric Tanguy - 0.0.12-1 - Update to 0.0.12 * Sat May 05 2007 Eric Tanguy - 0.0.11-2 - Rebuild wine-0.9.39-1.el4 ----------------- * Sun Jun 17 2007 Andreas Bierfert - 0.9.39-1 - version upgrade - convert to utf8 (#244046) - fix mime entry (#243511) 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 Jun 20 18:01:15 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 20 Jun 2007 12:01:15 -0600 Subject: log from 2007-06-20 meeting Message-ID: <20070620120115.4d4e04da@ghistelwchlohm.scrye.com> Jun 20 11:00:32 --- mmcgrath has changed the topic to: EPEL meeting - http://fedoraproject.org/wiki/EPEL/Schedule Jun 20 11:00:40 --> [0x100] (n=bjohnson at c-67-172-144-52.hsd1.co.comcast.net) has joined #fedora-meeting Jun 20 11:00:49 wwoods: :) Jun 20 11:00:59 Ping epel contributors, who's here? Jun 20 11:01:13 * [0x100] listening Jun 20 11:01:15 dgilmore, nirik, stahnma, quaid: ping Jun 20 11:01:33 * nirik is here... Jun 20 11:01:38 nirik: yo Jun 20 11:01:41 oi Jun 20 11:01:46 sup mmcgrath Jun 20 11:01:50 --> smooge (n=smooge at pdpc/supporter/bronze/smooge) has joined #fedora-meeting Jun 20 11:01:54 smooge: yooooo Jun 20 11:02:11 Anyone else want to MC this meeting? If not I'll do it. Jun 20 11:02:21 I'm in the peanut gallary today Jun 20 11:02:22 <- here too Jun 20 11:02:32 morbidly curious as to if repotags will be brought up again this week. Jun 20 11:02:49 Alllright. Jun 20 11:02:57 --- mmcgrath has changed the topic to: Finish the wiki - quaid Jun 20 11:03:01 quaid: Whats the word bird? Jun 20 11:03:40 oh, well Jun 20 11:03:54 I didn't finish by end of last week, did I? Jun 20 11:04:11 * mmcgrath doesn't remember what's left Jun 20 11:04:12 so .. Jun 20 11:04:21 I think all of you have done a good job of making the content ... full and rich Jun 20 11:04:37 so it's a few hours of edits left Jun 20 11:05:03 I'll be able to do an hour today, for sure, so again ... should be done by the end of the week :) Jun 20 11:05:16 :) k. We'll be looking forward to that. Jun 20 11:05:23 is it a gating factor right now for announcements and such? Jun 20 11:05:33 * quaid sometimes has to respond only to what is on fire or about to be Jun 20 11:05:36 yeah, just to finally say "we're here" Jun 20 11:05:40 ok Jun 20 11:05:49 it will help my other causes Jun 20 11:05:57 such as getting RH marketing attention Jun 20 11:06:02 if it is all announced and here and such Jun 20 11:06:03 Jun 20 11:06:08 ok, then Jun 20 11:06:14 don't we need to have updates/buildsys solved before we can formally announce? Jun 20 11:06:19 quaid: anything else on that topic? Jun 20 11:06:28 nirik: not sure. Thats part of the next topic though. Jun 20 11:06:31 related is the communications plan, so I'll work them together Jun 20 11:06:36 * rdieter sits in the rabble seats... Jun 20 11:06:52 so, one outcome is to ask everyone by EOWeek to comment on that plan Jun 20 11:06:56 eof Jun 20 11:06:57 * _blah_ hands rdieter a frosty beverage Jun 20 11:07:00 :) Jun 20 11:07:12 * quaid could use more hot coffee,himself Jun 20 11:07:15 --- mmcgrath has changed the topic to: Repo-layout - UNASSIGNED Jun 20 11:07:32 lmacken: ping? Jun 20 11:07:54 mmcgrath: pong Jun 20 11:08:18 i looked at the proposed layout.. looks fine to me Jun 20 11:08:20 so we're talking about the repo layout and part of that is the updates system. Jun 20 11:08:31 might require some bodhi hackery.... but shouldn't be too bad Jun 20 11:08:32 dgilmore: how different is the proposed layout from what we currently have there? Jun 20 11:09:02 lmacken: my concern is what else you have on your plate for bodhi, do you know when we might be able to start using bodhi? Jun 20 11:09:19 mmcgrath: isn't EPEL still blocking on koji support ? Jun 20 11:09:30 lmacken: it depends on how you look at it. Jun 20 11:09:37 * mmcgrath has been using EPEL for a couple of months. Jun 20 11:09:48 mmcgrath: quite a bit Jun 20 11:09:57 I'm worried that stable/rolling will confuse people (It does sort of confuse me) Jun 20 11:10:10 well, once koji knows about EPEL, adding support to bodhi will take a few minutes Jun 20 11:10:13 lmacken: to do what we really want we need koji and bodhi thats not going to happen for awhile Jun 20 11:10:20 hmm.. Jun 20 11:10:45 dgilmore: yeah, thats my concern too. I think development on Fedora will keep lmacken and mbonnet busy for a while. Jun 20 11:10:53 hate to re-open old discussions, but could we look at just building with Centos to get past the block on moving to koji? Jun 20 11:10:56 the work in koji is low priority right now Jun 20 11:11:15 so the question is... what do we do about it? We have people, we have the source, we even have a current working system. Do we wait or announce? Jun 20 11:11:15 nirik: +1 (stable vs rollilng = needless confusion) Jun 20 11:11:33 mmcgrath: current scripts can't deal with testing. Jun 20 11:11:59 I'm pretty sure bodhi+koji is months away if no one in our group does the work and submits a patch. Jun 20 11:12:10 announce: +1, just do it. Release early, release often = good. Jun 20 11:12:19 if someone could mod the current push scripts to handle pushing to updates I think we could move forward with plague... Jun 20 11:12:41 also we need to make sure we have broken deps and evr checking in place to block broken packages. Jun 20 11:12:57 nirik: we really cant do that right now Jun 20 11:13:14 since we cant expose RHEL binaries to check against Jun 20 11:13:38 ugh. ;( Jun 20 11:13:46 <_blah_> mmcgrath: what modifications need to be made to koji? Jun 20 11:13:58 <-- Karl_le_Rouge has quit (Connection timed out) Jun 20 11:14:02 _blah_: I'm not quite sure, you'd have to work with mbonnet Jun 20 11:14:04 mbonnet: ping? Jun 20 11:14:08 mbonnet__: ping? Jun 20 11:14:11 _blah_: we need to be able to mark binaries as private for security embrago, RHEL etc Jun 20 11:14:13 mmcgrath: yo Jun 20 11:14:33 mbonnet: we're talking about the private binaries and the RHEL rpm's. Exactly what sort of work would be involved with that? Jun 20 11:14:37 make them not show up in the web interface and not be accesable via the web period Jun 20 11:15:04 <_blah_> dgilmore: would it be okay for users to see that an rpm exists, but not be able to download it? Jun 20 11:15:11 dgilmore: but still have them exposed to the builders, right? Jun 20 11:15:21 mmcgrath: yes Jun 20 11:15:33 * nirik thinks just using centos would be much easier and open, but oh well. ;( Jun 20 11:15:33 _blah_: they cant see it exists Jun 20 11:15:49 mmcgrath: unless we want to stop making koji.fp.o/packages/ web accessible, it's a non-trivial amount of work Jun 20 11:16:01 nirik: we could probably depsolve against CentOS binaries Jun 20 11:16:06 <_blah_> dgilmore: so buildroot listing would be invalid? Jun 20 11:16:12 mbonnet: what if we did a mod_rewrite regarding the el tags ? Jun 20 11:16:25 oh wait, some of the RHEL bins have fc6 in the dist tag :) Jun 20 11:16:27 _blah_: probably yes Jun 20 11:16:34 mmcgrath: not all RHEL packages necessarily use .el5 disttags Jun 20 11:16:44 mmcgrath: because they are fc6 builds so there is no harm there Jun 20 11:16:58 mmcgrath: they are already released Jun 20 11:17:24 so right now the announcement is blocking on the build system. Jun 20 11:17:56 nirik: regarding testing, is that the only piece missing from what is currently in place? Jun 20 11:18:19 not sure... dgilmore ? Jun 20 11:18:39 we need to be able to selectively push to testing and from there to stable or direct to stable (security) Jun 20 11:18:43 Its just odd that we're blocking on that since EPEL is already there. Jun 20 11:18:53 right now everything goes to stable/release. Jun 20 11:18:57 nirik: but do we need that right now? Or just as a long/middle term goal? Jun 20 11:19:56 well, according to the old release plan, we would not allow minor updates/version bumps/minor bugfixes in a minor release cycle, they would queue up in testing and then go to release only when the next minor was out. Jun 20 11:20:16 ie, 5.0 is out now, minor updates queue in testing, when 5.1 comes out they go to release. Jun 20 11:20:26 <_blah_> mbonnet / dgilmore: are there any design docs on how to modify koji to do this? or has the embargoed binaries mod not even made it to the whiteboard stage? Jun 20 11:20:39 there is alot of work to enable testing in the current scripts Jun 20 11:20:43 but if we want to change our release procedures I guess we could do without testing. I would like to have it tho. Jun 20 11:20:51 _blah_: there are ideas, but no consensus yet Jun 20 11:20:56 _blah_: right now its just an idea Jun 20 11:21:03 nirik: I'd like to too, but not if it means we wait till December :-/ Jun 20 11:21:28 Ok, so lets discuss this on the list further. Jun 20 11:21:28 imo, go without testing for now. It comes for free with koji/bodhi integration (yes?). Jun 20 11:21:33 yeah, it's frustrating sometimes the slow progress... ;( Jun 20 11:22:14 nirik: we need more worker bees. Progress would be quick if we could get someone to hack on Koji but mbonnet is busy with other stuff (and rightfully so) Jun 20 11:22:24 So I see two threads we need to start on the list Jun 20 11:22:31 1) staging / rolling Jun 20 11:22:48 2) Testing and what we can and cannot do right now based off of the tools we have. Jun 20 11:22:53 is that right? Jun 20 11:22:58 yeah, time is always at a premium. :( Jun 20 11:23:04 right. Jun 20 11:23:10 * mmcgrath wishes days were 26 hours long :) Jun 20 11:23:25 nirik: would you mind starting 1) ? I'll start 2) Jun 20 11:23:54 sure, was meaning to reply to knurd's thread about the repolayout with that. Jun 20 11:24:04 k. Jun 20 11:24:10 I'll move on to the next item for now Jun 20 11:24:18 --- mmcgrath has changed the topic to: Make sure the repo is in good shape - UNASSIGNED Jun 20 11:24:30 <_blah_> mbonnet / dgilmore: i'm not an awesome python programmer but im willing to help implement once a consensus is developed. for an out there suggestion you could use selinux + sepostgres for mac to make sure that, for example, only redhat internal can see embargoed binaries. Jun 20 11:24:43 So it was brought up in #epel last week that we should probably start running the spam-o-matic script. Jun 20 11:25:08 <_blah_> mmcgrath: there are lots of broken dependencies in epel right now. Jun 20 11:25:11 And toshio noticed a lot of packages that were not in the epel owners list. Jun 20 11:25:23 abadger1999: ping Jun 20 11:25:30 +a lot to spam-o-matic Jun 20 11:25:32 _blah_: do you happen to have an estimate? Jun 20 11:25:58 toshio's changes to owners.epel.list were checked in... hopefully now everything is in there. Jun 20 11:26:01 <_blah_> mmcgrath: i've only looked at bugzilla and there are maybe 10 missing dependencies for it alone. Jun 20 11:26:10 mmcgrath: pong Jun 20 11:26:34 abadger1999: how bad was the owners epel list? Jun 20 11:26:37 _blah_: I fixed one of mine a few days ago... it wasn't assigned properly to me, so the fedora maintainer wasn't sure what to do. Jun 20 11:26:44 as far as missing packages and stuff? Jun 20 11:26:45 mmcgrath: i synced up the tree agaes ago but have not made sure that it was continued since Jun 20 11:27:03 I see 4 open epel bugs. Jun 20 11:27:28 mmcgrath: 16 missing entries Jun 20 11:27:33 _blah_: when you say dependency are you talking about packages that aren't listed in bugzilla? Or are you talking about packages that won't install because a required package isn't available? Jun 20 11:27:42 abadger1999: can you send me the list? Jun 20 11:28:09 Make that 12. 4 were a maintainer changed email addresses. Jun 20 11:28:17 Will the diff do? Jun 20 11:28:36 abadger1999: sure Jun 20 11:28:38 thanks. Jun 20 11:28:41 <_blah_> mmcgrath: packages that won't install due to missing dependencies. Jun 20 11:28:47 _blah_: k. Jun 20 11:28:49 mock and bugzilla packages are the only 2 with bugs files about missing dependencies. Jun 20 11:28:59 so I'll do some more research on getting spam-o-matic just running. Jun 20 11:29:20 please don't kill me :) Jun 20 11:30:10 I think spam for that is good... also if the push scripts can spot broken deps/evrs and allow not pushing a package that would be great. Jun 20 11:30:17 k. Jun 20 11:30:33 Anyone else have anything on that topic? Jun 20 11:30:44 make it happen Jun 20 11:31:07 dgilmore: we need to find a server to host that stuff. Right now spam-o-matic is still run on some rawhide server internally. Jun 20 11:31:10 probably app5... Jun 20 11:31:29 mmcgrath: sounds sane to me we can run repo checks there against RHEL Jun 20 11:31:38 k Jun 20 11:31:46 next item... Jun 20 11:31:51 --- mmcgrath has changed the topic to: Announce EPEL officially Jun 20 11:32:04 so we're blocking on the wiki as well as the build stuff. Jun 20 11:32:32 So thats the end of the big picture tasks really. Jun 20 11:33:05 --- mmcgrath has changed the topic to: EPEL mock configs in Fedora's mock package Jun 20 11:33:12 dgilmore: this got completed I think right? Jun 20 11:33:23 in updates-testing Jun 20 11:33:29 we need to spin a new package though Jun 20 11:33:32 f13: so its on its way out? Jun 20 11:33:38 somewhat Jun 20 11:33:51 k, I'll leave that up for next week just to be safe Jun 20 11:34:01 k Jun 20 11:34:09 --- mmcgrath has changed the topic to: EPEL Meeting -- comps.xml for EPEL -- dgilmore nirik and Jeff_S Jun 20 11:34:15 if somebody could grab it from updates-testing and verify that the epel configs work that would b egood. Jun 20 11:34:32 f13: I have used the latest mock on rawhide ok with epel4/5... Jun 20 11:34:38 mmcgrath: mi started on it i wanted to remove packages that dont exist before checking it in Jun 20 11:34:49 dgilmore: k Jun 20 11:35:10 but i can check it in and then let people clean it up Jun 20 11:35:30 dgilmore: sounds good, when you think its ready send a note to the list and we'll all take a look Jun 20 11:36:19 * stahnma is here now Jun 20 11:36:24 --- mmcgrath has changed the topic to: EPEL Meeting -- Communication plan for enterprise customers/ISVs/IHVs -- stahnma, quaid Jun 20 11:36:27 stahnma: yo Jun 20 11:36:37 quaid: stahnma: any updates / ideas on this? Jun 20 11:37:27 --> riczho (i=ricky at gateway/gpg-tor/key-0xCCAF484E) has joined #fedora-meeting Jun 20 11:37:38 * f13 has a lovely topic to bring up too Jun 20 11:37:57 I haven't done much of anything since the packager draft Jun 20 11:38:02 f13: k, one moment :) Jun 20 11:38:12 asking if if I a packager has plans to branch for EPEL Jun 20 11:38:20 I will clean that up this week and send out on list again Jun 20 11:38:30 stahnma: k. Sounds good. Jun 20 11:38:44 I will need some branching info from dgilmore Jun 20 11:38:50 --- mmcgrath has changed the topic to: EPEL Meeting -- vacant seat in the steering committee Jun 20 11:38:59 dgilmore: hook stahnma up :) Jun 20 11:39:12 So whats the latest on the vacant seat? I'll be honest I haven't followed it that closely. Jun 20 11:39:13 * quaid updated on the comm plan before, fwiw Jun 20 11:39:42 not sure... Perhaps we should ping the list asking if anyone at all is interested? Jun 20 11:39:51 stahnma: what access do you need? Jun 20 11:39:55 I think jeff_s was interested... don't see him around today tho Jun 20 11:40:01 no access, just some questions dgilmore Jun 20 11:40:02 nirik: I thought someone was interested already and made that known. Jun 20 11:40:04 nirik: smooge was also Jun 20 11:40:06 we can talk later dgilmore Jun 20 11:40:12 stahnma: hit me up Jun 20 11:40:19 k Jun 20 11:40:31 * mmcgrath could be confused though. Jun 20 11:40:50 I thought a few people were interesed in the seat Jun 20 11:41:14 knurd would know, I'll take a look at the list archives. Jun 20 11:41:19 Jeff_S or smooge maybe? Jun 20 11:41:22 ok Jun 20 11:41:32 stahnma: both of them Jun 20 11:41:37 smooge: were you interested in a seat on the SIG? Jun 20 11:41:54 perhaps we could just add both? I think more input would be good... of course that would make an even number Jun 20 11:42:06 * stahnma would be happy with either/both of them Jun 20 11:42:11 same here Jun 20 11:42:24 I was interested... but withdrew my self-nomination as I saw that there were too many layer-8 issues I couldnt help with without getting people in a room with a brick Jun 20 11:42:34 we'll take that to the list since Jeff_S doesn't appear to be around right now and I'd hate to volunteer him :) Jun 20 11:42:43 ok Jun 20 11:42:45 sounds like a plan Jun 20 11:42:46 smooge: fair enough Jun 20 11:42:58 thats all I see on the schedule Jun 20 11:43:05 --- mmcgrath has changed the topic to: EPEL Meeting -- Free discussion around EPEL Jun 20 11:43:09 f13: you had a topic to discuss? Jun 20 11:43:14 smooge: any input would be welcome tho... brick or no. ;) Jun 20 11:43:33 mmcgrath: yeah, has RHX been discussed at all? Jun 20 11:43:42 f13: not seriously. Jun 20 11:43:46 specifically, RHX is in RHN, but it hosts some opensource content. Jun 20 11:43:46 what is RHX? Jun 20 11:43:58 the red hat exchange, of course Jun 20 11:44:01 and you can't get to that content through rhn without buying whatever RHX is selling for that particular software Jun 20 11:44:07 I brought up the idea of having the MySQL guys actually maintaining MySQL and having EPEL allow for that. Jun 20 11:44:13 so how does that fall with our EPEL can't package anything available in RHX? Jun 20 11:44:14 a way of upstream isvs getting software pkged and available via rhn Jun 20 11:44:25 er Jun 20 11:44:27 so how does that fall with our EPEL can't package anything available in RHN? Jun 20 11:44:39 f13: what? Jun 20 11:44:50 not sure... is there any way to see whats available there? Jun 20 11:44:52 f13: thats part of our guidelines (not really RHN but the core OS) Jun 20 11:44:53 * stahnma notes that most stuff on RHX isn't even in Fedora yet Jun 20 11:45:09 but I think if we were going to coordinate with an ISV to bring something out of RHEL into EPEL, that shouldn't be a problem. Jun 20 11:45:10 I thought the guidelines did mention layered products too Jun 20 11:45:11 stahnma: not yet, but just yesterday I had a conversation with Digium about Asterisk. Jun 20 11:45:19 f13: great :) Jun 20 11:45:20 --> JSchmitt_ (n=s4504kr at p54B10976.dip0.t-ipconnect.de) has joined #fedora-meeting Jun 20 11:45:34 stahnma: they are fixing it up to go into Fedora, and RHX, but if it's in RHX, can we put it in EPEL? and how do we handle where EPEL NVR might be different than RHX and .... Jun 20 11:45:35 what about things like Fedora-d? Jun 20 11:45:45 <-- JSchmitt_ has quit (Remote closed the connection) Jun 20 11:45:49 fedora-ds even Jun 20 11:45:53 <_blah_> f13: sounds like you're asking for repotags Jun 20 11:45:55 * _blah_ ducks Jun 20 11:45:56 mmcgrath: it also includes layerd products Jun 20 11:45:56 ditto Zenoss Jun 20 11:46:00 --> JSchmitt_ (n=s4504kr at p54B10976.dip0.t-ipconnect.de) has joined #fedora-meeting Jun 20 11:46:14 fedora-ds is ok and im going to make sure it gets in Jun 20 11:46:17 RHX throws a big wrinkle into the original guidelines for EPEL. Jun 20 11:46:34 f13: Well sort of. Jun 20 11:46:36 f13: indeed RHX was not know about when we started Jun 20 11:46:39 I guess we'd leave that up to the ISV Jun 20 11:46:45 f13: I agree, we should revisit this. Will the big problem be we compete against RH on it? Jun 20 11:46:51 * quaid perks up at f13's question Jun 20 11:46:58 if we have the same (similar) open source packages ready for EL Jun 20 11:47:05 stahnma: I honestly don't know. I haven't brought up the subject to many people internally yet. Jun 20 11:47:06 f13: it'd be nice to work with the RHX people in this regard but I'm not sure if they even know EPEL exists. Jun 20 11:47:12 they do Jun 20 11:47:20 I've been talking with the RHX releng person a bit about this. Jun 20 11:47:20 hrm Jun 20 11:47:27 I hadn't thought of this either Jun 20 11:47:31 f13: How does RH intend on maintaing the Zenoss RPM? Jun 20 11:47:37 f13, does priorities work with RHN? Jun 20 11:47:38 f13: theres one package in RHX that id like to see in Fedora and EPEL and its build setup is horrible Jun 20 11:47:40 did they plan on having the Zenoss people do it? Jun 20 11:47:54 mmcgrath: RHX is tier 1 and 2 support Jun 20 11:47:56 for the whole stack Jun 20 11:47:59 the conundrum of the day goes to f13 Jun 20 11:48:03 quaid: but what about the actual RPM's? Jun 20 11:48:06 RHX then escalates to the vendor Jun 20 11:48:06 perhaps this would get some traction for a rpm/yum/up2date solution to multiple repos. ;) Jun 20 11:48:13 mmcgrath: the idea is that ISVs can maintain the software, but it has to adhere to Fedora packaging standards to be in RHX Jun 20 11:48:14 aiui, RHX does their own RPMs Jun 20 11:48:23 oh, right Jun 20 11:48:25 how do RHX packages get built? Jun 20 11:48:26 duff is working with people Jun 20 11:48:51 dgilmore: right now? an internal build server Jun 20 11:48:52 f13: EPEL does have the infrastructure to do all of this already, it was one of the hopes/plans for EPEL. Jun 20 11:48:55 look, I can't solve this stuff, but 'tis my purview to lead us to a solution Jun 20 11:48:56 f13: i dont see how the package i want adheres to our packaging standards Jun 20 11:49:00 --> nman64 (n=n-man at fedora/nman64) has joined #fedora-meeting Jun 20 11:49:15 dgilmore: yeah, dhuff wasn't good about that for the first round of get it out the door Jun 20 11:49:15 dgilmore: it may be "in transition" Jun 20 11:49:22 dgilmore: I don't think the RHX stuff is really out the door yet. Jun 20 11:49:32 mmcgrath: it's available and announced Jun 20 11:49:36 for US customers at least. Jun 20 11:49:50 * stahnma has browsed it a few times... Jun 20 11:49:55 who from EPEL can woirk on this Jun 20 11:49:55 f13: yeah but are the RPM's available and built under Fedora's guidelines? Jun 20 11:50:00 from the technical standpoint? Jun 20 11:50:02 quaid, f13: what i want to use is Zimbra. its one of the most horrible set of something ive seen as far as packing goes Jun 20 11:50:08 from a customer perspecitve, I would love to see this stuff in EPEL to 'try before i buy' Jun 20 11:50:21 then if my compnay relies upon it heavily, move to RHX Jun 20 11:50:25 stahnma: indeed Jun 20 11:50:26 much like RHEL Jun 20 11:50:28 voice from the outside, at least some customers of RHEL/RHN had thought Red Hat Exchange was EPEL Jun 20 11:50:34 f13: quaid: what are the odds that RH would support those RPM's in EPEL? Jun 20 11:50:42 dgilmore: right, as I said, they've been somewhat fly by night to get things launched. He's now working with us to try and integrate our guidelines, and was even talking about using our build system to produce the content. Jun 20 11:50:48 mmcgrath: well, it might be higher than you think Jun 20 11:50:56 yep Jun 20 11:51:01 quaid: can you look into that more? Jun 20 11:51:04 mmcgrath: id like to see that Jun 20 11:51:05 f13: I talked with duff about that a few months ago Jun 20 11:51:13 mmcgrath: yes, that's my purview as a work position Jun 20 11:51:23 quaid: yeah, he pinged me on it a week or 2 ago Jun 20 11:51:29 Does anyone here think RH shouldn't support RHX packages packaged in EPEL? Jun 20 11:51:30 at which point I brought up epel. Jun 20 11:51:35 although the kicker is.... Jun 20 11:51:37 <_blah_> does everything on RHX require a subscription? Jun 20 11:51:40 to coordinate between online services grps (such as RHX) and FEdora groups (such as EPEL) Jun 20 11:51:41 RHX can have content which is not open source Jun 20 11:51:44 _blah_: yeah Jun 20 11:51:56 so RHX can't entirely rely upon our infrastructure as they can't host the sources with us. Jun 20 11:52:00 f13: yeah but if its opensource id like to see it in EPEL Jun 20 11:52:03 but they can Jun 20 11:52:06 * stahnma cries a little on the inside Jun 20 11:52:06 witht he stuff that is FLOSS Jun 20 11:52:08 dgilmore: +1 Jun 20 11:52:12 dgilmore: I woudl too Jun 20 11:52:20 who can help me Jun 20 11:52:24 from a tech standpoint Jun 20 11:52:27 from EPEL? Jun 20 11:52:27 stahnma: yes, that makes me cry as well. A /lot/. Jun 20 11:52:40 quaid: help with what exactly? Jun 20 11:52:44 well Jun 20 11:52:52 quaid: i can Jun 20 11:52:54 packaging, build sys quesitons Jun 20 11:52:56 ok Jun 20 11:52:59 quaid: I can help with what I can. I'm not deeply entrenched within epel though, just keeping an eye on things. Jun 20 11:53:15 quaid: count me in as a second on that Jun 20 11:53:19 f13: how about if you are in the loop on all the email, in a CI position of RACI? Jun 20 11:53:24 mmcgrath too Jun 20 11:53:28 quaid: worksforme Jun 20 11:53:31 ok Jun 20 11:53:33 sounds good Jun 20 11:53:43 * quaid smacks his head for not having seen this one coming Jun 20 11:53:43 if you need external customer POV, let me know Jun 20 11:53:45 quaid: me too Jun 20 11:53:48 stahnma: you bet Jun 20 11:54:03 id like to be cc'd on things Jun 20 11:54:05 Ok, we're getting close to the top of the hour, anyone else have anything to discuss? Jun 20 11:54:06 dgilmore: what I want to do is get with you and the RHX packager Jun 20 11:54:16 did we go a whole meeting without repotags? Jun 20 11:54:28 quaid: sure Jun 20 11:54:29 dgilmore: we'll start with that from the tech angle, and work up what "business problems" we create with all that; Jun 20 11:54:33 stahnma: yep, AFAIK, its done. We voted. Jun 20 11:54:39 * stahnma cheers Jun 20 11:54:41 stahnma: UNTIL JUST NOW Jun 20 11:54:51 now it's greppable in the logs Jun 20 11:54:53 quaid: we could tap mspevack on this as well. Jun 20 11:54:54 damn you stahnma for bring it up Jun 20 11:54:59 mmcgrath: wise, yes Jun 20 11:55:02 * stahnma hasn't read back through the top yet... Jun 20 11:55:22 stahnma: did you have something further to discuss? Jun 20 11:55:25 mmcgrath: I want us to suss out the tech thoughts before we go to someone for a "ruling" Jun 20 11:55:30 if not I'll close the meeting. Jun 20 11:55:35 mmcgrath: no, thanks though Jun 20 11:55:36 quaid: solid Jun 20 11:55:40 Alllright Jun 20 11:55:44 * mmcgrath will close the meeting in 30 Jun 20 11:55:46 we done? Jun 20 11:56:02 thanks all, dgilmore I will try to hit you up tonight Jun 20 11:56:07 10 Jun 20 11:56:11 f5 Jun 20 11:56:13 f13: dhuff, right? Jun 20 11:56:30 --- mmcgrath has changed the topic to: EPEL Meeting -- Meeting End Jun 20 11:56:40 Thanks everyone, who can send the log minutes? Jun 20 11:56:52 * mmcgrath has a horrible irc logger and it isn't enabled right now anyway :) Jun 20 11:56:54 quaid: yes. Jun 20 11:57:12 <-- JSchmitt has quit (No route to host) Jun 20 11:57:16 13:02 morbidly curious as to if repotags will be brought up again this week. Jun 20 11:57:19 13:45 <_blah_> f13: sounds like you're asking for repotags Jun 20 11:57:22 13:54 did we go a whole meeting without repotags? Jun 20 11:57:42 mmcgrath: I have logs, you want me to mail them to you? or ? Jun 20 11:57:54 nirik: to the list if you wouldn't mind. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mmcgrath at redhat.com Wed Jun 20 18:05:00 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 20 Jun 2007 13:05:00 -0500 Subject: Official announcement and reality Message-ID: <46796C4C.1020201@redhat.com> While discussing the repo layout stuff in the meeting today we were talking about what we'd like to do vs what we can do. And while we're headed to a bodhi/koji updates-testing system MHO is that it will likely be months before that is ready, it's simply an issue of time and not enough workers (though _blah_ may have volunteered, if so please come forward on the list :) So the question at hand is, do we wait for these tools, or try to do the best with what we've got knowing that we have a long term plan. After all, many of us have been using EPEL for a couple of months already. -Mike From kevin at tummy.com Wed Jun 20 18:14:02 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 20 Jun 2007 12:14:02 -0600 Subject: Proposal for final repolayout In-Reply-To: <4677D000.30005@leemhuis.info> References: <4677D000.30005@leemhuis.info> Message-ID: <20070620121402.498fdb76@ghistelwchlohm.scrye.com> On Tue, 19 Jun 2007 14:45:52 +0200 fedora at leemhuis.info (Thorsten Leemhuis) wrote: > Hi, > > seems we need koji modification to use bodhi, which likely itself > might need some adjustments for proper EPEL support as well. Both > things will take time to get realized as it seems other work is > higher on peoples todo list atm. Yeah. > So I'd say EPEL should for the near future plan to continue to use > plague together with the old Fedora Extras push scripts until we can > switch to koji and bodhi; otherwise it might take a long time until we > are ready to announce EPEL officially, which I'd like to avoid See Mike's email on this. The push scripts currently don't have any way to handle testing. So should we go forward without testing? Or try and find some way to get them working with it? > We just should make sure the repo layout is sane for the near future > and can be used with bodihi later as well (Luke, that's why you are > in the CC of this mail; if there is anything that would be hard to > realize in bodihi let us know please). > > I'd like to propose round about this layout below > http://redhat.download.fedoraproject.org/pub/epel/ > > stable/ > 4/ -> 4.(current_version()) > 4.1/ > ... > 4.5/ > 5/ -> 5.(current_version()) > 5.1/ > ... > testing/ > 4/ > 5/ > rolling/ > 4/ -> 4.(current_version()) > 4.1/ > ... > 5/ -> 5.(current_version()) > 5.1/ > ... > > We currently have symbolic links from "4{AS,WS,ES}" to "4" and > "5{Client,Server}" to "5" on the server as well; they should be there > in the future as well, but I left them out of this scheme to not make > things even more complicated to understand. > > Please ignore the "rolling" stuff as well; it seems some people would > like to have a more "Fedora Extras" like EPEL with a bold update > policy (always latest and greatest). I'd like to leave the path for > this open in the long term, that why I'd say we should put the > current EPEL stuff below "stable". I think this adds to confusion... I thought we had determined that EPEL was going to target more 'stable' type update methods? Folks wanting a really fast a furious update should use another repo that does that, or perhaps they could always have updates-testing enabled (although that might not be fast enough for them). > How to realize the layout: have two different plague-targets per > release; the default target is "testing/(release())"; that repo > becomes the stable release automatically when RH ships a new > quarterly update. If you want to get something into the stable repo > for the current release use a special build target, from which the > extras-push-scripts push into the proper dir directly. Humm... that might work. I don't know enough of how the push scripts work currently. perhaps Dgilmore could comment? > Comments? All sounds good except I would skip the 'stable/rolling' dirs. > CU > thl kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Jun 20 18:25:10 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 20 Jun 2007 13:25:10 -0500 Subject: Official announcement and reality References: <46796C4C.1020201@redhat.com> Message-ID: Mike McGrath wrote: > So the question at hand is, do we wait for these tools, or try to do the > best with what we've got knowing that we have a long term plan. The latter. We (and the public) have waited long enough. Go dog go. -- Rex From rob.myers at gtri.gatech.edu Wed Jun 20 19:26:04 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Wed, 20 Jun 2007 15:26:04 -0400 Subject: Official announcement and reality In-Reply-To: <46796C4C.1020201@redhat.com> References: <46796C4C.1020201@redhat.com> Message-ID: <1182367564.4065.38.camel@rxm-581b.stl.gtri.gatech.edu> On Wed, 2007-06-20 at 13:05 -0500, Mike McGrath wrote: > While discussing the repo layout stuff in the meeting today we were > talking about what we'd like to do vs what we can do. And while we're > headed to a bodhi/koji updates-testing system MHO is that it will likely > be months before that is ready, it's simply an issue of time and not > enough workers (though _blah_ may have volunteered, if so please come > forward on the list :) I (_blah_) am willing to help add the functionality to koji, but I know adding embargoed binaries is a bigger job than I can do myself. > So the question at hand is, do we wait for these tools, or try to do the > best with what we've got knowing that we have a long term plan. After > all, many of us have been using EPEL for a couple of months already. I vote for koji as the plan for the future- but I don't think it is a blocker for getting EPEL out. rob. From sheltren at cs.ucsb.edu Wed Jun 20 20:22:22 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 20 Jun 2007 15:22:22 -0500 Subject: Vacant Seat [Was: log from 2007-06-20 meeting] In-Reply-To: <20070620120115.4d4e04da@ghistelwchlohm.scrye.com> References: <20070620120115.4d4e04da@ghistelwchlohm.scrye.com> Message-ID: <31C17F33-5546-4C99-A095-F7DF33AC7FCF@cs.ucsb.edu> On Jun 20, 2007, at 1:01 PM, Kevin Fenzi wrote: > Jun 20 11:38:50 --- mmcgrath has changed the topic to: EPEL Meeting > -- vacant seat in the steering committee Hi, sorry I missed the meeting - I'm just getting over the flu. Yes, I am still interested in being part of the steering committee. Thanks, Jeff From buildsys at fedoraproject.org Thu Jun 21 00:09:27 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 20 Jun 2007 20:09:27 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-20 Message-ID: <20070621000927.C55A7152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 10 NEW aqbanking-2.2.9-2.el5 : A library for online banking functions and financial data import/export dbmail-2.2.5-3.el5 NEW gnucash-docs-2.0.1-2.el5 : Help files and documentation for the GnuCash personal finanace manager NEW gwenhywfar-2.6.0-1.el5 : A multi-platform helper library for other libraries NEW libofx-0.8.3-4.el5 : A library for supporting Open Financial Exchange (OFX) NEW perl-Finance-Quote-1.13-1.el5 : A Perl module that retrieves stock and mutual fund quotes NEW perl-HTML-TableExtract-2.10-2.el5 : A Perl module for extracting content in HTML tables NEW reciteword-0.8.3-3.el5 : Recite Word Easily tcptraceroute-1.5-0.2.beta7.el5 tmda-1.1.11-4.el5 Packages built and released for Fedora EPEL 4: 7 NEW aqbanking-2.2.9-2.el4 : A library for online banking functions and financial data import/export NEW gnucash-docs-2.0.1-2.el4 : Help files and documentation for the GnuCash personal finanace manager NEW gwenhywfar-2.6.0-1.el4 : A multi-platform helper library for other libraries NEW libofx-0.8.3-4.el4 : A library for supporting Open Financial Exchange (OFX) NEW perl-Finance-Quote-1.13-1.el4 : A Perl module that retrieves stock and mutual fund quotes NEW perl-HTML-TableExtract-2.10-2.el4 : A Perl module for extracting content in HTML tables tmda-1.1.11-4.el4 Changes in Fedora EPEL 5: aqbanking-2.2.9-2.el5 --------------------- * Wed Jun 20 2007 Bill Nottingham - 2.2.9-2 - add a dist tag dbmail-2.2.5-3.el5 ------------------ * Wed Jun 20 2007 Bernard Johnson 2.2.5-3 - assign uid from package user registry gnucash-docs-2.0.1-2.el5 ------------------------ * Tue Feb 13 2007 Bill Nottingham - 2.0.1-2 - move yelp requirement from gnucash to here gwenhywfar-2.6.0-1.el5 ---------------------- * Mon Jun 11 2007 Bill Nottingham - 2.6.0-1 - update to 2.6.0 libofx-0.8.3-4.el5 ------------------ * Mon Jun 11 2007 Bill Nottingham - 0.8.3-4 - minor tweaks for EPEL builds perl-Finance-Quote-1.13-1.el5 ----------------------------- * Mon Jan 08 2007 Bill Nottingham - 1.13-1 - update to 1.13 perl-HTML-TableExtract-2.10-2.el5 --------------------------------- * Wed Jun 20 2007 Bill Nottingham - 2.10-2 - EPEL build tweaks reciteword-0.8.3-3.el5 ---------------------- * Wed Jun 20 2007 Hu Zheng - 0.8.3-3 - Fix x86_64 compile error. * Fri Jun 15 2007 Hu Zheng - 0.8.3-2 - Small fixes according to Parag AN's suggestion. * Thu Jun 07 2007 Hu Zheng - 0.8.3-1 - Initial build for Fedora tcptraceroute-1.5-0.2.beta7.el5 ------------------------------- * Wed Jun 20 2007 Sindre Pedersen Bj?rdal - 1.5-0.2.beta7 - Fix typo to really remove duplicate doc files tmda-1.1.11-4.el5 ----------------- * Wed Jun 20 2007 Bernard Johnson 1.1.11-4 - assign package uid Changes in Fedora EPEL 4: aqbanking-2.2.9-2.el4 --------------------- * Wed Jun 20 2007 Bill Nottingham - 2.2.9-2 - add a dist tag gnucash-docs-2.0.1-2.el4 ------------------------ * Tue Feb 13 2007 Bill Nottingham - 2.0.1-2 - move yelp requirement from gnucash to here gwenhywfar-2.6.0-1.el4 ---------------------- * Mon Jun 11 2007 Bill Nottingham - 2.6.0-1 - update to 2.6.0 libofx-0.8.3-4.el4 ------------------ * Mon Jun 11 2007 Bill Nottingham - 0.8.3-4 - minor tweaks for EPEL builds perl-Finance-Quote-1.13-1.el4 ----------------------------- * Mon Jan 08 2007 Bill Nottingham - 1.13-1 - update to 1.13 perl-HTML-TableExtract-2.10-2.el4 --------------------------------- * Wed Jun 20 2007 Bill Nottingham - 2.10-2 - EPEL build tweaks tmda-1.1.11-4.el4 ----------------- * Wed Jun 20 2007 Bernard Johnson 1.1.11-4 - assign package uid 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 Jun 21 04:11:47 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Wed, 20 Jun 2007 23:11:47 -0500 Subject: Draft of Personal Package Request Message-ID: <7874d9dd0706202111pefd1144l91d540f70a014215@mail.gmail.com> I updated the draft on the package request email/notification on the wiki. Found currently at : http://fedoraproject.org/wiki/MichaelStahnke/Draft-EPELPackageRequest Reads as follows: --- Attention $USER Your packages currently found in Fedora have been requested for inclusion in Extra Packages for Enterprise Linux (EPEL)[1]. Thus far, while looking at our Contributor Status[2] page, we are unable to determine if you are planning to build your packages for EPEL. If you are interested in building, please follow the Branching Procedure[3] for EPEL. If you maintain several packages (> 2) you can also use a scripted branching method (all packages from a contributor) by using the Scripted Branch Process[4]. If you are not interested in EPEL or don't feel like you have the time to put your packages into EPEL, the EPEL project would like to request that a co-maintainer who is a part of EPEL be added to your packages. To do this, please follow the co-maintainer process[5]. We appreciate your help in readying EPEL for official launch soon. The EPEL team [1] http://fedoraproject.org/wiki/EPEL [2] http://fedoraproject.org/wiki/EPEL/ContributorStatus [3] http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure [4] http://fedoraproject.org/wiki/MichaelStahnke/ScriptedBranchProcess [5] http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership --- Please review and give feedback. Also, take a closer look at [4], as I just wrote that tonight with dgilmore's help. And finally, should [5] reference the Extras namespace? --- stahnma From mastahnke at gmail.com Fri Jun 22 00:42:53 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 21 Jun 2007 19:42:53 -0500 Subject: Readme.fedora files in EPEL Message-ID: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> Should README.fedora files be ranamed in EPEL? It probably isn't too big of a deal, but I was looking through a package and wondered. Also, in the case of some PHP packages, in RHEL 5, php provides a directory called /usr/share/php and then non-pear php apps can use /usr/share/php/whatever for their content. In EL 4, no such dir exists. Should we create a package that provides /usr/share/php, or relocate the packages on EL4? stahnma From buildsys at fedoraproject.org Fri Jun 22 02:47:48 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 21 Jun 2007 22:47:48 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-21 Message-ID: <20070622024748.CBFE0152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 4 NEW ganymed-ssh2-210-2.el5 : SSH-2 protocol implementation in pure Java NEW kmymoney2-0.8.6-1.el5 : Personal finance puppet-0.23.0-1.el5 NEW svnkit-1.1.2-2.el5 : Pure Java Subversion client library Packages built and released for Fedora EPEL 4: 3 NEW g-wrap-1.9.6-13.el4 : A tool for creating Scheme interfaces to C libraries NEW gnucash-2.0.5-3.1.el4 : GnuCash is an application to keep track of your finances puppet-0.23.0-1.el4 Changes in Fedora EPEL 5: ganymed-ssh2-210-2.el5 ---------------------- * Tue Oct 10 2006 Robert Marcano 210-2 - Update to upstream release 210 kmymoney2-0.8.6-1.el5 --------------------- * Sat Mar 10 2007 Rex Dieter 0.8.6-1 - kmymoney2-0.8.6 - fix Obsoletes: kmymoney puppet-0.23.0-1.el5 ------------------- * Wed Jun 20 2007 David Lutterkort - 0.23.0-1 - Install one puppet.conf instead of old config files, keep old configs around to ease update - Use plain shell commands in install instead of macros svnkit-1.1.2-2.el5 ------------------ * Mon Jun 18 2007 Robert Marcano 1.1.2-2 - Package review fixes Changes in Fedora EPEL 4: g-wrap-1.9.6-13.el4 ------------------- * Mon Jun 11 2007 Bill Nottingham - 1.9.6-13 - EPEL packaging tweaks * Fri Jun 08 2007 Bill Nottingham - 1.9.6-12 - fix license tag - LGPL, not GPL (#222347) gnucash-2.0.5-3.1.el4 --------------------- * Tue Jun 12 2007 Bill Nottingham - 2.0.5-3.1 - EPEL packaging tweaks puppet-0.23.0-1.el4 ------------------- * Wed Jun 20 2007 David Lutterkort - 0.23.0-1 - Install one puppet.conf instead of old config files, keep old configs around to ease update - Use plain shell commands in install instead of macros For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From bojan at rexursive.com Fri Jun 22 06:19:09 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 22 Jun 2007 16:19:09 +1000 Subject: viewvc package Message-ID: <1182493149.2937.23.camel@shrek.rexursive.com> At one point during the package review process there was some discussion about viewvc being part of EPEL and the spec has been crafted to enable such things. Any chance this package actually goes in? Original review request here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230512 PS. I'm only asking because I need it, of course :-) -- Bojan From bjohnson-sender-11eeb1 at symetrix.com Fri Jun 22 06:32:25 2007 From: bjohnson-sender-11eeb1 at symetrix.com (Bernard Johnson) Date: Fri, 22 Jun 2007 00:32:25 -0600 Subject: viewvc package In-Reply-To: <1182493149.2937.23.camel@shrek.rexursive.com> References: <1182493149.2937.23.camel@shrek.rexursive.com> Message-ID: <467B6CF9.5010902@symetrix.com> Bojan Smojver wrote: > At one point during the package review process there was some discussion > about viewvc being part of EPEL and the spec has been crafted to enable > such things. Any chance this package actually goes in? > > Original review request here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230512 > > PS. I'm only asking because I need it, of course :-) > > Be sure and check the dependencies first. I'm guess some things like cvsgraph, enscript, and possibly others have not (yet?) been built for epel - and then, maybe only for epel5. From bojan at rexursive.com Fri Jun 22 06:38:25 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 22 Jun 2007 16:38:25 +1000 Subject: viewvc package In-Reply-To: <467B6CF9.5010902@symetrix.com> References: <1182493149.2937.23.camel@shrek.rexursive.com> <467B6CF9.5010902@symetrix.com> Message-ID: <1182494305.2937.27.camel@shrek.rexursive.com> On Fri, 2007-06-22 at 00:32 -0600, Bernard Johnson wrote: > Be sure and check the dependencies first. I'm guess some things like > cvsgraph, enscript, and possibly others have not (yet?) been built for > epel - and then, maybe only for epel5. I'm on EL5, so I'll focus on that for now. Enscript is there, but cvsgraph isn't. I'll see if Fedora packages build on EL5 and report back. I'll also check other build/runtime dependencies. -- Bojan From dag at wieers.com Fri Jun 22 07:05:51 2007 From: dag at wieers.com (Dag Wieers) Date: Fri, 22 Jun 2007 09:05:51 +0200 (CEST) Subject: viewvc package In-Reply-To: <467B6CF9.5010902@symetrix.com> References: <1182493149.2937.23.camel@shrek.rexursive.com> <467B6CF9.5010902@symetrix.com> Message-ID: On Fri, 22 Jun 2007, Bernard Johnson wrote: > Bojan Smojver wrote: > > At one point during the package review process there was some discussion > > about viewvc being part of EPEL and the spec has been crafted to enable > > such things. Any chance this package actually goes in? > > > > Original review request here: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230512 > > > > PS. I'm only asking because I need it, of course :-) > > Be sure and check the dependencies first. I'm guess some things like > cvsgraph, enscript, and possibly others have not (yet?) been built for > epel - and then, maybe only for epel5. Which aren't strictly speaking dependencies, since it can work fine without them and make less sense when using viewvc with subversion. Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From buildsys at fedoraproject.org Fri Jun 22 20:15:45 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 22 Jun 2007 16:15:45 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-22 Message-ID: <20070622201545.66E80152133@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 9 NEW asciidoc-8.1.0-1.el5 : Text based document generation NEW checkstyle-4.1-4jpp.1.el5 : Java source code checker NEW g-wrap-1.9.6-13.el5 : A tool for creating Scheme interfaces to C libraries NEW gnucash-2.0.5-3.1.el5 : GnuCash is an application to keep track of your finances NEW jakarta-commons-cli-1.0-6jpp_10.el5 : Command Line Interface Library for Java NEW mercurial-0.9.3-1.el5 : A fast, lightweight distributed source control management system NEW rsnapshot-1.3.0-1.el5 : Local and remote filesystem snapshot utility NEW sec-2.4.1-1.el5 : SEC (simple event correlator) NEW slib-3a3-3.el5 : Platform independent library for scheme Packages built and released for Fedora EPEL 4: 2 NEW git-1.5.2.1-2.el4 : Git core and tools mercurial-0.9.1-2.el4 Changes in Fedora EPEL 5: asciidoc-8.1.0-1.el5 -------------------- * Mon Mar 19 2007 Chris Wright - 8.1.0-1 - update to asciidoc 8.1.0 checkstyle-4.1-4jpp.1.el5 ------------------------- * Sat Feb 24 2007 Deepak Bhole - 0:4.1-4jpp.1 - Update per Fedora spec - Removed emma and excalibur-avalon-logkit dependencies g-wrap-1.9.6-13.el5 ------------------- * Mon Jun 11 2007 Bill Nottingham - 1.9.6-13 - EPEL packaging tweaks * Fri Jun 08 2007 Bill Nottingham - 1.9.6-12 - fix license tag - LGPL, not GPL (#222347) gnucash-2.0.5-3.1.el5 --------------------- * Tue Jun 12 2007 Bill Nottingham - 2.0.5-3.1 - EPEL packaging tweaks jakarta-commons-cli-1.0-6jpp_10.el5 ----------------------------------- * Thu Oct 05 2006 Christian Iseli - 0:1.0-6jpp_10 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 mercurial-0.9.3-1.el5 --------------------- * 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 rsnapshot-1.3.0-1.el5 --------------------- * Mon May 28 2007 Chris Petersen 1.3.0-1 - Upgrade to 1.3.0 sec-2.4.1-1.el5 --------------- * Mon May 28 2007 Chris Petersen 2.4.1-1 - Update to 2.4.1 slib-3a3-3.el5 -------------- * Fri Jun 22 2007 Bill Nottingham 3a3-2 - initial build for EPEL, back down to 3a3 to work with EL-5 guile * Fri Jun 22 2007 Miroslav Lichvar 3a4-2 - fix summary and buildroot (#226421) Changes in Fedora EPEL 4: git-1.5.2.1-2.el4 ----------------- * Fri Jun 22 2007 James Bowes 1.5.2.1-2 - Remove buildreq on perl(Error) and perl-devel for el4. * Fri Jun 08 2007 James Bowes 1.5.2.1-1 - git-1.5.2.1 mercurial-0.9.1-2.el4 --------------------- * Mon Aug 28 2006 Jeremy Katz - 0.9.1-2 - rebuild 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 Jun 22 20:53:00 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 22 Jun 2007 16:53:00 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-22 Message-ID: <20070622205300.26F75152133@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 2 NEW eclipse-cdt-3.1.2-4.1.el5 : Eclipse C/C++ Development Tools (CDT) plugin NEW git-1.5.2.1-2.el5 : Git core and tools Packages built and released for Fedora EPEL 4: 0 Changes in Fedora EPEL 5: eclipse-cdt-3.1.2-4.1.el5 ------------------------- * Fri Jun 22 2007 Jeff Johnston 3.1.2-4.1 - Fix typo in spec file. - Add EPEL support. git-1.5.2.1-2.el5 ----------------- * Fri Jun 22 2007 James Bowes 1.5.2.1-2 - Remove buildreq on perl(Error) and perl-devel for el5. * Fri Jun 08 2007 James Bowes 1.5.2.1-1 - git-1.5.2.1 Changes in Fedora EPEL 4: For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From sundaram at fedoraproject.org Fri Jun 22 20:55:14 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 23 Jun 2007 02:25:14 +0530 Subject: Draft of Personal Package Request In-Reply-To: <7874d9dd0706202111pefd1144l91d540f70a014215@mail.gmail.com> References: <7874d9dd0706202111pefd1144l91d540f70a014215@mail.gmail.com> Message-ID: <467C3732.3090404@fedoraproject.org> Michael Stahnke wrote: > I updated the draft on the package request email/notification on the wiki. > > Found currently at : > http://fedoraproject.org/wiki/MichaelStahnke/Draft-EPELPackageRequest > Looks good to me. Rahul From sundaram at fedoraproject.org Fri Jun 22 20:56:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 23 Jun 2007 02:26:43 +0530 Subject: Readme.fedora files in EPEL In-Reply-To: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> References: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> Message-ID: <467C378B.8090106@fedoraproject.org> Michael Stahnke wrote: > Should README.fedora files be ranamed in EPEL? It probably isn't too > big of a deal, but I was looking through a package and wondered. > Maybe we need to enforcing calling it README.distribution or a generic name like in the Fedora packaging guidelines that so EPEL can reuse the content or atleast the file name without any issues. Rahul From opensource at till.name Fri Jun 22 21:52:35 2007 From: opensource at till.name (Till Maas) Date: Fri, 22 Jun 2007 23:52:35 +0200 Subject: Readme.fedora files in EPEL In-Reply-To: <467C378B.8090106@fedoraproject.org> References: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> <467C378B.8090106@fedoraproject.org> Message-ID: <200706222352.40353.opensource@till.name> On Fr Juni 22 2007, Rahul Sundaram wrote: > Maybe we need to enforcing calling it README.distribution or a generic > name like in the Fedora packaging guidelines that so EPEL can reuse the > content or atleast the file name without any issues. In Bugzilla EPEL is called "Fedora EPEL". So a README.Fedora is no problem imho. Regards, Till From dennis at ausil.us Fri Jun 22 22:17:27 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 22 Jun 2007 17:17:27 -0500 Subject: comps.xml Message-ID: <200706221717.27263.dennis@ausil.us> Hey All, I have checked in comps files for epel they should have only packages in epel in them. please make sure that you use update when you add packages to epel Dennis From buildsys at fedoraproject.org Sat Jun 23 21:21:59 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 23 Jun 2007 17:21:59 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-23 Message-ID: <20070623212159.0A255152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 6 NEW babel-0.8-1.el5 : Tools for internationalizing Python applications NEW ctapi-cyberjack-3.0.0-2.el5 : CT-API 1.1 driver for REINER SCT cyberjack USB chipcard reader NEW cvsplot-1.7.4-4.el5 : Collect statistics from CVS controlled files dbmail-2.2.5-5.el5 nas-1.9-1.el5 NEW rzip-2.1-1.el5 : A large-file compression program Packages built and released for Fedora EPEL 4: 3 NEW ctapi-cyberjack-3.0.0-3.el4 : CT-API 1.1 driver for REINER SCT cyberjack USB chipcard reader NEW cvsplot-1.7.4-4.el4 : Collect statistics from CVS controlled files NEW rzip-2.1-1.el4 : A large-file compression program Changes in Fedora EPEL 5: babel-0.8-1.el5 --------------- * Thu Jun 21 2007 Jeffrey C. Ollie - 0.8-1 - First version for Fedora ctapi-cyberjack-3.0.0-2.el5 --------------------------- * Sat Jun 23 2007 Frank B?ttner - 3.0.0-2.el5 - rebuild because of missing file in the cvs system * Sat Jun 23 2007 Frank B?ttner - 3.0.0-1.el5 - final release for 3.0.0 * Thu May 31 2007 Frank B?ttner - 3.0.0beta1-2.el5 - rebuild with the missing file cvsplot-1.7.4-4.el5 ------------------- * Sat Jun 23 2007 Marek Mahut - 1.7.4-4 - rebuild * Thu Jun 14 2007 Marek Mahut - 1.7.4-3 - Added patch for compatibility with gnuplot 4 - Fixing spec file dbmail-2.2.5-5.el5 ------------------ * Sat Jun 23 2007 Bernard Johnson 2.2.5-5 - patch to reopen logs files on -HUP - patch to send error when thread references requested - don't filter libdbmail.so* * Sat Jun 23 2007 Bernard Johnson 2.2.5-4 - kill ld.so config - filter private libraries from provides (bz#245326) * Wed Jun 20 2007 Bernard Johnson 2.2.5-3 - assign uid from package user registry (bz#244611) nas-1.9-1.el5 ------------- * Sun Apr 08 2007 Frank B?ttner - 1.9-1.el5 - update to 1.9 - remove old patch file rzip-2.1-1.el5 -------------- * Sat Dec 30 2006 Paul P Komkoff Jr - 2.1-1 - Added -L compression level option - minor portability fixes - fixed a bug that could cause some files to not be able to be uncompressed Changes in Fedora EPEL 4: ctapi-cyberjack-3.0.0-3.el4 --------------------------- * Sat Jun 23 2007 Frank B?ttner - 3.0.0-3.el4 - disable PC/SC part for EL4 * Sat Jun 23 2007 Frank B?ttner - 3.0.0-2.el4 - rebuild because of missing file in the cvs system * Sat Jun 23 2007 Frank B?ttner - 3.0.0-1.el4 - final release for 3.0.0 * Thu May 31 2007 Frank B?ttner - 3.0.0beta1-2.el4 - rebuild with the missing file cvsplot-1.7.4-4.el4 ------------------- * Sat Jun 23 2007 Marek Mahut - 1.7.4-4 - rebuild * Thu Jun 14 2007 Marek Mahut - 1.7.4-3 - Added patch for compatibility with gnuplot 4 - Fixing spec file rzip-2.1-1.el4 -------------- * Sat Dec 30 2006 Paul P Komkoff Jr - 2.1-1 - Added -L compression level option - minor portability fixes - fixed a bug that could cause some files to not be able to be uncompressed 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 Mon Jun 25 13:42:59 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 25 Jun 2007 15:42:59 +0200 Subject: Readme.fedora files in EPEL In-Reply-To: <200706222352.40353.opensource@till.name> References: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> <467C378B.8090106@fedoraproject.org> <200706222352.40353.opensource@till.name> Message-ID: <467FC663.2020508@leemhuis.info> On 22.06.2007 23:52, Till Maas wrote: > On Fr Juni 22 2007, Rahul Sundaram wrote: > >> Maybe we need to enforcing calling it README.distribution or a generic >> name like in the Fedora packaging guidelines that so EPEL can reuse the >> content or atleast the file name without any issues. > In Bugzilla EPEL is called "Fedora EPEL". So a README.Fedora is no problem > imho. I agree with both of you -- but "README.distribution" IMHO would be the proper solution. Especially if we could get the rest of the world (OpenSuse, ...) to use it as well to mention distribution specific stuff. CU thl From dag at wieers.com Mon Jun 25 13:46:06 2007 From: dag at wieers.com (Dag Wieers) Date: Mon, 25 Jun 2007 15:46:06 +0200 (CEST) Subject: Readme.fedora files in EPEL In-Reply-To: <467FC663.2020508@leemhuis.info> References: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> <467C378B.8090106@fedoraproject.org> <200706222352.40353.opensource@till.name> <467FC663.2020508@leemhuis.info> Message-ID: On Mon, 25 Jun 2007, Thorsten Leemhuis wrote: > On 22.06.2007 23:52, Till Maas wrote: > > On Fr Juni 22 2007, Rahul Sundaram wrote: > > > >> Maybe we need to enforcing calling it README.distribution or a generic > >> name like in the Fedora packaging guidelines that so EPEL can reuse the > >> content or atleast the file name without any issues. > > In Bugzilla EPEL is called "Fedora EPEL". So a README.Fedora is no problem > > imho. > > I agree with both of you -- but "README.distribution" IMHO would be the > proper solution. Especially if we could get the rest of the world > (OpenSuse, ...) to use it as well to mention distribution specific stuff. Like Thorsten's example, please use lowercase for the distribution name. We still have to shoot the NetworkManager people for their bad taste in naming things :) Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From sundaram at fedoraproject.org Mon Jun 25 15:19:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 25 Jun 2007 20:49:33 +0530 Subject: Readme.fedora files in EPEL In-Reply-To: <467FC663.2020508@leemhuis.info> References: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> <467C378B.8090106@fedoraproject.org> <200706222352.40353.opensource@till.name> <467FC663.2020508@leemhuis.info> Message-ID: <467FDD05.7000805@fedoraproject.org> Thorsten Leemhuis wrote: > On 22.06.2007 23:52, Till Maas wrote: >> On Fr Juni 22 2007, Rahul Sundaram wrote: >> >>> Maybe we need to enforcing calling it README.distribution or a generic >>> name like in the Fedora packaging guidelines that so EPEL can reuse the >>> content or atleast the file name without any issues. >> In Bugzilla EPEL is called "Fedora EPEL". So a README.Fedora is no problem >> imho. > > I agree with both of you -- but "README.distribution" IMHO would be the > proper solution. Especially if we could get the rest of the world > (OpenSuse, ...) to use it as well to mention distribution specific stuff. > Thorsten, can you follow this up with FESCo? Rahul From rob.myers at gtri.gatech.edu Mon Jun 25 17:21:50 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 25 Jun 2007 13:21:50 -0400 Subject: EPEL5 dependency report Message-ID: <1182792111.4065.70.camel@rxm-581b.stl.gtri.gatech.edu> Broken deps for x86_64 ---------------------------------------------------------- SDL_mixer - 1.2.7-2.el5.x86_64 requires timidity++ SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ bcfg2 - 0.9.3-2.el5.noarch requires python-lxml bugzilla - 3.0-2.el5.noarch requires perl-Email-Send bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier bugzilla - 3.0-2.el5.noarch requires perl-Email-Address ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi ctapi-cyberjack-pcsc - 3.0.0-2.el5.x86_64 requires libctapi-cyberjack.so.2()(64bit) fail2ban - 0.6.2-3.el5.noarch requires shorewall git-arch - 1.5.2.1-2.el5.x86_64 requires tla git-cvs - 1.5.2.1-2.el5.x86_64 requires cvsps gmrun - 0.9.2-7.el5.x86_64 requires xterm gnucash - 2.0.5-3.1.el5.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-3.1.el5.x86_64 requires libgwrap-guile-runtime.so.0()(64bit) gnucash - 2.0.5-3.1.el5.x86_64 requires libofx.so.3()(64bit) gnucash - 2.0.5-3.1.el5.x86_64 requires libgwrap-core-runtime.so.0()(64bit) nagios-plugins-fping - 1.4.6-3.el5.x86_64 requires /usr/sbin/fping nagios-plugins-game - 1.4.6-3.el5.x86_64 requires qstat nagios-plugins-ifoperstatus - 1.4.6-3.el5.x86_64 requires perl(Net::SNMP) nagios-plugins-ifstatus - 1.4.6-3.el5.x86_64 requires perl(Net::SNMP) ntfs-config - 1.0-0.3.rc4.el5.noarch requires ntfs-3g ofx - 0.8.3-4.el5.x86_64 requires libofx.so.3()(64bit) perl-Net-Pcap - 0.14-2.el5.x86_64 requires perl(IO::Interface) perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core python-Coherence - 0.2.1-3.el5.noarch requires python-nevow python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy qucs - 0.0.12-2.el5.x86_64 requires iverilog redet - 8.22-4.el5.noarch requires iwidgets rss2email - 2.60-3.el5.noarch requires python-feedparser translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant zabbix - 1.1.7-1.el5.1.x86_64 requires fping Broken deps for i386 ---------------------------------------------------------- SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ bcfg2 - 0.9.3-2.el5.noarch requires python-lxml bugzilla - 3.0-2.el5.noarch requires perl-Email-Send bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier bugzilla - 3.0-2.el5.noarch requires perl-Email-Address ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi fail2ban - 0.6.2-3.el5.noarch requires shorewall git-arch - 1.5.2.1-2.el5.i386 requires tla git-cvs - 1.5.2.1-2.el5.i386 requires cvsps gmrun - 0.9.2-7.el5.i386 requires xterm nagios-plugins-fping - 1.4.6-3.el5.i386 requires /usr/sbin/fping nagios-plugins-game - 1.4.6-3.el5.i386 requires qstat nagios-plugins-ifoperstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) nagios-plugins-ifstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) ntfs-config - 1.0-0.3.rc4.el5.noarch requires ntfs-3g perl-Net-Pcap - 0.14-2.el5.i386 requires perl(IO::Interface) perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core python-Coherence - 0.2.1-3.el5.noarch requires python-nevow python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy qucs - 0.0.12-2.el5.i386 requires iverilog redet - 8.22-4.el5.noarch requires iwidgets rss2email - 2.60-3.el5.noarch requires python-feedparser translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant zabbix - 1.1.7-1.el5.1.i386 requires fping From notting at redhat.com Mon Jun 25 18:02:11 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 25 Jun 2007 14:02:11 -0400 Subject: EPEL5 dependency report In-Reply-To: <1182792111.4065.70.camel@rxm-581b.stl.gtri.gatech.edu> References: <1182792111.4065.70.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <20070625180211.GA14914@nostromo.devel.redhat.com> rob myers (rob.myers at gtri.gatech.edu) said: > Broken deps for x86_64 Is there a broken push? For example... > gnucash - 2.0.5-3.1.el5.x86_64 requires libaqbanking.so.16()(64bit) > gnucash - 2.0.5-3.1.el5.x86_64 requires libgwrap-guile-runtime.so.0()(64bit) > gnucash - 2.0.5-3.1.el5.x86_64 requires libofx.so.3()(64bit) > gnucash - 2.0.5-3.1.el5.x86_64 requires libgwrap-core-runtime.so.0()(64bit) ... there's no way this could have *built* and have this be the case. Also, the packages appear to be there on download.fedora. Bill From rob.myers at gtri.gatech.edu Mon Jun 25 20:09:23 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 25 Jun 2007 16:09:23 -0400 Subject: EPEL5 dependency report In-Reply-To: <20070625180211.GA14914@nostromo.devel.redhat.com> References: <1182792111.4065.70.camel@rxm-581b.stl.gtri.gatech.edu> <20070625180211.GA14914@nostromo.devel.redhat.com> Message-ID: <1182802163.4065.72.camel@rxm-581b.stl.gtri.gatech.edu> On Mon, 2007-06-25 at 14:02 -0400, Bill Nottingham wrote: > rob myers (rob.myers at gtri.gatech.edu) said: > > Broken deps for x86_64 > > Is there a broken push? For example... > > > gnucash - 2.0.5-3.1.el5.x86_64 requires libaqbanking.so.16()(64bit) > > gnucash - 2.0.5-3.1.el5.x86_64 requires libgwrap-guile-runtime.so.0()(64bit) > > gnucash - 2.0.5-3.1.el5.x86_64 requires libofx.so.3()(64bit) > > gnucash - 2.0.5-3.1.el5.x86_64 requires libgwrap-core-runtime.so.0()(64bit) > > ... there's no way this could have *built* and have this be the > case. Also, the packages appear to be there on download.fedora. thanks bill, looks like i've got an issue here. i'll have to investigate... rob. From buildsys at fedoraproject.org Tue Jun 26 13:12:52 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 26 Jun 2007 09:12:52 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-26 Message-ID: <20070626131252.B4CD9152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 9 NEW bash-completion-20060301-4.el5 : Programmable completion for Bash bcfg2-0.9.4-2.el5 NEW eclipse-checkstyle-4.0.1-6.el5 : Checkstyle plugin for Eclipse NEW fortune-mod-1.99.1-7.el5 : A program which will display a fortune libupnp-1.6.0-1.el5 mock-0.7.2-1.el5 NEW muParser-1.27-5.el5 : A fast math parser library NEW recode-3.6-24.el5 : Conversion between character sets and surfaces ushare-0.9.10-3.el5 Packages built and released for Fedora EPEL 4: 8 NEW bash-completion-20060301-4.el4 : Programmable completion for Bash bcfg2-0.9.4-2.el4 NEW fortune-mod-1.99.1-4.el4 : A program which will display a fortune libupnp-1.6.0-1.el4 mock-0.7.2-1.el4 NEW muParser-1.27-5.el4 : A fast math parser library NEW recode-3.6-24.el4 : Conversion between character sets and surfaces ushare-0.9.10-3.el4 Changes in Fedora EPEL 5: bash-completion-20060301-4.el5 ------------------------------ * Sun Jun 24 2007 Jeff Sheltren - 20060301-4 - Update triggers to work with older versions of RPM bcfg2-0.9.4-2.el5 ----------------- * Mon Jun 25 2007 Jeffrey C. Ollie - 0.9.4-2 - Bump revision and rebuild * Mon Jun 25 2007 Jeffrey C. Ollie - 0.9.4-1 - Update to 0.9.4 final * Thu Jun 21 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre4 - Update to 0.9.4pre4 * Thu Jun 14 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre3 - Update to 0.9.4pre3 * Tue Jun 12 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre2 - Update to 0.9.4pre2 eclipse-checkstyle-4.0.1-6.el5 ------------------------------ * Wed May 16 2007 Rob Myers 4.0.1-6 - remove epoch from changelog fortune-mod-1.99.1-7.el5 ------------------------ * Sat Sep 09 2006 Jeff Sheltren 1.99.1-7 - bump release for buildsystem libupnp-1.6.0-1.el5 ------------------- * Wed Jun 13 2007 Eric Tanguy - 1.6.0-1 - Update to version 1.6.0 mock-0.7.2-1.el5 ---------------- * Wed Jun 13 2007 Michael Brown - 0.7.1-1 - Fix problem with autocache where different users couldnt share same cache - Fix problem creating resolv.conf in rootfs - cleanup perms on rootfs /etc/ muParser-1.27-5.el5 ------------------- * Fri Jun 15 2007 Frank B?ttner - 1.27-5.el5 - fix bug #244309 * Fri Jun 08 2007 Frank B?ttner - 1.27-4.el5 - fix depend on pkgconfig * Wed Jun 06 2007 Frank B?ttner - 1.27-3.el5 - clean build root before run install part - fix missing pkconfig file recode-3.6-24.el5 ----------------- * Sat Jun 23 2007 Jeff Sheltren 3.6-24 - rebuild for EPEL ushare-0.9.10-3.el5 ------------------- * Sat May 05 2007 Eric Tanguy - 0.9.10-3 - Rebuild for libupnp-1.6.0 * Sat May 05 2007 Eric Tanguy - 0.9.10-2 - Rebuild Changes in Fedora EPEL 4: bash-completion-20060301-4.el4 ------------------------------ * Sun Jun 24 2007 Jeff Sheltren - 20060301-4 - Update triggers to work with older versions of RPM bcfg2-0.9.4-2.el4 ----------------- * Mon Jun 25 2007 Jeffrey C. Ollie - 0.9.4-2 - Bump revision and rebuild * Mon Jun 25 2007 Jeffrey C. Ollie - 0.9.4-1 - Update to 0.9.4 final * Thu Jun 21 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre4 - Update to 0.9.4pre4 * Thu Jun 14 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre3 - Update to 0.9.4pre3 * Tue Jun 12 2007 Jeffrey C. Ollie - 0.9.4-0.1.pre2 - Update to 0.9.4pre2 fortune-mod-1.99.1-4.el4 ------------------------ * Tue Oct 04 2005 Jeff Sheltren 1.99.1-4 - Move fortunes into _datadir/games/fortune libupnp-1.6.0-1.el4 ------------------- * Wed Jun 13 2007 Eric Tanguy - 1.6.0-1 - Update to version 1.6.0 mock-0.7.2-1.el4 ---------------- * Wed Jun 13 2007 Michael Brown - 0.7.1-1 - Fix problem with autocache where different users couldnt share same cache - Fix problem creating resolv.conf in rootfs - cleanup perms on rootfs /etc/ muParser-1.27-5.el4 ------------------- * Fri Jun 15 2007 Frank B?ttner - 1.27-5.el4 - fix bug #244309 * Fri Jun 08 2007 Frank B?ttner - 1.27-4.el4 - fix depend on pkgconfig * Wed Jun 06 2007 Frank B?ttner - 1.27-3.el4 - clean build root before run install part - fix missing pkconfig file recode-3.6-24.el4 ----------------- * Sat Jun 23 2007 Jeff Sheltren 3.6-24 - rebuild for EPEL ushare-0.9.10-3.el4 ------------------- * Sat May 05 2007 Eric Tanguy - 0.9.10-3 - Rebuild for libupnp-1.6.0 * Sat May 05 2007 Eric Tanguy - 0.9.10-2 - Rebuild For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From dev at nigelj.com Tue Jun 26 14:10:00 2007 From: dev at nigelj.com (Nigel Jones) Date: Wed, 27 Jun 2007 02:10:00 +1200 (NZST) Subject: EPEL5 dependency report Message-ID: <52129.202.154.148.243.1182867000.squirrel@webmail.nigelj.com> > Broken deps for x86_64 > ---------------------------------------------------------- > redet - 8.22-4.el5.noarch requires iwidgets > > > > Broken deps for i386 > ---------------------------------------------------------- > redet - 8.22-4.el5.noarch requires iwidgets Drats, I'll contact the iwidgets maintainer later today > > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > From fedora at leemhuis.info Tue Jun 26 18:14:33 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 26 Jun 2007 20:14:33 +0200 Subject: EPEL report week 25, 2007 Message-ID: <46815789.3000009@leemhuis.info> (sorry, a bit late this week) http://fedoraproject.org/wiki/EPEL/Reports/Week25 = Weekly EPEL Summary = Week 25/2007 == Most important happenings == We'll likely fill the Vacant Steering Committee Seat over the next week; so if you are interested let knurd know! == EPEL SIG Meeting == === Attending === >From the Steering Committee: * mmcgrath (MikeMcGrath) * nirik (KevinFenzi) * dgilmore (DennisGilmore) * stahnma (MichaelStahnke) * quiad (KarstenWade) (had fun at the dentist) Missing from the Steering Committee: * knurd (ThorstenLeemhuis) (partly) Others that participated the meeting: rdieter, _blah_, === Summary === * Finish the wiki -- quaid * quaid > I think all of you have done a good job of making the content ... full and rich ; so it's a few hours of edits left ; I'll be able to do an hour today, for sure, so again ... should be done by the end of the week :) * Repo-layout * looks like Fedora will keep lmacken and mbonnet busy for a while; so we should might towards a solution to annouce epel, but use plague and the old extras push-scripts for the near future; or go without testing for nowdiscuss further on the list * some discussion if we want stable and rolling releases * Make sure the repo is in good shape * we maybe should run the dependency checker script regularly; mmcgrath will look into this * Announce EPEL officially * mmcgrath> so we're blocking on the wiki as well as the build stuff. So thats the end of the big picture tasks really. * Vacant seat in the steering committee * will get discussed on the list * Free Discussion: * some discussion around RHX and if EPEL can package stuff that's part of it; see full log for details === Full Log === https://www.redhat.com/archives/epel-devel-list/2007-June/msg00056.html == Stats == === General === Number of EPEL Contributors 98 We welcome 8 new contributors: alex_AT_dalloz.de, i_AT_stingr.net, jjohnstn_AT_redhat.com, john_AT_ncphotography.com, jonathansteffan_AT_gmail.com, lists_AT_forevermore.net, otaylor_AT_redhat.com, overholt_AT_redhat.com, robert_AT_marcanoonline.com, than_AT_redhat.com === EPEL 5 === Number of source packages: 393 Number of binary packages: 641 There are 34 new Packages: * aqbanking | A library for online banking functions and financial data import/export * asciidoc | Text based document generation * babel | Tools for internationalizing Python applications * bash-completion | Programmable completion for Bash * checkstyle | Java source code checker * ctapi-cyberjack | CT-API 1.1 driver for REINER SCT cyberjack USB chipcard reader * cvsplot | Collect statistics from CVS controlled files * eclipse-cdt | Eclipse C/C++ Development Tools (CDT) plugin * eclipse-checkstyle | Checkstyle plugin for Eclipse * fortune-mod | A program which will display a fortune * ganymed-ssh2 | SSH-2 protocol implementation in pure Java * git | Git core and tools * gnucash-docs | Help files and documentation for the GnuCash personal finanace manager * gnucash | GnuCash is an application to keep track of your finances * gwenhywfar | A multi-platform helper library for other libraries * g-wrap | A tool for creating Scheme interfaces to C libraries * jakarta-commons-cli | Command Line Interface Library for Java * kmymoney2 | Personal finance * libofx | A library for supporting Open Financial Exchange (OFX) * mercurial | A fast, lightweight distributed source control management system * mksh | MirBSD enhanced version of the Korn Shell * mod_security | Security module for the Apache HTTP Server * muParser | A fast math parser library * perl-Finance-Quote | A Perl module that retrieves stock and mutual fund quotes * perl-HTML-TableExtract | A Perl module for extracting content in HTML tables * pfqueue | Queue manager for the Postfix/Exim Mail Transport Agents * postgresql-table_log | Log data changes in a PostgreSQL table * reciteword | Recite Word Easily * recode | Conversion between character sets and surfaces * rsnapshot | Local and remote filesystem snapshot utility * rzip | A large-file compression program * sec | SEC (simple event correlator) * slib | Platform independent library for scheme * svnkit | Pure Java Subversion client library * tcptraceroute | A traceroute implementation using TCP packets === EPEL 4 === Number of source packages: 248 Number of binary packages: 460 There are 18 new Packages: * aqbanking | A library for online banking functions and financial data import/export * bash-completion | Programmable completion for Bash * ctapi-cyberjack | CT-API 1.1 driver for REINER SCT cyberjack USB chipcard reader * cvsplot | Collect statistics from CVS controlled files * fortune-mod | A program which will display a fortune * git | Git core and tools * gnucash-docs | Help files and documentation for the GnuCash personal finanace manager * gnucash | GnuCash is an application to keep track of your finances * gwenhywfar | A multi-platform helper library for other libraries * g-wrap | A tool for creating Scheme interfaces to C libraries * libofx | A library for supporting Open Financial Exchange (OFX) * mercurial | A fast, lightweight distributed source control management system * mksh | MirBSD enhanced version of the Korn Shell * muParser | A fast math parser library * perl-Finance-Quote | A Perl module that retrieves stock and mutual fund quotes * perl-HTML-TableExtract | A Perl module for extracting content in HTML tables * pfqueue | Queue manager for the Postfix/Exim Mail Transport Agents * recode | Conversion between character sets and surfaces * rzip | A large-file compression program ---- ["CategoryEPELReports"] From buildsys at fedoraproject.org Wed Jun 27 13:09:45 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 27 Jun 2007 09:09:45 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-27 Message-ID: <20070627130945.E3D67152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 5 NEW bzr-0.15-1.el5 : Friendly distributed version control system ntfs-config-1.0-0.4.rc5.el5 NEW python-memcached-1.36-3.el5 : A Python memcached client library NEW python-paramiko-1.6.4-1.el5 : A SSH2 protocol library for python reciteword-0.8.3-4.el5 Packages built and released for Fedora EPEL 4: 0 Changes in Fedora EPEL 5: bzr-0.15-1.el5 -------------- * Thu Mar 22 2007 Toshio Kuratomi - 0.15-1 - Update to 0.15. - Simplify the %files list. ntfs-config-1.0-0.4.rc5.el5 --------------------------- * Tue Jun 26 2007 Xavier Lamien - 1.0-0.4.rc5 - Udpated Release. python-memcached-1.36-3.el5 --------------------------- * Sun Jun 10 2007 Sean Reifschneider 1.36-3 - Changes based on feedback from Ruben Kerkhof: - Fixing license. - Removing PKG-INFO from doc. - Fixing summary. - Removing setuptools build dependency. - Changing permissions of memcache module to * Sat Jun 09 2007 Sean Reifschneider 1.36-2 - Adding python-devel build requirement. * Sat Jun 09 2007 Sean Reifschneider 1.36-1 - Initial RPM spec file. python-paramiko-1.6.4-1.el5 --------------------------- * Sat Dec 09 2006 Toshio Kuratomi - 1.6.4-1 - Update to 1.6.4 - Upstream is now shipping tarballs - Bump for python 2.5 in devel reciteword-0.8.3-4.el5 ---------------------- * Wed Jun 27 2007 Hu Zheng - 0.8.3-4 - Fix no .mo file problem. Changes in Fedora EPEL 4: For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Wed Jun 27 15:04:56 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 27 Jun 2007 17:04:56 +0200 Subject: Readme.fedora files in EPEL In-Reply-To: <467FDD05.7000805@fedoraproject.org> References: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> <467C378B.8090106@fedoraproject.org> <200706222352.40353.opensource@till.name> <467FC663.2020508@leemhuis.info> <467FDD05.7000805@fedoraproject.org> Message-ID: <46827C98.1070105@leemhuis.info> On 25.06.2007 17:19, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> On 22.06.2007 23:52, Till Maas wrote: >>> On Fr Juni 22 2007, Rahul Sundaram wrote: >>> >>>> Maybe we need to enforcing calling it README.distribution or a generic >>>> name like in the Fedora packaging guidelines that so EPEL can reuse the >>>> content or atleast the file name without any issues. >>> In Bugzilla EPEL is called "Fedora EPEL". So a README.Fedora is no problem >>> imho. >> I agree with both of you -- but "README.distribution" IMHO would be the >> proper solution. Especially if we could get the rest of the world >> (OpenSuse, ...) to use it as well to mention distribution specific stuff. > Thorsten, can you follow this up with FESCo? I'd be glad if someone else could take care of it. Any volunteers? BTW, isn't the Fedora Packaging Committee the proper place for this? CU thl From fedora at leemhuis.info Wed Jun 27 15:15:20 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 27 Jun 2007 17:15:20 +0200 Subject: Proposal for final repolayout In-Reply-To: <20070620121402.498fdb76@ghistelwchlohm.scrye.com> References: <4677D000.30005@leemhuis.info> <20070620121402.498fdb76@ghistelwchlohm.scrye.com> Message-ID: <46827F08.1040905@leemhuis.info> Sorry, still a bit in "was on vacation and there are lots of mails to answer" mode... On 20.06.2007 20:14, Kevin Fenzi wrote: > On Tue, 19 Jun 2007 14:45:52 +0200 > fedora at leemhuis.info (Thorsten Leemhuis) wrote: > [...] >> Please ignore the "rolling" stuff as well; it seems some people would >> like to have a more "Fedora Extras" like EPEL with a bold update >> policy (always latest and greatest). I'd like to leave the path for >> this open in the long term, that why I'd say we should put the >> current EPEL stuff below "stable". > I think this adds to confusion... Yes, it's a bit more confusion, but I more and more tend to think it's worth the trouble, as some people for some purposes want latest and greatest. And it seems to me some contributors would like that as well. With a proper yum plugin we maybe in the long term might be able to say "use RHEL and EPEL-stable repo, but get foo and it's deps from EPEL-rolling" > I thought we had determined that EPEL > was going to target more 'stable' type update methods? That's what the normal repo would be for. > Folks wanting a really fast a furious update should use another repo > that does that, or perhaps they could always have updates-testing > enabled (although that might not be fast enough for them). We defined that the testing dir becomes the next stable when RH ships the next quarterly update. So you can't push foo-2.0 there if you don#t want that in EPEL-stable in the long term. >> How to realize the layout: have two different plague-targets per >> release; the default target is "testing/(release())"; that repo >> becomes the stable release automatically when RH ships a new >> quarterly update. If you want to get something into the stable repo >> for the current release use a special build target, from which the >> extras-push-scripts push into the proper dir directly. > Humm... that might work. I don't know enough of how the push scripts > work currently. perhaps Dgilmore could comment? Dglimore? here it is in other words: Define different plague targets; e.g. EPEL5-stable and EPEL5-testing; configure different targets for the push scripts. The everything build for EPEL5-testing could land into testing/ and EPEL5-stable in the proper dir. Testing then could manually be moved to stable on update (e.g. 5.1). But there is no way to move something from testing to stable that way. So if you want something in stable tested first you'd need to build it for testing first, and for stable again later. Not nice, but could work. >> Comments? > All sounds good except I would skip the 'stable/rolling' dirs. I'd just like to leave that path open for the long term. CU thl From rob.myers at gtri.gatech.edu Wed Jun 27 16:52:35 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Wed, 27 Jun 2007 12:52:35 -0400 Subject: EPEL5 dependency report In-Reply-To: <1182802163.4065.72.camel@rxm-581b.stl.gtri.gatech.edu> References: <1182792111.4065.70.camel@rxm-581b.stl.gtri.gatech.edu> <20070625180211.GA14914@nostromo.devel.redhat.com> <1182802163.4065.72.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <1182963155.4065.84.camel@rxm-581b.stl.gtri.gatech.edu> On Mon, 2007-06-25 at 16:09 -0400, rob myers wrote: > On Mon, 2007-06-25 at 14:02 -0400, Bill Nottingham wrote: > > rob myers (rob.myers at gtri.gatech.edu) said: > > > Broken deps for x86_64 > > > > Is there a broken push? For example... > > > > > gnucash - 2.0.5-3.1.el5.x86_64 requires libaqbanking.so.16()(64bit) > > > gnucash - 2.0.5-3.1.el5.x86_64 requires libgwrap-guile-runtime.so.0()(64bit) > > > gnucash - 2.0.5-3.1.el5.x86_64 requires libofx.so.3()(64bit) > > > gnucash - 2.0.5-3.1.el5.x86_64 requires libgwrap-core-runtime.so.0()(64bit) > > > > ... there's no way this could have *built* and have this be the > > case. Also, the packages appear to be there on download.fedora. > > thanks bill, looks like i've got an issue here. i'll have to > investigate... one problem seems to be solved (we dropped some 64bit stuff on the floor), but take this list with a grain of salt and please let me know if there are other inaccuracies. Broken deps for x86_64 ---------------------------------------------------------- SDL_mixer - 1.2.7-2.el5.x86_64 requires timidity++ SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ bcfg2 - 0.9.3-2.el5.noarch requires python-lxml bugzilla - 3.0-2.el5.noarch requires perl-Email-Send bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier bugzilla - 3.0-2.el5.noarch requires perl-Email-Address ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi ctapi-cyberjack - 3.0.0-2.el5.x86_64 requires /usr/lib64/ctapi fail2ban - 0.6.2-3.el5.noarch requires shorewall git-arch - 1.5.2.1-2.el5.x86_64 requires tla git-cvs - 1.5.2.1-2.el5.x86_64 requires cvsps gmrun - 0.9.2-7.el5.x86_64 requires xterm nagios-plugins-fping - 1.4.6-3.el5.x86_64 requires /usr/sbin/fping nagios-plugins-game - 1.4.6-3.el5.x86_64 requires qstat nagios-plugins-ifoperstatus - 1.4.6-3.el5.x86_64 requires perl(Net::SNMP) nagios-plugins-ifstatus - 1.4.6-3.el5.x86_64 requires perl(Net::SNMP) ntfs-config - 1.0-0.3.rc4.el5.noarch requires ntfs-3g perl-Net-Pcap - 0.14-2.el5.x86_64 requires perl(IO::Interface) perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core python-Coherence - 0.2.1-3.el5.noarch requires python-nevow python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy qucs - 0.0.12-2.el5.x86_64 requires iverilog redet - 8.22-4.el5.noarch requires iwidgets rss2email - 2.60-3.el5.noarch requires python-feedparser translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant zabbix - 1.1.7-1.el5.1.x86_64 requires fping Broken deps for i386 ---------------------------------------------------------- SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ bcfg2 - 0.9.3-2.el5.noarch requires python-lxml bugzilla - 3.0-2.el5.noarch requires perl-Email-Send bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier bugzilla - 3.0-2.el5.noarch requires perl-Email-Address ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi fail2ban - 0.6.2-3.el5.noarch requires shorewall git-arch - 1.5.2.1-2.el5.i386 requires tla git-cvs - 1.5.2.1-2.el5.i386 requires cvsps gmrun - 0.9.2-7.el5.i386 requires xterm nagios-plugins-fping - 1.4.6-3.el5.i386 requires /usr/sbin/fping nagios-plugins-game - 1.4.6-3.el5.i386 requires qstat nagios-plugins-ifoperstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) nagios-plugins-ifstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) ntfs-config - 1.0-0.3.rc4.el5.noarch requires ntfs-3g perl-Net-Pcap - 0.14-2.el5.i386 requires perl(IO::Interface) perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core python-Coherence - 0.2.1-3.el5.noarch requires python-nevow python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy qucs - 0.0.12-2.el5.i386 requires iverilog redet - 8.22-4.el5.noarch requires iwidgets rss2email - 2.60-3.el5.noarch requires python-feedparser translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant zabbix - 1.1.7-1.el5.1.i386 requires fping rob. From notting at redhat.com Wed Jun 27 17:44:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Jun 2007 13:44:07 -0400 Subject: excludearch trackers? Message-ID: <20070627174407.GB29669@nostromo.devel.redhat.com> I've got a package in EPEL that I have to ExcludeArch (gnucash, EPEL4, x86_64). While my reason isn't the normal reason for doing it (see bug #203761), I was wondering - do we want separate ExcludeArch tracking bugs for EPEL, or should we just piggyback on the Fedora ones? Bill From buildsys at fedoraproject.org Wed Jun 27 20:03:02 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 27 Jun 2007 16:03:02 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-27 Message-ID: <20070627200302.575D5152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 0 Packages built and released for Fedora EPEL 4: 0 Changes in Fedora EPEL 5: Changes in Fedora EPEL 4: For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From orion at cora.nwra.com Wed Jun 27 20:06:25 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 27 Jun 2007 14:06:25 -0600 Subject: xfce for EPEL? Message-ID: <4682C341.1040105@cora.nwra.com> Has anyone been working on xfce for EPEL? -- 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 buildsys at fedoraproject.org Wed Jun 27 20:09:55 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 27 Jun 2007 16:09:55 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-27 Message-ID: <20070627200955.52A80152134@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 0 Packages built and released for Fedora EPEL 4: 0 Changes in Fedora EPEL 5: Changes in Fedora EPEL 4: For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From kevin at tummy.com Wed Jun 27 20:14:21 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 27 Jun 2007 14:14:21 -0600 Subject: xfce for EPEL? In-Reply-To: <4682C341.1040105@cora.nwra.com> References: <4682C341.1040105@cora.nwra.com> Message-ID: <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> On Wed, 27 Jun 2007 14:06:25 -0600 orion at cora.nwra.com (Orion Poplawski) wrote: > Has anyone been working on xfce for EPEL? Yeah. I wasn't sure if I wanted to push it out for EPEL or not. CentOS has it available in their extras repository now. I am leaning toward going ahead and adding to EPEL (at least 5) and trying to keep it in sync with the CentOS versions. Any thoughts/Opinions? kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Michael_E_Brown at dell.com Wed Jun 27 20:28:38 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 27 Jun 2007 15:28:38 -0500 Subject: Fedora EPEL Package Build Report 2007-06-27 In-Reply-To: <20070627200955.52A80152134@buildsys.fedoraproject.org> References: <20070627200955.52A80152134@buildsys.fedoraproject.org> Message-ID: <20070627202838.GA19701@humbolt.us.dell.com> On Wed, Jun 27, 2007 at 04:09:55PM -0400, buildsys at fedoraproject.org wrote: > > Packages built and released for Fedora EPEL 5: 0 Would it be possible to skip mailing the report if the numbers are all 0? -- Michael From pertusus at free.fr Wed Jun 27 20:25:05 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 27 Jun 2007 22:25:05 +0200 Subject: xfce for EPEL? In-Reply-To: <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> References: <4682C341.1040105@cora.nwra.com> <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> Message-ID: <20070627202505.GA8013@free.fr> On Wed, Jun 27, 2007 at 02:14:21PM -0600, Kevin Fenzi wrote: > On Wed, 27 Jun 2007 14:06:25 -0600 > orion at cora.nwra.com (Orion Poplawski) wrote: > > > Has anyone been working on xfce for EPEL? > > Yeah. > > I wasn't sure if I wanted to push it out for EPEL or not. > CentOS has it available in their extras repository now. In that case I guess the best would be to contact the maintainer of xfce at Centos and try to make fedora and Centos xfce converge before adding it to EPEL. -- Pat From orion at cora.nwra.com Wed Jun 27 20:30:54 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 27 Jun 2007 14:30:54 -0600 Subject: xfce for EPEL? In-Reply-To: <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> References: <4682C341.1040105@cora.nwra.com> <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> Message-ID: <4682C8FE.8080504@cora.nwra.com> Kevin Fenzi wrote: > On Wed, 27 Jun 2007 14:06:25 -0600 > orion at cora.nwra.com (Orion Poplawski) wrote: > >> Has anyone been working on xfce for EPEL? > > Yeah. > > I wasn't sure if I wanted to push it out for EPEL or not. > CentOS has it available in their extras repository now. > > I am leaning toward going ahead and adding to EPEL (at least 5) and > trying to keep it in sync with the CentOS versions. > > Any thoughts/Opinions? > > kevin Hmm, somehow forgot about CentOS extras. In this case I don't really care where it comes from as long as it's available. I suppose this all falls under the larger repo cooperation issue... -- 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 kevin at tummy.com Wed Jun 27 20:32:42 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 27 Jun 2007 14:32:42 -0600 Subject: xfce for EPEL? In-Reply-To: <20070627202505.GA8013@free.fr> References: <4682C341.1040105@cora.nwra.com> <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> <20070627202505.GA8013@free.fr> Message-ID: <20070627143242.3e81f12a@ghistelwchlohm.scrye.com> On Wed, 27 Jun 2007 22:25:05 +0200 pertusus at free.fr (Patrice Dumas) wrote: > On Wed, Jun 27, 2007 at 02:14:21PM -0600, Kevin Fenzi wrote: > > On Wed, 27 Jun 2007 14:06:25 -0600 > > orion at cora.nwra.com (Orion Poplawski) wrote: > > > > > Has anyone been working on xfce for EPEL? > > > > Yeah. > > > > I wasn't sure if I wanted to push it out for EPEL or not. > > CentOS has it available in their extras repository now. > > In that case I guess the best would be to contact the maintainer > of xfce at Centos and try to make fedora and Centos xfce converge > before adding it to EPEL. Luckily I have already talked with him. :) The specs they are using are mine, so they should match pretty closely with what I have now. ;) I don't think they needed to make any changes from the Fedora specs, although I will have to check each package carefully to make sure of that. > Pat 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 Wed Jun 27 20:38:22 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 27 Jun 2007 14:38:22 -0600 Subject: xfce for EPEL? In-Reply-To: <4682C8FE.8080504@cora.nwra.com> References: <4682C341.1040105@cora.nwra.com> <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> <4682C8FE.8080504@cora.nwra.com> Message-ID: <20070627143822.1b8461b5@ghistelwchlohm.scrye.com> On Wed, 27 Jun 2007 14:30:54 -0600 orion at cora.nwra.com (Orion Poplawski) wrote: > Hmm, somehow forgot about CentOS extras. In this case I don't really > care where it comes from as long as it's available. I suppose this > all falls under the larger repo cooperation issue... Yeah. I think it might be good to push into EPEL as well so that those folks that only have EPEL enabled have access to it. Personally I use centos here, so the centos extras would be enough for me. :) 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 Jun 28 04:36:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 28 Jun 2007 06:36:48 +0200 Subject: xfce for EPEL? In-Reply-To: <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> References: <4682C341.1040105@cora.nwra.com> <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> Message-ID: <46833AE0.3040606@leemhuis.info> On 27.06.2007 22:14, Kevin Fenzi wrote: > On Wed, 27 Jun 2007 14:06:25 -0600 > orion at cora.nwra.com (Orion Poplawski) wrote: > >> Has anyone been working on xfce for EPEL? > Yeah. > [...] > I am leaning toward going ahead and adding to EPEL (at least 5) and > trying to keep it in sync with the CentOS versions. +1 CU thl From kevin at tummy.com Thu Jun 28 05:07:42 2007 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 27 Jun 2007 23:07:42 -0600 Subject: EPEL4 broken deps Re: EPEL5 dependency report In-Reply-To: <1182963155.4065.84.camel@rxm-581b.stl.gtri.gatech.edu> References: <1182792111.4065.70.camel@rxm-581b.stl.gtri.gatech.edu> <20070625180211.GA14914@nostromo.devel.redhat.com> <1182802163.4065.72.camel@rxm-581b.stl.gtri.gatech.edu> <1182963155.4065.84.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <20070627230742.1e7c2395@ghistelwchlohm.scrye.com> Here's what I see broken in EPEL4 (at least against centos4.5): Checking Dependencies Repos looked at: 5 epel update base addons extras Num Packages in Repos: 2812 package: python-psycopg2-zope - 2.0.6-1.el4.x86_64 from epel unresolved deps: zope package: python-Coherence - 0.2.1-3.el4.noarch from epel unresolved deps: python-twisted-web python-nevow python-twisted-core python-configobj SOAPpy package: redet - 8.22-4.el4.noarch from epel unresolved deps: iwidgets package: zabbix - 1.1.6-1.el4.x86_64 from epel unresolved deps: fping package: nagios-plugins-fping - 1.4.6-3.el4.x86_64 from epel unresolved deps: /usr/sbin/fping package: ctapi-cyberjack - 3.0.0-3.el4.x86_64 from epel unresolved deps: /usr/lib64/ctapi package: perl-libwhisker2 - 2.4-3.el4.noarch from epel unresolved deps: perl(MD5) package: python-psycopg2-zope - 2.0.5.1-8.el4.x86_64 from epel unresolved deps: zope package: perl-libwhisker2 - 2.4-2.el4.noarch from epel unresolved deps: perl(MD5) package: mimedefang - 2.62-2.el4.x86_64 from epel unresolved deps: perl(MIME::Words) perl(MIME::Parser) perl(MIME::Base64) >= 0:3.03 perl(MIME::Tools) >= 0:5.410 package: mock - 0.7.1-1.el4.x86_64 from epel unresolved deps: yum >= 0:3.0 package: bugzilla-contrib - 2.22.2-1.el4.noarch from epel unresolved deps: perl(MIME::Parser) package: postgresql-pgpoolAdmin - 1.0.0-6.el4.noarch from epel unresolved deps: php-pgsql >= 0:4.4.2 php >= 0:4.4.2 package: ghex - 2.8.2-4.el4.i386 from epel unresolved deps: libgnomeui-2.so.0 libbonoboui-2.so.0 package: git-cvs - 1.5.2.1-2.el4.x86_64 from epel unresolved deps: cvsps package: rss2email - 2.60-3.el4.noarch from epel unresolved deps: python-feedparser package: bcfg2 - 0.9.3-2.el4.noarch from epel unresolved deps: python-lxml package: nagios-plugins-game - 1.4.6-3.el4.x86_64 from epel unresolved deps: qstat package: specto - 0.2.0-4.el4.noarch from epel unresolved deps: notify-python package: git-arch - 1.5.2.1-2.el4.x86_64 from epel unresolved deps: tla package: otrs - 2.1.5-2.el4.noarch from epel unresolved deps: perl(MIME::Words) perl(MIME::Parser) perl-GDGraph perl(Date::Pcalc) perl(Compress::Zlib) perl(MIME::Entity) package: SDL_mixer - 1.2.6-8.el4.i386 from epel unresolved deps: timidity++ package: libgnomeuimm26 - 2.8.0-1.el4.i386 from epel unresolved deps: libgnomeui-2.so.0 libbonoboui-2.so.0 package: qucs - 0.0.12-2.el4.x86_64 from epel unresolved deps: iverilog package: sqlgrey - 1.7.5-1.el4.noarch from epel unresolved deps: perl(DBD::SQLite) package: openoffice.org2-pyuno - 1:2.0.4-5.7.0.1.0.i386 from update unresolved deps: libpython2.3.so.1.0 package: openoffice.org2-pyuno - 1:2.0.4-5.7.0.i386 from update unresolved deps: libpython2.3.so.1.0 package: nagios - 2.7-2.el4.i386 from epel unresolved deps: libperl.so package: bugzilla - 2.22.2-1.el4.noarch from epel unresolved deps: graphviz perl(Template::Stash) perl(MIME::Parser) package: specto - 0.2.0-3.el4.noarch from epel unresolved deps: notify-python package: ctapi-cyberjack - 3.0.0-3.el4.i386 from epel unresolved deps: /usr/lib/ctapi package: bcfg2 - 0.9.3-1.el4.noarch from epel unresolved deps: python-lxml package: perl-SOAP-Lite - 0.68-5.el4.noarch from epel unresolved deps: perl(MIME::Lite) package: nagios-plugins-ifoperstatus - 1.4.6-3.el4.x86_64 from epel unresolved deps: perl(Net::SNMP) package: nagios-plugins-ifstatus - 1.4.6-3.el4.x86_64 from epel unresolved deps: perl(Net::SNMP) package: SDL_mixer - 1.2.6-8.el4.x86_64 from epel unresolved deps: timidity++ package: postgresql-dbi-link - 2.0.0-3.el4.noarch from epel unresolved deps: perl-DBI >= 0:1.52 package: otrs - 2.1.5-1.el4.noarch from epel unresolved deps: perl(MIME::Words) perl(MIME::Parser) perl(Date::Pcalc) perl(Compress::Zlib) perl(MIME::Entity) package: perl-SOAP-Lite - 0.68-3.el4.noarch from epel unresolved deps: perl(MQSeries) perl(MQSeries::Message) perl(MQSeries::Queue) perl(MIME::Lite) perl(MQSeries::QueueManager) package: zabbix - 1.1.7-1.el4.x86_64 from epel unresolved deps: fping package: perl-Net-Server - 0.96-1.el4.noarch from epel unresolved deps: perl(IO::Multiplex) package: fail2ban - 0.6.2-3.el4.noarch from epel unresolved deps: shorewall kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Thu Jun 28 11:37:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Jun 2007 17:07:07 +0530 Subject: Readme.fedora files in EPEL In-Reply-To: <46827C98.1070105@leemhuis.info> References: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> <467C378B.8090106@fedoraproject.org> <200706222352.40353.opensource@till.name> <467FC663.2020508@leemhuis.info> <467FDD05.7000805@fedoraproject.org> <46827C98.1070105@leemhuis.info> Message-ID: <46839D63.7030405@fedoraproject.org> Thorsten Leemhuis wrote: > > On 25.06.2007 17:19, Rahul Sundaram wrote: >> Thorsten Leemhuis wrote: >>> On 22.06.2007 23:52, Till Maas wrote: >>>> On Fr Juni 22 2007, Rahul Sundaram wrote: >>>> >>>>> Maybe we need to enforcing calling it README.distribution or a generic >>>>> name like in the Fedora packaging guidelines that so EPEL can reuse the >>>>> content or atleast the file name without any issues. >>>> In Bugzilla EPEL is called "Fedora EPEL". So a README.Fedora is no problem >>>> imho. >>> I agree with both of you -- but "README.distribution" IMHO would be the >>> proper solution. Especially if we could get the rest of the world >>> (OpenSuse, ...) to use it as well to mention distribution specific stuff. >> Thorsten, can you follow this up with FESCo? > > I'd be glad if someone else could take care of it. Any volunteers? > > BTW, isn't the Fedora Packaging Committee the proper place for this? I will take care of this. Will post to fedora-devel. I have a related topic I wanted to discuss anyway. Rahul From fedora at leemhuis.info Thu Jun 28 12:03:10 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 28 Jun 2007 14:03:10 +0200 Subject: Readme.fedora files in EPEL In-Reply-To: <46839D63.7030405@fedoraproject.org> References: <7874d9dd0706211742u5233d8bau5af01d991db61fe1@mail.gmail.com> <467C378B.8090106@fedoraproject.org> <200706222352.40353.opensource@till.name> <467FC663.2020508@leemhuis.info> <467FDD05.7000805@fedoraproject.org> <46827C98.1070105@leemhuis.info> <46839D63.7030405@fedoraproject.org> Message-ID: <4683A37E.4070307@leemhuis.info> On 28.06.2007 13:37, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: >> On 25.06.2007 17:19, Rahul Sundaram wrote: >>> Thorsten Leemhuis wrote: >>>> On 22.06.2007 23:52, Till Maas wrote: >>>>> On Fr Juni 22 2007, Rahul Sundaram wrote: >>>>> >>>>>> Maybe we need to enforcing calling it README.distribution or a generic >>>>>> name like in the Fedora packaging guidelines that so EPEL can reuse the >>>>>> content or atleast the file name without any issues. >>>>> In Bugzilla EPEL is called "Fedora EPEL". So a README.Fedora is no problem >>>>> imho. >>>> I agree with both of you -- but "README.distribution" IMHO would be the >>>> proper solution. Especially if we could get the rest of the world >>>> (OpenSuse, ...) to use it as well to mention distribution specific stuff. >>> Thorsten, can you follow this up with FESCo? >> I'd be glad if someone else could take care of it. Any volunteers? >> BTW, isn't the Fedora Packaging Committee the proper place for this? > I will take care of this. Will post to fedora-devel. I have a related > topic I wanted to discuss anyway. Thanks for your help Rahul! Much appreciated! CU thl From pertusus at free.fr Wed Jun 27 21:23:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 27 Jun 2007 23:23:50 +0200 Subject: xfce for EPEL? In-Reply-To: <20070627143242.3e81f12a@ghistelwchlohm.scrye.com> References: <4682C341.1040105@cora.nwra.com> <20070627141421.48cb3ff3@ghistelwchlohm.scrye.com> <20070627202505.GA8013@free.fr> <20070627143242.3e81f12a@ghistelwchlohm.scrye.com> Message-ID: <20070627212350.GD8013@free.fr> On Wed, Jun 27, 2007 at 02:32:42PM -0600, Kevin Fenzi wrote: > > The specs they are using are mine, so they should match pretty closely > with what I have now. ;) I don't think they needed to make any changes > from the Fedora specs, although I will have to check each package > carefully to make sure of that. Ah, ok, in that case I think you should just assume that they are following your choices unless you changed something dramatically, otherwise said you are the reference. -- Pat From fedora at leemhuis.info Thu Jun 28 16:19:26 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 28 Jun 2007 18:19:26 +0200 Subject: excludearch trackers? In-Reply-To: <20070627174407.GB29669@nostromo.devel.redhat.com> References: <20070627174407.GB29669@nostromo.devel.redhat.com> Message-ID: <4683DF8E.5010205@leemhuis.info> Bill, thx for bringing this up to the list; that makes initial discussion IMHO much easier then in the meeting (we can find the final decision in a meeting later) On 27.06.2007 19:44, Bill Nottingham wrote: > I've got a package in EPEL that I have to ExcludeArch (gnucash, EPEL4, > x86_64). While my reason isn't the normal reason for doing it (see > bug #203761), I was wondering - do we want separate ExcludeArch tracking > bugs for EPEL, or should we just piggyback on the Fedora ones? Well, first of: we IMHO should get rid of the trackers in general and let some scripts or koji auto-generate a list or bugs (or something like that). I'm fine with creating a EPEL ExcludeArch tracking bugs or go with none at all; but we IMHO should not reuse the Fedora trackers (we of course can reuse the bugs, so they block both the EPEL and the Fedora ExcludeArch tracking bugs). But do we need them or not? The main reason for them is: People interested in arch foo can look at them and help fixing stuff for arch foo in other peoples packages. If that is done properly in Fedora and if EPEL maintainers don't add ExcludeArch bugs for stupid reasons then I'd tend say: EPEL can live without them. Other opinions? CU thl From fedora at leemhuis.info Thu Jun 28 17:05:48 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 28 Jun 2007 19:05:48 +0200 Subject: Draft of Personal Package Request In-Reply-To: <7874d9dd0706202111pefd1144l91d540f70a014215@mail.gmail.com> References: <7874d9dd0706202111pefd1144l91d540f70a014215@mail.gmail.com> Message-ID: <4683EA6C.10108@leemhuis.info> On 21.06.2007 06:11, Michael Stahnke wrote: > I updated the draft on the package request email/notification on the wiki. > > Found currently at : > http://fedoraproject.org/wiki/MichaelStahnke/Draft-EPELPackageRequest > > Reads as follows: [...] I just was in the situation where I needed a dep for one of my packages in EPEL that is not yet part of it. I took your text and modified it a bit to give it a more "personal" touch. Michael, what do you think of it? Maybe you can take parts of it? --- Hi! There are people around that would like to see some of your Fedora packages in Extra Packages for Enterprise Linux (EPEL) [1] -- I for example would like to see FOOBARBAZ in EPEL and mainly send you this mail on behalf of the EPEL team as you didn't yet let the team know via the Contributor Status [2] page if you are planning to build some or all of your Fedora packages for EPEL. Are you interested in maintaining your packages in EPEL? EPEL is similar to Fedora Extras -- just that EPEL is a add-on repo for RHEL and compatible spinoffs such as CentOS. EPEL uses the same CVS and the same build servers as Fedora and a lot of Fedora maintainers are EPEL maintainers as well; the main difference is just that packages in EPEL are updated more carefully and supported for a longer timeframe. See [3] and [4] for details. In short: EPEL tries to ship a package once and update it to later versions only when there is a strong need to. For branching your packages for EPEL follow the standard Fedora procedure[5] -- instead of FC-6 or F-7 targets just use EL-4 or EL-5 as branch names. If you maintain several packages (> 2) you can also use a scripted branching method (all packages from a contributor) by using the scripted branch process[6]. If you are not interested in EPEL please let the EPEL contributors know and update the information on [2] to avoid further mails like this -- that just takes a minute or two and would be a great help for the EPEL team. Please note that EPEL maintainers that might want to see your package in EPEL will likely start to maintain the package in EPEL sooner or later and thus become co-maintainers [7] of your packages for EPEL. The EPEL team appreciate your help in readying EPEL for official launch soon. [1]http://fedoraproject.org/wiki/EPEL [2]http://fedoraproject.org/wiki/EPEL/ContributorStatus [3]http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies [4] http://fedoraproject.org/wiki/EPEL/FAQ [5]http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure [6]http://fedoraproject.org/wiki/MichaelStahnke/ScriptedBranchProcess [7]http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership --- CU thl From fedora at leemhuis.info Thu Jun 28 18:15:40 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 28 Jun 2007 20:15:40 +0200 Subject: EPEL5 dependency report In-Reply-To: <1182963155.4065.84.camel@rxm-581b.stl.gtri.gatech.edu> References: <1182792111.4065.70.camel@rxm-581b.stl.gtri.gatech.edu> <20070625180211.GA14914@nostromo.devel.redhat.com> <1182802163.4065.72.camel@rxm-581b.stl.gtri.gatech.edu> <1182963155.4065.84.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <4683FACC.40700@leemhuis.info> > Broken deps for i386 > ---------------------------------------------------------- > SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ > bcfg2 - 0.9.3-2.el5.noarch requires python-lxml > bugzilla - 3.0-2.el5.noarch requires perl-Email-Send > bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) > bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper > bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) > bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) > bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) > bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) > bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME > bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) > bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) > bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit > bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple > bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) > bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply > bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier > bugzilla - 3.0-2.el5.noarch requires perl-Email-Address > ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi > fail2ban - 0.6.2-3.el5.noarch requires shorewall > git-arch - 1.5.2.1-2.el5.i386 requires tla > git-cvs - 1.5.2.1-2.el5.i386 requires cvsps > gmrun - 0.9.2-7.el5.i386 requires xterm > nagios-plugins-fping - 1.4.6-3.el5.i386 requires /usr/sbin/fping > nagios-plugins-game - 1.4.6-3.el5.i386 requires qstat > nagios-plugins-ifoperstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) > nagios-plugins-ifstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) > ntfs-config - 1.0-0.3.rc4.el5.noarch requires ntfs-3g > perl-Net-Pcap - 0.14-2.el5.i386 requires perl(IO::Interface) > perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) > perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) > php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash > php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt > python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core > python-Coherence - 0.2.1-3.el5.noarch requires python-nevow > python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web > python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy > qucs - 0.0.12-2.el5.i386 requires iverilog > redet - 8.22-4.el5.noarch requires iwidgets > rss2email - 2.60-3.el5.noarch requires python-feedparser > translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant > zabbix - 1.1.7-1.el5.1.i386 requires fping I created a small "quick and dirty" script to look up who owns those *missing* packages. Find it attached; run with ./foo sh <<< " python-Coherence - 0.2.1-3.el5.noarch requires SOAPp qucs - 0.0.12-2.el5.i386 requires iverilog" The output: > Package SDL_mixer requires timidity++ which is owned by twoerner_AT_redhat.com in Fedora > Package bcfg2 requires python-lxml which is owned by shahms_AT_shahms.com in Fedora > Package bugzilla requires perl-Email-Send which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Email-Address which is owned by jpo_AT_di.uminho.pt in Fedora > Package bugzilla requires perl-Email-MIME-Attachment-Stripper which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Email-Reply which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Email-MIME-Attachment-Stripper which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Email-MIME-Creator which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Email-Send which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Email-MIME which is owned by jpo_AT_di.uminho.pt in Fedora > Package bugzilla requires perl-Email-MIME-Modifier which is owned by jpo_AT_di.uminho.pt in Fedora > Package bugzilla requires perl-Template-Toolkit which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Template-Toolkit which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Email-Simple which is owned by jpo_AT_di.uminho.pt in Fedora > Package bugzilla requires perl-Template-Toolkit which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Email-Reply which is owned by tcallawa_AT_redhat.com in Fedora > Package bugzilla requires perl-Email-MIME-Modifier which is owned by jpo_AT_di.uminho.pt in Fedora > Package bugzilla requires perl-Email-Address which is owned by jpo_AT_di.uminho.pt in Fedora > Package ctapi-cyberjack requires ctapi-common which is owned by ville.skytta_AT_iki.fi in Fedora > Package fail2ban requires shorewall which is owned by robert_AT_marcanoonline.com in Fedora > Package git-arch requires tla which is owned by jwboyer_AT_jdub.homelinux.org in Fedora > Package git-cvs requires cvsps which is owned by ville.skytta_AT_iki.fi in Fedora > Package gmrun requires xterm which is owned by mlichvar_AT_redhat.com in Fedora > Package nagios-plugins-fping requires fping which is owned by kaboom_AT_oobleck.net in Fedora > Package nagios-plugins-game requires qstat which is owned by andy_AT_smile.org.ua in Fedora > Package nagios-plugins-ifoperstatus requires perl-Net-SNMP which is owned by jpo_AT_di.uminho.pt in Fedora > Package nagios-plugins-ifstatus requires perl-Net-SNMP which is owned by jpo_AT_di.uminho.pt in Fedora > Package ntfs-config requires ntfs-3g which is owned by tcallawa_AT_redhat.com in Fedora > Package perl-Net-Pcap requires perl-IO-Interface which is owned by jpo_AT_di.uminho.pt in Fedora > Package perl-Test-Base requires perl-Module-Install which is owned by steve_AT_silug.org in Fedora > Package perl-libwhisker2 requires perl-MD5 which is owned by andreas_AT_bawue.net in Fedora > Package php-pear-Crypt-CHAP requires php-mhash which is owned by in Fedora > Package php-pear-Crypt-CHAP requires php-mcrypt which is owned by in Fedora > Package python-Coherence requires python-twisted-core which is owned by thomas_AT_apestaart.org in Fedora > Package python-Coherence requires python-nevow which is owned by matthias_AT_rpmforge.net in Fedora > Package python-Coherence requires python-twisted-web which is owned by thomas_AT_apestaart.org in Fedora > Package python-Coherence requires SOAPpy which is owned by chris.stone_AT_gmail.com in Fedora > Package qucs requires iverilog which is owned by cbalint_AT_redhat.com,cgoorah at yahoo.com.au in Fedora > Package redet requires iwidgets which is owned by wart_AT_kobold.org in Fedora > Package rss2email requires python-feedparser which is owned by icon_AT_fedoraproject.org in Fedora > Package translate-toolkit requires python-enchant which is owned by roozbeh_AT_farsiweb.info in Fedora > Package zabbix requires fping which is owned by kaboom_AT_oobleck.net in Fedora HTH CU thl -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.sh Type: application/x-shellscript Size: 492 bytes Desc: not available URL: From smooge at gmail.com Thu Jun 28 19:18:31 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 28 Jun 2007 13:18:31 -0600 Subject: EPEL5 dependency report In-Reply-To: <4683FACC.40700@leemhuis.info> References: <1182792111.4065.70.camel@rxm-581b.stl.gtri.gatech.edu> <20070625180211.GA14914@nostromo.devel.redhat.com> <1182802163.4065.72.camel@rxm-581b.stl.gtri.gatech.edu> <1182963155.4065.84.camel@rxm-581b.stl.gtri.gatech.edu> <4683FACC.40700@leemhuis.info> Message-ID: <80d7e4090706281218mc27d04bq79ccf4e218c58607@mail.gmail.com> On 6/28/07, Thorsten Leemhuis wrote: > > Broken deps for i386 > > ---------------------------------------------------------- > > SDL_mixer - 1.2.7-2.el5.i386 requires timidity++ > > bcfg2 - 0.9.3-2.el5.noarch requires python-lxml > > bugzilla - 3.0-2.el5.noarch requires perl-Email-Send > > bugzilla - 3.0-2.el5.noarch requires perl(Email::Address) > > bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Attachment-Stripper > > bugzilla - 3.0-2.el5.noarch requires perl(Email::Reply) > > bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Attachment::Stripper) > > bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME) > > bugzilla - 3.0-2.el5.noarch requires perl(Email::Send) > > bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME > > bugzilla - 3.0-2.el5.noarch requires perl(Email::MIME::Modifier) > > bugzilla - 3.0-2.el5.noarch requires perl(Template::Stash) > > bugzilla - 3.0-2.el5.noarch requires perl-Template-Toolkit > > bugzilla - 3.0-2.el5.noarch requires perl-Email-Simple > > bugzilla - 3.0-2.el5.noarch requires perl(Template::Config) > > bugzilla - 3.0-2.el5.noarch requires perl-Email-Reply > > bugzilla - 3.0-2.el5.noarch requires perl-Email-MIME-Modifier > > bugzilla - 3.0-2.el5.noarch requires perl-Email-Address > > ctapi-cyberjack - 3.0.0-2.el5.i386 requires /usr/lib/ctapi > > fail2ban - 0.6.2-3.el5.noarch requires shorewall > > git-arch - 1.5.2.1-2.el5.i386 requires tla > > git-cvs - 1.5.2.1-2.el5.i386 requires cvsps > > gmrun - 0.9.2-7.el5.i386 requires xterm > > nagios-plugins-fping - 1.4.6-3.el5.i386 requires /usr/sbin/fping > > nagios-plugins-game - 1.4.6-3.el5.i386 requires qstat > > nagios-plugins-ifoperstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) > > nagios-plugins-ifstatus - 1.4.6-3.el5.i386 requires perl(Net::SNMP) > > ntfs-config - 1.0-0.3.rc4.el5.noarch requires ntfs-3g > > perl-Net-Pcap - 0.14-2.el5.i386 requires perl(IO::Interface) > > perl-Test-Base - 0.53-1.el5.noarch requires perl(Module::Install::Base) > > perl-libwhisker2 - 2.4-3.el5.noarch requires perl(MD5) > > php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mhash > > php-pear-Crypt-CHAP - 1.0.1-1.el5.noarch requires php-mcrypt > > python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-core > > python-Coherence - 0.2.1-3.el5.noarch requires python-nevow > > python-Coherence - 0.2.1-3.el5.noarch requires python-twisted-web > > python-Coherence - 0.2.1-3.el5.noarch requires SOAPpy > > qucs - 0.0.12-2.el5.i386 requires iverilog > > redet - 8.22-4.el5.noarch requires iwidgets > > rss2email - 2.60-3.el5.noarch requires python-feedparser > > translate-toolkit - 0.10.1-1.el5.noarch requires python-enchant > > zabbix - 1.1.7-1.el5.1.i386 requires fping > I am seeing this one is missing on the break tree for some reason: --> Processing Dependency: python-imaging = 1.1.6-3.el5 for package: python-imaging-tk --> Processing Dependency: python-imaging for package: plone --> Finished Dependency Resolution --> Populating transaction set with selected packages. Please wait. ---> Package kernel.i686 0:2.6.18-8.1.4.el5 set to be erased --> Running transaction check --> Processing Dependency: python-imaging = 1.1.6-3.el5 for package: python-imaging-tk --> Processing Dependency: python-imaging for package: plone --> Finished Dependency Resolution Error: Missing Dependency: python-imaging = 1.1.6-3.el5 is needed by package python-imaging-tk -- 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 mastahnke at gmail.com Fri Jun 29 00:24:46 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Thu, 28 Jun 2007 19:24:46 -0500 Subject: Draft of Personal Package Request In-Reply-To: <4683EA6C.10108@leemhuis.info> References: <7874d9dd0706202111pefd1144l91d540f70a014215@mail.gmail.com> <4683EA6C.10108@leemhuis.info> Message-ID: <7874d9dd0706281724m11525c07x4307005f6804500@mail.gmail.com> On 6/28/07, Thorsten Leemhuis wrote: > On 21.06.2007 06:11, Michael Stahnke wrote: > > I updated the draft on the package request email/notification on the wiki. > > > > Found currently at : > > http://fedoraproject.org/wiki/MichaelStahnke/Draft-EPELPackageRequest > > > > Reads as follows: [...] > > I just was in the situation where I needed a dep for one of my packages > in EPEL that is not yet part of it. I took your text and modified it a > bit to give it a more "personal" touch. Michael, what do you think of > it? Maybe you can take parts of it? > > --- > Hi! > > There are people around that would like to see some of your Fedora > packages in Extra Packages for Enterprise Linux > (EPEL) [1] -- I for example would like to see FOOBARBAZ in EPEL and > mainly send you this mail on behalf of the EPEL team as you didn't yet > let the team know via the Contributor Status [2] page if you are > planning to build some or all of your Fedora packages for EPEL. > > Are you interested in maintaining your packages in EPEL? EPEL is similar > to Fedora Extras -- just that EPEL is a add-on repo for RHEL and > compatible spinoffs such as CentOS. EPEL uses the same CVS and the same > build servers as Fedora and a lot of Fedora maintainers are EPEL > maintainers as well; the main difference is just that packages in EPEL > are updated more carefully and supported for a longer timeframe. See [3] > and [4] for details. In short: EPEL tries to ship a package once and > update it to later versions only when there is a strong need to. > > For branching your packages for EPEL follow the standard Fedora > procedure[5] -- instead of FC-6 or F-7 targets just use EL-4 or EL-5 as > branch names. If you maintain several packages (> 2) you can also use a > scripted branching method (all packages from a contributor) by using the > scripted branch process[6]. > > If you are not interested in EPEL please let the EPEL contributors know > and update the information on [2] to avoid further mails like this -- > that just takes a minute or two and would be a great help for the EPEL > team. Please note that EPEL maintainers that might want to see your > package in EPEL will likely start to maintain the package in EPEL sooner > or later and thus become co-maintainers [7] of your packages for EPEL. > > The EPEL team appreciate your help in readying EPEL for official launch > soon. > > [1]http://fedoraproject.org/wiki/EPEL > > [2]http://fedoraproject.org/wiki/EPEL/ContributorStatus > > [3]http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies > > [4] http://fedoraproject.org/wiki/EPEL/FAQ > > [5]http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure > > [6]http://fedoraproject.org/wiki/MichaelStahnke/ScriptedBranchProcess > > [7]http://fedoraproject.org/wiki/Extras/Policy/EncourageComaintainership > > --- > > > CU > thl > > _______________________________________________ > epel-devel-list mailing list > epel-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/epel-devel-list > Look good to me. I normally tend to write short, so that if someone isn't that interested, I didn't explain everything to them already. Thorough is probably better here though. stahnma From buildsys at fedoraproject.org Fri Jun 29 03:14:21 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 28 Jun 2007 23:14:21 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-28 Message-ID: <20070629031421.0F8D8152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 5 NEW cvs2svn-1.5.1-2.el5 : CVS to Subversion Repository Converter NEW python-dateutil-1.2-1.el5 : Powerful extensions to the standard datetime module NEW python-matplotlib-0.90.1-1.el5 : Python plotting library NEW pytz-2006p-1.el5 : World Timezone Definitions for Python NEW re2c-0.12.1-2.el5 : Tool for generating C-based recognizers from regular expressions Packages built and released for Fedora EPEL 4: 2 NEW cvs2svn-1.5.1-2.el4 : CVS to Subversion Repository Converter NEW re2c-0.12.1-2.el4 : Tool for generating C-based recognizers from regular expressions Changes in Fedora EPEL 5: cvs2svn-1.5.1-2.el5 ------------------- * Thu Jun 28 2007 Konstantin Ryabitsev - 1.5.1-2 - Include cvs2svn-example.options in docs (#241533) python-dateutil-1.2-1.el5 ------------------------- * Thu Jun 28 2007 Orion Poplawski 1.2-1 - Update to 1.2 python-matplotlib-0.90.1-1.el5 ------------------------------ * Thu Jun 28 2007 Orion Poplawski 0.90.1-1 - Update to 0.90.1 pytz-2006p-1.el5 ---------------- * Fri Dec 08 2006 Orion Poplawski 2006p-1 - Update to 2006p re2c-0.12.1-2.el5 ----------------- * Wed Jun 20 2007 Matthias Saou 0.12.1-2 - Fix license tag to "Public Domain". - Update description with most recent text from the website. * Wed Jun 20 2007 Matthias Saou 0.12.1-1 - Spec file changes. Changes in Fedora EPEL 4: cvs2svn-1.5.1-2.el4 ------------------- * Thu Jun 28 2007 Konstantin Ryabitsev - 1.5.1-2 - Include cvs2svn-example.options in docs (#241533) re2c-0.12.1-2.el4 ----------------- * Wed Jun 20 2007 Matthias Saou 0.12.1-2 - Fix license tag to "Public Domain". - Update description with most recent text from the website. * Wed Jun 20 2007 Matthias Saou 0.12.1-1 - Spec file changes. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From buildsys at fedoraproject.org Sat Jun 30 16:58:12 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 30 Jun 2007 12:58:12 -0400 (EDT) Subject: Fedora EPEL Package Build Report 2007-06-30 Message-ID: <20070630165812.EC4E5152131@buildsys.fedoraproject.org> Packages built and released for Fedora EPEL 5: 6 babel-0.8-3.el5 NEW glpk-4.18-1.el5 : GNU Linear Programming Kit NEW itcl-3.3-0.7.RC1.el5 : Object oriented extensions to Tcl and Tk nagios-2.9-1.el5 NEW python-feedparser-4.1-3.el5 : Parse RSS and Atom feeds in Python NEW yum-utils-1.0.3-1.el5 : Utilities based around the yum package manager Packages built and released for Fedora EPEL 4: 3 NEW itcl-3.3-0.9.RC1.el4 : Object oriented extensions to Tcl and Tk nagios-2.9-1.el4 NEW python-feedparser-4.1-3.el4 : Parse RSS and Atom feeds in Python Changes in Fedora EPEL 5: babel-0.8-3.el5 --------------- * Fri Jun 29 2007 Jeffrey C. Ollie - 0.8-3 - Replace patch with one that actually applies. * Fri Jun 29 2007 Jeffrey C. Ollie - 0.8-2 - Apply upstream patch to rename command line script to "pybabel" - BZ#246208 glpk-4.18-1.el5 --------------- * Thu Jun 28 2007 Quentin Spencer 4.18-1 - New release. itcl-3.3-0.7.RC1.el5 -------------------- * Mon Aug 28 2006 Wart - 3.3-0.7.RC1 - Rebuild for Fedora Extras nagios-2.9-1.el5 ---------------- * Fri Jun 29 2007 Mike McGrath 2.9-1 - Upstream released 2.9 python-feedparser-4.1-3.el5 --------------------------- * Thu Jun 28 2007 Konstantin Ryabitsev - 4.1-3 - Ghostbusting (#205413). - Remove manual python-abi Requires. - Appease rpmlint. yum-utils-1.0.3-1.el5 --------------------- * Mon Feb 19 2007 Tim Lauridsen - Added %{?dist} tag again Changes in Fedora EPEL 4: itcl-3.3-0.9.RC1.el4 -------------------- * Thu Mar 22 2007 Orion Poplawski - 3.3-0.9.RC1 - Rebuild for tcl8.4 downgrade nagios-2.9-1.el4 ---------------- * Fri Jun 29 2007 Mike McGrath 2.9-1 - Upstream released 2.9 python-feedparser-4.1-3.el4 --------------------------- * Thu Jun 28 2007 Konstantin Ryabitsev - 4.1-3 - Ghostbusting (#205413). - Remove manual python-abi Requires. - Appease rpmlint. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From heiko.adams at gmx.de Sat Jun 30 18:43:34 2007 From: heiko.adams at gmx.de (Heiko Adams) Date: Sat, 30 Jun 2007 20:43:34 +0200 Subject: Request: Add an additonal tag to package names Message-ID: <1183229014.2943.2.camel@Ostfriesland> Hello, I would request to add an addtional tag like "epel" to the packagename for easier differ where which package came from. At the moment there is no way to differ if a package is a package from the distribution or if it comes from epel repo. -- Heiko Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From fedora at leemhuis.info Sat Jun 30 18:53:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 30 Jun 2007 20:53:35 +0200 Subject: Request: Add an additonal tag to package names In-Reply-To: <1183229014.2943.2.camel@Ostfriesland> References: <1183229014.2943.2.camel@Ostfriesland> Message-ID: <4686A6AF.7010506@leemhuis.info> On 30.06.2007 20:43, Heiko Adams wrote: > > I would request to add an addtional tag like "epel" to the packagename > for easier differ where which package came from. > At the moment there is no way to differ if a package is a package from > the distribution or if it comes from epel repo. Look at the archives. That topic has been discussed multiple times in the past months over and over again. People can't agree -- some want them, other don't want them. But the topic has three times been voted down (once by FESCo months ago and two times by the EPEL Steering Committee). CU thl From rayvd at bludgeon.org Sat Jun 30 18:54:25 2007 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Sat, 30 Jun 2007 11:54:25 -0700 Subject: Request: Add an additonal tag to package names In-Reply-To: <1183229014.2943.2.camel@Ostfriesland> References: <1183229014.2943.2.camel@Ostfriesland> Message-ID: <20070630185425.GA6377@bludgeon.org> On Sat, Jun 30, 2007 at 08:43:34PM +0200, Heiko Adams wrote: > Hello, > I would request to add an addtional tag like "epel" to the packagename > for easier differ where which package came from. > At the moment there is no way to differ if a package is a package from > the distribution or if it comes from epel repo. Heh, oh boy. :) The EPEL steering committee has decided (multiple times) to not use repotags. https://www.redhat.com/archives/epel-devel-list/2007-June/msg00032.html Has the summary of the last time it was discussed... I believe the EPEL SIG plans to come out with an official statement on the decision? Ray