python-devel February 2012

python-devel@lists.fedoraproject.org

7 participants
4 discussions

Django packages - proposed name changes
by Bohuslav Kabrda 07 Mar '12

07 Mar '12

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.

5 23

Bug #787712 threaded python deadlocks
by Warren Togami Jr. 25 Feb '12

25 Feb '12

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

3 4

Help with a simple package
by Caghan Demirci 09 Feb '12

09 Feb '12

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

2 1

python-sqlite2 retirement/orphaning
by Toshio Kuratomi 07 Feb '12

07 Feb '12

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

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel February 2012