Re: C API include files
Heya, On 6 December 2013 09:49, Olе Streicher debian-de...@liska.ath.cx wrote: Hi, I am the maintainer of the astropy package [1], and there the topic was brought up what to do with header files for the C API [2]. The package provides a C API for one sub-package, astropy.wcs. In the moment, its header files are just installed under On a similar note, I have libboost-python packages. It is not a python extension itself, but rather it is a C++/boost api to write compiled python extensions. At the moment headers are the same thus are simply shipped in /usr/include/ direct, the shared library however are on per-python version/flavour. At the moment libboost_python.so referes to python2 and libboost_python3.so refers to python3 (default versions). This is not ideal, as it doesn't leave room for -dbg python variants. Therefore I was thinking to ship libboost_python.so (same name) in per python versioned directories e.g. /usr/lib/python3.3/config-3.3m-x86_64-linux-gnu/ I haven't checked if that would that work out for typical boost-python extension modules. Regards, Dmitrijs. -- 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/CANBHLUhzb02K1100Aa7cL2quifMSBaJ0qwNC�5ok3twf-...@mail.gmail.com
Re: debian/rules for packages using Cython
On 13 November 2013 19:42, Tim Michelsen timmichel...@gmx-topmail.de wrote: Either don't use pybuild at clean stage with launchpad recipes, How do I disable pybuild cleaning? Please address your packaging questions to mailing list, either where this thread started. Or on debian mentors. If one is using dh(1), one should read how it works at dh(1) It accurately describes how that works, and how to override specific targets. pybuild, is simply implementation system for dh_auto_* based commands. How in general those work, see individual manpages for those, and debhelper(7) manpage for common build system options. Regards, Dmitrijs. -- 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/canbhluhnt0utcjil_h3qeuv5doj4w3lpl9j7wrmk7rw_ilw...@mail.gmail.com
Re: debian/rules for packages using Cython
On 12 November 2013 21:56, Tim Michelsen timmichel...@gmx-topmail.de wrote:
multiple other packages? I recommend pybuild for sanity.
OK, I followed that style guie but still get failures in the build:
dpkg-source -i -I --before-build recipe-1.0.1~ppa7~revno-{revno}
oh, paths with {foo} will not work, sorry (will be fixed in next
dh-python upload). I bet you wanted to replace {revno} with revision
number, though.
Yes, but usually, this should be the task of bzr dailydeb.
For instance, here it works without troubles:
https://code.launchpad.net/~pythonxy/+recipe/pandas-daily-current
This one is not use pybuild at clean, but rather python_distutils
dh clean --buildsystem=python_distutils
Regards,
Dmitrijs.
--
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/canbhluibeanafbnkkx6kpj1wypwlz+u51oz5gjhhkjwid3f...@mail.gmail.com
Re: debian/rules for packages using Cython
On 12 November 2013 22:54, Tim Michelsen timmichel...@gmx-topmail.de wrote:
This one is not use pybuild at clean, but rather python_distutils
dh clean --buildsystem=python_distutils
OK, but where can I find an example on how to configure the
corresponding pybuild-based rule correctly?
Sorry, I am lost here.
And this packaging is full of style rules but no trouble shooting guide!
no, launchpad recipes are shooting you =)
when launchpad prepares the package it clones it into a directory
which has {} in the path, and pybuild chokes on paths with {} in
it, as Piotr just explained.
Either don't use pybuild at clean stage with launchpad recipes, or
don't use launchpad repices but rather generate source package locally
and upload it into ppa with dput.
Regards,
Dmitrijs.
--
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/CANBHLUiCL7RWPAfLW33Nw9=a0ur1v0_6zdd8gjdc9+jfzrr...@mail.gmail.com
Re: Will rtupdate be used for python 2 -- python 3 transition?
On 29 October 2013 02:22, Steve M. Robbins st...@sumost.ca wrote: Hello, The Debian Python Policy documents [1] the rtupdate script for dealing with default runtime changes. Is this documentation still valid? Will rtupdate be used when the default runtime changes to python 3 or later? python3.X series and python2.X series are two distinct languages (incompatible API and ABI changes), and it has been decided to keep both alive as independent implementations. thus /usr/bin/python will always point to a python2.X implementation, the last one ever of which is python2.7. However, /usr/bin/python3 will continue to be updated, and will be migrating in debian (e.g. 3.1 - 3.2, 3.2 - 3.3, and etc). .rtupdate file location for python3 is /usr/share/python3/runtime.d ps. ... apart from Arch who decided to point python to a python3.x implementation, which is widely agreed as being wrong. And Python upstream essentially veto doing so - http://www.python.org/dev/peps/pep-0394/ Regards, Dmitrijs. -- 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/CANBHLUiEzygwknQvifxhe4a29aSgOSvag0=qodjrfhu1d3t...@mail.gmail.com
Re: Reverting switch to dh-python for pyflakes
Hello, On 21 September 2013 05:02, Thomas Goirand z...@debian.org wrote: Hi, I'm having issues with backporting pyflakes 0.7.3-1 to Ubuntu precise. It would help a lot if you reverted your switch to dh-python. Do you think that's possible? No, I will not revert that. Instead dh-python should be backported into precise-backports, if that hasn't been done yet. Similarly how it's already been backported to stable-backports. Also note that pyflakes is using/building python3 modules as well. Not sure if pyflakes support the precise's python3. Regards, Dmitrijs. -- 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/canbhlug1vff4e1yx3pz_uqnb6qhvkqodocnmno0mb5ccdbv...@mail.gmail.com
Re: dh-python in unstable
On 2 August 2013 14:15, Piotr Ożarowski pi...@debian.org wrote: dh-python is already in unstable \o/ To build/install python3-foo or pypy-foo binary packages, you can use this in debian/rules: %: dh $@ --with python2,python3,pypy --buildsystem=pybuild or if you don't want to play with .install files: export PYBUILD_DESTDIR_python2=debian/python-foo/ export PYBUILD_DESTDIR_python2-dbg=debian/python-foo-dbg/ export PYBUILD_DESTDIR_python3=debian/python3-foo/ export PYBUILD_DESTDIR_python3-dbg=debian/python3-foo-dbg/ export PYBUILD_DESTDIR_pypy=debian/pypy-foo/ %: dh $@ --with python2,python3,pypy --buildsystem=pybuild See pybuild(1) and dh_pypy(1) for more info. Note that adding dh-python to Build-Depends enables multiarch support in dh_python2 There is package that needs sources to be processed with 2to3, before doing the python3 build. So far I have failed to build the package properly with pybuild. I've tried setting PYBUILD_D_python3= to directory with processed source files, but that resulted in python3 unit-tests still running against normal python2 sources. Setting PYBUILD_BEFORE_BUILD_python3 to process the sources in-tree, resulted instead python2 unit-tests running against python3 code which fails. Is there an example of using pybuild with 2to3 style build? Package is paste. Regards, Dmitrijs. -- 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/CANBHLUjy=gF9X6MJigs5AH5-b+wjwL=BpFdUyWn=qxtsoot...@mail.gmail.com
Re: dh-python in unstable
On 28 August 2013 21:15, Barry Warsaw ba...@python.org wrote: On Aug 02, 2013, at 05:42 PM, Piotr Ożarowski wrote: [Barry Warsaw, 2013-08-02] On Aug 02, 2013, at 03:15 PM, Piotr Ożarowski wrote: export PYBUILD_DESTDIR_python2=debian/python-foo/ export PYBUILD_DESTDIR_python2-dbg=debian/python-foo-dbg/ export PYBUILD_DESTDIR_python3=debian/python3-foo/ export PYBUILD_DESTDIR_python3-dbg=debian/python3-foo-dbg/ export PYBUILD_DESTDIR_pypy=debian/pypy-foo/ I wonder if it wouldn't be possible to calculate default values for all of these. E.g. if you had: export PYBUILD_NAME=foo I think the rest could be pretty much figured out, at least for the common cases. Is that worth it? good idea, I'll add --name and PYBUILD_NAME I'm wondering if this is (supposed to be) working yet (in dh-python 1.20130819-1)? If you look at my nose2 package in svn, I tried to do this: export PYBUILD_NAME=nose2 but it didn't seem to calculate the other variables automatically, and the build did not put things in the right place. By adding these: export PYBUILD_DESTDIR_python2=debian/python-nose2 export PYBUILD_DESTDIR_python3=debian/python3-nose2 what caught me off-guard that above paths are relative dh_auto_* --sourcedirectory and are not relative top-level package src dir, aka $(CURDIR). I happen to have a normal package which has a distutils python app in a subdir that I need to build. Is that a bug or a feature? Seems inconsistent from the rest of paths specified within debhelper. Regards, Dmitrijs. -- 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/canbhlujq43dzs3ybtbnpwisvuvvp-lzrp+oyfwqaf0rn42c...@mail.gmail.com
Re: dh-python in unstable
On 2 August 2013 14:15, Piotr Ożarowski pi...@debian.org wrote: dh-python is already in unstable \o/ To build/install python3-foo or pypy-foo binary packages, you can use this in debian/rules: %: dh $@ --with python2,python3,pypy --buildsystem=pybuild Shouldn't it be soon. dh $@ --with python2,python3,pypy,pypy3 --buildsystem=pybuild pypy published a release with python3 support in which case, can pypy2 become an alias for pypy to at least match python2, python3 ? Regards, Dmitrijs. -- 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/CANBHLUgx6Y8UZ2hORFbqq7pv5GzppSWs0FfHNtEDKu=vzr2...@mail.gmail.com
Re: python3.3 status
On 13 June 2013 07:01, Scott Kitterman deb...@kitterman.com wrote: On Wednesday, June 12, 2013 03:13:38 PM Scott Kitterman wrote: On Wednesday, June 12, 2013 12:48:45 AM Scott Kitterman wrote: On Thursday, June 06, 2013 12:46:05 PM Scott Kitterman wrote: More updates and added all the unknown packages from the transition tracker. Items marked as fixed in the last update have been removed. On Thursday, May 23, 2013 06:19:06 PM Scott Kitterman wrote: I've been working on this a bit ... On Tuesday, May 07, 2013 02:01:26 PM Jakub Wilk wrote: python3-defaults maintainer(s?) decided to make python3.3 a supported version without prior notice. Yay. Now we have dozens of packages failing to build: boost1.49 FTBFS TODO (could not find an open bug) - I plan to ignore this this and wait until the boost1.53 transition starts and we can not care. boost1.49 fixed in the 1.49.0-4 upload. Regards, Dmitrijs. -- 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/CANBHLUi0rvVWs60=D_Pya-NxYczsh2AV=jm1x=1yexcub2-...@mail.gmail.com
Re: pyflakes and Python 3 scripts (was Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz)
On 24 May 2013 20:40, Barry Warsaw ba...@python.org wrote: On May 24, 2013, at 02:55 PM, Barry Warsaw wrote: py3flakes - What I don't like about that is that it's harder to locate(1). I like pyflakes3, but better yet I'd prefer: python3 -m flakes similar to how compileall / unittest / et al work. Regards, Dmitrijs. -- 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/canbhluh-ejci6vrcxafbgrjkqvmo0+9zwd+knk+53aggbxf...@mail.gmail.com
Re: Accepted python-defaults 2.7.3-5 (source all)
On 6 May 2013 00:29, Sandro Tosi matrixh...@gmail.com wrote: Hello, has this been discussed *and* agreed on? I can only see Luca's mail for python plans, but no ack from other members of the debian python board nor the ACK from RT. Python2.6 security support ends in October 2013 upstream. Which is well ahead of jessie freeze release. From security point of view alone, it would be unwise to ship python2.6 in jessie. Which imho is serious enough reason to remove python2.6 given its potential high exposure when used by web-frameworks. Regards, Dmitrijs. On Mon, May 6, 2013 at 3:18 AM, Matthias Klose d...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 06 May 2013 02:48:48 +0200 Source: python-defaults Binary: python python-minimal python-examples python-dev idle python-doc python-dbg python-all python-all-dev python-all-dbg Architecture: source all Version: 2.7.3-5 Distribution: unstable Urgency: low Maintainer: Matthias Klose d...@debian.org Changed-By: Matthias Klose d...@debian.org Description: idle - IDE for Python using Tkinter (default version) python - interactive high-level object-oriented language (default version) python-all - package depending on all supported Python runtime versions python-all-dbg - package depending on all supported Python debugging packages python-all-dev - package depending on all supported Python development packages python-dbg - debug build of the Python Interpreter (version 2.7) python-dev - header files and a static library for Python (default) python-doc - documentation for the high-level object-oriented language Python python-examples - examples for the Python language (default version) python-minimal - minimal subset of the Python language (default version) Changes: python-defaults (2.7.3-5) unstable; urgency=low . * Drop Python 2.6 as a supported Python version. Checksums-Sha1: 315dc450ead64db62a2fa12ad33b47274c995904 1560 python-defaults_2.7.3-5.dsc 328d99a7291bb06fc6e34d82d2c6b284ae9dacaa 164899 python-defaults_2.7.3-5.tar.gz a41aa886f6e511400424c73c8eb620e2b981d83a 184016 python_2.7.3-5_all.deb 6a89b342c56926c9a88a9f674d8ff2cb67a142ba 41796 python-minimal_2.7.3-5_all.deb 48f7d67b1692a6b9fbfa56417a56c587c7cf85fe 850 python-examples_2.7.3-5_all.deb af3227891f517dcc595c71f8c76dd9cb2e086f17 908 python-dev_2.7.3-5_all.deb 21b2969b35907c50d49465553c327d37fec6513f 3032 idle_2.7.3-5_all.deb 2132985c086355f0beec97ef561335e3fc32338a 22738 python-doc_2.7.3-5_all.deb aa637dab2b14a02f83c29a77aa4a98fa314f3d0f 1008 python-dbg_2.7.3-5_all.deb 725d890be4a767c02fd9466765a3c8493ba1a8c4 856 python-all_2.7.3-5_all.deb 93869e7bbe3d15ab2ed3e2dd546fd1f05ec5e73a 874 python-all-dev_2.7.3-5_all.deb e46b3d62aa365e95a957c49add92252b154cf2aa 882 python-all-dbg_2.7.3-5_all.deb Checksums-Sha256: 4cc77363730638924075a9ec096f8870c6a67fb36bd6b12fd1e6c669b9055e8e 1560 python-defaults_2.7.3-5.dsc 82a2a99e9a81b8552f23665f305b353702d5d854803d497842a6b1f0b0ff 164899 python-defaults_2.7.3-5.tar.gz 3e7a417705fa203a9629e5bbd3893b2506e79ef3a2463a99e338380f0188d096 184016 python_2.7.3-5_all.deb b057061a2d2d8281b43836ae56e0ee2e86b25d1236d1aed6299760e1d06c713e 41796 python-minimal_2.7.3-5_all.deb c9324ca4cb0ed964e8b273f0d81bf3f5a29be71539e75ff8f62d2daba8f23995 850 python-examples_2.7.3-5_all.deb 74b58147b451b1bc278dbd8cdcb12294fa5381975e24ae92a87a9933150d8b8a 908 python-dev_2.7.3-5_all.deb db41c1e2983d79df8187c3a1ffdd2c4ba22bbf7d90e45e2bdb0f3b62c01611fa 3032 idle_2.7.3-5_all.deb 090f564a8ae8cdcb8b1d5e59dc766237a2a124a9e29a506c2c78f1075a357e07 22738 python-doc_2.7.3-5_all.deb 51d56f09fb38920e1066c883fdc013facd069da5ac2172b5b5302ad305189ea9 1008 python-dbg_2.7.3-5_all.deb 09e0831f1c5e8ef3d13699003614df3028c18853cb92751982843dfdeba32756 856 python-all_2.7.3-5_all.deb 43984b78bc44f82fdf3c4554c5d0bd77b22e171a2ddfdfe8f161424a052d33a7 874 python-all-dev_2.7.3-5_all.deb b43eeca70ed21769bdc478cb26c7172cb1c4806b96e60f56cbe3e481529101b5 882 python-all-dbg_2.7.3-5_all.deb Files: ea09587c19d1fc46f1ee21313d1985d4 1560 python optional python-defaults_2.7.3-5.dsc cde37a578130113b6404de0dd4ee228a 164899 python optional python-defaults_2.7.3-5.tar.gz af727799182693133343afeef1e17800 184016 python standard python_2.7.3-5_all.deb 4dd3d659dbd2f7705f0aa10f34fdd350 41796 python standard python-minimal_2.7.3-5_all.deb 4404958df2028d7e12f463a17391f6ee 850 python optional python-examples_2.7.3-5_all.deb da57f5461bf1e2c1338e3ebbb971888b 908 python optional python-dev_2.7.3-5_all.deb 96d8a24c4590b15681a0ab5c236cb648 3032 python optional idle_2.7.3-5_all.deb d098b041656927b689a51b5bd567dc11 22738 doc optional python-doc_2.7.3-5_all.deb 7e5d66559b7566079f485a085c03cd85 1008 debug extra python-dbg_2.7.3-5_all.deb 835fc1f38b7c9bf01a6e5c2f83530613 856 python optional python-all_2.7.3-5_all.deb
Re: About canonical Vcs fields
On 23 March 2013 12:37, Jakub Wilk jw...@debian.org wrote: * Dmitry Shachnev mity...@gmail.com, 2013-03-23, 15:51: I use svn.d.o everywhere, I don't like the new ones. However, the thing I don't like much more is inconsistency: some packages use svn.d.o, some anonscm.d.o, and some mixture of the two... Ugh. I don't mind switching if we switch everything at once. I'm happy to make the mass-commit if there's consensus that this is the right to do. I don't have anything against a mass-commit, it looks like others don't as well. And Dmitrijs provided a good technical rationale... so please do it :) Okay. Unless I hear objections, I'll do mass-commit to switch to anonscm.d.o in ~2 weeks. Can you do such commit simply after wheezy is out the door? Regards, Dmitrijs. -- 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/canbhluiiddtubaaukrznmqsksxqvzrbgxnbayr2z_8byfl5...@mail.gmail.com
Re: About canonical Vcs fields
On 14 March 2013 13:56, Dmitry Shachnev mity...@gmail.com wrote: Hi, We discussed new lintian vcs-field-not-canonical check in IRC last week, which affects *lots* of packages in our SVN (see [¹]). Now people are recommended to use `svn://anonscm.debian.org/*` URIs instead of `svn://svn.debian.org/*`, but it seems that it's not what most packages use at the moment. So let's do a quick poll: [1a] I used anonscm.debian.org, and like it. [1b] I used svn.debian.org, but like the new URIs and will switch. [2a] I used svn.debian.org, don't like the new URIs but I don't mind switching. [2b] I used svn.debian.org, and will continue to use it, lintian should allow that. [2c] I used anonscm.debian.org, but don't like it. (I hope I've covered all options, let me know if there is something not listed above. If you had different packages that used different URIs, vote for the variant that applies to the biggest part of your packages.) Some technical rational behind switching to annonscm: The machine hosting alioth.debian.org is running on wagner.debian.org. VCSs are no longer on wagner since the migration which took place during 2011, vasks.debian.org is now hosting svn.debian.org, arch.debian.org, bzr.debian.org, darcs.debian.org, git.debian.org, and hg.debian.org. Those services are tightly related to Alioth since all the user accounts and the groups are taken from FusionForge database. This means that you can only create VCS repositories for existing alioth projects and that any member of that project will have access to the corresponding public repository. So it was nice when all of them pointed to alioth, now all $vcs are on vasks and thus have a new / different ssh host key. So it's nice to change hostname for all VCS fields to point to something that internally resolves to vasks, and at the same time not expose the internal host name. anonscm is as good as any to serve this purpose. Regards, Dmitrijs. -- 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/canbhluikpo3hpepqtzpgfuce+bpwweqwpeqxzmfr3vuvjd8...@mail.gmail.com
Re: [Python-apps-commits] r9456 - in packages/pyflakes/trunk/debian (7 files)
On 25 February 2013 19:03, Sandro Tosi sandro.t...@gmail.com wrote:
hey, can you stop committing huge changes without asking to uploaders
first? I've already contacted you when you un-coordinately upload
pyflakes to experimental, ans you hadn't reply - it's time to give it
a stop now
I'm sorry for missing your previous email, due to a filtering mistake
on my side.
My understanding was that package has Debian Python Team set as
maintainer, such that improvements and co-maintainership is welcomed.
Newer packages in experimental require/need/want pyflakes support
specifically python3 support.
Do you disagree with proposed changes? If yes, please comment and
revert relevant pieces.
Or is this just a concern over my lack of courtesy? If you feel the
need to ack every commit of pyflakes, you should consider moving
python team to uploads and setting yourself as maintainer and/or
removing the package from the team all together. In either of those
cases, I typically file wishlist bugs with a patch attached.
I again apologies for not promptly replying to your previous message.
Regards,
Dmitrijs.
On Mon, Feb 25, 2013 at 7:20 PM, x...@users.alioth.debian.org wrote:
Date: Monday, February 25, 2013 @ 18:20:53
Author: xnox
Revision: 9456
Add python3 package / module.
Added:
packages/pyflakes/trunk/debian/patches/use-standard-unittest.patch
packages/pyflakes/trunk/debian/pyflakes.manpages
(from rev 9455, packages/pyflakes/trunk/debian/manpages)
Modified:
packages/pyflakes/trunk/debian/changelog
packages/pyflakes/trunk/debian/control
packages/pyflakes/trunk/debian/patches/series
packages/pyflakes/trunk/debian/rules
Deleted:
packages/pyflakes/trunk/debian/manpages
Modified: packages/pyflakes/trunk/debian/changelog
===
--- packages/pyflakes/trunk/debian/changelog2013-02-25 14:11:44 UTC (rev
9455)
+++ packages/pyflakes/trunk/debian/changelog2013-02-25 18:20:53 UTC (rev
9456)
@@ -1,3 +1,9 @@
+pyflakes (0.6.1-1~exp1ubuntu1) UNRELEASED; urgency=low
+
+ * Add python3 package / module.
+
+ -- Dmitrijs Ledkovs dmitrij.led...@ubuntu.com Mon, 25 Feb 2013 18:15:57
+
+
pyflakes (0.6.1-1~exp1) experimental; urgency=low
* New upstream release:
Modified: packages/pyflakes/trunk/debian/control
===
--- packages/pyflakes/trunk/debian/control 2013-02-25 14:11:44 UTC (rev
9455)
+++ packages/pyflakes/trunk/debian/control 2013-02-25 18:20:53 UTC (rev
9456)
@@ -3,8 +3,10 @@
Priority: optional
Maintainer: Python Applications Packaging Team
python-apps-t...@lists.alioth.debian.org
Uploaders: Tristan Seligmann mithra...@mithrandi.net, Varun Hiremath
va...@debian.org, Sandro Tosi mo...@debian.org
-Build-Depends: debhelper (= 9), python
+#Needs python3.3 to run unittests, but can be executed / used with lower
py3.x
+Build-Depends: debhelper (= 9), python, python3, python3 (= 3.3) |
python3.3
XS-Python-Version: = 2.6
+X-Python3-Version: = 3.2
Standards-Version: 3.9.4
Homepage: https://launchpad.net/pyflakes
Vcs-Svn: svn://anonscm.debian.org/python-apps/packages/pyflakes/trunk/
@@ -20,3 +22,14 @@
.
Unlike PyLint, Pyflakes checks only for logical errors in programs;
it does not perform any checks on style.
+
+Package: py3flakes
+Architecture: all
+Depends: ${python3:Depends}, ${misc:Depends}
+Description: passive checker of Python 3 programs
+ Pyflakes is program to analyze Python 3 programs and detect various
+ errors. It works by parsing the source file, not importing it, so it
+ is safe to use on modules with side effects. It's also much faster.
+ .
+ Unlike PyLint, Pyflakes checks only for logical errors in programs;
+ it does not perform any checks on style.
Deleted: packages/pyflakes/trunk/debian/manpages
===
--- packages/pyflakes/trunk/debian/manpages 2013-02-25 14:11:44 UTC (rev
9455)
+++ packages/pyflakes/trunk/debian/manpages 2013-02-25 18:20:53 UTC (rev
9456)
@@ -1 +0,0 @@
-debian/pyflakes.1
Modified: packages/pyflakes/trunk/debian/patches/series
===
--- packages/pyflakes/trunk/debian/patches/series 2013-02-25 14:11:44
UTC (rev 9455)
+++ packages/pyflakes/trunk/debian/patches/series 2013-02-25 18:20:53
UTC (rev 9456)
@@ -1 +1,2 @@
add_main_function.diff
+use-standard-unittest.patch
Added: packages/pyflakes/trunk/debian/patches/use-standard-unittest.patch
===
--- packages/pyflakes/trunk/debian/patches/use-standard-unittest.patch
(rev 0)
+++ packages/pyflakes/trunk/debian/patches/use-standard-unittest.patch
2013-02-25 18:20:53 UTC (rev 9456)
@@ -0,0 +1,86 @@
+Description: do not use
Re: [Python-apps-commits] r9456 - in packages/pyflakes/trunk/debian (7 files)
On 25 February 2013 20:29, Sandro Tosi sandro.t...@gmail.com wrote: On Mon, Feb 25, 2013 at 8:15 PM, Dmitrijs Ledkovs x...@debian.org wrote: On 25 February 2013 19:03, Sandro Tosi sandro.t...@gmail.com wrote: hey, can you stop committing huge changes without asking to uploaders first? I've already contacted you when you un-coordinately upload pyflakes to experimental, ans you hadn't reply - it's time to give it a stop now I'm sorry for missing your previous email, due to a filtering mistake on my side. My understanding was that package has Debian Python Team set as maintainer, such that improvements and co-maintainership is welcomed. and they are, but switching python helper or introducing a new package are huge changes enough to require a consultation with the people that are responsible for the package (the uploaders), which didn't happen. In my view they aren't, since -support is deprecated in the team and many pyflakes reverse-build-dependencies are being ported to python3. But point taken. I'm not sure I agree with consultation who are responsible for the package in the context of python-team uploaders field usage as done in pyflakes. But I am fine with your interpretation, I shall consult you from now on, when I notice you in the maintainer/uploaders/who-uploads fields. Newer packages in experimental require/need/want pyflakes support specifically python3 support. explicit is better than implicit: file a bug against pyflakes, explaining why you need a new package and what's the tool requiring it - that's what I'd expected. ack. Do you disagree with proposed changes? If yes, please comment and revert relevant pieces. I'm disagreeing with the *way* you're doing such changes. ok. Thanks for explaining it as well. Or is this just a concern over my lack of courtesy? If you feel the need to ack every commit of pyflakes, you should consider moving python team to uploads and setting yourself as maintainer and/or removing the package from the team all together. In either of those cases, I typically file wishlist bugs with a patch attached. see above: team maintenance (even with team set to maintainer) doesn't mean you can do whatever changes you see fit for the moment (and them maybe disappear because you lost interest). small changes doesn't require any ack from my side; adding new bin packages or changing helper do. Ok. I do wonder where the line of small vs not-so-small changes lies, but I guess it will often be different on per-package specific factors/basis. Point taken. Regards, Dmitrijs. -- 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/canbhluhhathkcsosrrz0pstzhan_f2osn6y1p7tnc86fkhm...@mail.gmail.com
Re: How does team maintenace of python module works?
On 19 February 2013 23:49, Ludovic Gasc gml...@gmail.com wrote: On Feb 19, 2013 11:21 PM, Barry Warsaw ba...@python.org wrote: On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote: I can do that this week-end. I've only a github account to publish the git repository, unless somebody else has an access for a better place? For a test, I think that github is enough. Using github would be against the basic principles laid out in the Debian Social Contract. While gitorious hosted solution, would be ok it reimplements the git server protocol and hence lacks many features. It is best to continue to use excellent hosting facilities provided by git.debian.org / alioth.debian.org. One can create repositories in a home directory (please don't use official team account / group names) which would be good enough for maintainance. Having an gerrit instance would help a lot to serve merge requests functionality. Regards, Dmitrijs. -- 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/canbhlugvhb5fv3srj+dojsvit+1hordojkuafzbgeolhx5+...@mail.gmail.com
Re: [Python-modules-team] Bug#699312: Bug#699312: pytest version in raring is old
On 16 February 2013 18:10, Simon Chopin chopin.si...@gmail.com wrote: Hello Joseph, Quoting Joseph Tate (2013-01-30 05:27:08) I've updated the version of pytest to the latest upstream. It doesn't need to be backported, I would just like to see the version in raring be updated. *** /tmp/tmpKV7SC6/bug_body In Ubuntu, the attached patch was applied to achieve the following: * New upstream release, backport to precise Thanks for considering the patch. As you might not be aware of, Debian testing is currently frozen, which means that to keep a clear migration path for RC bug fixes I avoid uploading new upstream versions to unstable at this time. However, I'm considering uploading this new upstream version to experimental as soon as I've figured out how the DPMT deals with branching. Some started pushing experimental to trunk, expecting no further uploads into sid. Some create branches/experimental if they expect to keep the two in parallel. Just do it, and tag it, one can always branch from a tag if further uploads to sid are required. Although a consensus would be nice. d-i team for example is using a jessie branch name for things that should atm be uploaded into experimental. Regards, Dmitrijs. -- 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/CANBHLUj9Uv63TSv6UO5vc_XF=oKyPCWdfA=vybuxvj-nwsb...@mail.gmail.com
Re: How does team maintenace of python module works?
On 16 February 2013 14:27, Jakub Wilk jw...@debian.org wrote: * Scott Kitterman deb...@kitterman.com, 2013-02-16, 09:10: On Saturday, February 16, 2013 12:43:02 PM Thomas Kluyver wrote: The following four positions have all been advocated in this thread: A - Maintain the status quo, in which DPMT packages may only be maintained in SVN. B - As A, but encourage the creation of a separate team where Python modules can be maintained in git. C - Allow DPMT-maintained packages to live in SVN or git, so new packages can be committed to git if the packager prefers. Optionally, we could make provisions to migrate existing packages. D - Migrate all the DPMT-maintained packages to git. (I suggest we don't consider other VCSs - while we might have our favourites, I sampled the list of Debian teams, and found very few using anything other than svn or git. So tools workflows for other VCSs are likely to be less well developed.) So I would vote CDBA, in order of preference. E - Migrated to bzr, but I want someone else to to all the work. EA F - Migrate to Mercurial, but I want someone else to do all the work. A, F.1 - Migrate to Mercurial, if and only if mercurial queues are fully functional and are used to maintain the debian/patches sub-repository. realisticly i am opposed to a mix of version control systems. someone to do the work - means starting a mirror which works in read-only / mirror mode only. When gnome.org was migrating from svn - they had multiple mirrors running (bzr, and git, not sure if an hg was there as well) Regards, Dmitrijs. -- 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/CANBHLUjUfbFBnanRP2P9pu2M_PmmvEUWC5W4Byi=-ns2hqg...@mail.gmail.com
Re: How does team maintenace of python module works?
On 16 February 2013 21:35, Robert Collins robe...@robertcollins.net wrote: On 17 February 2013 08:29, Dmitrijs Ledkovs x...@debian.org wrote: On 16 February 2013 14:27, Jakub Wilk jw...@debian.org wrote: * Scott Kitterman deb...@kitterman.com, 2013-02-16, 09:10: On Saturday, February 16, 2013 12:43:02 PM Thomas Kluyver wrote: The following four positions have all been advocated in this thread: A - Maintain the status quo, in which DPMT packages may only be maintained in SVN. B - As A, but encourage the creation of a separate team where Python modules can be maintained in git. C - Allow DPMT-maintained packages to live in SVN or git, so new packages can be committed to git if the packager prefers. Optionally, we could make provisions to migrate existing packages. D - Migrate all the DPMT-maintained packages to git. (I suggest we don't consider other VCSs - while we might have our favourites, I sampled the list of Debian teams, and found very few using anything other than svn or git. So tools workflows for other VCSs are likely to be less well developed.) So I would vote CDBA, in order of preference. E - Migrated to bzr, but I want someone else to to all the work. EA F - Migrate to Mercurial, but I want someone else to do all the work. A, F.1 - Migrate to Mercurial, if and only if mercurial queues are fully functional and are used to maintain the debian/patches sub-repository. realisticly i am opposed to a mix of version control systems. someone to do the work - means starting a mirror which works in read-only / mirror mode only. When gnome.org was migrating from svn - they had multiple mirrors running (bzr, and git, not sure if an hg was there as well) Regards, Dmitrijs. I will *always* have a soft spot in my heart for bzr, having spent many years working on it. But consider: http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bazaarshow_installed=onshow_vote=onwant_legend=onwant_ticks=onfrom_dateto_datehlght_datedate_fmt=%25Y-%25mbeenhere=1 Corrected url s/bazaar/bzr/ and disabled vote to make the graph lighter. http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bzrshow_installed=onwant_legend=onwant_ticks=onfrom_date=to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1 If we're changing VCS, there is a vastly higher probability that the folk whose software we are packaging is in git, and that contributors we get will be familiar with git, than any other system now. That doesn't mean git is better or worse, but if we're changing systems because of preference (rather than fitness-for-purpose), then I think we'd be crazy to consider any other VCS. svn is very alive and stable. I have managed in the past to crash or otherwise make bzr/hg/git inconsistent. Some of my bugs got fixed and mostly git is fit for purpose on the stability side of things. I haven't used hg in a while. svn has always been good for me (but i guess i'm a fairly recent developer and haven't seen the pre 1.5 days of svn). we are yet to figure out a packaging workflow that works great, especially w.r.t. patch management. On one hand you want to simply commit and merge, on the other hand you want to ship a patch series for the convenience of dowstream/users, but that means rebasing, and rebasing is pain to track history off, hence end up committing patches but one wants to commit directly LOOPREACHED. Regards, Dmitrijs. -- 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/canbhluimts5aijzvzcuye9yajm6rzkbskvsadnjdug9prp0...@mail.gmail.com
Python Software Foundation: Python Trademark at Risk
Dear All, Full article: http://pyfound.blogspot.co.uk/2013/02/python-trademark-at-risk-in-europe-we.html There is a company in the UK that is trying to trademark the use of the term Python for all software, services, servers... pretty much anything having to do with a computer. Specifically, it is the company that got a hold on the python.co.uk domain 13 years ago. According to our London counsel, some of the best pieces of evidence we can submit to the European trademark office are official letters from well-known companies using PYTHON branded software in various member states of the EU so that we can obtain independent witness statements from them attesting to the trade origin significance of the PYTHON mark in connection with the software and related goods/services. We also need evidence of use throughout the EU. Further instructions on how to submit letters of support are in the blog article linked above. Please help defend python trademark. Regards, Dmitrijs. -- 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/CANBHLUh5LzzB3=fYjWMbFmGSEw452zjV=xfp0oexuxzemfb...@mail.gmail.com
Re: How does team maintenace of python module works?
On 12 February 2013 15:08, Dmitry Shachnev mity...@gmail.com wrote: Hi Thomas, On Tue, Feb 12, 2013 at 7:00 PM, Thomas Goirand z...@debian.org wrote: ... So I wonder, how is the python module packaging policy? Since this module is marked as team maintained, and that I've been accepted in the python module packaging team on Alioth, am I allowed to just refresh the package, and upload version 1.0 in debian experimental? Or do I need approval from current uploaders? What does it mean for a package to be team maintained in the python packaging team? If the team is in Maintainer field, I think you can freely upload the new version. See http://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin#Policy_About_Maintainer_and_Uploaders_Fields for details. But please join the team and update the svn repository, or alternatively ask somebody from the team to commit your upload. Regards, Dmitrijs. -- 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/CANBHLUj8e2LVJzSYcERve7+t33cANU+2w=q1cref0zhmheo...@mail.gmail.com
Re: PIL/python-imaging becomes a python package and gets Python3 support
On 10 February 2013 16:54, Matthias Klose d...@debian.org wrote: There are 126 source packages needing updates. The list of packages and maintainers is attached below. I'll file bug reports later (user: d...@debian.org, tag: pillow). I see that a few packages were identified to work out of the box by fedora folks and they have also started patching packages. There is some overlap so it's worth checking fedora trackers before doing our own patches: https://fedoraproject.org/wiki/Features/Pillow https://bugzilla.redhat.com/show_bug.cgi?id=894484 Debian HPIJS and HPLIP maintainers pkg-hpijs-de...@lists.alioth.debian.org hplip Matthias Klose d...@debian.org python-reportlab Does this mean that hplip python-reportlab are now have all their dependenices ported to python3 and hence can also be ported? \o/ Regards, Dmitrijs. -- 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/canbhlugyw1bnnnzsextrrndjqdetj02yaaz3x+vsazagrfk...@mail.gmail.com
Re: Setting http_proxy in debian/rules
On 5 February 2013 17:48, Barry Warsaw ba...@python.org wrote: There's been a lot of discussion lately on various forums (e.g. catalog-sig) about PyPI security. I realized that our recommendation for setting http_proxy in debian/rules can have beneficial local security implications. More details here: http://mail.python.org/pipermail/catalog-sig/2013-February/004831.html I should add a hook to export that for the build binary stages of the package build in my sbuild config (but not the fetching build-deps) Also one should be able to set that in debuild hooks. Cause python pypi is hardly the only type of packages that try to go online for things (waf, maven, gems and custom scripts come to mind). Regards, Dmitrijs. -- 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/CANBHLUg001BoG9i02OfexcRde-u-NO5o9rHw6bOaVwC_Na=2...@mail.gmail.com
Re: Private modules
On 22 December 2012 23:27, Barry Warsaw ba...@python.org wrote: On Dec 22, 2012, at 05:19 PM, Paul Tagliamonte wrote: Yeah, please don't use virtualenv, as much as I'd like to see a good way of using virtualenv in Debian. Can you expand on that? It should be usable to develop code, but do you mean something else? The way I interpreted Paul's comment is that it implies don't use virtualenv inside the .deb package as to be distributed by Debian e.g. system-wide python packages should not be using virtualenv environment out of the box on Debian, as that opens a can of worms. (virtualenv does nothing to help to what a coherent distribution tries to achieve). I do agree with you that one should not break vritualenv on purpose for those people who wish to use it. Regards, Dmitrijs. -- 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/CANBHLUjiu=RfsBvaj-Q+11yQhFngZMhoPQh=6KFAwk=op4y...@mail.gmail.com
Re: Solving the multiarch triplet once and for all
On 18 December 2012 15:48, Paul Wise p...@debian.org wrote: Seems like a lot of effort when there is no /usr/bin/triplet/python so there can be only one arch of python installed anyway. What are the use-cases for python multiarch? cross-compiling the archive / cross-bootstrapping the archive for a new architecture. Regards, Dmitrijs. -- 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/canbhlujab32bcb+xptzm0z-oo-iie39jkqv2jbl17o+mnp4...@mail.gmail.com
Re: RFS: pyxdg 0.24-1
On 6 November 2012 11:14, Thomas Kluyver tho...@kluyver.me.uk wrote: Hello, I'd like to request a sponsor to upload a new version of pyxdg. This is essentially the same as an earlier RFS for 0.23-1, but with a new upstream version. Can you add an autopkgtest that runs the upstream testsuite? Regards, Dmitrijs. -- 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/canbhlugn2rdw8inyoux9ocovhvxbutrwuapi3ett+41k4of...@mail.gmail.com
Re: RFS: pyxdg 0.24-1
On 6 November 2012 12:36, Thomas Kluyver tho...@kluyver.me.uk wrote: On 6 November 2012 12:03, Dmitrijs Ledkovs x...@debian.org wrote: Can you add an autopkgtest that runs the upstream testsuite? I've had a go - can you have a glance at the attached patch? If it looks OK, I'll commit it. Looks good. Commit and I will sponsor your package. Regards, Dmitrijs. pyxdg_add_autopkgtest.patch Description: Binary data
Re: RFS: pyxdg 0.24-1
On 6 November 2012 12:55, Thomas Kluyver tho...@kluyver.me.uk wrote: On 6 November 2012 12:54, Dmitrijs Ledkovs x...@debian.org wrote: Looks good. Commit and I will sponsor your package. Done. Thanks, Dmitrijs. I am thinking to upload to experimental instead of unstable. It's a few upstream releases jump and a python3 package is introduced. This makes this changes unsuitable for unstable considering that we are currently frozen and these changes are not appropriate for wheezy at this time. Is that ok with you? Or did you intend to upload into unstable? Regards, Dmitrijs. -- 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/canbhluidottjeo__+gns-ns1xuobqtg28qy69feznajyxmd...@mail.gmail.com
Re: RFS: pyxdg 0.24-1
On 6 November 2012 14:09, Thomas Kluyver tho...@kluyver.me.uk wrote: On 6 November 2012 13:58, Dmitry Shachnev mity...@gmail.com wrote: It won't be _automatically_ synced, but you can file a sync request: https://wiki.ubuntu.com/SyncRequestProcess. Or Dmitrijs will sync it for you :) Great, thanks Dmitry. Dmitrijs, let me know if you're happy to do the sync - otherwise I can make a request. I have a small white board with stuff to sync =) as there is ~6hour delay until I can do it. Cool, will upload sync. Regards, Dmitrijs. -- 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/CANBHLUhZ3F_BNAzLsOLpTqc_oTi+G=yscse7cpvgjvrpens...@mail.gmail.com
Re: DD requesting to join python-modules-team
On 10 October 2012 16:22, Hans-Christoph Steiner h...@at.or.at wrote: On Oct 9, 2012, at 4:48 AM, Jakub Wilk wrote: * Hans-Christoph Steiner h...@eds.org, 2012-10-08, 20:14: I'm a DD that is working on a couple python module packages. I have 'pyjavaproperties' already in wheezy/unstable and python-pure-otr in the works, packaged as 'python-potr' since that was the original name and the library is still called 'potr', i.e. import potr Welcome to the team! :) Please note that we use Subversion as VCS: https://wiki.debian.org/Teams/PythonAppsPackagingTeam/HowTo (but replace apps with modules). For a team package, is git-buildpackage out of the question? If so, I can convert. I doubt you will get hardly any team commits for it. Or team code review from automatic commit emails. You can check the mailing list archive for the past discussions. Currently none of the other version control systems / build tools offer as fluent workflow as the current one for the top commiters/uploaders/sponsors in the team. Nothing stops you to use bzr-svn or git-svn though ;-) works like a charm for me. Regards, Dmitrijs. -- 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/canbhlujsouoykp1eabz5po6pf4ujfpm5fl7i2vxqr6_1uof...@mail.gmail.com
Re: PyCon 2013 -- tentative title/abstract/outline -- feedback plz
On 02/10/12 17:57, Nicolas Chauvat wrote: On Tue, Oct 02, 2012 at 09:59:32AM -0400, Barry Warsaw wrote: On Oct 02, 2012, at 02:42 PM, Nicolas Chauvat wrote: As far as I know, pylint already runs with Python3. Doesn't it? pyflakes is the one we want to port. May I ask why ? Because it was used with python2 code bases, now code is ported to python3 and we'd like to continue using pyflakes with out python3 code as before without leaving compatibility future imports around, just for pyflakes to work. ps. I'm with barry on this one, btw ;-) -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Availability of Numpy, WX, Matplotlib and Scipy under Python3
On 3 September 2012 21:27, Thomas Kluyver tho...@kluyver.me.uk wrote: Hi Nigel, On 3 September 2012 14:57, Nigel Sedgwick n...@camalg.co.uk wrote: The application makes heavy use of numpy and wx and will soon make heavy use of scipy, matplotlib and various other python libraries that are widely used. Python 3 versions of numpy and scipy are already in wheezy. wx and matplotlib haven't yet released Python 3 compatible versions, and Wheezy is frozen now, so they've missed that boat. If you need to use those packages for a substantial application in the near future, sticking with Python 2 for now is your safest bet. If you use Python 2.6 or 2.7 with modern idioms, it should be relatively easy to port code later when all the libraries are ready. As far as I understand Debian, none of those python3- packages will be added to Squeeze. The idea of a stable release is that the only updates it gets are bugfixes and security. One more thing there is debian-backports =) http://backports-master.debian.org/ You may want to request a backport from folks who do those, and maybe (dependencies permitting) they can make a python3 backport of scipy / numpy for current stable release squeeze. Looking further ahead: matplotlib is aiming to release a Python 3 version in October. wxPython has a development version working on Python 3, but I don't see any indication of how soon a release is planned. Other GUI toolkits (Qt, GTK) already support Python 3, if they are an option for you. Best wishes, Thomas Regards, Dmitrijs. -- 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/canbhluj7xcppo3bgujw-7+sazvjvet_kjtqdovfh-3-7ruk...@mail.gmail.com
Re: Double build failures
On 04/05/12 18:05, Vincent Bernat wrote: Hi! I got some bug reports from Jakub about double build failures. I have always found those kind of tests a bit silly, but that's just my opinion. Most of the time, the failures are because of the created egg directory that is not cleaned up by the clean target of setup.py. While I could add the appropriate bits to each clean target in debian/rules, it seems better to fix the problem either in dh_python2 or in setuptools. Any thoughts? IMHO it is a better fit in dh_auto_clean (python_distutils buildsystem) and or dh_clean. -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Double build failures
On 04/05/12 18:23, Sandro Tosi wrote: On Fri, May 4, 2012 at 7:19 PM, Jakub Wilk jw...@debian.org wrote: or in setuptools. Ideally, by burning it with fire. CPython upstreams are developing a new module to replace distutils and setuptools: packaging. It might be worth check with them if it will handle this case. I swear last week it was called distribute... (if a buildsystem changes it's name more often than every 10 years think twice before using it.) -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: Double build failures
On 04/05/12 19:04, Scott Kitterman wrote: On Friday, May 04, 2012 06:38:30 PM Dmitrijs Ledkovs wrote: On 04/05/12 18:23, Sandro Tosi wrote: On Fri, May 4, 2012 at 7:19 PM, Jakub Wilk jw...@debian.org wrote: or in setuptools. Ideally, by burning it with fire. CPython upstreams are developing a new module to replace distutils and setuptools: packaging. It might be worth check with them if it will handle this case. I swear last week it was called distribute... (if a buildsystem changes it's name more often than every 10 years think twice before using it.) distribute is a fork of setuptools. distutils is still distutils, so you can use it only thinking once. ok. what is the relationship between 'distribute' 'packaging'? -- Regards, Dmitrijs. signature.asc Description: OpenPGP digital signature
Re: PyGTK and Python 2.6
2009/12/17 Josselin Mouette j...@debian.org: Le mercredi 16 décembre 2009 à 19:22 -0500, Scott Kitterman a écrit : Am I missing something? Can I get import gtk to work under Python 2.6 on Debian? Should I try to port Epidermis back to Python 2.5 or should I wait for Python 2.6 to be fully supported in Debian experimental or unstable? You would have to rebuild pygtk locally using the experimental packages. I expect we'll see Python 2.6 in unstable some time next week. I'm not looking for a definitive answer, (unless there is one!), just advice. Thank you. My advice would be wait. OTOH porting from python2.6 to python2.5 should be really easy, there have been very few language additions to python2.6. This would allow your software to also work on Debian stable, as well as some other major releases of other distributions. Unless import from future was used extensively -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
2009/12/9 Loïc Minier l...@dooz.org: On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? Concerning the Python Policy, it's currently not handled in any VCS, so I created a private git repo from the uploads of the python-defaults package (which I found in the morgue) and committed the proposed changes on top of that. I can provide a copy of the repo to you, but it's not in any way an official repo for the python-defaults package or the policy. -- Loďc Minier Yes please! I'm struggling to read the patches like that I'd rather read git annotate =) which would be proposed final but with info where the words came from (patches or old stuff) Thanks. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
2009/12/8 Loïc Minier l...@dooz.org: [ MFT: debian-pyt...@ldo ] Hi all, To resurrect the Python Policy as a document reflecting required and recommended Python packaging practices, we prepared a set of patches. We started in private to provide a complete set of changes and avoid flames as much as possible, but now we'd like the whole Debian Python community to send comments, feedback, or additional patches. Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lintian troubles ... almost done
2009/9/3 Alessandro Dentella san...@e-den.it: bad-distribution-in-changes-file If I run lintian on .changes it complains bad-distribution-in-changes-file but I'm unsure on what I should do. At present I'm building on an ubuntu-hardy so the name gets written in the changelog. There is nothing peculiar of one distro or another so I'm unsure what I should write. Not sure about Ubuntu, but for Debian, that'd always be “unstable” (unless you're uploading to another suite of course, but that's another story). fine thanks. I tryied 'sid', but that's clearly not accepted. For debian valid once are: experimental unstable (there others but they are not needed usually). And in general packages get uploaded to unstable. For ubuntu you should use the adjectives of a release eg karmic jaunty etc. for eg ppa uploads. Last question - When testing creating the package from my newly created sources on a newer machine (ubuntu 9.04), lintian complained: W: python-sqlkit: embedded-javascript-library usr/share/doc/python-sqlkit/html/_static/jquery.js That's clearly the jquery of the sphinx documentation. It's introduced in the upstream package when sphinx compile the docs (not at my build time). Is it mecessary to fix this or I can just leave it as is (it appears as a warning, not an error). Imho documentation should be build (rebuild) at deb package building stage. thanks again sandro *:-) -- Sandro Dentella *:-) http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: VCS for Python code Was: Trac team almost dead?
Recently I have discovered some very nice features of hg that make it attractive: 1) Multiple branches such that debian/ can be kept on alioth and have working copy that has everything if maintainer prefers so 2) MercurialQueues plugin allows to keep versioned quilt patches, rebase, merge and split them. Keep their history in a seperate branch and always upto date series file. This 2 features are very neat that imho bzr and git are lacking. (well bzr will have stable support for nested trees soon can be simulated with checkouts now and git has tg2quilt) One major drawback of hg is missing pristine-tar support and abandoned hg-buildpackage. Anyone willing to start working on this drawback together with me? I have a little bit of ugly hackish code. =) -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- 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
2009/5/29 Jakub Wilk uba...@users.sf.net: Hello, What is the correct umbrella to package a plugin for a Python application under? DPMT or PAPT? Depends how you package it. If you inject it into the app's private modules folder eg /usr/share/APPLICATION/plugins/new plugin then I think it is safe to go into PAPT. If you install/package it as a public module than it has to go into DPMT. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Butchered python configuration ...
2009/4/28 itsovermyhead itsovermyh...@googlemail.com: 2009/4/28 Piotr Ożarowski pi...@debian.org: [itsovermyhead, 2009-04-28] dev3:/usr/bin# ls -la python* -rwxr-xr-x 2 root root 1015264 2008-10-23 08:53 python -rwxr-xr-x 2 root root 1015264 2008-10-23 08:53 python2.4 -rwxr-xr-x 1 root root 1276 2008-10-23 08:53 python2.4-config I'd start with: # rm /usr/bin/python # and all other local files # ln -s /usr/bin/python2.4 /usr/bin/python Thanks for your reply Piotr - are you confident about this solution? A lot of people use this server so I want to be as sure as possible that this is the right approach to the problem. Can you could explain your reasoning so I can understand what you're proposing better. Cheers S As far as i know. python binary is always the default python interpreter which points to one of the supported version and by default it points (symlink) to python2.5 in lenny (I think). the pythonX.Y are actually real binaries. If you are not convineced I gues you should $apt-get source python and study the packaging. -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Python-apps-team] RFS: cgmail (adopted)
2009/2/16 Sandro Tosi mo...@debian.org: you'd be welcome to so do :) You can find some documentation at [1] [2] [3], and feel free to ask d-pyt...@l.d.o for clarification or, if you hang around irc, we're on #debian-python at irc.debian.org. [1] http://wiki.debian.org/Teams/PythonAppsPackagingTeam [2] http://python-apps.alioth.debian.org/policy.html [3] http://wiki.debian.org/PAPT_Howto Thanks for the links. Inject didn't work so I did the manual injection. Looks good to me =D * Updated Maintainers field to PAPT * Set myself in Uploaders * Update VCS-* fields to point to svn * Rebuild from svn and uploaded to mentors I again kindly request to sponsor this upload for me. I am looking for a sponsor for the new version 0.5-1 of my package cgmail. It builds these binary packages: cgmail - A new shiny mail checker for the GNOME desktop The package appears to be lintian clean. The upload would fix these bugs: 461447, 515539 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cgmail - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cgmail/cgmail_0.5-1.dsc -- With best regards Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
