DPMT; salsa access
hi, Please add me to the DPMT group on salsa.debian.org. I am already a member of DPMT. Username: jtaylor-guest cheers, Julian signature.asc Description: OpenPGP digital signature
Re: Getting ready for Python 3.5
On 06/24/2015 05:34 PM, Barry Warsaw wrote: On Jun 24, 2015, at 11:13 AM, Sandro Tosi wrote: but it was the version from sid (1.8), not experimental (1.9) Ah, gotcha. I'll look at syncing 1.9 to the PPA. Cheers, -Barry fwiw, numpy itself will fail with python 3.5 due to an API change in the GZip module: https://travis-ci.org/numpy/numpy/jobs/68248141 To my knowledge this has not been reported to CPython yet. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558b4bea.1090...@googlemail.com
Re: multiprocessing.queues.Queue does not work in pbuilder?
On 31.01.2015 11:32, Dimitri John Ledkov wrote: Hello, On 29 January 2015 at 09:01, Ole Streicher oleb...@debian.org wrote: Hi, I am trying to get the release candidate for python-astropy packaged. The packaging includes a number of tests, where many fail in pbuilder, which can be traced back to: $ sudo pbuilder login make sure run/shm is mounted, put this in .pbuilderrc export BINDMOUNTS=/run/shm -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54cccbf7.4080...@googlemail.com
Re: Fwd: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1
On 24.09.2014 08:14, Matthias Urlichs wrote: Hi, Scott Kitterman: This kind of nonsense is a great reason to stay with svn. Nah. It's a great reason to teach the tool in question to be *way* more reasonable. Who needs a single email per commit? Esp. since the number of actual commits will go way up with increased git usage – feature branches are easy in git, and more granular commits are a great way to help with tracking down exactly which change introduced a regression. Single mails/irc messages per commmit are very useful, they help a lot to find mistakes others are making before an upload happens. What we don't want is messages for upstream changes. This should be simple to fix, simply check the changed paths for debian/ before sending a message. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54226f73.70...@googlemail.com
Re: librabbitmq and git
On 19.08.2014 01:52, Brian May wrote: Hello, I would like to package the latest upstream version of librabbitmq. However, the packaging is in git, and I am not sure how to insert the latest upstream version in this git repository. From debian/control: Homepage: https://github.com/alanxz/rabbitmq-c Vcs-Git: git://anonscm.debian.org/collab-maint/librabbitmq.git http://anonscm.debian.org/collab-maint/librabbitmq.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/librabbitmq.git From debian/copyright: Source: https://github.com/alanxz/rabbitmq-c I take this to mean I should be downloading the orig.tag.gz from github. However, just to make things more interesting, the 5.0 and 5.1 tar.gz file from github contains a sub git repository (not sure I have used correct git terminology here), with invalid relative reference, under rabbitmq-c-0.5.1/codegen, which wasn't included in librabbitmq_0.5.0.orig.tar.gz brian@aquitard:~/tree/debian/unstable/librabbitmq/librabbitmq/codegen$ cat .git gitdir: ../.git/modules/codegen brian@aquitard:~/tree/debian/unstable/librabbitmq/librabbitmq/codegen$ git diff fatal: Not a git repository: ../.git/modules/codegen So it looks like maybe the librabbitmq_0.5.0.orig.tar.gz was repackaged from upstream? Should I do the same thing for 0.5.1? github.com tag downloads do not include submodules as git archive itself does not support them. You will have to download your full tarball from another place than github. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f2f69c.2030...@googlemail.com
Re: Proposed policy change to define but discourage Python wheels in Debian
On 16.05.2014 17:53, Scott Kitterman wrote: On Friday, May 16, 2014 11:28:45 Barry Warsaw wrote: Here is the diff I propose to Debian Python policy, describing our policy on packaging wheels. Cheers, -Barry === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml2014-05-12 10:21:25 + +++ debian/python-policy.sgml2014-05-16 15:23:30 + @@ -32,7 +32,11 @@ nameScott Kitterman/name emailsc...@kitterman.com/email /author - versionversion 0.9.5/version + author +nameBarry Warsaw/name +emailba...@debian.org/email + /author + versionversion 0.9.6/version abstract This document describes the packaging of Python within the @@ -468,6 +472,36 @@ programs included in the same package. /p /sect + sect id=wheels +headingWheels/heading +p + url id=http://legacy.python.org/dev/peps/pep-0427/; + name=PEP 427 + defines a built-package format called wheels, which is a zip + format archive containing Python code and a dist-info metadata + directory, in a single file named with the .whl suffix. As zip + files, wheels containing pure-Python can be put on sys.path and + modules in the wheel can be imported directly by Python's import + statement. (Importing extension modules from wheels is not yet + supported as of Python 3.4.) +/pp + The use, building, and inclusion of wheels in binary packages is + strongly discouraged. A very limited set of wheel packages are + available in the archive, but these support the narrow purpose of + providing the Python 3 built-in virtual environment creation + executable prgnpyvenv-3.x/prgn, as well as the + within-venv prgnpip/prgn executable, in a Debian policy + compliant way. +/pp + Wheels supporting prgnpyvenv/prgn and prgnpip/prgn are named + with the varpython-/var prefix, and the var-wheels/var + suffix, e.g. packagepython-chardet-wheels/package. When + these binary packages are installed, their .whl files should be + placed in the /usr/share/python-wheels directory. Such wheels + should be built with the tt--universal/tt flag so as to generate + wheels compatible with both Python 2 and Python 3. +/p + /sect sect id=package_names headingModule Package Names/heading p I good start. I think strongly discouraged is too weak. I think it should be a must not except the packages needed for pyvenv/pip and all those packages should be explicitly listed (so that it takes an update to policy to make it policy OK to add more wheels. I think the text should contain why it is strongly discouraged. It is not clear to me from this text. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53764865.4050...@googlemail.com
Re: git-buildpackage python3
On 30.04.2014 22:56, Alex Mestiashvili wrote:
Greetings everybody,
git-buildpackage --git-pbuilder --git-arch=amd64
dh clean --with python2,python3 --buildsystem=pybuild
dh_testdir -O--buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
pybuild --clean -i python{version} -p 2.7 --dir .
I: pybuild base:170: python2.7 setup.py clean
running clean
removing
'/home/toor/debian-med/python-multipletau/.pybuild/pythonX.Y_2.7/build'
(and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-2.7' does not exist -- can't clean it
pybuild --clean -i python{version} -p 3.3 3.4 --dir .
I: pybuild base:170: python3.3 setup.py clean
Traceback (most recent call last):
File setup.py, line 4, in module
from setuptools import setup, find_packages
ImportError: No module named 'setuptools'
E: pybuild pybuild:256: clean: plugin distutils failed with: exit
code=1: python3.3 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 3.3 3.4 --dir .
returned exit code 13
make: *** [clean] Error 13...
git-buildpackage runs the clean target before exporting the dsc so you
need the build dependencies installed on the host for pybuild.
you can disable that with --git-cleaner=true
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53617b9b.3060...@googlemail.com
Re: recommended numpy dependency ranges?
On 31.03.2014 17:08, Diane Trout wrote: Hi, I have a small package the depends on numpy and it recently stopped working. Traceback (most recent call last): File /usr/local/lib/R/site- library/DEXSeq/python_scripts/dexseq_prepare_annotation.py, line 33, in module import HTSeq File /usr/lib/python2.7/dist-packages/HTSeq/__init__.py, line 9, in module from _HTSeq import * File numpy.pxd, line 155, in init HTSeq._HTSeq (src/_HTSeq.c:33074) ValueError: numpy.dtype has the wrong size, try recompiling I'm pretty sure a recompile will fix it, the question I have is how often does numpy break binary compatibility? Should set your numpy dependencies to something like: python-numpy (= 1.8, 1.9) numpy doesn't break compatibility often on purpose, the goal is never as its a major pain for windows users. The last accidental break was in 1.6 which we solved by just recompiling the rdepends. Are you sure you are not picking up something from /usr/local? import HTSeq works for me in unstable. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5339af51.9070...@googlemail.com
Re: Compiled C modules are not found by test suite (Was: Help needed for python-biopython which splits up modules into two packages per Python version)
On 15.03.2014 00:15, Éric Araujo wrote: Hello, I got the code and the debian directory. I confirmed that extension modules are in the build directory, not alongside the Python modules, so they can’t be imported from tests. There are two ways to fix that: either make distutils build the extensions alongside the Python modules, or make the test import all code from the build directory. I’m surprised that this isn’t a common issue for PMPT. a typical approach is to not test in dh_auto_test but to install and then test from debian/tmp by setting PYTHONPATH -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/532430c0.9030...@googlemail.com
Re: Python coding help: Has anybody seen this syntax
On Thu, Feb 13, 2014 at 5:37 PM, Andreas Tille andr...@an3as.eu wrote: Hi, I'm trying to package spades[1] and found the following code inside an __init__.py file: File /usr/share/spades/pyyaml3/__init__.py, line 284 class YAMLObject(metaclass=YAMLObjectMetaclass): ^ SyntaxError: invalid syntax I'm not a very skilled Python coder but IMHO the critical line should be replaced by class YAMLObject(YAMLObjectMetaclass): Is this correct? Do you have any clue whether this is some old syntax or what sensible hint I might give to upstream? no this is python3 syntax see here for the python2 syntax: http://mikewatkins.ca/2008/11/29/python-2-and-3-metaclasses/#using-the-metaclass-in-python-2-x is this an embedded copy of pyyaml? if so please use the packaged version, it supports both python 2 and 3. -- 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/cak5faths5iud2uenxywbophhz4ebpd17qp9trtegrhcaf_p...@mail.gmail.com
Re: Help with packaging of python executable and its modules
On Fri, Feb 7, 2014 at 2:20 PM, Andreas Tille andr...@an3as.eu wrote: Hi folks, I have commited some packaging for a bioinformatics package arden to git://anonscm.debian.org/debian-med/arden.git Since it expects to find its modules under the pretty generic name core I decided to move the modules under /usr/share/pyshared/arden/core and tried to patch the executable scripts to say something like I assume this is a python application and not a library? don't install into pyshared, its an implementational detail that might eventually go away as its technically not needed anymore since we only have one python2 version left. python applications usually get installed into /usr/lib/package-name/ as upstream intended then you just patch the entry points to add that path to their search path: sys.path.insert(0, 'module-path') just for completeness, your approach does not work as you are missing a __init__.py in the folder
Re: debian/rules for packages using Cython
On 06.11.2013 22:54, Tim Michelsen wrote: https://wiki.debian.org/Python/LibraryStyleGuide Sorry, but I cannot see a place where I could find a hint on how to include the cypthon rules. A little push would be very nice. what is the error? cythoning is often just running cython file.pyx if its more complicated upstream normally provides scripts to cythonize or do it via setup.py build, sometimes setup.py cython -- 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/527ac2d7.7000...@googlemail.com
Re: Using ‘export http_proxy = http://127.0.9.1:9/’ to fail noisily on dependency problems
On 11.10.2013 17:04, Barry Warsaw wrote:
On Oct 11, 2013, at 12:21 PM, Piotr Ożarowski wrote:
Note that pybuild is doing it by default (if http{,s}_proxy is not set),
so with --buildsystem=pybuild you will expose missing build dependencies
*and* let get-orig-source work (pybuild doesn't set http_proxy in this
target). If you for some reason need network during build (f.e. tests
setup a HTTP server), just set http_proxy to empty string, in src:flask
I do this:
override_dh_auto_test:
http_proxy='' dh_auto_test
Ah yes of course. I've had to override it in get-orig-source and occasionally
in the tests. Really happy to hear that pybuild DTRT.
-Barry
while I think doing it in the helper tools is a good idea, one shouldn't rely
on it.
It is better if one disables internet access of package builds completely.
With pbuilder and iptables this is very easy, just run this when booting:
iptables -I OUTPUT ! -d 127.0.0.1 -m owner --gid-owner 1234 -j REJECT
--reject-with icmp-port-unreachable
ip6tables -I OUTPUT ! -d ::1 -m owner --gid-owner 1234 -j REJECT --reject-with
icmp6-port-unreachable
(It works because pbuilder builds as user 1234, won't work for --login sessions)
--
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/52583425.6010...@googlemail.com
Re: Packaging the new upstream release of ipython (i.e. 1.1.0)
Hi, sorry I am working very very slow in ipython, a reason is that there is no stable release on the horizon, so I have been slacking of a bit. Now that ubuntu 13.10 is almost out soon I have no excuse anymore :) The issue with ipython 1.1 is the large amount of third party javascript libraries it embeds. These are the libraries it needs (from bowser.json) and its status in debian: bootstrap: ~2.3, in debian (libjs-twitter-bootstrap) but too old this is also hard to handle with packages so I currently plan to embed it. If you want to help out, please do a license/dfsg review of the embedded stuff and send me a debian/copyright file. codemirror: ~3.15, in debian but far to old and in hardly usable state. ipython currently embeds so I am willing to continue with that. But also needs a new license review for 1.0. font-awesome: ~3.1, debian package was not suitable, but was fixed recently, should be fine. Deian package needs adapting to use it. jquery: ~2.0, 2.0 not in debian, hopefully will be soon. Maybe ipython also works with 1.7, didn't test that much yet. jquery-ui: ~1.10, available in debian, packaging needs adapting to use it as 0.13.2 embeds a fork of it, fork not needed with 1.0 so far I know. less.js: ~1.3, in debian, package needs adapting to use it (via fab) marked: ~0.2.8, packaged for debian recently, ipython package needs adapting to use it. requirejs: ~2.1 not in debian and looks like something that should be in debian (unlike bootstrap or codemirror it looks stable). Its not my area of expertise, help wanted. if none show up I'll probably go with embedding as I can't maintain a proper package of this. In this case needs a license review. On 03.10.2013 18:55, Jean-Christophe Jaskula wrote: Hey, I haven't heard from any of you and I'm still a bit curious of the status of the package. FYI, I continued patching and rearranging to fit with the upstream sources. I got something which starts looking good to me. Hope to hear from you soon :-) Cheers, JC Le 29 sept. 2013 à 16:31, Jean-Christophe Jaskula a écrit : Hi, The Ipython team has released a couple of major releases during the last months but I haven't seen any discussions about packaging them in debian. Just for curiosity, I decided to start trying to update the debian package (v0.13.2) to the latest release (v.1.1.0). When doing it, I realized there is a lot of changes to do and I do understand why it is not in sid yet (putting aside you might be also very busy with other things). I didn't plan to propose this work for a NMU but I'm wondering if someone was working on it. So far, my work is still in progress but I don't mind keeping working on it if it helps you or dropping it if a debian package is going to be uploaded soon. I have adapted most of the debian patches to the upstream release. I'm still working on the Mathjax patch to avoid ugly hack. I started from the source that one can get at: https://github.com/ipython/ipython/archive/rel-1.1.0.tar.gz . However, everything isn't shipped in this archive and I had to add static components that I took from: https://github.com/ipython/ipython/releases/download/rel-1.1.0/ipython-1.1.0.tar.gz . I put these files altogether in the same .orig.tar.gz archive and started packaging from it. If you need help on this packaging, I'll be very happy to contribute. Cheers, JC PS: I'm attaching the debian folder for your information. ipython_1.1.0-0+nmu1.debian.tar.gz -- Jean-Christophe Jaskula -- 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/524da85d.4070...@googlemail.com
Re: Removing /usr/bin/nosetests-3.x scripts
On 02/22/2013 07:28 AM, Dmitry Shachnev wrote: Hi, As discussed yesterday on IRC, nose's /usr/bin/nosetests-3.x scripts are broken (provided only for python3 version(s) that was/were default on build time), and instead of writing hacks to fix that we have decided to instead remove those scripts and make packages use python3.x /usr/bin/nosetests3 instead (note: this will only affect experimental for now). After looking at all packages that build-depend on python3-nose, I've identified these packages as needing fix: - beautifulsoup4 (autopkgtests, only SVN trunk is affected) (uploader: Stefano Rivera) - cssutils (debian/rules) (active uploader: Charlie Smotherman) - python-flexmock (debian/rules) (uploader: Stefano Rivera) - python-markdown (debian/rules and autopkgtests) (my package) Thankfully all these packages are team-maintained, so I've pushed fixes to the SVN. hi, did you also check the autopkgtest directories? e.g. pyzmq in svn (not yet uploaded) currently uses nosetests-3.x in the autopkgtests but not in debian/rules. -- 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/5127a61d.1040...@googlemail.com
Re: Solving the multiarch triplet once and for all
On 12/13/2012 11:34 AM, Jakub Wilk wrote: How about undoing the Python multi-arch mess until someone provides evidence that the changes solve more problems than they create? (I'd like to note that the changes were never discussed on debian-python@, which is in violation of tech-ctte resolution.) the issue goes beyond multiarched python (for which there already are in-python upstreamed ways to get the path, e.g. get_python_inc(plat_specific=1)). e.g. numpy needs it for its own of distutils So unless you want to revert multiarch as a whole or teach all upstreams to stop relying on stuff being in usr/lib, having something in python itself to get the path is a good thing. -- 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/50ca261b.1000...@googlemail.com
Re: [Python-modules-team] numpy 1.6.1 into unstable?
On 04/10/2012 10:56 AM, Sandro Tosi wrote: Hello Yaroslav, such questions are better asked on debian-python: few people reads the pkging ml (cc added). On Mon, Apr 9, 2012 at 22:02, Yaroslav Halchenko deb...@onerussian.com wrote: sorry if that is obvious from somewhere but I wondered -- what are the showstoppers preventing numpy 1.6.1 migration from noone-sees experimental to shiny and bleeding edge unstable? 1:1.5.1-4 is in both unstable and testing so I guess there is no other transition cooking and I thought it would be a good time to prepare for upcoming freeze assuring that dependent packages are in good shape... ? I think it's time to move it to unstable, yes; the numpy transition (#658289) was closed some days ago, so we're clear to go. I planned to ask yesterday Jakub for support/opinion in the transition, but didn't see him in IRC, adding CC now: Jakub, what do you think about uploading new Numpy to unstable? There is (to my knowledge) one bug 659403 (nipy) that would become RC, while 659409 (veusz) is fixed but not yet migrated into testing due to RC bug. Given the work done by Jakub, this new numpy shouldn't generated a transition per se (it just bump the API version, not the ABI, which most of the packages use) so it would be the first smooth transition: let's see how it goes :) Cheers, 640940 [0] and 665998 should probably still be resolved in the upload to unstable. ftw. numpy 1.6 has been uploaded in ubuntu precise three weeks ago and the world did not fall apart yet. I also expect a smooth transition thanks to the excellent preparation by you and jakub. [0] crappy patch for it: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/python-numpy/precise/view/head:/debian/patches/search-multiarch-paths.patch signature.asc Description: OpenPGP digital signature
Re: python-tornado Python 3
On 03/12/2012 08:39 PM, Thomas Kluyver wrote: On 12 March 2012 14:49, Yaroslav Halchenko deb...@onerussian.com mailto:deb...@onerussian.com wrote: well -- it might be beneficial meanwhile to share your changes one way or another (patch, git, mentors) so someone could review them OK, I've attached the patch (against the debian/ directory) to this e-mail. The built packages are in my PPA: https://launchpad.net/~takluyver/+archive/python3 Thanks, Thomas thanks for the patch, I have applied it to the team repository along with some more minor fixes to other parts of the package. http://anonscm.debian.org/viewvc/python-modules/packages/python-tornado/trunk/ I think its ready for an upload. signature.asc Description: OpenPGP digital signature
Re: Bug#653650: ipython: Please depend on python (= 2.7) | python-argparse
On 01/08/2012 01:00 PM, Jakub Wilk wrote: The current Depends doesn't guarantee that ipython is usable with non-default Python version anyway (e.g. you don't depend on python2.6, you have little control over versions supported by your dependencies, etc.). you get a helpful error message when you try the 2.6 script it without 2.6 installed. I'd have to patch the source to do the same for missing argparse. signature.asc Description: OpenPGP digital signature
Re: Bug#563391: Package Trac 0.12 as well
On 07/11/2011 05:43 PM, W. Martin Borgert wrote: Quoting Éric Araujo mer...@netwok.org: Are you sure the full python-setuptools is required, not only python-pkg-resources? Look in debian/changelog :~) I replaced python-setuptools once with python-pkg-resources and had to revert the change. fyi, this will not be necessary any more with python-defaults 2.7.2-2 currently in exp: python-defaults (2.7.2-2) experimental; urgency=low ... - remove setuptools from requires.txt (it is replaced with python-pkg-resources Debian dependency) signature.asc Description: OpenPGP digital signature
Re: RFS: pycxx (updated package) + feedback wanted
On 09/03/11 20:10, Julian Taylor wrote: On 03/06/2011 06:48 PM, Julian Taylor wrote: Dear mentors, I am looking for a sponsor for the new version 6.2.0-6 of my package pycxx. It builds these binary packages: python-cxx - A Set of facilities to extend Python with C++ python-cxx-dev - A Set of facilities to extend Python with C++ python3-cxx - A Set of facilities to extend Python3 with C++ python3-cxx-dev - A Set of facilities to extend Python3 with C++ The upload would fix these bugs: 611061 https://bugs.launchpad.net/ubuntu/+source/pycxx/+bug/730144 This is a minimal change upload to fix a bug currently occurring in ubuntu natty (which is in feature freeze). The lintian warning build-depends-on-python-dev-with-no-arch-any should thus be ignored (see below). I'm not sure why I get this warning: changelog-should-mention-qa I plan to package the new upstream 6.2.3 when it is released. In this respect I also want ask for comments on this mail by me: http://lists.debian.org/debian-mentors/2011/02/msg00299.html The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pycxx - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pycxx/pycxx_6.2.0-6.dsc I would be glad if someone uploaded this package for me. Kind regards Julian Taylor ping. 6.2.3 was released shortly so some feedback on http://lists.debian.org/debian-mentors/2011/02/msg00299.html is highly appreciated. Best Regards, Julian Taylor ping #3. Still the same one line change + adoption. I have also placed the package under the python modules team (although it technically is no module). I'll just summarise the situation of this package and my plans again: PyCXX is a library which can be used to create python extentions in C++ similar to boost python and swig (but in a different way). reverse build depends are: - pysvn (O) - freecad (- python-matplotlib (embedded #613818)) The package currently consists of a normal package and a -dev package for python 2 and 3. The non-dev packages are empty and just contain a dummy __init__.py doing nothing. As PyCXX is a library and no python module I think the package it should be renamed to something like libpycxx/libpy3cxx. A problem is that upstream only ships the raw source files without a build system to compile a library out of them. A patch was rejected (http://sourceforge.net/tracker/?func=detailaid=3177349group_id=3180atid=353180). Thus I see following futures for the package: - rename the package and patch it to build a static library (and possibly also a shared library, which would imply maintaining abi compatibility without upstream support, *not good*) - rename package but remain shipping only source files. This has the drawback that there now is a lib package which is not providing a library in /usr/lib. It might confuse people. - only remove the empty packages and stick with present packaging for the -dev - don't change anything in this respect in any case I'll modernise the package to newest standards (format 3.0, DEP3, DEP5 etc.) providing someone would sponsor it. Any kind of feedback is highly appreciated. Best Regards, Julian Taylor signature.asc Description: OpenPGP digital signature
pycxx packaging
Hi, I intend to adopt the pycxx package used to build python extensions in C ++ [0]. I'd like to ask for some advice on how to package it in the best possible way. Currently it contains of an basically empty package python-cxx and the python-cxx-dev package which contains the required headers and sources to build the an extension. The user is required to build the sources them self and link the result with their files. The sources are placed in /usr/share/python2.6/CXX I intend to change this by building a library which must only be linked with extension objects (proof of concept patch for build system forwarded [1]). See also the similar package libboost-python which provides libboost-python.so for some reference. Concerning this I have some questions: - Is there anything obvious I'm overlooking in my plan? - If upstream does not accept the patch, should I go ahead and patch the package to provide a library or stick with upstream intended build scheme? - When providing a library, should the source still be shipped (when the rdeps [2] are adapted)? Is the location policy conform (/usr/share/python2.6/CXX)? - Should a shared or static library or both be provided? A shared library would obviously decrease memory usage a bit, but there are only two rdeps [2] and it makes library transition and maintenance harder (abi compatibility ...). Is it worth it? - should the package be renamed to libpython-cxx? As it is really a library and no python module. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611061 [1] http://sourceforge.net/tracker/?func=detailaid=3177349group_id=3180atid=353180 [2] pysvn, freecad, (matplotlib [embedded copy]) Best Regards, Julian Taylor signature.asc Description: This is a digitally signed message part
