XS-Python-Version: current fix (was: Re: RFS: deejayd (updated package))
Hi, The current version of my package does not launch in unstable following the switch of the current python version. I think it is because of the current keyword in the XS-Python-Version tag. A rebuild fixes the problem. Is this appropriate fix? -XS-Python-Version: current, = 2.4 +XS-Python-Version: = 2.4, 3.0 Or should I remove the line to get the defaults? Or should I drop the 3.0 which is implied? How do I fix this? Upload new fixed version and seek a sponsor? Request a rebuild in some way (is that possible for arch: all packages?)? Thanks in advance for your advices. Alex On Tue, Apr 6, 2010 at 19:27, Alexandre Rossi alexandre.ro...@gmail.com wrote: Dear mentors, I am looking for a sponsor for the new version 0.10.0-1 of my package deejayd. It builds these binary packages: deejayd - Network controllable media player daemon deejayd-client - Client library and command line tool to access the deejayd server deejayd-gstreamer - Deejayd GStreamer backend deejayd-webui - Web interface for deejayd deejayd-webui-extension - Deejayd web user interface Iceweasel extension deejayd-xine - Deejayd XINE backend The package appears to be lintian clean. The upload would fix these bugs: 575118 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/deejayd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/deejayd/deejayd_0.10.0-1.dsc I would be glad if someone uploaded this package for me and to address any issues you would find with the package. Kind regards Alexandre Rossi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilphm0nnjh-7tgf10v4dpcq0wfdsxtlu-r0t...@mail.gmail.com
Request to join the Python Modules Packaging Team
Hello everyone! I would be glad to join the Python Modules Packaging Team. I would like to start taking care of #579114 continuing to maintain it as part of the Debian Python Modules Team and packaging pyth[1], a module intended to make it easy to convert marked-up text between different common formats. I immagine I have to send an ITA for pywavelets, right? My alioth login is: eriol-guest Thanks!!! [1] http://pypi.python.org/pypi/pyth/ -- Daniele Tricoli 'Eriol' http://mornie.org signature.asc Description: This is a digitally signed message part.
Re: Request to join the Python Modules Packaging Team
Hi Daniele, On Wed, Jun 23, 2010 at 12:04, Daniele Tricoli er...@mornie.org wrote: I immagine I have to send an ITA for pywavelets, right? yep, that's the right next-step to do :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinqqewyhdarzrbdeeofhibhsgv5urane74om...@mail.gmail.com
Re: XS-Python-Version: current fix (was: Re: RFS: deejayd (updated package))
* Alexandre Rossi alexandre.ro...@gmail.com, 2010-06-23, 10:53: The current version of my package does not launch in unstable following the switch of the current python version. I think it is because of the current keyword in the XS-Python-Version tag. A rebuild fixes the problem. Is this appropriate fix? -XS-Python-Version: current, = 2.4 +XS-Python-Version: = 2.4, 3.0 Please don't add 3.0. While we didn't agree yet how to specify 3.0 version, there's consensus that is should be explicit, i.e. = 2.4 will continue to contain only 2.* series. While current is frowned upon[0], this is not what caused your package breakage. The culprit it that scripts have #!/usr/bin/pythonX.Y shebangs - if they were unversioned, the package would continue to work with new Python. How do I fix this? Upload new fixed version and seek a sponsor? Yes. Request a rebuild in some way (is that possible for arch: all packages?)? No, it's not possible. [0] Either your Python modules are intended for general use - then they should be bytecompiled with all supported version; or they are not - then they should be put into a private directory. -- Jakub Wilk signature.asc Description: Digital signature
Re: XS-Python-Version: current fix (was: Re: RFS: deejayd (updated package))
Alexandre Rossi alexandre.ro...@gmail.com wrote: Hi, The current version of my package does not launch in unstable following the switch of the current python version. I think it is because of the current keyword in the XS-Python-Version tag. A rebuild fixes the problem. Is this appropriate fix? -XS-Python-Version: current, = 2.4 +XS-Python-Version: = 2.4, 3.0 Or should I remove the line to get the defaults? Or should I drop the 3.0 which is implied? How do I fix this? Upload new fixed version and seek a sponsor? Request a rebuild in some way (is that possible for arch: all packages?)? Thanks in advance for your advices. It will take a new upload to change this. The 3.0 is not needed. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafa233a-055d-4ac2-9674-e43c08197...@email.android.com
Re: Request to join the Python Modules Packaging Team
On Wednesday 23 June 2010 12:27:05 Piotr Ożarowski wrote: [Daniele Tricoli, 2010-06-23] I would be glad to join the Python Modules Packaging Team. I will add you this evening. Many thanks!!! :) I immagine I have to send an ITA for pywavelets, right? I hope you mean to *rename* 586894 to ITA... Of course, sorry for my poor English :( I wrote send because I have to send a mail to cont...@b.d.o Send me RFS mail once you will want to upload new version, see A3 from my FAQ¹ [¹] http://people.debian.org/~piotr/sponsor Thanks for your attention! Regards, -- Daniele Tricoli 'Eriol' http://mornie.org -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006231347.54197.er...@mornie.org
Re: XS-Python-Version: current fix (was: Re: RFS: deejayd (updated package))
While current is frowned upon[0], this is not what caused your package breakage. The culprit it that scripts have #!/usr/bin/pythonX.Y shebangs - if they were unversioned, the package would continue to work with new Python. Those are changed by python distutils, that's why a rebuild fixes the problem. My debian/rules is too complicated because I do not need to build python modules for all python versions. The following construct (from pycentral howto) is useless in my case : PYVERS=$(shell pyversions -vr) install: build $(PYVERS:%=install-python%) install-python%: python$* setup.py install --root $(CURDIR)/debian/python-foo Because setup.py is used with python$*, it replaces the shebang line with python$*. Anyway when squeeze is frozen, I won't need a lenny backport and I'll switch to a much simpler debian/rules. I'll fix the breakage in the next upload. Thanks a lot for your input. Alex -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik73ubba6sxrlinfgzazh27epokiihzpb6is...@mail.gmail.com
Re: XS-Python-Version: current fix
While current is frowned upon[0], this is not what caused your package breakage. The culprit it that scripts have #!/usr/bin/pythonX.Y shebangs - if they were unversioned, the package would continue to work with new Python. Those are changed by python distutils, that's why a rebuild fixes the problem. You can pass an option named --executable to the build_scripts command to override that, directly on the command line, or in a configuration file: $ cat setup.cfg [build_scripts] executable = /usr/bin/python Regards merwok (distutils2 GSoC student for PSF :) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c21fd3e.5070...@netwok.org
[Half-OT] Plone and: Re: python 2.6 deb for lenny ?
Hi, On Wed, 21.04.2010 at 06:46:27 +0200, Fabio Tranchitella fa...@tranchitella.eu wrote: * 2010-04-21 01:17, Bernd Zeimetz wrote: I think Fabio (kob...@d.o) also wanted to / is working on a backport, might make sense to co-maintain that with him. CCed him :) I'm definitely interested in co-maintaining the backport (and using my own backport in production already). I'll have a look at the packages from Toni, and see the difference with my own backport. well... I'm currently trying to create packages for Python 2.6.5 (bpo), and would really like to get some help with using them. As you know, I'm a Plone user, and I am a bit stumped as to how to create a clean virtualenv using python2.6 w/o disrupting the rest of the system... Some of you recommended using the Unified Installer, which I have quite mixed results with. I recently talked to a number of Zope and Plone experts, who uninanimously recommended to stay clear of the UI. So I'm back to square one, but I'd still like to use a system Python instead of a fully-local Python under eg. /usr/local. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100623170544.22732.qm...@oak.oeko.net
Proposed Email to the release team about XS/B-P-V
Subj: Future requirements for specifying supported Python versions and
transition support
In Debian Python we are currently discussing how best to specify version
information for Python 3. There is a strong (but not unanimous) view among
the participants in debian-pyt...@l.d.o and #debian-python that Python(2) and
Python 3 are sufficiently different that they should be treated as essentially
separate run time systems. If a package expresses support for Python versions
greater than (for example) 2.4, this should never include any Python 3
versions.
This discussion has caused us to take a look as the current methods for
expressing support for different python versions. AIUI the approach of
embedding this information in the source and binary control files was intended
to support the release team for Python transitions, e.g. if the source
expressed support for Python 2.4 and later:
XS-Python-Version: = 2.4
and the binary was only built for python2.5:
XB-Python-Version: 2.5
Then this would be a package that needed either binNMU or sourceful changes
for the python2.6 transition.
I have consulted with Luca Falavigna (DktrKranz) and Jakub Wilk (jwilk), who
did most of the analysis for the last two Python transitions (Adding 2.6 to
supported versions and the current transition to 2.6 as default) and neither
of them found this embedded information useful in their analysis. They did
their work based on package dependencies. While I'm sure XS/B-P-V was a good
idea at the time, it does not seem to have, in practice met it's goal.
Among the group discussing the question of how to represent Python 3 versions,
there is some reasonable consensus around the idea of a separate field in
debian/control, but there is concern about further bloating Packages.{gz,bz2}
and adding more to the binary control file.
Since support to the release team was an important use case for the current
design, we are consulting with you before any decisions are made.
The first question is: Does the release team still consider it a requirement
for supported Python{3} versions to be externally exposed in some way other
than through package dependencies? In our review of the recent transitions,
we don't see a case for it.
We have discussed a number of options (and I've added more for completeness):
1. Use XS/B-P-V for Python and Python3 versions, but Python tools must never
return any versions 3 or higher and Python 3 tools must never return versions
lower than 3. This is implemented in pyversions and py3versions in Sid. It
has the advantage of not introducing any new fields, but it does depend on
implementation correctness to avoid mixing versions. It also leads to warts
like:
XS-Python-Version: = 2.4, = 3.0
2. Create a new set of fields, XS/B-Python3-Version. This would obtain a
clearer separation and conditions like XS-Python-Version: 2.5, 2.5, 3.1 can be
treated as an error so that maintainers are aware of a problem. It does add
to the information exposed in Packages.{gz,bz2} for no clear gain.
3. Create a new field, X-Python-Version: for Python3 versions. This avoids
concerns about control file bloat, but may be a bit confusing in combination
with the existing XS/B-P-V.
4. Create a new field, X-Python3-Version: for Python3 versions and in Squueze
+1 migrate the existing XS/B-P-V to X-Python-Version. This avoids confusion,
but does require lots of packages to be changed and tools to be updated to
recognize X-Python-Version. In the long run, it does stop Python packages
from exposing information externally that has turned out not to be very
useful.
Please CC me on any replies as I am not subscribed. Anyone with an interest
in the topic is encouraged to join the discussion on debian-pyt...@l.d.o and
in #debian-python.
Scott K
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201006231315.47072.deb...@kitterman.com
Re: Proposed Email to the release team about XS/B-P-V
[Scott Kitterman, 2010-06-23] 3. Create a new field, X-Python-Version: for Python3 versions. This avoids concerns about control file bloat, but may be a bit confusing in combination with the existing XS/B-P-V. + Please note the lack of XB-Python-Version, i.e. X-Python-Version will be used to feed build tools only. 4. Create a new field, X-Python3-Version: for Python3 versions and in Squueze +1 migrate the existing XS/B-P-V to X-Python-Version. This avoids confusion, but does require lots of packages to be changed and tools to be updated to recognize X-Python-Version. In the long run, it does stop Python packages from exposing information externally that has turned out not to be very useful. is it worth mentioning migration of XS-Python-Version to X-Python-Version? Will we ever do that? For what gain? -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: Proposed Email to the release team about XS/B-P-V
Piotr Ożarowski pi...@debian.org wrote: [Scott Kitterman, 2010-06-23] 3. Create a new field, X-Python-Version: for Python3 versions. This avoids concerns about control file bloat, but may be a bit confusing in combination with the existing XS/B-P-V. + Please note the lack of XB-Python-Version, i.e. X-Python-Version will be used to feed build tools only. Thanks. 4. Create a new field, X-Python3-Version: for Python3 versions and in Squueze +1 migrate the existing XS/B-P-V to X-Python-Version. This avoids confusion, but does require lots of packages to be changed and tools to be updated to recognize X-Python-Version. In the long run, it does stop Python packages from exposing information externally that has turned out not to be very useful. is it worth mentioning migration of XS-Python-Version to X-Python-Version? Will we ever do that? For what gain? It would remove the wart of exposing useless information and slightly de-bloat the files that would no longer carry this information. If we were to start over it would be something more like this. I think it's worth mentioning the more correct design even if we conclude the gain is not worth the effort now. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d03302b6-287a-4ed0-a7fb-bc6b9eee9...@email.android.com
Re: [Half-OT] Plone and: Re: python 2.6 deb for lenny ?
* 2010-06-23 19:34, Toni Mueller wrote: Some of you recommended using the Unified Installer, which I have quite mixed results with. I recently talked to a number of Zope and Plone experts, who uninanimously recommended to stay clear of the UI. So I'm back to square one, but I'd still like to use a system Python instead of a fully-local Python under eg. /usr/local. I personally use the unified installer with the system-wide python, using --with-python; if you have system-wide python packages you don't want to expose to the UI, you can use virtenv. Best regards, Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100623174904.gf30...@mail.tranchitella.eu
Re: [Half-OT] Plone and: Re: python 2.6 deb for lenny ?
Hi, On Wed, 23.06.2010 at 19:49:04 +0200, Fabio Tranchitella fa...@tranchitella.eu wrote: I personally use the unified installer with the system-wide python, using --with-python; if you have system-wide python packages you don't want to expose to the UI, you can use virtenv. well... that's a near miss. Maybe. I have a number of problems with the Unified Installer that I see no easy way to avoid, one of them being that I want to create independent buildouts from one Plone installation, and one being that we're more than one person developing several projects together/alternatingly, off the same Plone installation (I don't want subtle differences, and nor do I want much code duplication to take care of), and one being that it is surprisingly hard to convince an installation that began as a system-wide zeo installation, to run without trying to assert special user privileges, or outside the precompiled directories. Last but not least, it works fine on one machine, but totally breaks on another machine which is otherwise quite similar - NOT really trust-inspiring... Short story: I want to abandon the UI as soon as possible. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100623191557.30638.qm...@oak.oeko.net
Re: Proposed Email to the release team about XS/B-P-V
Le mercredi 23 juin 2010 à 13:15 -0400, Scott Kitterman a écrit : 1. Use XS/B-P-V for Python and Python3 versions 2. Create a new set of fields, XS/B-Python3-Version. 3. Create a new field, X-Python-Version: for Python3 versions. 4. Create a new field, X-Python3-Version: for Python3 versions 5. End this madness and use the version in build-dependencies instead of asking maintainers to specify it twice - which they usually do wrong. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Proposed Email to the release team about XS/B-P-V
Josselin Mouette j...@debian.org wrote:
Le mercredi 23 juin 2010 à 13:15 -0400, Scott Kitterman a écrit :
1. Use XS/B-P-V for Python and Python3 versions
2. Create a new set of fields, XS/B-Python3-Version.
3. Create a new field, X-Python-Version: for Python3 versions.
4. Create a new field, X-Python3-Version: for Python3 versions
5. End this madness and use the version in build-dependencies instead of
asking maintainers to specify it twice - which they usually do wrong.
With this approach then with the current python-defaults in Sid, how would one
specify works with 2.5 and 2.6, but not 2.7?
b-d python{-all} (= 2.5), python{-all} (= 2.7)
Since a python-all version of 2.6 may at different times reflect b-d on 2.5,
2.6, and/or 2.7 versions, this isn't clear to me.
Also how does that intersect with needing specific package features to build
(e.g python-all (= 2.6.5-2~) because I switched from python-central to
dh_python2)?
I'd love to just specify it once if we can do it in a reasonably non-convoluted
and complete way.
Scott K
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/44796d70-2a7e-41ae-a736-7078f5779...@email.android.com
Re: Proposed Email to the release team about XS/B-P-V
On Thu, Jun 24, 2010 at 1:15 AM, Scott Kitterman deb...@kitterman.com wrote: In Debian Python we are currently discussing how best to specify version information for Python 3. There is a strong (but not unanimous) view among the participants in debian-pyt...@l.d.o and #debian-python that Python(2) and Python 3 are sufficiently different that they should be treated as essentially separate run time systems. If a package expresses support for Python versions greater than (for example) 2.4, this should never include any Python 3 versions. Your mail doesn't seem to mention the planned python-foo/python3-foo duplication for modules that are portable to both versions of python. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimaz8owqmc11fogtfgpvgqmsjcy-qcypg8ro...@mail.gmail.com
Re: Proposed Email to the release team about XS/B-P-V
On Wednesday, June 23, 2010 10:01:03 pm Paul Wise wrote: On Thu, Jun 24, 2010 at 1:15 AM, Scott Kitterman deb...@kitterman.com wrote: In Debian Python we are currently discussing how best to specify version information for Python 3. There is a strong (but not unanimous) view among the participants in debian-pyt...@l.d.o and #debian-python that Python(2) and Python 3 are sufficiently different that they should be treated as essentially separate run time systems. If a package expresses support for Python versions greater than (for example) 2.4, this should never include any Python 3 versions. Your mail doesn't seem to mention the planned python-foo/python3-foo duplication for modules that are portable to both versions of python. The email is meant to go to the release team to address what I understand to be release team specific requirement. I think that the broader question needs to be discussed in a broader audience. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006232242.41734.deb...@kitterman.com
Re: Proposed Email to the release team about XS/B-P-V
On Thu, Jun 24, 2010 at 10:42 AM, Scott Kitterman deb...@kitterman.com wrote: The email is meant to go to the release team to address what I understand to be release team specific requirement. I think that the broader question needs to be discussed in a broader audience. I think it is relevant there as well, IIRC folks from the then release team were behind the move from python2.X-foo to python-foo modules. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimzqrdcbyxlmafqa12t5npj4xbvze75d3skj...@mail.gmail.com
Re: Proposed Email to the release team about XS/B-P-V
On Wednesday, June 23, 2010 11:08:47 pm Paul Wise wrote: On Thu, Jun 24, 2010 at 10:42 AM, Scott Kitterman deb...@kitterman.com wrote: The email is meant to go to the release team to address what I understand to be release team specific requirement. I think that the broader question needs to be discussed in a broader audience. I think it is relevant there as well, IIRC folks from the then release team were behind the move from python2.X-foo to python-foo modules. OK. I'll include them in that discussion, although I think what we are proposing now is entirely unrelated to that decision. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006240044.37497.deb...@kitterman.com
Re: [Half-OT] Plone and: Re: python 2.6 deb for lenny ?
* 2010-06-23 21:17, Toni Mueller wrote: Short story: I want to abandon the UI as soon as possible. Me too, TBH. But.. sorry, there is either plan buildout, or UI (which produces a buildout-ready environment). Everything else (eg. debian packages) has been labeled messy, unstable, old from the developers themselves. IMHO, the real mess is Plone itself: it can be a great platform, but it is a nightmare to deploy and maintain. Best regards, Fabio -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100624045830.gg30...@mail.tranchitella.eu
