Migration from python-central to python-support
Hello, since I have read [0], I'm migrating to python-support for the new version of my python-shapely package. But I admit that in the followups of the said mail, I got somehow confused... the 3 lines that Piotr suggests to add: | if [ $1 = upgrade ] dpkg --compare-versions $2 lt 1.2.3-4; then | pycentral pkgremove python-foo | fi seem to be of at least debated utility... however [1] seems still open... so in the end is there a final position on this at all? thanks Pietro P.S: it was a while since I didn't read mail from the list, but I think/hope I have read all what could even vaguely have something to do with the subject... sorry if I missed anything. [0]: http://lists.debian.org/debian-python/2009/03/msg00015.html [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479852 signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: Migration from python-central to python-support
[Pietro Battiston, 2009-05-29] since I have read [0], I'm migrating to python-support for the new version of my python-shapely package. But I admit that in the followups of the said mail, I got somehow confused... the 3 lines that Piotr suggests to add: | if [ $1 = upgrade ] dpkg --compare-versions $2 lt 1.2.3-4; then | pycentral pkgremove python-foo | fi seem to be of at least debated utility... however [1] seems still open... so in the end is there a final position on this at all? #479852 is fixed in unstable and testing (dunno why it's not closed, though, maybe there are some special cases that are still not fixed and that I'm not aware of). Anyway, this bug is NOT fixed in stable so you still need to use preinst maintainer script (I'll try to convince Matthias to fix it in Lenny soon as we didn't find other way[0] to avoid preinst) PS remember to replace 1.2.3-4 with a *first* version of your package that is using python-support and python-foo with your package name. [0] * Conflicts: python-central 0.6.10 in python-support will not guarantee that python-central is configured at upgrade (and thus old .pyc files will not be removed) * Pre-Depends: python-central = 0.6.10 in python-support will still require Pre-Depends: python-support = 0.90 in all packages that suffer from this pycentral bug (it's easier do add Pre-Depends than to add preinst IMHO but Joss see problems here and said that preinst is a better choice[1]) [1] please note that `pycentral pkgremove python-foo` could not be enough (f.e. if list of .py files provided by pycentral based package changed at least once, you'll have to use rm -rf, see f.e. python-formencode package) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531038: ITP: python-repoze-tm2 -- Zope-like transaction manager via WSGI middleware
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli z...@debian.org * Package name: python-repoze-tm2 Version : 1.0a4 Upstream Author : Agendaless Consulting repoze-dev at lists repoze org * URL : http://pypi.python.org/pypi/repoze.tm2/ * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : Zope-like transaction manager via WSGI middleware Long description coming soon ... I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. Cheers. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531042: ITP: python-toscawidgets -- Web widget creation toolkit based on TurboGears widgets
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli z...@debian.org * Package name: python-toscawidgets Version : 0.9.4 Upstream Author : Alberto Valverde Gonzalez alberto at toscat net * URL : http://toscawidgets.org/ * License : MIT/X Programming Lang: Python Description : Web widget creation toolkit based on TurboGears widgets Long description coming soon ... [ mini-boilerplate follows, for the sake of context in the bug log ] I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] Packaging will continue from the current SVN of python-toscawidgets, which was worked on in 2007, but never uploaded. The previous packagers agree (and hopefully will collaborate :-)) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531044: ITP: python-webflash -- Portable flash messages for Python WSGI apps
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli z...@debian.org * Package name: python-webflash Version : 0.1a9 Upstream Author : Alberto Valverde Gonzalez alberto at python-rum org * URL : http://python-rum.org/wiki/WebFlash * License : MIT/X Programming Lang: Python Description : Portable flash messages for Python WSGI apps Long description coming soon ... [ mini-boilerplate follows, for the sake of context in the bug log ] I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531045: ITP: python-repoze-what -- Authorization framework for Python WSGI applications
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli z...@debian.org * Package name: python-repoze-what Version : 1.0.8 Upstream Author : Gustavo Narea repoze-dev at lists repoze org * URL : http://www.repoze.org/ * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : Authorization framework for Python WSGI applications Long description coming soon ... [ mini-boilerplate follows, for the sake of context in the bug log ] I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531046: ITP: python-repoze-what-pylons -- Authorization framework for Python WSGI applications - Pylons/TG2 plugin
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli z...@debian.org * Package name: python-repoze-what-pylons Version : 1.0 Upstream Author : Gustavo Narea repoze-dev at lists repoze org * URL : http://pypi.python.org/pypi/repoze.what-pylons/ * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : Authorization framework for Python WSGI applications - Pylons/TG2 plugin Long description coming soon ... [ mini-boilerplate follows, for the sake of context in the bug log ] I'm declaring my intent to package this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *LOOKING FOR HELP* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
pkg-turbogears dead?
Hi Kov and Bob,
in the process of packaging Python modules that are needed for
TurboGears 2, I've stumbled upon the pkg-turbogears alioth project
[1], which looks like dead: not even turbogears 1 dependencies are
there and is inactive since 2006.
Can you confirm that?
Also, it looks like nowadays is more reasonable to package TG2
dependencies under the umbrella of the Python Modules team, since TG
is more and more thin and its external components are shared by other
applications or frameworks (e.g. Pylons).
If you confirm that the project is no longer in use, I propose to
request the alioth admin to close it, to diminish a bit the confusion
around TG in Debian :-)
Many thanks in advance!
Cheers.
[1] https://alioth.debian.org/projects/pkg-turbogears
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Packaging plugins for Python applications
Hello, What is the correct umbrella to package a plugin for a Python application under? DPMT or PAPT? And, is there some recommended binary package naming scheme for such packages? I am asking those questions, because I intend[1] to package hg-git[2], a plugin for Mercurial (maintained by PAPT). [1] http://bugs.debian.org/531028 [2] http://hg-git.github.com/ -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531083: ITP: python-repoze.who -- Identification and authentication framework for Python WSGI applications
Package: wnpp Severity: wishlist Owner: Stefano Zacchiroli z...@debian.org * Package name: python-repoze.who Version : 1.0.13 Upstream Author : Agendaless Consulting repoze-dev at lists repoze org * URL : http://www.repoze.org/ * License : BSD-derived (http://www.repoze.org/LICENSE.txt) Programming Lang: Python Description : Identification and authentication framework for Python WSGI applications repoze.who is an identification and authentication framework for arbitrary Python WSGI applications; it acts as WSGI middleware. . repoze.who is inspired by Zope 2's Pluggable Authentication Service (PAS), but is not dependent on Zope in any way; it is useful for any WSGI application. . It provides no facility for authorization (ensuring whether a user can or cannot perform the operation implied by the request). This is considered to be the domain of the WSGI application. [ mini-boilerplate follows, for the sake of context in the bug log ] I'm packaging this as a dependency for python-turbogears2 (TG2 for short), which is in unstable but lacks several of its dependencies, and hence is currently useless. Several libraries are missing to have a working TG2, this ITP is just one of those needed. I'm *looking for help* in maintaining the related packages, under the umbrella of the Python Modules team. Packaging will happen in the related SVN repository. [ end of boilerplate ] -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packaging plugins for Python applications
Jakub Wilk escribió: Hello, Hi Jakub, What is the correct umbrella to package a plugin for a Python application under? DPMT or PAPT? PAPT, since it's not a module And, is there some recommended binary package naming scheme for such packages? Nope, there's only one for modules, but that doesn't apply here, so just go with the upstream name if it's sensible. Best regards, Emilio signature.asc Description: OpenPGP digital signature
Re: Packaging plugins for Python applications
Emilio Pozuelo Monfort po...@ubuntu.com writes: Jakub Wilk escribió: What is the correct umbrella to package a plugin for a Python application under? DPMT or PAPT? PAPT, since it's not a module Hmm? I can't see a reasonable way to package a Python application plug-in that *isn't* a module (or a Python “package”, which is essentially a library of modules). It would make more sense, in my view, to say that an application plug-in isn't an application, so it doesn't fit PAPT. -- \“Holy uncanny photographic mental processes, Batman!” —Robin | `\ | _o__) | Ben Finney pgpqgTMVQNYt5.pgp Description: PGP signature
