Re: Ongoing Python Transition: related FTBFSes
Am Donnerstag, den 28.01.2010, 07:10 -0500 schrieb Scott Kitterman:
> > Scott Kitterman (17/12/2009):
> >> I believe that we are getting close to uploading Python 2.6 to
> >> Unstable and dropping Python 2.4 as a supported Python version. If
> >> we finish preparations in the next week, are there any ongoing
> >> transitions a python2.6/python- defaults upload would entangle that
> >> would cause the release team to want the uploads to be delayed?
> >
> > Hi,
> >
> > I'm not sure it's the proper thread to mention this, but from a quick
> > look, it sounds like related.
> >
> > FWIW, here are some FTBFSes I've reported lately, which look due to
> > this transition:
> > #567220: qscintilla2
> > #567222: python-qt3
> > #567224: python-qt4
> > #567226: pysvn
> > #567227: pyqwt3d
> > #567228: pyqwt5
> > #567231: gammu
> > #567302: babel
> >
> > python-qt* FTBFSes are likely responsible for some others, so
> > interested people may want to look into those first.
> >
> >> P.S. Please cc me on any replies as I am not subscribed to the list.
> >
> > Done. I've also added -python@ in the loop.
>
> The solution for python-qt* is a bit complicated, but is in progress. I
> saw uploads to Experimental that include new tools to better deal with
> python-sip changes.
>
Hi,
yes, the sip/python-qt* situation (including the qwt packages) is being
dealt with. Basically, the experimental upload was to get sip 4.10
through NEW, which has already happened. Now, all other build
dependencies need to be adapted (or added to Breaks: in python-sip4),
since sip 4.10 introduces a new ABI, again. However, dependencies of
sip-based packages are now on the virtual sip-abi-x.y (currently, 7.0)
packages, which is provided by python-sip and can be added to a
package's dependencies via ${sip:Depends} and dh_sip. python-qt{3,4} and
qscintilla2 in experimental already use this.
best,
Torsten
--
.: Torsten Marek
.: http://shlomme.diotavelli.net
.: tors...@diotavelli.net -- GnuPG: 1024D/A244C858
signature.asc
Description: This is a digitally signed message part
Re: Modules with changing APIs/ABIs; python-qt* package names
Am Montag, den 10.08.2009, 22:33 +0200 schrieb Piotr Ożarowski: > [Piotr Ożarowski, 2009-08-10] > > [Torsten Marek, 2009-08-04] > > > 2. Provides: > > > > I like solution 2, sounds responsible. > ^^^ > Thanks for the input! I'm currently a bit swamped in work stuff (paper deadlines coming up etc), but I'll hope I get around to finally work on that this week. I'll have a look at the renamings. There are also some requests about splitting up python-qt4 since it's rather large and depends on many different Qt4 libs, I might do it in one sweep. best, Torsten -- .: Torsten Marek .: http://shlomme.diotavelli.net .: tors...@diotavelli.net -- GnuPG: 1024D/A244C858 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Modules with changing APIs/ABIs
Hi,
python-sip4 (the runtime support library beneath all bindings of Qt for
Python) changes its ABI with more or less every major release, and
sometimes between minor releases. While practically no code uses it
directly, all Python extension modules using Qt or KDE depend on it and
have to be recompiled for every new release.
So far, in python-qt{3,4} I have handled this by depending on the
current major version (i.e. python-sip4 (>= 4.x), python-sip4 (<< 4.(x
+1)), but several more project have started using it and this approach
clearly doesn't scale.
So far, I could think of two solutions:
1. Changing binary package names
This is more or less how libraries are handled: The runtime module is
shipped in python-sip4-x (with x being whatever the ABI version happens
to be) and changed appropriately.
2. Provides:
In this scenario, the package name stays the same, but python-sip4
provides sth. like sip-runtime-x.y, which is updated accordingly.
Packages like python-qt4 then have to depend on the correct sip-runtime
version.
In any case, exact version should not be hardcoded, but provided by a
substvar. A package which builds Python extension modules has to
build-depend on sip4 (which is the code-generator package) and invoke
dh_sip4 in its rules file. Each binary package that ships a Python
extension that depends on the sip module must then depend on
${sip:Depends}, which contains either the binary package name or the
virtual package name. Thus, the packages are binNMU-safe and a new
version of sip can be handled by a simple rebuild (assuming that the
binding code does not have to be adapted, which happens frequently
enough).
I would somehow prefer solution no. 2 (less hassle, no new queue
involve), especially since the module name is always sip.so and thus
python-sip4-x+1 replaces python-sip4-x completely anyway.
If you have any comments/thoughts, I'd be pleased to hear your input.
best,
Torsten
--
.: Torsten Marek
.: http://shlomme.diotavelli.net
.: tors...@diotavelli.net -- GnuPG: 1024D/A244C858
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: Pyopengl, couple of doubts.
Am Montag, den 14.07.2008, 15:10 +0200 schrieb Andrea Gasparini: > Hi, > i'm looking at pyopengl debian/rules file[1], and I saw a couple of things > that made arise these (stupid?) question: > 1) about > install/python-opengl-doc:: > cd documentation/pydoc/ && PYTHONPATH="../.." python2.5 builddocs.py > > won't be better use a $pyvers variable? we're more general, and if (for > some strange reasons) python2.5 won't be the default, we'll take care of > it. Considering also that XS-Python-Version is "all"... Yes, that's true. I think it could also just be python, without any version and just always use the default version. > > Or when python3.0 will be the default, we'll handle it without > effort! :) > > 2) about: > clean:: > -sed -i -e '/setup\.cfg/d' PyOpenGL.egg-info/SOURCES.txt > why this? i didn't see it in any other packages, and it's not documented in > changelog. SOURCES.txt will be edited by setup.py, and it will add setup.cfg to it. This is reverted in clean, so that there is no difference to the original source distribution after debian/rules clean. best, Torsten -- .: Torsten Marek .: http://shlomme.diotavelli.net .: [EMAIL PROTECTED] -- GnuPG: 1024D/A244C858 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
PyOpenGL 3, API changes in general
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, in followup to a bug from last year, I asked Jamie Wilkinson if he would let the PyOpenGL package be maintained by the DPMT. He agreed, and I'm going to prepare a package of PyOpenGL 3 for experimental in the coming weeks. PyOpenGL 3 is not *completely* API-compatible with the 2.x series, notably error types have changed. While this might not be a major problem, I'm still wondering if there should be a general rule how to handle API breakages in Python modules/libraries. We (the PyQt maintainers) got bitten by that majorly at least one time, and the solution was to let PyQt3 conflict with all the old packages that used it. This solution is possible if there are only a handful of packages, but if the number grows this might not be feasible. The easiest solution would be to let Python packages that are prone to such problem provide a special package which other packages can then depend on. Versioned provides would be a plus, but are they going to be implemented anytime? Back to the original question, should PyOpenGL 3 become python-opengl3 or stay python-opengl? List of (known) incompatibilities is at [1]. best, Torsten [1] http://pyopengl.sourceforge.net/ctypes/using.html - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5Ko2fMVFHqJEyFgRAmlUAJ96ZsV0XMJVljNo4vOd58O+AyBtEgCcD6nR IcGOgIcH0kAptB9hbOq2LK4= =WaTW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Policy transition for IPython
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, is anybody going to work on IPython, or has already done some work for its policy transition? Otherwise, I'd do it in the upcoming days. best, Torsten - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEr1CjfMVFHqJEyFgRAhDjAKCmAOwMVXwgOT4WdvWSeslELu3E9wCfYNzy +KPPv/0CKrhomivBMICRhKM= =03tR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eggifying ellementtree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Klose wrote: > Raphael Hertzog writes: >> Hi Torsten, >> >> I've just committed a few changes to the "elementtree" source package. >> I added "egg support" to it because Turbogears (and kid) rely on it and >> elementtree (like cherrypy) do not use setuptools natively upstream (and >> the turbogears project provide "custom-made eggs" directly on their >> website: http://www.turbogears.org/download/index.html) > > that will become interesting ... elementtree is part of 2.5, no egg. > Hi Raphae, hi Matthias, I briefly thought about python-support. I don't know the internals of python-support (yet). At least there should be no namespace problems when 2.5 is released, since python-elementtree is in the namespace elementtree, 2.5's version in etree. Thus, we can drop the package once there are no versions older than 2.5 left in Debian. As to the eggs, I can just say that I my knowledge of them is very limited. I'll use this opportunity to become informed about them. best, Torste - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFERQ1sfMVFHqJEyFgRAsIXAKCrHu6cBM25eSMHqHL3gwUtGKKY7ACgjPdy SC0a9G4t1rGLHZwaAv/AbKA= =wm0f -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: python-enchant -- spellchecking library for Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Piotr Ozarowski wrote: > Torsten Marek ([EMAIL PROTECTED]): >> - the repo contains only the debian/ dir, but the mergeWithUpstream property >> is >> missing. You can set it with >> $ svn propset mergeWithUpstream 1 debian >> - you should use debhelper (>= 5) and set debian/compat to 5 > > done > >> - have you considered switching to cdbs? For a python module, the >> debian/rules > > cdbs generates bad packages, f.e. it builds .egg files, clean rule is > not working, it compresses exemple .py files (my rule is not doing it > anymore :) Hi, To suppress compression of .py files, use DEB_COMPRESS_EXCLUDE := .py Do you use an option to suppress creation of .egg files? Add it to DEB_PYTHON_BUILD_ARGS The cdbs documentation is at https://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml best, Torsten - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEQQ0YfMVFHqJEyFgRAlzaAJ4tgRWifCKoYAqyAIr6mhQ7IMK9awCfTgWZ RxNwnL3v6RdIOOEvzy1tJZQ= =WOxq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: python-enchant -- spellchecking library for Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Piotr Ozarowski wrote: > I'm looking for a sponsor for python-enchant (ITP #299783). > Package is lintian/linda clean and builds in pbuilder. > > * Package name: python-enchant > Version : 1.1.5 > Upstream Author : Ryan Kelly <[EMAIL PROTECTED]> > * URL : http://pyenchant.sourceforge.net/ > * License : LGPL with a special exception to link to non-free > spell checker backend (e.g. Microsoft Office > spell checker) > Description : spellchecking library for Python > > PyEnchant consists of Python binding to Enchant spellchecking > library and some wrapper classes. It includes all the functionality > of Enchant in Pythonic object-oriented interface, and also provides > some higher-level functionality than is available in the C API. > > > I have also updated my gaupol package, so now it recommends > python2.4-enchant > > Both packages can be downloaded from: http://debian.pox.one.pl/ > > BTW: I have permission to take over from Seo Sanghyeon Hi Piotr, I just had a look at your packaging as present in the Python module svn. I noticed several things: - - the repo contains only the debian/ dir, but the mergeWithUpstream property is missing. You can set it with $ svn propset mergeWithUpstream 1 debian - - you should use debhelper (>= 5) and set debian/compat to 5 - - have you considered switching to cdbs? For a python module, the debian/rules file boils down to: == begin #!/usr/bin/make -f include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/python-distutils.mk clean:: # hack (CDBS bug -- see #300149) -rm -rf build == end and I'm not sure if the clean:: hack is still needed. - - it's a matter of taste, but I think that compressing the example is not needed. With dh_make, you can just add the flag -X.py to dh_compress to excluded python files from compression. - - there are some grammar mistakes in the package descriptions: PyEnchant consists of Python binding*s* to *the* Enchant spellchecking library and some wrapper classes. It includes all the functionality of Enchant in *a* Pythonic, object-oriented interface and also provides some higher-level functionality *which is not* available in the C API. Apart from that, it looks good to me. Maybe you could also add a short statement about the license of the Debian packaging, along the lines of [1]. best, Torsten [1] http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEQOkWfMVFHqJEyFgRAiahAJ9ZUUqz624oqzjghfUiEnZzIOYQWwCgpof4 Z0cn97DwsJRSfV6/zaKs5sg= =BGut -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Joining the Python modules team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd like to join, too. Please add my account (shlomme). I bring in ElementTree, cElementTree and ElementTidy (currently in the NEW queue). best, Torsten - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPX5rfMVFHqJEyFgRAtyPAJ0fFQmak8n5DGQPjQA7TGJmbvLMsQCfT2HJ Hsa5NEyPf/q7pcQHu3/mzGY= =f8ac -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Python only packages and the new Python policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sergio Talens-Oliag schrieb: > Hello all, > > I was reading the last messages to the list and I've noticed that all python > packages I have are pure python and I that I could install them for all > python versions (at least for python >=2.3), but if I install the code on > /usr/lib/site-python/ the code will only work with the current python > version and the multiple package solution looks an overkill, as some people > said. > > My proposal for those cases is simple [snipped out] Hi, i like that idea. But still, pure Python packages are a minority, and C extensions have to be built for each Python version. I do not see a simple solution that can support several Python versions while keeping the overhead of packages low. And it's not so much about being compatible to older versions of Python, but to newever ones. Right now, the default Python version is outdated by quite a time, and quite some people are using 2.4 as a development base right now. I fear that it'll stay for quite some time now and might happen again in the future, so supporting only one version of Python might be feasible for stable, but not for the early adopters and developers using unstable. greetings Torsten - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCyYOhfMVFHqJEyFgRAuoLAJ0UVQX5ltPTNBvbWVEL2TMvAwwWBwCgtXAP IRjqygP6fYdFGFUGXVctipY= =xD0Y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upload of new Python extension packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donovan Baarda schrieb: > On Thu, 2005-06-30 at 14:21, Josselin Mouette wrote: > >>Le jeudi 30 juin 2005 à 21:31 +0200, Torsten Marek a écrit : >> >>>right now I have a package for ElementTidy [1] in my private repository [2], >>>which I am going to upload to Debian one day (either as a DD or via a >>>sponsor). >>>My question is, whether I should delay the upload till after Python 2.3 is >>>released or just happily go on and take into account the >>>python2.3-elementtidy >>>package being removed in some months/weeks/years/releases? >>>There are not too many users, and a link to my repo is in the wnpp bug, >>>therefore people can use the package already. >> >>Please, don't use the python2.X-foo scheme for such a small package. You >>only need a single python-foo package, built against the default python >>version. It eases transitions a lot, and avoids unnecessary cluttering >>the archive. I think I'll wait until the transition is done, then. ElementTidy depends on ElementTree, which is a package for multiple Python versions right now, but could be put into /usr/lib/site-python (it's Python-only). > > > And should pure-python modules go into /usr/lib/site-python, or > /usr/lib/python2.3/site-packages? ElementTidy contains a C extension module. > > The first means the package will not need fixing when we transition to > 2.4, but the second is what is documented in the python-policy. > > There are still quite a few things that need fixing in the policy... > Is something out yet? Any ideas how to deal with these problems? greetings Torsten - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCxIoLfMVFHqJEyFgRAgc2AJ9OvsKE+HA+DQU36GCPBXSn/xSgPgCeIWBZ MpINATejMdY3Ti/vCGc9WOM= =Go0p -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Upload of new Python extension packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, right now I have a package for ElementTidy [1] in my private repository [2], which I am going to upload to Debian one day (either as a DD or via a sponsor). My question is, whether I should delay the upload till after Python 2.3 is released or just happily go on and take into account the python2.3-elementtidy package being removed in some months/weeks/years/releases? There are not too many users, and a link to my repo is in the wnpp bug, therefore people can use the package already. thanks Torsten [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315544 [2] http://diotavelli.net/files/deb/ - -- Torsten Marek <[EMAIL PROTECTED]> ID: A244C858 -- FP: 1902 0002 5DFC 856B F146 894C 7CC5 451E A244 C858 Keyserver: subkeys.pgp.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCxEiEfMVFHqJEyFgRAgnjAJsFCxk579T2Jh5Ce3ZlAZ3e7Cp7WgCfVvpB 8hLtJCFL3OTc6MnigeWoK80= =TzPS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
