epel-devel July 2010

epel-devel@lists.fedoraproject.org

57 participants
79 discussions

Re: EPEL Packages in need of building for EL-6
by Bill Nottingham 01 Jul '10

01 Jul '10

tremble(a)fedoraproject.org (tremble(a)fedoraproject.org) said: > Owner: notting > aqbanking > gnucash > gnucash-docs > goffice > gwenhywfar > libofx > perl-Finance-Quote > perl-HTML-TableExtract > slib gnucash is currently preparing for a 2.4.0 release; I'm not intending to build it for EPEL until that point (which may or may not be before August 15th.) I may build some of the dependencies beforehand, but it's not like most of them have much use on their own. Bill

1 0

Re: EPEL Packages in need of building for EL-6
by Christoph Wickert 01 Jul '10

01 Jul '10

Am Donnerstag, den 01.07.2010, 08:41 +0000 schrieb tremble(a)fedoraproject.org: > Dear Package owner, > > On Monday June 28th at the EPEL meeting on IRC we agreed to an initial > target date of August 15th for having all packages built for EL-6. > > This is a summary of EPEL packages for Enterprise Linux 6 that you own > which have not yet been built. > > Owner: cwickert > gtraffic > lxappearance > lxde-common > lxde-settings-daemon > lxinput > lxlauncher > lxmenu-data > lxsession-edit > lxshortcut > lxtask > lxterminal > menu-cache > nimbus > parcellite > xarchiver I really like to see LXDE in EPEL. I already wanted to have it in EL-5, but it didn't work due to some outdated dependencies. Note that lxdm and libfm (dep of pcmanfm) are missing in your list. And what about the other packages that are part of LXDE but that I do not own? (openbox, obconf, pcmanfm) > We are aware that there are some packages which got branched which > either you may not be interested in maintaining for EL-6 or which we > have not caught as having made it into EL-6. > > If you do not wish to maintain your package for EL-6 please follow the > usual process for orphaning a package for a branch : > https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#O… How can I orphan a branch that is not even in place? > If we have not caught the fact that the package has now made it`s way > into EL-6 then either ask over on #epel on freenode or on the EPEL-devel > mailing list. > > Any questions or concerns, please ask over on #epel on freenode or > the epel-devel mailing list Yes, I do have a concern: parcellite is no longer maintained, so I don't want to see this in EPEL. For more info see https://bugzilla.redhat.com/show_bug.cgi?id=513097 Same goes for xarchiver, although it is not dead officially. Regards, Christoph

1 0

Fwd: Possible item for next EPEL meeting
by Stephen John Smoogen 01 Jul '10

01 Jul '10

Topic for Monday Meeting. EL-6 optional packages and EPEL packages. ---------- Forwarded message ---------- From: Mark Chappell <tremble(a)tremble.org.uk> Date: Wed, Jun 30, 2010 at 11:00 AM Subject: Possible item for next EPEL meeting To: smooge(a)gmail.com https://bugzilla.redhat.com/show_bug.cgi?id=608594 Dealing with packages that are available in the optional repo for SOME arches only. Made all the more fun in this case by the fact it's a noarch package. Mark -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. "We have a strategic plan. It's called doing things."" — Herb Kelleher, founder Southwest Airlines

2 1

Orphaned packages in EL-6
by Mark Chappell 01 Jul '10

01 Jul '10

Just so people are aware if they're waiting for a dependency to be built, this is a list of packages pkgdb things are orphaned in EPEL-6 aalib : orphan : abcde : orphan : apt-mirror : orphan : bottlerocket : orphan : cd-discid : orphan : csstidy : orphan : csync2 : orphan : cvs2cl : orphan : django-authopenid : orphan : djvulibre : orphan : DMitry : orphan : dnssec-conf : orphan : drgeo : orphan : drgeo-doc : orphan : firewalk : orphan : flam3 : orphan : freetennis : orphan : fxload : orphan : geda-docs : orphan : geda-examples : orphan : geda-gattrib : orphan : geda-gschem : orphan : geda-gsymcheck : orphan : geda-symbols : orphan : geda-utils : orphan : ginac : orphan : gkrellm : orphan : gkrellm-volume : orphan : globus-data-conversion : orphan : globus-duct-common : orphan : globus-duct-control : orphan : globus-duroc-common : orphan : globus-mp : orphan : globus-nexus : orphan : glom : orphan : gmime : orphan : gnustep-make : orphan : gperiodic : orphan : greylistd : orphan : gtkhtml38 : orphan : gtranslator : orphan : halberd : orphan : hellanzb : orphan : homestead : orphan : ircd-hybrid : orphan : joda-time : orphan : joni : orphan : jruby : orphan : JSDoc : orphan : kflickr : orphan : libcdaudio : orphan : libFoundation : orphan : libgcal : orphan : libgeda : orphan : libgnomedb : orphan : libmodplug : orphan : libmodplug-0.8.8.1-2.el6 (rdieter) libupnp : orphan : mach : orphan : maildrop : orphan : moin : orphan : ms-sys : orphan : mugshot : orphan : nettle : orphan : nikto : orphan : nssbackup : orphan : onesixtyone : orphan : pAgenda : orphan : pastebin : orphan : perl-Class-Gomor : orphan : perl-Class-MethodMaker : orphan : perl-Crypt-Simple : orphan : perl-DBIx-SQLite-Simple : orphan : perl-DDL-Oracle : orphan : perl-Exception-Base : orphan : perl-libwhisker2 : orphan : perl-Net-Libdnet : orphan : perl-Net-Packet : orphan : perl-Network-IPv4Addr : orphan : perl-Net-Write : orphan : perl-Perl6-Junction : orphan : perl-SQLite-Simple : orphan : perl-Text-CharWidth : orphan : perl-Text-WrapI18N : orphan : php-pear-Phlickr : orphan : po4a : orphan : pyfacebook : orphan : python-dbsprockets : orphan : python-feedparser : orphan : python-feedparser-4.1-10.el6 (ausil) python-kiwi : orphan : python-pgsql : orphan : python-urllib2_kerberos : orphan : qosmic : orphan : reciteword : orphan : redet : orphan : redet-doc : orphan : rubygem-RedCloth : orphan : rubygem-rufus-scheduler : orphan : sbackup : orphan : scidavis : orphan : scponly : orphan : SDL_net : orphan : snort : orphan : svn2cl : orphan : symkey : orphan : synaptic : orphan : tor : orphan : transmission : orphan : ushare : orphan : vidalia : orphan : windowlab : orphan : xautolock : orphan : xine-ui : orphan : zaptel : orphan : znc-extra : orphan : These 4 probably aren't needed : qt4 : orphan : qt4-qsa : orphan : python26 : orphan : python26-distribute : orphan : Mark

2 1

Re: EPEL Packages in need of building for EL-6
by Philippe Makowski 01 Jul '10

01 Jul '10

Hi, 2010/7/1 <tremble(a)fedoraproject.org>: > > Dear Package owner, > > On Monday June 28th at the EPEL meeting on IRC we agreed to an initial > target date of August 15th for having all packages built for EL-6. > > This is a summary of EPEL packages for Enterprise Linux 6 that you own > which have not yet been built. > > Owner: makowski > firebird > flamerobin > python-kinterbasdb > I'm aware of that but Firebird is about to release a new major version (2.5) and the package is now only 2.1 It is a matter of weeks before the release of what Firebird project hope to be the last 2.5 RC So I would like to wait and build these package when Firebird upstream will release 2.5 and such, August 15th seems a possible target date with Firebird 2.5

1 0

my EPEL-6 packages up for takers
by Patrice Dumas 01 Jul '10

01 Jul '10

Hello, I won't, at least for now, maintain the packages I maintain in EPEL-5 in EPEL-6. I have added a nobranch file in all of them. If you want to take up the package, you can. It is still unclear to me how to practically ensure that you become the EPEL-6 branch owner, instead of me, though. Hopefully this will be sorted out. If you want to maintain the EL-5 (or even EL-4) branch too, don't hesitate, the less package I maintain the better I am. I think that wdm should not be maintained in EL-6 anyway, since upstream is dead and there is no ConsoleKit integration. For the dap-* packages it maybe worth waiting for a stabilisation of the ABI, and maybe integration with bes and packaging of olfs to have a working hyrax server before branching. My guess is that there are no users of these packages anyway. Also maybe the opendap implementantion in netcdf itself could be used instead of libdap/libnc-dap. The list is: acpitool asa bibexport BibTool bitmap boolstuff cernlib cernlib-g77 cppunit dap-freeform_handler dap-hdf4_handler dap-netcdf_handler dap-server docbook2X elektra esmtp flasm g2clib gnochm gpicview grads halevt html2ps kchmviewer libdap libdockapp libesmtp libnc-dap libsx ooo2txt pam_ssh perl-Algorithm-CurveFit perl-Cache perl-Feed-Find perl-File-BaseDir perl-File-DesktopEntry perl-File-MimeInfo perl-File-NFSLock perl-Heap perl-HTML-FormatText-WithLinks perl-LWP-Authen-Wsse perl-Math-MatrixReal perl-Math-Symbolic perl-Module-Signature perl-Parse-Yapp perl-Statistics-Descriptive perl-Test-Distribution perl-Text-CHM perl-Text-Unidecode pmount ps2eps python-chm tetex-elsevier tetex-tex4ht uread wdm wmacpi wmix xbae xchm xdialog -- Pat

6 8

Re: EPEL Packages in need of building for EL-6
by Xavier Bachelot 01 Jul '10

01 Jul '10

On 07/01/2010 10:41 AM, tremble(a)fedoraproject.org wrote: > > Dear Package owner, > > On Monday June 28th at the EPEL meeting on IRC we agreed to an initial > target date of August 15th for having all packages built for EL-6. > > This is a summary of EPEL packages for Enterprise Linux 6 that you own > which have not yet been built. > > Owner: xavierb ... snip packages list including a big pile of perl packages ... Perl packages can have a huge list of nested dependencies, usually spread to various maintainers. It can be hard to get all the deps build in a coordinated manner, or at least it induce some latency. Would it be an acceptable practice to build packages from other maintainers, in order to ease the pain ? On a related topic, would make chain-build works currently for the EL-6 branch ? Regards, Xavier

2 1

Re: EPEL Packages in need of building for EL-6
by Richard W.M. Jones 01 Jul '10

01 Jul '10

On Thu, Jul 01, 2010 at 08:41:04AM +0000, tremble(a)fedoraproject.org wrote: > > Dear Package owner, > > On Monday June 28th at the EPEL meeting on IRC we agreed to an initial > target date of August 15th for having all packages built for EL-6. > > This is a summary of EPEL packages for Enterprise Linux 6 that you own > which have not yet been built. > > Owner: rjones [list of all mingw32-* packages] These packages need to be bootstrapped. They can't be built from nothing. See: http://fedoraproject.org/wiki/MinGW/Bootstrapping I can't do this without help from someone (releng?). > ocaml-autoconf > ocaml-bitmatch > ocaml-camlimages > ocaml-camomile > ocaml-gsl > ocaml-omake > ocaml-SDL > udpcast > vhostmd > zerofree I'm assuming these other packages failed to build. Are the build failures available anywhere for me to look at? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

3 2

Re: EPEL Packages in need of building for EL-6
by Paul Howarth 01 Jul '10

01 Jul '10

On 01/07/10 09:40, tremble(a)fedoraproject.org wrote: > > Dear Package owner, > > On Monday June 28th at the EPEL meeting on IRC we agreed to an initial > target date of August 15th for having all packages built for EL-6. > > This is a summary of EPEL packages for Enterprise Linux 6 that you own > which have not yet been built. > > Owner: pghmcfc > gtkwave Current versions of gtkwave that I'd like to build in EL-6 use the Judy array library, which is not yet in EPEL. I wrote to the maintainer some time ago about this but haven't seen a response. The version of the library in Fedora isn't recent either, so perhaps the maintainer is AWOL. Haven't had time to investigate that yet. > perl-Text-SpellChecker This is built on Text::Aspell, which in turn is built on aspell. Whilst aspell is included in EL-6, it's only there for the purposes of building the hunspell dictionaries and there are no aspell dictionaries available (#590700). I think the way forward here is to bring aspell-en (at least) into EPEL-6. I don't know if the aspell-en maintainer is willing to do that themselves yet. I did look at the Text::Hunspell module as an alternative approach but it's broken (CPAN RT#39824) and seems to be dead upstream (upstream doesn't know how to fix it anyway), which is a shame given that it's the official perl binding of hunspell. Paul.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

epel-devel July 2010