Python-Standards-Version
I'd like to suggest a last minute amendment to the Python Policy, that would help further transitions a lot. I'd suggest that packages uses a XS-Python-Standards-Version, that would'nt be mandatory for the current policy but *strongly* advised (a followup on every mass bug could help here) to use a: XS-Python-Standards-Version: 0.4 to specify the python policy the package is conforming to. that would help transitions a lot, and help to keep track of future transition statuses. comments ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpOjZO0pWlBk.pgp Description: PGP signature
Re: Bug#373387: python transition
Le jeu 15 juin 2006 00:00, Peter Samuelson a écrit : > unblock 373387 by 373628 > thanks > > (This block was a false positive. While we use cdbs a little, we > don't actually use it for anything python-related.) > > First, it's not clear to me what advantages anyone would get from > "fixing" the subversion packaging to comply with current python > policy. I do not see what is broken about our current package. It > doesn't hard-code python 2.3 anywhere, so it's binNMUable. (Well, > other than the "Provides: python2.3-subversion", which can probably > go away now. It's left over from renaming the package from that.) > > It's even less clear what point there is in supporting multiple > simultaneous python versions, except to avoid the need for a binNMU > once every 3 years. python-subversion has very few users. Building > the module code twice, and making the package hard to backport to > stable, is enough of a pain to make it reasonable to ask what benefit > these users will get in return. please follow-up on debian-python@ -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpUiRqR73NcS.pgp Description: PGP signature
Re: Python-Standards-Version
Pierre Habouzit ([EMAIL PROTECTED]): > I'd like to suggest a last minute amendment to the Python Policy, that > would help further transitions a lot. I'd suggest that packages uses a > XS-Python-Standards-Version, that would'nt be mandatory for the current > policy but *strongly* advised (a followup on every mass bug could help > here) to use a: > > XS-Python-Standards-Version: 0.4 > > to specify the python policy the package is conforming to. that would > help transitions a lot, and help to keep track of future transition > statuses. > > comments ? I think a better idea is to use Standards-Version as we did before (version 3.8.0 should be released) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgp4iiJXoK5ET.pgp Description: PGP signature
Re: Python-Standards-Version
Le jeu 15 juin 2006 10:50, Piotr Ozarowski a écrit : > Pierre Habouzit ([EMAIL PROTECTED]): > > I'd like to suggest a last minute amendment to the Python Policy, > > that would help further transitions a lot. I'd suggest that > > packages uses a XS-Python-Standards-Version, that would'nt be > > mandatory for the current policy but *strongly* advised (a followup > > on every mass bug could help here) to use a: > > > > XS-Python-Standards-Version: 0.4 > > > > to specify the python policy the package is conforming to. that > > would help transitions a lot, and help to keep track of future > > transition statuses. > > > > comments ? > > I think a better idea is to use Standards-Version as we did before > (version 3.8.0 should be released) well the thing is there is no way to track all the packages that *have* to follow the python subpolicy, and that makes the work of tracking them for transition harder. I think/thought it makes sense that a source package lists all the subpolicies it's supposed to follow, because it makes our lifes easier. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpr2FG8RvS4N.pgp Description: PGP signature
RFS: urwid: python transition and new upstream
Hi all, Can someone upload the urwid package from the python-modules svn? It updates to a new upstream and completes the changes needed for the new python policy. New upstream tarball is here: http://excess.org/urwid/urwid-0.9.4.tar.gz Changelog: urwid (0.9.4-1) unstable; urgency=low * New upstream release - Drop fix_shebangs (fixed upstream) and dpatch build-dep - Do not generate or install the tutorial yet (no templayer) - Drop README.Source, since we now have source for everything * Generate and install reference.html * Update for new Python Policy (Closes: #373403) * Conflict/replace upstream packages * Bump Standards-Version (no changes) * Move debhelper and cdbs to Build-Depends (needed on clean) * Add executable bits to the .py files since they have shebangs * Add Ian Ward (upstream) to Uploaders, he will co-maintain it -- Paul Wise <[EMAIL PROTECTED]> Thu, 15 Jun 2006 19:10:29 +0800 ian, if you haven't already, can you register a login on alioth and ask on debian-python to be added to the python-modules group so you have access to debian urwid svn? -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Python-Standards-Version
Pierre Habouzit ([EMAIL PROTECTED]): > Le jeu 15 juin 2006 10:50, Piotr Ozarowski a écrit : > > I think a better idea is to use Standards-Version as we did before > > (version 3.8.0 should be released) > > well the thing is there is no way to track all the packages that *have* > to follow the python subpolicy, and that makes the work of tracking > them for transition harder. > > I think/thought it makes sense that a source package lists all the > subpolicies it's supposed to follow, because it makes our lifes easier. You can't bump Standards-Version number if your package is not following *all* standards (i.e subpolicies). The fact is that python policy is not official yet (at least document on d.o is not updated) and /usr/share/doc/debian-policy/upgrading-checklist.txt.gz doesn't mention about new python policy at all. -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpbzaQcuSHeE.pgp Description: PGP signature
Re: Python-Standards-Version
Le jeu 15 juin 2006 13:36, Piotr Ozarowski a écrit : > Pierre Habouzit ([EMAIL PROTECTED]): > > well the thing is there is no way to track all the packages that > > *have* to follow the python subpolicy, and that makes the work of > > tracking them for transition harder. > > > > I think/thought it makes sense that a source package lists all the > > subpolicies it's supposed to follow, because it makes our lifes > > easier. > > You can't bump Standards-Version number if your package is not > following *all* standards (i.e subpolicies). > > The fact is that python policy is not official yet (at least document > on d.o is not updated) and > /usr/share/doc/debian-policy/upgrading-checklist.txt.gz > doesn't mention about new python policy at all. we are not talking about the same target. My goal is to be able to spot every package that has to conform to the python subpolicy by just listing those fields. Obviously the Standards-Version is bumped also, but it's not distinctive of python and not python related packages. Thouth I think it's handy, but it's not more than a suggestion, I don't really care about that. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpR4so3rmVnd.pgp Description: PGP signature
Re: Python-Standards-Version
Pierre Habouzit ([EMAIL PROTECTED]): > we are not talking about the same target. My goal is to be able to spot > every package that has to conform to the python subpolicy by just > listing those fields. Obviously the Standards-Version is bumped also, > but it's not distinctive of python and not python related packages. > > Thouth I think it's handy, but it's not more than a suggestion, I don't > really care about that. If you will be sure that _every_ package that should follow a subpolicy will have such field, than ok. It's not real IMHO :( -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpcC9y5QpRx4.pgp Description: PGP signature
installation directories for python-{central,support}
Currently both tools install into a directory
/
leading to situations like
package foo: /python-foo/same_file.py
package bar: /python-bar/same_file.py
Currently python-support does overwrite these (#373753),
python-central had a bug as well not byte-compiling these.
The intention for python-central to install these into a separate
subdirectory was to install more than one version of module foo in
(foo-1 working with python2.1, 2.2, foo-2 working with
python2.3, 2.4). I'm not sure how common this situation is, but as an
alternative solution these modules can be directly installed into
/usr/lib/pythonX.Y. OTOH packaging and archive tools cannot detect
the file conflicts anymore and become somewhat useless. I'm proposing
to drop the extra in the installation scripts and maybe
use a common prefix for both python-{central,support}. For some time
the tools had to support both (the old and the new) installation
directories. We should not do that right now, but try not to reference
the support/central dir in the packaging, so that the packaging
doesn't need to be changed later.
Comments?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python-Standards-Version
On Thu, 2006-06-15 at 13:44 +0200, Pierre Habouzit wrote: > Le jeu 15 juin 2006 13:36, Piotr Ozarowski a écrit : > > Pierre Habouzit ([EMAIL PROTECTED]): > > > > well the thing is there is no way to track all the packages that > > > *have* to follow the python subpolicy, and that makes the work of > > > tracking them for transition harder. > > > > > > I think/thought it makes sense that a source package lists all the > > > subpolicies it's supposed to follow, because it makes our lifes > > > easier. > > > > You can't bump Standards-Version number if your package is not > > following *all* standards (i.e subpolicies). > > > > The fact is that python policy is not official yet (at least document > > on d.o is not updated) and > > /usr/share/doc/debian-policy/upgrading-checklist.txt.gz > > doesn't mention about new python policy at all. > > we are not talking about the same target. My goal is to be able to spot > every package that has to conform to the python subpolicy by just > listing those fields. Obviously the Standards-Version is bumped also, > but it's not distinctive of python and not python related packages. This isn't really helpful now. Many packages have been uploaded already, without this field. Anything conforming to the new policy has XS-Python-Version. That seems to be enough to detect that it's been migrated. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Bug#373387: python transition
On Thu, 2006-06-15 at 09:15 +0200, Pierre Habouzit wrote: > Le jeu 15 juin 2006 00:00, Peter Samuelson a écrit : > > unblock 373387 by 373628 > > thanks > > > > (This block was a false positive. While we use cdbs a little, we > > don't actually use it for anything python-related.) > > > > First, it's not clear to me what advantages anyone would get from > > "fixing" the subversion packaging to comply with current python > > policy. I do not see what is broken about our current package. It > > doesn't hard-code python 2.3 anywhere, so it's binNMUable. (Well, > > other than the "Provides: python2.3-subversion", which can probably > > go away now. It's left over from renaming the package from that.) One advantage of the new policy is that it automatically records the version of Python it was compiled against as XB-Python-Version, so whether or not the package needs a binNMU is more obvious (a dependency on a specific Python version doesn't tell you whether it's an accident of compiling against that version, or if it really needs that version). > > It's even less clear what point there is in supporting multiple > > simultaneous python versions, except to avoid the need for a binNMU > > once every 3 years. python-subversion has very few users. Building > > the module code twice, and making the package hard to backport to > > stable, is enough of a pain to make it reasonable to ask what benefit > > these users will get in return. Supporting just one version, the current one, is fine. However, you do need to migrate the package to use pycentral, since dh_python alone will no longer manage the byte (re)compilation of the .py modules. > please follow-up on debian-python@ Following up both places, I don't see a good reason to move the discussion. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
python-central_0.4.16 is broken, please use 0.4.17
Brown paper bug ... as a workaround, install python2.4, so that both python2.3 and python2.4 are installed, or install 0.4.17 from http://people.debian.org/~doko/tmp/python-central_0.4.17_all.deb or from http://incoming.debian.org/ when it's available there. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
