Django packages - proposed name changes
by Bohuslav Kabrda
Hi Pythonists!
in RHBZ #736776, Yury V. Zaytsev proposed renaming all Django packages (including Django itself) to python-django-*. This change is suggested because of current inconsistent state: Django and Django-south packages start with capital letters, other Django extension libraries start with lowercase letters - django-*. Also, since Django is a Python framework (not a standalone app), all of the modules should have 'python-' prepended. Personally, I agree with Yury and I think we should make this change. Here are the steps that I propose:
- discuss it on this list
- ask FPC what they think
- create a special section in Python packaging guidelines for packaging Django extensions/libraries, if we agree that we should do this change
- perhaps postponing this change to F18 might be a good idea
Note, that this change should not affect applications written in Django, only Django itself and its extensions/libraries. I would also consider using some kind of virtual provides, so that if someone types "yum install django", it will work - maybe each Django extension/library could have a virtual provide like "Provides: django(foo) = %{version}".
So, what do you think?
Regards,
Bohuslav.
11 years, 3 months
Bug #787712 threaded python deadlocks
by Warren Togami Jr.
Hey folks,
https://bugzilla.redhat.com/show_bug.cgi?id=787712
I am hitting this bug very frequently on Fedora 16 where python deadlocks.
I tried to apply the patch in this bug to python.src.rpm currently in
Fedora 16, but my local rpmbuild fails with a test error. After disabling
%check rpmbuild fails with these missing files:
File not found:
/home/warren/rpmbuild/BUILDROOT/python-2.7.2-5.2.fc16.fork.x86_64/usr/lib64/python2.7/lib-dynload/ossaudiodev.so
File not found:
/home/warren/rpmbuild/BUILDROOT/python-2.7.2-5.2.fc16.fork.x86_64/usr/lib64/python2.7/plat-linux2
It seems python is missing some BuildRequires.
Anyhow, who maintains python these days? Could we please go ahead with a
F16 test update? This is a pretty serious issue. =(
Warren Togami
wtogami(a)gmail.com
11 years, 3 months
Help with a simple package
by Caghan Demirci
Hi everyone,
I wonder if someone would be interested in releasing a simple Fedora
package for EPEL. In my estimate, it shouldn't take more than an hour. I
would do it myself, but I need to go through the whole process of getting
into FAS, and it's not worth the trouble for just an hour of real work.
I am asking for the "nautilus-python" package. The EPEL owner is listed
as dignan under
https://admin.fedoraproject.org/pkgdb/acls/name/nautilus-python, and I
think there is already an EPEL branch for nautilus-python. However, I
can't find an EPEL build for nautilus-python. See RepoView, for example:
http://dl.fedoraproject.org/pub/epel/6/SRPMS/repoview/letter_n.group.html.
And I haven't been able to reach dignan.
nautilus-python versions up to 0.7.0-3 should work under both RHEL 5 and
RHEL 6 without any modifications. Versions 0.7.0-4 and higher won't work
under RHEL 5 or RHEL 6 because they require Nautilus 3.
I already created a bug for this (
https://bugzilla.redhat.com/show_bug.cgi?id=771262) and I have been trying
to get people's attention, but no one seems to be interested in some good
karma. :)
Thanks in advance and best wishes!
-Caghan
11 years, 4 months
python-sqlite2 retirement/orphaning
by Toshio Kuratomi
In cleaning up some half-retired packages yesterday, we discovered that
the python-sqlite2 maintainer wishes to retire the package. There are a few
packages that depend on it but after reviewing the history and the code of
the packages, I think that it is reasonably safe to let this go ahead.
Historically, there was a python-sqlite module. This version is not required
by any of the code we ship now. It was replaced by python-sqlite2 (in
python, this is import pysqlite2). In python-2.5, this library entered the
python stdlib as sqlite3 (import sqlite3). The pysqlite2 library continues
to be released outside of the stdlib, mainly so that people who want to get
changes to the module (perhaps bugfixes or optimizations) at a faster rate
than the python stdlib's release cycle are able to.
In Fedora, there are several packages that have an explicit:
Requires: python-sqlite2
I've reviewed the code for all of them and discovered that most will try to
import sqlite3 from the stdlib if pysqlite2 is not present. Likely, these
just need to have the Requires: python-sqlite2 removed and the package is
then rebuilt:
* anki
* supybot-gribble
* bibus
* conduit
* firmware-extract
* gourmet
* griffith
* hamster-applet
* mysql-workbench
* python-tg-devtools
* python-sqlobject
* roundup
* sigul
* transifex
* trytond-sqlite
* yokadi
* python-keystone
There is one package that actually has a code dependency on pysqlite2. I've
submitted a patch and asked someone I know who uses the package to test it:
* plague https://bugzilla.redhat.com/show_bug.cgi?id=788189
There are two packages that have a requirement on sqlite but don't actually
have any code that uses it:
* synce-sync-engine -- Looks like it may have at one time but has been ported
to a lighterweight, internal, picklable data struct instead.
* poky-depends -- This is supposed to be a metapackage:
The poky-depends is to ensure all the required packages are installed to
build poky images. Please note that this only installs the dependency
packages.
If you want to build images, you will need to download Poky. Please refer:
http://pokylinux.org/getit/
http://pokylinux.org/support/
I'll have to talk to the poky-depends maintainer to find out if the poky
upstream works with sqlite3 from the stdlib since we aren't actually
shipping the poky code... just this package that installs the
dependencies.
If it seems acceptable to everyone involved, I'll go ahead and modify and
rebuild the packages in the first group for F17/rawhide. I'll continue to
work on porting plague and contact the maintainers of synce-sync-engine and
poky-depends to see if it's okay to remove their deps. Once all that's
done, I'll finish up the retire package process for the python-sqlite2
maintainer.
If people want to keep the python-sqlite2 package around, I'd strongly
suggest they volunteer to take over maintainance of the package so the
current maintainer can release ownership to them.
Thanks,
-Toshio
11 years, 4 months
