Bug#668841: RFS: yp-svipc/0.13-1 [ITP] -- System V InterProcess Communication for Python/Yorick
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org Dear mentors, I am looking for a sponsor for my package "yp-svipc" * Package name: yp-svipc Version : 0.13-1 Upstream Author : Matthieu Bec * URL : https://github.com/frigaut/yorick-svipc/ * License : GPL-3 Section : Python, Science Programming Lang: C, Yorick, Python Description : System V InterProcess Communication for Python/Yorick ITP : http://bugs.debian.org/668841 It builds those binary packages: python-svipc - interprocess communication (shared memory...) for Python yorick-svipc - interprocess communication (shared memory...) for Yorick To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yp-svipc Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yp-svipc/yp-svipc_0.13-1.dsc When the two packages are installed, they can be tested with: - yorick-only multiprocess computing: yorick -i /usr/share/doc/yorick-svipc/examples/timing-demo.i - yorick/python communication: yorick -i /usr/share/doc/yorick-svipc/examples/ping.i I have not been able to make it work under python3 so far (on Linux: it works on a Mac). Regards, Thibaut Paumard. signature.asc Description: OpenPGP digital signature
Re: How do I add support for python3 to my package?
On Thursday, April 12, 2012 08:30:41 AM Barry Warsaw wrote: > Hi Paul, > > On Apr 12, 2012, at 02:09 AM, Paul Elliott wrote: > >A recent review of my package asked me to consider making a python3 > >version. > > Excellent! One more down the road to Python 3 world domination. :) > > >But the response below says that is difficult. It is several months old, > >has this changed? > > I think it's not so hard, and you should definitely do it. It's true that > the tools need to catch up to Python 3, but I think most packages can be > adapted to include python3-* versions without too much trouble. > > You might find this wiki page helpful: > > http://wiki.debian.org/Python/LibraryStyleGuide > I am not a expert python packager. I am dubious about a bunch of cargo cult packagers all writing seperate but similar debian/rules complications. It seems like one is creating a lot of debugging/maintainance problems. Why can not some expert that really know what she is doing write the neccessary infrastructure so that one could write > %: > dh $@ --with python2-and-python3 I am not an expert and not particularly interested in joining a cargo cult. I think that would be a better way to encourage python3 extensions. > Cheers, > -Barry -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: How do I add support for python3 to my package?
Hi Paul (2012.04.18_10:09:30_+0200) > I am not a expert python packager. I am dubious about a bunch of cargo cult > packagers all writing seperate but similar debian/rules complications. Indeed, it's messy and far from ideal. > Why can not some expert that really know what she is doing write the > neccessary infrastructure so that one could write That was: http://wiki.debian.org/SummerOfCode2011/PythonMultibuild Unfortunately, it stalled. But Piotr is intending to finish it, last I heard. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- 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/20120418083240.gs2...@bach.rivera.co.za
Re: How do I add support for python3 to my package?
[Paul Elliott, 2012-04-18] > I am not a expert python packager. I am dubious about a bunch of cargo cult > packagers all writing seperate but similar debian/rules complications. > > It seems like one is creating a lot of debugging/maintainance problems. > > Why can not some expert that really know what she is doing write the > neccessary infrastructure so that one could write > > > %: > > dh $@ --with python2-and-python3 --with should not really be used for build systems, there's --buildsystem... anyway, please wait a little bit longer, I plan to work on it really soon now (I want to have it in Wheezy so I have a month or so to add it to python3-defaults) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- 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/20120418084601.gi3...@piotro.eu
Re: RFS: dparser-1.16-1 [ITP] -- a scannerless GLR parser generator
* Jakub Wilk , 2012-04-16, 23:35: * Markus Wanner , 2012-04-16, 07:45: http://mentors.debian.net/debian/pool/main/d/dparser/dparser_1.26-1.dsc One more thing: pyversions -vr debian/control could be (more conventionally and more succinctly) written as: pyversions -vr -- Jakub Wilk -- 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/20120418151112.ga2...@jwilk.net
Re: How do I add support for python3 to my package?
On Apr 18, 2012, at 03:09 AM, Paul Elliott wrote: >I am not a expert python packager. I am dubious about a bunch of cargo cult >packagers all writing seperate but similar debian/rules complications. That's why I wrote the style guide; hopefully at least we'll converge on one set of (well-documented!) cargo. :) >It seems like one is creating a lot of debugging/maintainance problems. > >Why can not some expert that really know what she is doing write the >neccessary infrastructure so that one could write > >> %: >> dh $@ --with python2-and-python3 > >I am not an expert and not particularly interested in joining a cargo cult. > >I think that would be a better way to encourage python3 extensions. As Piotr and Stefano pointed out, multibuild will make many things better. Still, IMHO we should not wait for multibuild to start adding Python 3 support to Debian packages. If upstream supports Python 3, I would really love to have that available in Debian asap. Cheers, -Barry signature.asc Description: PGP signature
Re: How do I add support for python3 to my package?
On Wednesday, April 18, 2012 10:12:24 AM Barry Warsaw wrote: > On Apr 18, 2012, at 03:09 AM, Paul Elliott wrote: > >I am not a expert python packager. I am dubious about a bunch of cargo > >cult packagers all writing seperate but similar debian/rules > >complications. > > That's why I wrote the style guide; hopefully at least we'll converge on > one set of (well-documented!) cargo. :) > > >It seems like one is creating a lot of debugging/maintainance problems. > > > >Why can not some expert that really know what she is doing write the > >neccessary infrastructure so that one could write > > > >> %: > >> dh $@ --with python2-and-python3 > > > >I am not an expert and not particularly interested in joining a cargo > >cult. > > > >I think that would be a better way to encourage python3 extensions. > > As Piotr and Stefano pointed out, multibuild will make many things better. > Still, IMHO we should not wait for multibuild to start adding Python 3 > support to Debian packages. > > If upstream supports Python 3, I would really love to have that available > in Debian asap. > > Cheers, > -Barry Well for an interim solution, what is wrong with writting a completely seperate source package for the python 3 version, with the intent to collapse it into the python2 version when tools become available? That way I don't have to join a cargo cult. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: How do I add support for python3 to my package?
On Wednesday, April 18, 2012 10:35:04 AM Paul Elliott wrote: > On Wednesday, April 18, 2012 10:12:24 AM Barry Warsaw wrote: > > On Apr 18, 2012, at 03:09 AM, Paul Elliott wrote: > > >I am not a expert python packager. I am dubious about a bunch of cargo > > >cult packagers all writing seperate but similar debian/rules > > >complications. > > > > That's why I wrote the style guide; hopefully at least we'll converge on > > one set of (well-documented!) cargo. :) > > > > >It seems like one is creating a lot of debugging/maintainance problems. > > > > > >Why can not some expert that really know what she is doing write the > > >neccessary infrastructure so that one could write > > > > > >> %: > > >> dh $@ --with python2-and-python3 > > > > > >I am not an expert and not particularly interested in joining a cargo > > >cult. > > > > > >I think that would be a better way to encourage python3 extensions. > > > > As Piotr and Stefano pointed out, multibuild will make many things better. > > Still, IMHO we should not wait for multibuild to start adding Python 3 > > support to Debian packages. > > > > If upstream supports Python 3, I would really love to have that available > > in Debian asap. > > > > Cheers, > > -Barry > > Well for an interim solution, what is wrong with writting a completely > seperate source package for the python 3 version, with the intent to > collapse it into the python2 version when tools become available? > > That way I don't have to join a cargo cult. Alternately you could invest a little time in understanding what Barry's written up and build both sets of binaries from one source. This is the usual method. A separate source package doesn't make it any easier as it would still have to build for python3. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/31795822.DETZSrihNh@scott-latitude-e6320
Re: RFS: python3-dateutil
There are some warnings while running tests: build/lib/dateutil/tz.py:910: ResourceWarning: unclosed file <_io.BufferedReader name='/usr/share/zoneinfo/EST5EDT'> build/lib/dateutil/tz.py:910: ResourceWarning: unclosed file <_io.BufferedReader name='/usr/share/zoneinfo/UTC'> build/lib/dateutil/tz.py:910: ResourceWarning: unclosed file <_io.BufferedReader name='/usr/share/zoneinfo/America/New_York'> Please consider running tests with --verbose, because currently build log becomes unreadable if warnings are emitted But anyway, I bumped timestamp in the changelog, built, signed and uploaded the package. Thanks. -- Jakub Wilk -- 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/20120418170347.gb3...@jwilk.net
Re: RFS: python3-dateutil
On 18 April 2012 18:03, Jakub Wilk wrote: > But anyway, I bumped timestamp in the changelog, built, signed and uploaded > the package. Thanks. Thanks Jakub, and thanks for taking the time to go through all these things with me. Thomas -- 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/caovn4qhxk6ngw-dp+djxwcwysuxcxzycqkanmwdynt73jon...@mail.gmail.com
Re: Bug#668841: RFS: yp-svipc/0.13-1 [ITP] -- System V InterProcess Communication for Python/Yorick
(I don't intend to sponsor this package.)
* Thibaut Paumard , 2012-04-18, 09:32:
http://mentors.debian.net/debian/pool/main/y/yp-svipc/yp-svipc_0.13-1.dsc
Lintian emits:
P: yp-svipc source: debian-control-has-unusual-field-spacing line 5
The following files have even more unusual spacing: line 6 is indented
by a tab and 8 spaces, line 7 by two tabs.
You build-depend on "debhelper (>= 9.0.0)", but debhelper doesn't use
such versioning scheme anymore. I'd use just "debhelper (>= 9)".
I'd rather not use ${python:Provides}. See:
http://lists.debian.org/20110324164804.ga5...@jwilk.net
In compat >= 7, you can omit "debian/tmp" prefixed from *.install files.
Also, you don't need to specify destination directories in them,
dh_install will guess it correctly.
dh_numpy was first introduced in python-numpy 1:1.4.1-4, so ideally the
build-dependency should be versioned. (This is not very important, as
the required version is already in squeeze).
--
Jakub Wilk
--
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/20120418190320.ga2...@jwilk.net
Re: How do I add support for python3 to my package?
On Wednesday, April 18, 2012 10:49:34 AM Scott Kitterman wrote: > Alternately you could invest a little time in understanding what Barry's > written up and build both sets of binaries from one source. This is the > usual method. The problem is not understanding. It is a problem of style. Let us take one snippet > python$* setup.py install --root=$(CURDIR)/debian/tmp > --install-layout=deb That is the usual way we install in March 2012. But "the usual way we install" is a moving target; It will change. I don't want to codify "the usual way we install" in March 2012 and then maintain that moving target as it moves. I want to write code that means "install in the usual way" and let the code that implements that concept be maintained by someone smarter than me. It is not good design to have a bunch moving targets all tracked by multiple packagers with various abilities and attention spans. This is not criticism of Barry; He has written excellent documentation on how to join the cargo cult. I am saying that we ought to find ways of not joining cargo cults. It is not about me or my level of understanding. Every line of code I write has to be maintained by somebody. Eventually, by somebody other than me; I am not going to live forever. Therefore, I resist writting lines of code. > A separate source package doesn't make it any easier as it > would still have to build for python3. When I build for python2 alone I don't have to override dh_auto_build or dh_auto_install. I assume the same would be true if building for python3 alone. It is only when I want both in the same source package that I need these complicated overrides that create moving targets. > > Scott K -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: How do I add support for python3 to my package?
On Wednesday, April 18, 2012 02:35:20 PM Paul Elliott wrote: > On Wednesday, April 18, 2012 10:49:34 AM Scott Kitterman wrote: > > Alternately you could invest a little time in understanding what Barry's > > written up and build both sets of binaries from one source. This is the > > usual method. > > The problem is not understanding. It is a problem of style. > > Let us take one snippet > > > python$* setup.py install --root=$(CURDIR)/debian/tmp > > --install-layout=deb > > That is the usual way we install in March 2012. But "the usual way we > install" is a moving target; It will change. > > I don't want to codify "the usual way we install" in March 2012 and then > maintain that moving target as it moves. It's extremely unlikely to change anytime soon. > I want to write code that means "install in the usual way" and let the code > that implements that concept be maintained by someone smarter than me. That would be better, but such code isn't available yet, so your choices are do it by hand or wait. It's your choice, but I don't think it's so bad to go ahead. > It is not good design to have a bunch moving targets all tracked by multiple > packagers with various abilities and attention spans. The design is stable. What we don't have is a tool set that hides it from you. There is no chance before Wheezy releases and probably not for long after that that the existing choices will quit working or suddenly be wrong. > This is not criticism of Barry; He has written excellent documentation on > how to join the cargo cult. I was confused by assuming you knew what the phrase cargo cult meant. If you understand Barry's documentation, you aren't cargo culting the scripts. http://en.wikipedia.org/wiki/Cargo_cult_programming > I am saying that we ought to find ways of not joining cargo cults. I don't think anyone is suggesting you actually do that. > It is not about me or my level of understanding. Every line of code I write > has to be maintained by somebody. Eventually, by somebody other than me; I > am not going to live forever. Therefore, I resist writting lines of code. Then you can wait until multibuild is done if you prefer. > > A separate source package doesn't make it any easier as it > > would still have to build for python3. > > When I build for python2 alone I don't have to override > dh_auto_build or dh_auto_install. > > I assume the same would be true if building for python3 alone. > > It is only when I want both in the same source package that I need these > complicated overrides that create moving targets. No. You'd need overrides for a python3 only source package as well. The fundamental problem is debhelper doesn't know about building for python3. That doesn't change no matter how many source packages you split it up into. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2905556.ZJMP4yLkxT@scott-latitude-e6320
Re: How do I add support for python3 to my package?
On Wednesday, April 18, 2012 02:46:33 PM Scott Kitterman wrote: > No. You'd need overrides for a python3 only source package as well. The > fundamental problem is debhelper doesn't know about building for python3. > That doesn't change no matter how many source packages you split it up > into. > > Scott K I think you have just put your finger on another problem then. Nobody thinks python3 is important enough to have a debhelper infrastructure? My upstream tells me he does not know of any python3 programs using his module. Maybe I should delay python3 support then. -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: How do I add support for python3 to my package?
On Wednesday, April 18, 2012 03:09:35 PM Paul Elliott wrote: > On Wednesday, April 18, 2012 02:46:33 PM Scott Kitterman wrote: > > No. You'd need overrides for a python3 only source package as well. The > > fundamental problem is debhelper doesn't know about building for python3. > > That doesn't change no matter how many source packages you split it up > > into. > > > > Scott K > > I think you have just put your finger on another problem then. > > Nobody thinks python3 is important enough to have a debhelper > infrastructure? > > My upstream tells me he does not know of any python3 programs using his > module. > > Maybe I should delay python3 support then. Your call. It's a chicken/egg problem. If Python 3 modules aren't provided, application developers won't use them. If application developers don't use Python 3 modules, people don't worry about packaging them. It's not very hard to support, so I would recommend doing it and help move things forward. The work to properly support Python 3 is in progress, it just isn't done yet. Debian is a volunteer project and sometimes (as in this case) people don't have as much time as they had anticipated and things take longer. We all agree it's important. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1862368.sMrzQEgZva@scott-latitude-e6320
Re: How do I add support for python3 to my package?
On Apr 18, 2012, at 03:09 PM, Paul Elliott wrote: >Nobody thinks python3 is important enough to have a debhelper infrastructure? I wouldn't say that. I'd say that the higher level tools are simply lagging behind demand. The low-level tools are available and won't significantly change. As Scott says, all that will change is that the higher level tools will come along and hide some of the lower level stuff from you. If you use the lower level tools today, nothing will break when the higher level tools are ready. When they are, and you decide to adopt them, you'll make one change, which will satisfyingly be to remove code (and I don't say that sarcastically :). But you could also decide to leave things just the way they are, since nothing will be broken. >My upstream tells me he does not know of any python3 programs using his >module. It's a chicken-and-egg problem. In order to increase the momentum toward Python 3, we need to port things from the bottom up. Higher level libraries can't port until the ones they depend on are ported. Applications can't port until all their dependencies are ported. Most users and developers get most of their packages from their distro, so the upstream's judge of popularity isn't always sufficient to judge the pent up demand. >Maybe I should delay python3 support then. IMHO, no you shouldn't delay. The path is clear, and easy, and you don't risk doing busy work that you'll just have to undo later. There's no reason not support Python 3 in your package, and every reason to do it. Cheers, -Barry signature.asc Description: PGP signature
Re: Bug#668841: RFS: yp-svipc/0.13-1 [ITP] -- System V InterProcess Communication for Python/Yorick
Hi,
Le 18/04/12 21:03, Jakub Wilk a écrit :
> (I don't intend to sponsor this package.)
Thanks for the comments nevertheless. I've fixed them all.
In the meantime, upstream succeeded in porting this extension to python
3, so I've updated the package accordingly:
http://mentors.debian.net/package/yp-svipc
http://mentors.debian.net/debian/pool/main/y/yp-svipc/yp-svipc_0.14-1.dsc
> I'd rather not use ${python:Provides}. See:
> http://lists.debian.org/20110324164804.ga5...@jwilk.net
I see there's a consensus in this direction and that's in line with [1],
but that's contrary to the Python Policy as published in [2] which
states " Provides in binary packages of the form |python-foo| must be
specified, if the package contains an extension for more than one python
version."
[1] http://wiki.debian.org/Python/Policy
[2] http://www.debian.org/doc/packaging-manuals/python-policy/
I'm guessing [2] should be fixed and I'll file a bug report to that
effect tomorrow.
Regards, Thibaut.
--
* Dr Thibaut Paumard | LESIA/CNRS - B. Lyot (n°6)*
* Tel: +33 1 45 07 75 45 | Observatoire de Paris - Section de Meudon *
* Fax: +33 1 45 07 79 17 | 5, Place Jules Janssen*
* thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France) *
smime.p7s
Description: Signature cryptographique S/MIME
