On Fri, Feb 22, 2013 at 9:08 PM, Julian Taylor
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
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 resolu
On Saturday, February 23, 2013 12:24:16 AM Jakub Wilk wrote:
> * Scott Kitterman , 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 i
* Scott Kitterman , 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
Stefano Rivera 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
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'
Stefano Rivera wrote:
>Hi Jakub (2013.02.22_23:48:24_+0200)
>
>> * Stefano Rivera , 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
Hi Jakub (2013.02.22_23:48:24_+0200)
> * Stefano Rivera , 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 no
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 d
* Stefano Rivera , 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.debia
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, an
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
importlib (U)
❦ 22 février 2013 16:12 CET, Thomas Goirand :
>>> 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
On 22 February 2013 06:28, Dmitry Shachnev 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, b
* Markus Wanner , 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:
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 :
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 wrote:
> O
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
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 so
* Piotr Ożarowski , 2013-02-22, 16:41:
"For subpackages such as foo.bar, the recommendation is to
name the binary packages python-foo.bar
and python3-foo.bar.
any objections?
Not at all, sounds good to me.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
wit
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
[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 h
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
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 thos
24 matches
Mail list logo
