We have 178 packages that aren't being maintained with several with CVE's and such. Since most of them have been unmaintained for MUCH longer than the 6 weeks.. I think they are all ready to go.
Ajaxterm Cython DMitry TurboGears TurboGears2 apbs asa babel basket bcfg2 bodhi boolstuff bottlerocket cloud-init cmake-fedora dbus-qt django-dpaste django-mptt django-simple-captcha efte euca2ools fedora-easy-karma fedora-packager firmware-extract flumotion freefem++ func funtools glances gperiodic gsh haildb halevt holland homestead horde hosts3d imp ingo kronolith libdrizzle libprelude libsx miau minirpc mod_pubcookie mongodb nagios-plugins-check_sip nautilus-actions netstiff nocpulse-common nopaste nordugrid-arc orbited pastebin pcp-gui perl-DDL-Oracle perl-NOCpulse-CLAC perl-NOCpulse-Debug perl-NOCpulse-Gritch perl-NOCpulse-Object perl-NOCpulse-SetID perl-NOCpulse-Utils perl-SVK pfqueue php-magpierss php-pear-Phlickr php-spyc php-suhosin podcatcher pop-before-smtp pyfacebook pymongo pymssql python-Lightbox python-Scriptaculous python-TurboMail python-ZSI python-babel-BabelGladeExtractor python-backports-ssl_match_hostname python-chardet python-daemon python-drizzle python-fedora python-gflags python-halite python-jinja2 python-libcloud python-libgmail python-libgmail-docs python-markdown2 python-mechanoid python-morbid python-mox python-nevow python-okaara python-ordereddict python-pgsql python-psycopg2 python-pygments python-pygooglechart python-requests python-six python-sphinx python-sphinx10 python-taboot python-text_table python-tg-devtools python-tgcaptcha python-turboflot python-twisted-web python-urllib3 python-weberror python-zmq python26-PyXML python26-PyYAML python26-argparse python26-boto python26-cheetah python26-eventlet python26-greenlet python26-jinja2 python26-markupsafe python26-mod_python python26-msgpack python26-mysqldb python26-numpy python26-paramiko python26-requests python26-sqlalchemy python26-tornado python26-virtualenv pywbem reciteword rsstool rubygem-fastthread rubygem-gem_plugin rubygem-mongrel_cluster salt salt-cloud sbackup sigul snacc spec2scl spr starlab supybot-fedora tbcload tclchecker tclcompiler tclparser testng tetex-IEEEtran tigase-server tigase-utils tigase-xmltools towhee trac-customfieldadmin-plugin trac-tickettemplate-plugin trytond turba vblade viewvc virtaal webattery windowlab wmix wordpress-plugin-add-to-any wordpress-plugin-add-to-any-subscribe xinha zikula-module-MultiHook zikula-module-Polls zikula-module-advanced_polls zikula-module-crpTag zikula-module-filterutil zikula-module-menutree zikula-module-pagemaster zikula-module-scribite
2015-01-23 19:36 GMT+01:00 Stephen John Smoogen smooge@gmail.com:
python-jinja2
Huh? In what way is it unmaintained?
- Thomas
On 23 January 2015 at 11:41, Thomas Moschny thomas.moschny@gmail.com wrote:
2015-01-23 19:36 GMT+01:00 Stephen John Smoogen smooge@gmail.com:
python-jinja2
Huh? In what way is it unmaintained?
Sorry my sentence should have said "is unmaintained or relies on an unmaintained package which will not allow for it to be cleanly installed if the unmaintained package is no longer in the EPEL repository"
python-jinja2 (maintained by: lmacken, thm) python-jinja2-2.2.1-4.el5.x86_64 requires python-babel = 0.9.5-2.el5
- Thomas
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Am 23.01.2015 um 19:36 schrieb Stephen John Smoogen:
babel
This is wrong!
I assume this comes from a bug in your script which I already mentioned to you.
Subject: "Orphaned Packages in epel5 (2015-01-23)"
babel (maintained by: jcollie, fschwarz) babel-0.9.5-2.el5.src requires python26-distribute = 0.6.10-4.el5
babel does not rely on python26-distribute nor python26. I suspect many of the python packages are classified as "depend on python26" even though they work with Python 2.4.
Please fix the script and do not remove all the Python stuff in EPEL5.
Felix
On Fri, Jan 23, 2015 at 09:33:27PM +0100, Felix Schwarz wrote:
Am 23.01.2015 um 19:36 schrieb Stephen John Smoogen:
babel
This is wrong!
I assume this comes from a bug in your script which I already mentioned to you.
This is a wrong assumption, because it is not the bug and the bug was addressed, which I also wrote you.
Subject: "Orphaned Packages in epel5 (2015-01-23)"
babel (maintained by: jcollie, fschwarz) babel-0.9.5-2.el5.src requires python26-distribute = 0.6.10-4.el5
babel does not rely on python26-distribute nor python26. I suspect many of the python packages are classified as "depend on python26" even though they work with Python 2.4.
The python26-babel subpackage relies on python 2.6 and the SPEC file requires python26-distribute. Here is an excerpt from git, branch el5:
| 3 %if 0%{?el5} | 4 %global with_python26 1 | 5 %global py26dir %{_builddir}/python26-%{name}-%{version}-%{release} | 6 %global __python26 /usr/bin/python2.6 | 7 %global python26_sitelib /usr/lib/python2.6/site-packages | 8 # Disable byte compiling. Do ourselves later. | 9 %global __os_install_post %(echo '%{__os_install_post}' | sed -e 's!/usr/lib[^[:space:]]*/brp-python-bytecompile[[:space:]].*$!!g')░ | 10 %endif | 11 | 12 | 13 %if 0%{?with_python26} | 14 BuildRequires: python26-devel | 15 BuildRequires: python26-distribute | 16 %endif
Regards Till
Hi Till,
sorry: somehow I totally misunderstood what you wrote me earlier + I didn't occur to me that also subpackages might cause the main package to be removed. Anyhow I can just hope you accept apologies.
Now it seems as if I have to do something to save a part of EPEL5's Python stack from removal.
As a first step I disabled the babel-python26 package in git. (The changelog entry is not entirely correct, as I saw now only python26-distribute goes away, not python26 itself.)
Theoretically babel could also work without setuptools/distribute but that will cause reduced functionality (and not egg metadata) which is currently provided. Personally I'd rather keep installed babel-python26 installs as-is (= just remove the subpackage) than dropping setuptools support and regressing in functionality. Please let me know if there are any objections.
What's next? Do I have to trigger a build or even push an update?
Felix
On 24 January 2015 at 14:36, Felix Schwarz fschwarz@fedoraproject.org wrote:
Hi Till,
sorry: somehow I totally misunderstood what you wrote me earlier + I didn't occur to me that also subpackages might cause the main package to be removed. Anyhow I can just hope you accept apologies.
Now it seems as if I have to do something to save a part of EPEL5's Python stack from removal.
As a first step I disabled the babel-python26 package in git. (The changelog entry is not entirely correct, as I saw now only python26-distribute goes away, not python26 itself.)
actually python26 should go away also. the entire python26 stack has been EOL by the developers
Theoretically babel could also work without setuptools/distribute but that will cause reduced functionality (and not egg metadata) which is currently provided. Personally I'd rather keep installed babel-python26 installs as-is (= just remove the subpackage) than dropping setuptools support and regressing in functionality. Please let me know if there are any objections.
What's next? Do I have to trigger a build or even push an update?
I believe a build needs to be triggered.
Felix _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Hi,
On Sat, Jan 24, 2015 at 10:36:17PM +0100, Felix Schwarz wrote:
sorry: somehow I totally misunderstood what you wrote me earlier + I didn't occur to me that also subpackages might cause the main package to be removed. Anyhow I can just hope you accept apologies.
no need for apologies. Everyone makes mistakes. :-)
Now it seems as if I have to do something to save a part of EPEL5's Python stack from removal.
You can also just maintain the python packages. AFAIK nobody is really forcing that python26 is removed from EPEL5, it is just a lack of interest in package maintainers to care about the affected packages.
What's next? Do I have to trigger a build or even push an update?
Yes, you need to push an update to make sure that no broken dependencies stay in the repository. Please do it soon so I can move forward and retire all packages with broken dependencies in EPEL.
Regards Till
Hey,
Am 25.01.2015 um 21:10 schrieb Till Maas:
Now it seems as if I have to do something to save a part of EPEL5's Python stack from removal.
You can also just maintain the python packages. AFAIK nobody is really forcing that python26 is removed from EPEL5, it is just a lack of interest in package maintainers to care about the affected packages.
I know :-)
Actually I use the python26 packages for some internal scripts but I don't have enough time to maintain them so I figured it's better to do the work in private (maybe with a COPR repo) instead of giving other the impression that this maintained with the same (high) level of attention as other Fedora/EPEL packages.
What's next? Do I have to trigger a build or even push an update?
Yes, you need to push an update to make sure that no broken dependencies stay in the repository. Please do it soon so I can move forward and retire all packages with broken dependencies in EPEL.
done: http://koji.fedoraproject.org/koji/taskinfo?taskID=8719688
Just to be sure: Is it possible to get a hierarchy-based report so one could assess why packages are removed? There are so many python packages on the el5 removal list that I don't want to do the checks for every single package...
Felix
epel-devel@lists.fedoraproject.org
-
Felix Schwarz -
Stephen John Smoogen -
Thomas Moschny -
Till Maas -
Till Maas