EPEL epel beta report: 20140429 changes
Compose started at Tue Apr 29 08:15:03 UTC 2014 New package: createrepo_c-0.3.0-1.el7 Creates a common metadata repository New package: erlang-meck-0.7.2-5.el7 A mocking library for Erlang New package: galera-25.3.5-5.el7 Synchronous multi-master wsrep provider (replication engine) New package: geany-1.24.1-1.el7 A fast and lightweight IDE using GTK2 New package: golang-github-kdar-factorlog-0-0.1.git814d8f7.el7 Fast logging infrastructure for Go New package: lib3ds-1.3.0-16.el7 3D Studio file format library New package: mariadb-galera-5.5.36-10.el7 A community developed branch of MySQL New package: munin-2.0.21-1.el7.1 Network-wide graphing framework (grapher/gatherer) New package: perl-GraphViz-2.14-4.el7 Interface to the GraphViz graphing tool New package: php-horde-content-2.0.3-2.el7 Tagging application New package: php-horde-imp-6.1.7-2.el7 A web based webmail system New package: python-bitarray-0.3.5-8.el7 Efficient Array of Booleans --C Extensions New package: thunderbird-24.5.0-1.el7 Mozilla Thunderbird mail/newsgroup client Updated Packages: htop-1.0.3-1.el7 * Mon Apr 28 2014 Morten Stevens mstev...@imt-systems.com - 1.0.3-1 - Update to 1.0.3 - Should resolve BZ#925557, BZ#987805, BZ#1091943 * Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.0.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild php-PHP-CSS-Parser-5.1.2-1.el7 -- * Mon Apr 28 2014 Remi Collet r...@fedoraproject.org - 5.1.2-1 - update to 5.1.2 php-horde-horde-5.1.6-3.el7 --- * Tue Apr 29 2014 Remi Collet r...@fedoraproject.org - 5.1.6-3 - obsoletes horde only in f21 and epel7 php-symfony-icu-1.2.1-1.el7 --- * Mon Apr 28 2014 Shawn Iwinski shawn.iwin...@gmail.com - 1.2.1-1 - Updated to 1.2.1 (BZ #1078756) * Wed Nov 27 2013 Shawn Iwinski shawn.iwin...@gmail.com - 1.2.0-1 - Updated to 1.2.0 * Wed Nov 27 2013 Shawn Iwinski shawn.iwin...@gmail.com - 1.1.0-3 - Added conflicts - Minor comments and description updates php-tcpdf-6.0.072-1.el7 --- * Mon Apr 28 2014 Remi Collet r...@fedoraproject.org - 6.0.072-1 - update to 6.0.072 puppet-3.5.1-1.el7 -- * Mon Apr 28 2014 Sam Kottler skott...@fedoraproject.org.org 3.5.1-1 - Update to 3.5.1 * Tue Apr 08 2014 Lukas Zapletal lzap+...@redhat.com 3.4.3-3 - RHBZ#1070395 - fixed error in postun scriplet - Reformatted all scriplets and corrected exit codes * Tue Apr 08 2014 Lukas Zapletal lzap+...@redhat.com 3.4.3-2 - Fixed systemd unit files - wrappers are now in use and master starts with correct context * Mon Feb 24 2014 Sam Kottler skott...@fedoraproject.org - 3.4.3-1 - Update to 3.4.3 Summary: Added Packages: 13 Removed Packages: 0 Modified Packages: 6 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL RFC: Strategy for python3 versions
Hi guys, Orion has submitted a python34 package for EPEL and I'm going to review them soon if no one beats me to it. In parallel with getting that approved I'd like to ask about the general strategy we'd like to take with maintaining python3 in EPEL. Python3 is an evolving language. New 3.N releases bring new features, bugfixes, and both backwards compatibility breaking and backwards compatibility enhancing changes (For instance, 3.3 brought the ability to mark regular text strings with the u prefix to match with python2.x. 3.5 will bring back formatting methods for byte strings.) Currently, there are a good many python libraries that work with both python2 and python3 but few libraries and few applications that are python3-only. Upstream, python3 releases generally see 18 months of bugfix updates and 5 years of security fixes[1]_. As Orion has pointed out, it would be hard for us to maintain a python3 release past upstream's EOL date as there's a lot of code in a python3 package (Not to mention the stack of packages that we'll build on top of it.) In addition, I am a little worried about the amount of time we may end up having to devote to keeping multiple python3.N packages (and stacks of packages for them) alive if we only retire old python3 releases when upstream ceases to provide support for them (back of the envelope calculations are that if we don't skip any python3.N releases, we'd be attempting to maintain 4-5 python3 releases before the first of those EOL's upstream). I'd like to propose that we attempt to maintain 2 python3 releases at any one time. We'll create python3.4 now. When python3.5 comes out in 18 months (less since python3.4 has been out for several months), we'll package that in addition. When python3.6 comes out (3 years), we'll package that and retire python3.4. Pluses: * This gives users some time to verify that their homegrown applications continue to work with the newer python3 package that we produce before the old one goes EOL. * This means that we're only working on 3 versions of python3 at a time (the two we expect users to use and the next version that we're tracking as upstream works on finishing it). * This gives us a chance to update frameworks, libraries, and other stacks of software built on top of python3 at the same time as we create the new interpreter package. So you could get python3.4 with Django-1.6.x and you could get python3.5 with Django-1.8.x Negatives: * Users will have to reverify and port apps written against python3 to the new interpreter version sometime in the 3 year lifespan of the python3 package they originally wrote it against. * Package maintainers who are creating packages that run on python3 will need to submit new packages for python3.4, python3.5, etc. * Users may have to port to both new versions of python3 and to new versions of some libraries they depend on (because we took the opportunity to update those libraries for the new python3 interpreter stack). Precedents: * With mediawiki, we now ship versioned packages and retire the old versions when upstream stops shipping updates. The stacks of packages built on top of mediawiki have to be produced for each mediawiki version. Alternatives: * Never retire the python3 packages. This leaves us trying to support the release once upstream stops support. Since new python3 releases are in demand, we'd probably end up trying to maintain all of the python3 releases that came out between when RHEL-N was released and when RHEL-N+1 releases (because maintainer focus usually shifts to building packages for RHEL-N+1 then). * Retire the python3 packages when upstream stops support. This defers the pain for users (They can use a python3.N version for about 5 years instead of about 3 years). However, it means that we're maintaining 4-5 versions of python3 at a time instead of 2-3 What do people think? Is this something we can do within the policies of EPEL? Does it make sense to go forward with this? Is it better to go with one of the alternatives? .. [1]_: Previous versions of python3 have a lifespan defined in their PEP. For instance, this one for python3.3: http://legacy.python.org/dev/peps/pep-0398/#lifespan The lifespan for the previous versions are the same: * bugfix updates for python3.N approximately every 4-6 months for approximately 18 months. * After the release of python3.N+1, a final bugfix of python3.N is released. * After that, security updates (source only) will be released until 5 years after the initial release of 3.N. 3.4 doesn't have this lifespan section but that's probably an oversight (I can ask Larry Hastings to clarify that if need be). -Toshio pgpD0KdHyh6Gn.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RFC: Strategy for python3 versions
On Tue, 29 Apr 2014 16:54:31 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: ...snip... What do people think? Is this something we can do within the policies of EPEL? Does it make sense to go forward with this? Is it better to go with one of the alternatives? ...snip... I like the plan. I'm happy to help co-maintain/package monkey versions. kevin signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL thoughts or views on packages deliberately left out of rhel?
The RC for el7 specifically omits packages that have drawn interest in the past. A few examples of such packages would be kmail and pidgin. kmail is ordinarily part of the kde-pim suite, but is stripped from the final build via some 'rm' handiwork in the spec. Pidgin is omitted from the build via a check to see if the build host is rhel. The libs are used and included, but the binary is no longer produced. I'm curious to know if anyone from the epel side has thought about how these might be included. This doesn't appear to be a more straightforward case like thunderbird, but would require some prep-work to not overwrite core packages. Thoughts as to how this might be accomplished? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RFC: Strategy for python3 versions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/29/2014 05:54 PM, Toshio Kuratomi wrote:
Hi guys,
Orion has submitted a python34 package for EPEL and I'm going to
review them soon if no one beats me to it. In parallel with
getting that approved I'd like to ask about the general strategy
we'd like to take with maintaining python3 in EPEL.
Python3 is an evolving language. New 3.N releases bring new
features, bugfixes, and both backwards compatibility breaking and
backwards compatibility enhancing changes (For instance, 3.3
brought the ability to mark regular text strings with the u
prefix to match with python2.x. 3.5 will bring back formatting
methods for byte strings.)
...
I'd like to propose that we attempt to maintain 2 python3 releases
at any one time. We'll create python3.4 now. When python3.5 comes
out in 18 months (less since python3.4 has been out for several
months), we'll package that in addition. When python3.6 comes out
(3 years), we'll package that and retire python3.4.
Pluses: * This gives users some time to verify that their homegrown
applications continue to work with the newer python3 package that
we produce before the old one goes EOL. * This means that we're
only working on 3 versions of python3 at a time (the two we expect
users to use and the next version that we're tracking as upstream
works on finishing it). * This gives us a chance to update
frameworks, libraries, and other stacks of software built on top of
python3 at the same time as we create the new interpreter package.
So you could get python3.4 with Django-1.6.x and you could get
python3.5 with Django-1.8.x
Negatives: * Users will have to reverify and port apps written
against python3 to the new interpreter version sometime in the 3
year lifespan of the python3 package they originally wrote it
against. * Package maintainers who are creating packages that run
on python3 will need to submit new packages for python3.4,
python3.5, etc. * Users may have to port to both new versions of
python3 and to new versions of some libraries they depend on
(because we took the opportunity to update those libraries for the
new python3 interpreter stack).
So, I want to be explicit as to how we handle python3 modules in EPEL.
Originally I was hoping we could simply have python3.4 provide
python3 and maintainers could branch their current Fedora python
modules for epel7 and build as is resulting in python3-module packages
as in Fedora.
However, I don't see how we transition easily to the next python3
release. I suppose we could do a side tag and rebuild everything then
have a flag day release. Does this seem workable (I don't think so)?
If we're going to require having python34-module packages are we going
to require new reviews, or can we simply have people name them with
%package -n python34-module in the epel7 branch? Would we have people
maintain multiple versions at a time in a package? This seems like
the workable version. I'm afraid that requiring new review all the
time will be a serious impediment.
We'll have %{__python34} etc macros then too.
Alternatives: * Never retire the python3 packages. This leaves us
trying to support the release once upstream stops support. Since
new python3 releases are in demand, we'd probably end up trying to
maintain all of the python3 releases that came out between when
RHEL-N was released and when RHEL-N+1 releases (because maintainer
focus usually shifts to building packages for RHEL-N+1 then). *
Retire the python3 packages when upstream stops support. This
defers the pain for users (They can use a python3.N version for
about 5 years instead of about 3 years). However, it means that
we're maintaining 4-5 versions of python3 at a time instead of 2-3
What do people think? Is this something we can do within the
policies of EPEL? Does it make sense to go forward with this? Is
it better to go with one of the alternatives?
I like the plan of supporting 2 versions at a time. I'm willing to
defer deciding on what the next version should be till later. Perhaps
3.5 won't be all that compelling and we'll want to wait for 3.6.
Finally:
python34-3.4
or python3.4-3.4
or python-3.4-3.4
or python3-3.4-3.4?
Keep provides python(abi) = 3.4?
- --
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNgUFwACgkQORnzrtFC2/ujzQCguem5bziFQQZzn1WfLPZaPbuy
adMAoMOmF2Al81HWqxCFGYJgBr5UZcjZ
=OMyV
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL thoughts or views on packages deliberately left out of rhel?
On 2014-04-30 06:57, Jim Perrin wrote: The RC for el7 specifically omits packages that have drawn interest in the past. A few examples of such packages would be kmail and pidgin. kmail is ordinarily part of the kde-pim suite, but is stripped from the final build via some 'rm' handiwork in the spec. Pidgin is omitted from the build via a check to see if the build host is rhel. The libs are used and included, but the binary is no longer produced. In the pidgin case is libpurple the main thing that gets used in RHEL? If so but it's under the 'pidgin' namespace then maybe a -bin package could be provided via EPEL or some other means. Alternatively it might make sense to file a BZ to have it moved under a different package name altogether? kmail seems like a more simple case - build an alternate spec which removed everything from the source tarball *except* kmail? Just spitballing here to get the conversation started... -s I'm curious to know if anyone from the epel side has thought about how these might be included. This doesn't appear to be a more straightforward case like thunderbird, but would require some prep-work to not overwrite core packages. Thoughts as to how this might be accomplished? ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
