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: How does team maintenace of python module works?
Hi, On Wed, Feb 20, 2013 at 11:46:31PM -0500, Barry Warsaw wrote: 9. Git history is a bunch of lies The primary output of development work should be source code. Is a well-maintained history really such an important by-product? Most of the arguments for rebase, in particular, rely on aesthetic judgments about “messy merges” in the history, or “unreadable logs”. So rebase encourages you to lie in order to provide other developers with a “clean”, “uncluttered” history. Surely the correct solution is a better log output that can filter out these unwanted merges. http://mercurial.selenic.com/wiki/ChangesetEvolution Changeset Evolution is a set of features to gracefully handle history rewriting operations. It offers a safe and simple way to refine changesets. Results of your local history rewriting operations can be propagated to other clones in a solid way. It is even possible for multiple people to rewrite the same part of the history in a distributed way. My humble opinion is that this is about to become a major feature of Mercurial. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- 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/20130222131741.ga20...@volans.logilab.fr
binary package naming for submodules (Bug#701192)
[Barry Warsaw, 2013-02-22] DPP section 2.2 describes the policy for naming binary packages of Python packages, e.g. python-* and python3-*. For packages with submodules in namespaces, e.g. zope.interface, the implied policy is to name it python-foo.bar and python3-foo.bar. However, I've had some feedback from people that this should be explicitly stated, thus this bug Something like the following could be added to python-policy.sgml: For subpackages such as varfoo.bar/var, the recommendation is to name the binary packages packagepython-varfoo.bar/var/package and packagepython3-varfoo.bar/var/package. any objections? -- 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/20130222154130.gp31...@piotro.eu
Re: How does team maintenace of python module works?
On Friday, February 22, 2013 03:14:30 PM Thomas Goirand wrote: ... The problem is that with SVN, it takes so much time and space (as each tag will generate some files), so you might have been fooled into thinking it would also with Git. But the reality simply not that at all. ... I almost never check out the entire package, just trunk, so (as Piotr has indicated) your data is WAY off. This may be where your git experience caused you to look at this problem suboptimally. One of the real strengths of SVN over anything newer is the ability to check out just a small part of the repository without any special preparation for it needed. Developers can get as much or as little as they need. I also agree with Piotr that this thread has probably outlived whatever usefulness it might have had and should stop. 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/4006639.oYv6cMICYi@scott-latitude-e6320
Re: binary package naming for submodules (Bug#701192)
* Piotr Ożarowski pi...@debian.org, 2013-02-22, 16:41: For subpackages such as varfoo.bar/var, the recommendation is to name the binary packages packagepython-varfoo.bar/var/package and packagepython3-varfoo.bar/var/package. any objections? Not at all, sounds good to me. -- 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/20130222192608.ga1...@jwilk.net
Re: How does team maintenace of python module works?
On 02/22/2013 03:57 PM, Piotr Ożarowski wrote: [Thomas Goirand, 2013-02-22] From a server in a data center in Seattle, it took me 90 seconds to download the packaging sources of python-eventlet. Compare this to the 4 seconds it takes me to clone python-warlock from Alioth, upstream source included !!! your data is wrong (see below). piotr@hadar /tmp/test 0% time svn co svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/ So probably, it's git-svn which is slow (and plain svn isn't). Interesting! 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/51278afb.9050...@debian.org
Re: Removing /usr/bin/nosetests-3.x scripts
On Feb 22, 2013, at 10:28 AM, Dmitry Shachnev wrote: 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) Sorry, can you please provide more detail for folks who were not participating in the IRC discussion? Is there no better way to provide nosetests-X.Y scripts with the proper shebang lines for all supported Python versions? Cheers, -Barry signature.asc Description: PGP signature
Re: Removing /usr/bin/nosetests-3.x scripts
Thanks for the heads up! I've checked reverse build-dependencies in sid only, in experimental there are more matching packages, but only pyxdg needs fixing. Surprisingly, many packages are already using the right way. -- Dmitry Shachnev On Fri, Feb 22, 2013 at 3:32 PM, Thomas Kluyver tho...@kluyver.me.uk wrote: On 22 February 2013 06:28, Dmitry Shachnev mity...@gmail.com wrote: After looking at all packages that build-depend on python3-nose, I've identified these packages as needing fix: I happen to recall that python-xdg is also affected, both in debian/rules [1] and autopkgtests [2]. I'm happy to update that, but you might want to double check the script that you were using to scan packages, to make sure that we're not missing other cases. [1] http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/trunk/debian/rules?revision=22479view=markup [2] http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/trunk/debian/tests/upstream?revision=23091view=markup 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/CAKimPHVhz3HMH4rMoOnAn_SVEcEiCYN4oO9xi4ckiCFi=zw...@mail.gmail.com
Bug#701194: RFS: dparser-1.29-1 [ITP] -- a scannerless GLR parser generator
X-Debbugs-Cc: debian-python@lists.debian.org Package: sponsorship-requests Severity: wishlist Dear mentors, dear python gurus, I am still looking for a sponsor for my package dparser, now upgraded from 1.26 to 1.29. * Package name: dparser Version : 1.29-1 Upstream Author : John Bradley Plevyak jplev...@acm.org * URL : http://dparser.sourceforge.net/ * License : mostly BSD-3-clause, one file GPL Section : devel Programming Lang: C and Python It builds those binary packages: dparser - scannerless GLR parser generator dparser-doc - documentation for dparser python-dparser - Python bindings for dparser To access further information about this package, please visit the following URL: http://mentors.debian.net/package/dparser Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/dparser/dparser_1.29-1.dsc Jakub Wilk reviewed (the earlier 1.26 version of) the package. I think all issues have been addressed, see ITP bug #668556. I realize we are in deep freeze, I just want to renew my offer to maintain the dparser package. Regards Markus Wanner -- 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/512797e4.4090...@bluegap.ch
Re: Bug#701194: RFS: dparser-1.29-1 [ITP] -- a scannerless GLR parser generator
* Markus Wanner mar...@bluegap.ch, 2013-02-22, 17:08: http://mentors.debian.net/debian/pool/main/d/dparser/dparser_1.29-1.dsc Lintian emits: W: dparser source: out-of-date-standards-version 3.9.3 (current is 3.9.4) lintian4python emits: e: python-dparser: string-exception usr/share/pyshared/dparser.py:215 e: python-dparser: string-exception usr/share/pyshared/dparser.py:233 e: python-dparser: string-exception usr/share/pyshared/dparser.py:236 e: python-dparser: string-exception usr/share/pyshared/dparser.py:260 e: python-dparser: pyflakes-undefined-name usr/share/pyshared/dparser.py:98: i Is export DH_OPTIONS in debian/rules needed for anything? I don't think it is. -- 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/2013000910.ga...@jwilk.net
Re: Removing /usr/bin/nosetests-3.x scripts
On 22 February 2013 06:28, Dmitry Shachnev mity...@gmail.com wrote: After looking at all packages that build-depend on python3-nose, I've identified these packages as needing fix: I happen to recall that python-xdg is also affected, both in debian/rules [1] and autopkgtests [2]. I'm happy to update that, but you might want to double check the script that you were using to scan packages, to make sure that we're not missing other cases. [1] http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/trunk/debian/rules?revision=22479view=markup [2] http://anonscm.debian.org/viewvc/python-modules/packages/pyxdg/trunk/debian/tests/upstream?revision=23091view=markup Thomas
Re: How does team maintenace of python module works?
❦ 22 février 2013 16:12 CET, Thomas Goirand z...@debian.org : From a server in a data center in Seattle, it took me 90 seconds to download the packaging sources of python-eventlet. Compare this to the 4 seconds it takes me to clone python-warlock from Alioth, upstream source included !!! your data is wrong (see below). piotr@hadar /tmp/test 0% time svn co svn://svn.debian.org/python-modules/packages/python-eventlet/trunk/ So probably, it's git-svn which is slow (and plain svn isn't). Interesting! git-svn tries to download the whole history. svn don't. -- Don't patch bad code - rewrite it. - The Elements of Programming Style (Kernighan Plauger) pgp1UDMNntfKW.pgp Description: PGP signature
svn rm debian/source/local-options
Can we please remove debian/source/local-options from our repositories? I don't think storing them in VCS makes sense. See the attachment for the list of affected packages and maintainers. (There's a few more if you count also /tags/ directories.) -- Jakub Wilk David Watson dwat...@debian.org importlib (U) Fladischer Michael fladischermich...@fladi.at importlib (U) Janos Guljas ja...@resenje.org python-dexml python-django-feincms python-django-localeurl python-django-mptt python-django-shorturls python-django-social-auth python-mongoengine python-mrjob python-pyftpdlib transifex-client Michael Fladischer fladischermich...@fladi.at kombu (U) Nikolaus Rath nikol...@rath.org python-llfuse Nikolaus Schulz microsch...@web.de archivemail
Re: Packaging applications with extensions modules
Hi Jakub (2013.02.16_14:01:58_+0200) C) Built the modules only for the default Python version and install them to a private directory (/usr/lib/PKGNAME/ or similar). This is what Python Policy tells us to do. I see the following problem with this approach: This is my preferred approach, and I think we should deal with the problems. - You can ship extensions only for one Python version. (Arguably that's not a big deal.) Not a big deal because: * 2.7 is the end of 2 (we hope) * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags * we don't tend to have more than one 3.x version in the archive for long (thanks to easy transitions, but they are sure to get harder) - Unless you write the code yourself, there is no protection against loading extensions modules for a wrong Python version. Not going to a problem with 3.x - dh_python2 (which, for some reason, everyone wants to use) doesn't generate §3.1.1-compliant dependency for such setup. Yeah, we should fix that. I don't think the problems with C are big enough to warrant changing the policy. I think the approach is fairly sound. 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/2013013110.ga29...@bach.rivera.co.za
Re: Packaging applications with extensions modules
* Stefano Rivera stefa...@debian.org, 2013-02-22, 23:31: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) -- 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/2013014824.ga4...@jwilk.net
Re: Removing /usr/bin/nosetests-3.x scripts
Hi Barry (2013.02.22_15:38:46_+0200) 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) Sorry, can you please provide more detail for folks who were not participating in the IRC discussion? Is there no better way to provide nosetests-X.Y scripts with the proper shebang lines for all supported Python versions? Our options were: 1. Status quo: Provide a nosetests-3.X script for the default version at build time. Pros: None Cons: - This potentially breaks unit tests if there are two supported 3.x versions. 2. Drop all nosetsts-3.X scripts. Pros: - Maintainers who were aware of the problems with 1 had to manually call python3.X /usr/bin/nostests3 anyway, so this doesn't cause them any harm. - Don't accidentally end up with dependencies on all python3.Xs Cons: - Maintainers who weren't needed their packages patched. 3. Apply a messy patch to generate scripts based on py3verions -s at build time. Pros: - Neat Cons: - It's ugly as hell - Have to do a sourceful upload for each python3 supported versions change - Will accidentally end up with dependencies on all python3.Xs 4. Use .rtinstall, .rtremove, postinst, and prerm scripts to maintain all the nosetsets-3.X scripts (pytest does this) Pros: - Neat - No accidental dependencies on all python3.Xs Cons: - You are creating and deleting things in /usr/bin in maintainer scripts - this made some people cringe. 2 seemed better than 1, and was dead easy. Given the fairly low number of packages using python3-nose, fixing them wasn't hard. 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/2013015103.gb29...@bach.rivera.co.za
Re: Packaging applications with extensions modules
Hi Jakub (2013.02.22_23:48:24_+0200) * Stefano Rivera stefa...@debian.org, 2013-02-22, 23:31: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) You have a point. That'd be non-trivial to support. If only the tags were applied applied before dh_python3 got there... 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/2013015209.gc29...@bach.rivera.co.za
Re: Packaging applications with extensions modules
Stefano Rivera stefa...@debian.org wrote: Hi Jakub (2013.02.22_23:48:24_+0200) * Stefano Rivera stefa...@debian.org, 2013-02-22, 23:31: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) You have a point. That'd be non-trivial to support. If only the tags were applied applied before dh_python3 got there... SR What's not supported? 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/b0143391-e898-4dd0-919e-c02f3d9df...@email.android.com
Re: Packaging applications with extensions modules
Hi Scott (2013.02.23_00:17:30_+0200) * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) You have a point. That'd be non-trivial to support. What's not supported? Not all build systems append tags to the C extension file names, so if you install to the same directory in a pyversion loop, you may overwrite C extensions from earlier python versions. Not a problem for distutils, though. So, maybe that's only a very minor issue. 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/2013023849.gd29...@bach.rivera.co.za
Re: Packaging applications with extensions modules
Stefano Rivera stefa...@debian.org wrote: Hi Scott (2013.02.23_00:17:30_+0200) * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) You have a point. That'd be non-trivial to support. What's not supported? Not all build systems append tags to the C extension file names, so if you install to the same directory in a pyversion loop, you may overwrite C extensions from earlier python versions. Not a problem for distutils, though. So, maybe that's only a very minor issue. dh_python3 does rewrite extension names with the tags. As an example, python-qt4 uses this. 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/b601b85e-de8e-4811-b163-86a85807c...@email.android.com
Re: Packaging applications with extensions modules
* Scott Kitterman deb...@kitterman.com, 2013-02-22, 17:56: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) I gave it a try, and it appears to work, provided that upstream build system supports ABI tagging. Wow. :-) dh_python3 does rewrite extension names with the tags. As an example, python-qt4 uses this. If you install multiple non-tagged extensions to a private directory, they'll have overwritten each other before dh_python3 will have a chance to rename them. We'll have this problem also for build systems which install stuff to /usr/lib/python3/dist-packages/, but don't support PEP3149... -- 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/2013032416.ga7...@jwilk.net
Re: Packaging applications with extensions modules
On Saturday, February 23, 2013 12:24:16 AM Jakub Wilk wrote: * Scott Kitterman deb...@kitterman.com, 2013-02-22, 17:56: * you can ship extensions for more than one 3.x version in the same private directory, thanks to tags Does dh_python3 support such setup? (I would be very surprised if it did.) I gave it a try, and it appears to work, provided that upstream build system supports ABI tagging. Wow. :-) dh_python3 does rewrite extension names with the tags. As an example, python-qt4 uses this. If you install multiple non-tagged extensions to a private directory, they'll have overwritten each other before dh_python3 will have a chance to rename them. We'll have this problem also for build systems which install stuff to /usr/lib/python3/dist-packages/, but don't support PEP3149... I think for most build systems you can override the install directory. For sip4, python-qt4, and friends I install in /buildx.y and then dh_python3 renames the files on move. You're correct that you can end up overwriting the files if you aren't careful. The worst thing I've seen this: http://bazaar.launchpad.net/~ubuntu- branches/ubuntu/raring/pykde4/raring/view/head:/debian/rules Certainly not the easiest thing in the world, but it works. BTW, there is no support at all for pure python3 code that's version specific. I had to do horrible things in sip4/python-qt4 to make that work. 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/2204074.jeqpeBvNHb@scott-latitude-e6320
Bug#701222: RFP: dnsgraph -- trace and graph all resolution paths for DNS names
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org * Package name: dnsgraph Upstream Author : Dennis Kaarsemaker * URL : https://github.com/seveas/dnsgraph * License : MIT Programming Lang: Python Description : trace and graph all resolution paths for DNS names dnsgraph depends on python-whelk by the same author: https://github.com/seveas/whelk -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Removing /usr/bin/nosetests-3.x scripts
On Fri, Feb 22, 2013 at 9:08 PM, Julian Taylor jtaylor.deb...@googlemail.com wrote: 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. Hi Julian, I was checking both debian/rules and debian/tests/*, but only for packages in sid and experimental that build-depend on python3-nose. Now I have done something like grep-dctrl -sTests -FDepends python3-nose ./*/trunk/debian/tests/control grep-dctrl -sSource -FBuild-Depends-Indep python3-nose ./*/trunk/debian/control grep-dctrl -sSource -FBuild-Depends python3-nose ./*/trunk/debian/control in both DPMT and PAPT SVNs, and again pyzmq is the only package that wasn't noticed by my previous checks. Please fix it before uploading. -- Dmitry Shachnev -- 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/1361601561.17193.2.camel@mandriver-laptop
