On Feb 06, 2013, at 01:13 PM, Piotr Ożarowski wrote:
FTR: pybuild does that by default (http_proxy=http://127.0.0.1:9/)
Nice.
it probably should be changed to not overwrite existing http_proxy (if set)
or to make it possible to disable it.
The only case where I found I had to unset http_proxy
On Feb 06, 2013, at 11:18 AM, Dmitrijs Ledkovs wrote:
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.
That would help make local sbuilds act more like
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:
On Dec 24, 2012, at 12:43 AM, Dmitrijs Ledkovs wrote:
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
On Dec 18, 2012, at 02:22 PM, Julien Cristau wrote:
On Thu, Dec 13, 2012 at 11:34:12 +0100, Jakub Wilk wrote:
How about undoing the Python multi-arch mess until someone provides
evidence that the changes solve more problems than they create?
Having some explanation of what's going on would
On Dec 18, 2012, at 10:40 AM, Andrew Starr-Bochicchio wrote:
This is the only thing I've come across:
http://wiki.debian.org/Python/MultiArch
Ah, of course. I've added some cross-links.
-Barry
signature.asc
Description: PGP signature
On Dec 12, 2012, at 07:09 PM, Barry Warsaw wrote:
Wouldn't it be nice if Python just told you what the values were?
Bugs and patches are now up on b.d.o:
2.7: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695958
3.3: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695959
This exposes
On Dec 10, 2012, at 02:33 PM, Bradley M. Froehle wrote:
Interesting, the LibraryStyleGuide [1] suggests a plain `=` and the
AppStyleGuide [2] suggests `:=`. (The difference of course is that `=`
does delayed evaluation meaning the command is run once for every time the
variable is needed, and
On Nov 15, 2012, at 04:15 PM, Thomas Kluyver wrote:
- uscan puts upstream tarballs into ../, but svn-buildpackage expects them
in ../tarballs/
- To work on patches, you have the debian/ directory in amongst the
upstream codebase. But having the rest of the codebase there clutters up
information
On Nov 14, 2012, at 02:14 PM, Jakub Wilk wrote:
* Thomas Kluyver tak...@gmail.com, 2012-11-14, 11:44:
While working on the python3-sympy package, I've seen that if Python 2 is
installed, various dh_* commands, like dh_auto_clean, will automatically try
to run setup.py in Python 2. In this case,
On Nov 14, 2012, at 02:00 PM, Stefano Rivera wrote:
Hi Barry (2012.11.13_01:04:59_+0200)
I am upgrading Ubuntu 13.04's python-virtualenv package to 1.8.2. This
could provide a basis for upgrading the Debian version in Wheezy+1.
As usual, I'd say: You're a member of DPMT, which is the primary
On Nov 15, 2012, at 03:49 AM, Tristan Seligmann wrote:
On Wed, Nov 14, 2012 at 5:42 PM, Tomás Di Domenico td...@tdido.com.ar wrote:
Another blurry point. I'm having a hard time understanding the
separation of tasks between the tarball packaging done by upstream I
described before, and my
On Nov 13, 2012, at 02:25 AM, Jakub Wilk wrote:
* Barry Warsaw ba...@python.org, 2012-11-12, 13:32:
The LICENSE file reads:
| The execnet package is released under the provisions of the Gnu Public
| License (GPL), version 2 or later.
Shouldn't it be s/execnet/tox/ and s/Gnu/GNU General/?
I've
On Nov 10, 2012, at 10:55 PM, Jakub Wilk wrote:
(I don't intend to sponsor this, sorry.)
No problem, thanks for the review.
* Barry Warsaw ba...@python.org, 2012-11-09, 20:27:
http://anonscm.debian.org/viewvc/python-apps/packages/tox/trunk/
I see some warnings in the build log:
| loading
On Nov 12, 2012, at 08:29 PM, Piotr Ożarowski wrote:
[Barry Warsaw, 2012-11-12]
p: python-tox: SOURCES.txt-in-binary-package
Fixed, but we really need better rationale for this in the wiki. ;)
If keeping this file in .deb package doesn't have any advantages,
it can simply be removed
I am upgrading Ubuntu 13.04's python-virtualenv package to 1.8.2. This could
provide a basis for upgrading the Debian version in Wheezy+1.
I'd like to modify the add_distribute.patch. What this currently does is set
virtualenv to use distribute by default. This is fine, and I want to keep
this
Bug 664759 is the ITP for python-tox. Back in June, Bradley M. Froehle
provided an initial packaging. I finally found some time to take his work,
add a few things (manpage, updated to latest tox version, debian/watch,
lintian clean), and svn-injected it into the PAPT repo.
On Oct 27, 2012, at 06:53 PM, Jakub Wilk wrote:
* Thomas Kluyver tho...@kluyver.me.uk, 2012-10-26, 11:03:
Are there any situations where you might want to run a system script with
modified Python environment variables? I can't think of any off the top of
my head. Here's the list of environment
On Oct 26, 2012, at 09:19 AM, Floris Bruynooghe wrote:
On 25 October 2012 20:34, Piotr Ożarowski pi...@debian.org wrote:
[Steve Langasek, 2012-10-25]
On Thu, Oct 25, 2012 at 10:56:05AM -0400, Barry Warsaw wrote:
Using -E fixed the immediate bug, but I think it is generally useful to
include
On Oct 26, 2012, at 12:33 PM, Jakub Wilk wrote:
* Thomas Kluyver tho...@kluyver.me.uk, 2012-10-26, 11:03:
Are there any situations where you might want to run a system script with
modified Python environment variables? I can't think of any off the top of
my head. Here's the list of environment
I wanted to mention something that came up recently in Ubuntu, where
lsb_release is a Python 3 script. This isn't specific to Python 3, since
Python 2 scripts can also be affected.
The Launchpad bug is symptomatic of the more general problem:
On Oct 25, 2012, at 07:05 PM, Jakub Wilk wrote:
* Barry Warsaw ba...@python.org, 2012-10-25, 10:56:
https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/938869
When you write system scripts like 'lsb_release' that use
/usr/bin/python{,3} in the #! line, please remember to include -Es
switches
On Oct 25, 2012, at 11:18 AM, Steve Langasek wrote:
On Thu, Oct 25, 2012 at 10:56:05AM -0400, Barry Warsaw wrote:
This doesn't requires a mass freakout, but it might be useful for a mass bug
filing (of non-urgent priority, I think). I don't have time before UDS-R to
look into that, so I
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.
Cheers,
-Barry
signature.asc
Description: PGP signature
On Sep 28, 2012, at 09:47 AM, Paul Tagliamonte wrote:
^^ this is a great idea. It'd be nice if we could prototype a flake8 /
pyflakes run against the archive, and filter for serious errors
First, we need to get tools like pyflakes ported to Python 3. It's rather
crazy that pyflakes will
On Sep 28, 2012, at 09:04 AM, Yaroslav Halchenko wrote:
PEP396,
Status: Draft
Barry, was there any progress?
Nope. For whatever reason (maybe not enough controversy), there have been no
discussions on this in ages. I really should try to resurrect it.
I could start with this one of cause
On Sep 28, 2012, at 12:53 PM, Yaroslav Halchenko wrote:
I just vaguely remember that there were problems in some projects relying on
__file__ (some times opportunistically with os.path.realpath) to deduce the
path to other components of the project, which might had been symlinked
elsewhere ;-)
On Sep 21, 2012, at 09:18 AM, Yaroslav Halchenko wrote:
Since the deadline for the submission of talks/tutorials for the PyCon
2013 is approaching (28th of Sep) I thought to check if anyone from the
'team' will be attending (Barry?) and may be someone already is
planing to give a talk or might be
On Sep 18, 2012, at 10:07 PM, Russ Allbery wrote:
I've just uploaded Debian Policy 3.9.4.0, which includes the Technical
Committee decision to make build-arch and build-indep mandatory targets
(but not for wheezy; see below)
4.9
`build-arch' and `build-indep' are now mandatory
On Sep 18, 2012, at 05:23 PM, أحمد المحمودي wrote:
On Tue, Sep 18, 2012 at 06:27:21PM +1000, Dmitry Smirnov wrote:
Although Xpra is mainly an application its modules can be used by frontends
like winswitch, packaged by yours truly. In particular winswitch have an
ugly workaround [1] to find
On Sep 04, 2012, at 09:00 AM, Nigel Sedgwick wrote:
Given the issue with (especially) WX, I think I will stick with Python
2.7 for the time being.
The only suggestion I'd make is that you write your Python 2 code so that it's
easier to port to Python 3 when all your dependencies are available.
On Jul 30, 2012, at 07:36 PM, Thomas Kluyver wrote:
The attached diff updates pyxdg with a new upstream version, which
includes Python 3 support (bug #591017).
Thanks for doing this port Thomas. I ported 0.20 in Ubuntu 12.10 to Python 3,
and I've been meaning to post my changes to Debian, but I
On Jul 12, 2012, at 09:00 PM, Piotr Ożarowski wrote:
can we agree on a common suffix for such¹ packages and add a suggestion
to Debian Python Policy?
+1
I use -ext (python-sqlalchemy-ext) but now I see that there are also
-accel (python-reportlab-accel) and -lib (python-guppy-lib)
I suppose I
Apologies for the cross-posting, but I think both lists will have valuable
input on this issue.
As part of Ubuntu's push to ship only Python 3 on our desktop image, I'm now
looking at libpeas (Gnome plugin system).
The good news is that upstream supports Python 3.2 and 2.6/7 just fine,
however
On May 28, 2012, at 12:33 AM, Jakub Wilk wrote:
It's a mistake to write
assert(tilsit, 'Never at the end of the week, sir.')
instead of
assert tilsit, 'Never at the end of the week, sir.'
The former assertion is always true, and thus no-op. Python = 2.6 emits a
SyntaxWarning about
On May 14, 2012, at 11:27 PM, Thomas Kluyver wrote:
- The tests: Running the tests during the build requires dbus and a
notification daemon, which in turn requires an X server running. I've
come up with a recipe that works in a pbuilder, but is it suitable for
the autobuilders, and is there a
On May 04, 2012, at 07:16 PM, Thomas Kluyver wrote:
On 4 May 2012 19:06, Dmitrijs Ledkovs x...@debian.org wrote:
ok. what is the relationship between 'distribute' 'packaging'?
Let's see if I get all these right:
distutils: basic packaging functionality, part of the Python standard library
I just wanted to make people aware of the upstream Python 3.3 schedule. 3.3
alpha 3 was tagged today and we're less than two months away from beta 1.
Georg Brandl (the 3.3 release manager) sent out this message today:
http://mail.python.org/pipermail/python-dev/2012-May/119157.html
PEP 398
On May 01, 2012, at 11:37 AM, Scott Kitterman wrote:
On Tuesday, May 01, 2012 10:45:24 AM Barry Warsaw wrote:
...
The ipaddr library is as well, though that might get the provisional
tag.
...
This is one I'll need to keep an eye on as ipaddr is packaged in dpmt as a
seperate module
On Apr 30, 2012, at 04:07 PM, Natalia Frydrych wrote:
2012/4/29 Andrew Straw straw...@astraw.com:
(I'm coming at this very late - apologies for only noticing your email now.)
What you describe is exactly the pypi-install command of stdeb:
http://github.com/astraw/stdeb .
Stdeb is one of the
On Apr 30, 2012, at 11:23 AM, Piotr Ożarowski wrote:
[Barry Warsaw, 2012-04-25]
- dh_python{2,3} should rewrite the shebang lines by default, with an option
to disable that.
there wasn't a consensus so I dropped this idea, I think I will add it
as an optional feature in next upload, though
On Apr 30, 2012, at 12:08 PM, Simon McVittie wrote:
On 30/04/12 10:39, Piotr Ożarowski wrote:
[Piotr Ożarowski, 2012-04-30]
I will change that to /usr/share/package-name/module and
/usr/lib/package-name/module if no one objects
(adding /usr/share or /usr/lib to sys.path is not a good idea, we
On Apr 30, 2012, at 05:00 PM, Piotr Ożarowski wrote:
I don't remember arguments against making it the default,
will have to dig the IRC/mailing list archives later.
I'd prefer rewrite since I think /usr/bin/env is almost always the wrong
thing to use in production (though I acknowledge Stefano's
On Apr 30, 2012, at 11:04 AM, Yaroslav Halchenko wrote:
With such a massive automated packaging it would be great if from day
0 you would think about adding build-time testing into the
pipeline. It should be quite easy to discover if module carries any
unittests (grep for unittest ;) ) and what
On Apr 30, 2012, at 05:13 PM, Simon McVittie wrote:
I hope you're not arguing that virt-manager, the Gtk tool for managing
virtual machines, ought to be called python-virtmanager, just because it
happens to be implemented in Python and contain a private Python package
(off the default sys.path)
Apologies for reviving this thread. It's recently come up in relation to
other discussions I've had and I did a grep over s/usr/bin to find instances
where /usr/bin/env python was being used. Stefano reminded me of this
thread, and when I went back and re-read it, I noticed there wasn't
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
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
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
On Apr 12, 2012, at 10:09 AM, Paul Elliott wrote:
On Thursday, April 12, 2012 08:30:41 AM Barry Warsaw wrote:
Hi Paul,
I'm not sure what you mean by no python3 program to test it. You can and
should create the Python 3 extension modules. `apt-get install python3`
should do the trick, right
On Apr 03, 2012, at 10:36 AM, Stefano Zacchiroli wrote:
Allow me be blunt then: do we have volunteers to maintain the pythonX.Y
packages? Can those volunteers manifest themselves on this list?
Apologies for not responding sooner, I was off-line for a while.
I have no opinion on how the
On Mar 15, 2012, at 10:11 AM, Scott Kitterman wrote:
Thomas Kluyver tak...@gmail.com wrote:
Sandro:
I won't migrate to dh_python2, so it would be a waste of your time.
Why not? I thought python-support was deprecated, and everything was
supposed to move to dh_python2?
So, is it practical to
On Mar 14, 2012, at 12:41 PM, Thomas Kluyver wrote:
You changed the packaging to build for all supported Python 3 versions,
rather than only the default (although I think only 3.2 is currently
supported, anyway). I'd originally had it like that, but when I looked at
the PyQt4 packaging, it was
On Mar 14, 2012, at 01:27 PM, Scott Kitterman wrote:
It would be nice to have it in Experimental though. There are some bits of
multi-version support for Python 3 that still need work and we could work on
that with 3.3 and a new python3-defaults in experimental.
+1
-Barry
--
To
On Feb 24, 2012, at 12:24 PM, Jakub Wilk wrote:
* Paul Wise p...@debian.org, 2012-02-24, 13:29:
Also, please remove Google Analytics code, and references to other
JavaScript code and CSS hosted on external websites. I don't want to be
tracked when viewing local documentation. :
That sounds like
On Feb 09, 2012, at 01:02 AM, Ben Finney wrote:
In other words, I'm not directing that as a request to any particular
people. I'm expressing only the hope that Barry's initial document is,
in some future form, acknowledged by policy-shapers to embody best
packaging practices. It's a thank-you to
In the interest of making life easier for future packagers of Python
libraries, I wrote up the following guidelines.
http://wiki.debian.org/Python/LibraryStyleGuide
I've based these recommendations on feedback I've received on my own packages,
and a few other packages I've submitted bugs on.
I've been looking at the following issues in distribute/setuptools:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618367
https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/725178
Without getting into the specifics of the issue atm, I have a more basic
question. It looks like the
On Jan 29, 2012, at 11:38 PM, Jakub Wilk wrote:
* Barry Warsaw ba...@python.org, 2012-01-29, 17:30:
Can you recommend a good package to look at to implement this?
You can look at the flufl.enum
Why does it print nocheck set, skipping tests in every target (including
e.g. clean
On Jan 27, 2012, at 05:43 PM, Brian Sutherland wrote:
On Fri, Jan 27, 2012 at 11:16:02AM -0500, Barry Warsaw wrote:
On Jan 27, 2012, at 03:38 PM, Brian Sutherland wrote:
On Fri, Jan 27, 2012 at 08:36:40AM -0500, Barry Warsaw wrote:
What if we proposed a hook to get DEFAULT_VERSION from
On Jan 27, 2012, at 03:07 PM, Julien Cristau wrote:
I think a build system downloading random stuff from random places on
the internet is just as insane upstream as in debian...
For upstream development, it's handy. I like that `python setup.py test`, or
virtualenv usage will ensure that all
On Jan 27, 2012, at 03:38 PM, Brian Sutherland wrote:
On Fri, Jan 27, 2012 at 08:36:40AM -0500, Barry Warsaw wrote:
What if we proposed a hook to get DEFAULT_VERSION from a file or environment
variable? Then at least on Debian systems we could provide that file in our
python-setuptools
On Jan 04, 2012, at 01:58 PM, Luca Falavigna wrote:
After switching python-defaults to python2.7, I'm not sure we discussed
whether to keep python2.6 for Wheezy or not. In theory, we should be able to
get rid of python2.6 in time for the release (I'd likely be able to act as a
driver for the
On Nov 17, 2011, at 01:55 PM, Stefano Rivera wrote:
If you don't need the python3 version, yet, I'd ignore this until the
tools improve.
Piotr was working on a rewrite of python-multibuild at UDS in Orlando. I
haven't heard any status on that. Piotr, how's that going? Do you have
anything
On Oct 19, 2011, at 04:27 AM, Paul Elliott wrote:
Can someone please give me an alternate way to contact Python-modules-team
mailing list. I am subscribed to this list. But my messages to the list bouce
because of blacklist. I can not even send email to list-owner.
I need to find some way to
On Oct 19, 2011, at 07:49 AM, Vincent Bernat wrote:
You should not run test against the source package. Instead, you should run
tests against the yet-to-be-installed version. You need to use a wrapper for
this. I don't know if this is the best example available but it works :
On Oct 03, 2011, at 11:10 PM, Piotr Ożarowski wrote:
[Barry Warsaw, 2011-10-03]
There are no definitive mappings between Cheeseshop names and Debian
package names, but
take a look at /usr/share/python/dist_fallback, sane ones are not listed
there, though
Ah neat. Do you keep that updated
Hi Thomas,
On Oct 03, 2011, at 12:15 PM, Thomas Waldmann wrote:
I guess I could do that, although I'ld prefer some experienced DD or
developer using debian would do it (I am using ubuntu on my desktops /
development machines, but I could create some VM, of course).
Not to discourage you working
On Oct 03, 2011, at 10:16 PM, Mathieu Malaterre wrote:
So how do people track dependencies needed for python packages ? There
is no test shipped with my current package, so all I can do is `grep
-r import` at the moment.
If your package has a setup.py, you can check it for dependencies. There
On Sep 27, 2011, at 01:35 PM, Scott Kitterman wrote:
The release team has given us a transition slot and python-defaults is ready
for upload, so we'll be starting the transition shortly. We're currently
looking into 642601. We're not aware of any other issues that might cause us
to delay.
On Sep 21, 2011, at 02:40 AM, Thomas Goirand wrote:
Thanks for the pointer. However, I don't understand this:
All packages that use the same namespace have to be
converted at the same time. Be sure to use Breaks or
Depends relationships to ensure you cannot mix
installation of
On Sep 16, 2011, at 11:16 AM, Yaroslav Halchenko wrote:
Long story short -- we can't use any of the 1-5 logos. Indeed leaving us
with #6 and #7 -- please vote!
#7!
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
On Sep 15, 2011, at 01:03 PM, Daniele Tricoli wrote:
Maybe the best thing to do is contacting the PSF.
Already done!
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
On Sep 14, 2011, at 03:41 PM, Yaroslav Halchenko wrote:
Do we have a logo for our Python-In-Debian effort(s) (was needing one
for a recent talk but failed to deliver in time)? What about
having one? I am not a designer and possibly lacking any taste, so
please do not judge wildly. What would
On Sep 11, 2011, at 12:22 AM, Piotr Ożarowski wrote:
yep, NEWS.txt.gz is now a symlink to changelog.gz
thanks to dh_installchangelogs' -k flufl/lock/NEWS.txt option in your
debian/rules
I'm still not getting this one, so I don't know what to do about it.
-k flufl/lock/NEWS.txt is the fix,
I've finally managed to look into these problems. I believe I've solved them
all and will commit the updates, along with cargo-culting the same changes
into the other three flufl.* packages, asap.
On Aug 23, 2011, at 11:06 PM, Piotr Ożarowski wrote:
[Barry Warsaw, 2011-08-22]
I've managed
On Sep 05, 2011, at 10:24 PM, David Spence wrote:
Firstly, thank you for the replies: it's the response to even the daftest
question which keeps the community flourishing. To those who've replied: you
have reinforced my faith in Debian and Python.
Awesome! I'm glad we were helpful.
Barry,
Hi everyone.
I've managed to file ITPs and package up two more flufl packages, flufl.lock
and flufl.bounce. I've also updated flufl.enum and flufl.i18n. Alioth should
be up-to-date.
I wonder if someone would please review the packages, and if they look okay,
sponsor them into Debian. I've
Thanks for the update Piotr! I wish I could have made it, but it conflicted
with family vacations.
On Aug 08, 2011, at 11:50 PM, Piotr Ożarowski wrote:
At DebConf11 in Banja Luka, we had a short discussion¹ about Python 3
support in Debian. Apparently everything is very good, nobody
Hi Piotr,
Another question about the intent of dh_python2, this time as it relates to
private packages.
So, I'm converting ibus-table, which installs some .py files into
/usr/share/ibus-table/engine. I've been playing with different incantations
of the binary-indep rule:
...
Hi Piotr,
Martin Pitt discovered this problem in dh_python3:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/809951
Even in a post-PEP 3149 world, Python 3.2 itself can import untagged .so files
(which preserves backward compatibility). python3-gobject's build system does
not
Very minor grammatical fix: In the python-support section...
s/It was system/It was a system/
Also, I find the tense switch in both this and the python-central sections a
little weird.
Cheers,
-Barry
signature.asc
Description: PGP signature
On Jul 07, 2011, at 09:18 AM, Scott Kitterman wrote:
On Thursday, July 07, 2011 04:27:32 AM Piotr Ożarowski wrote:
[Scott Kitterman, 2011-07-07]
B.Packaging Tools
- B.1. distutils
- B.2. python-support
- B.3. python-central
- B.4.
On Jul 04, 2011, at 08:20 AM, Robert Collins wrote:
unittest2 is still a unittest runner at heart; the basic model is
sound to scale up to N processes and so forth (see tox or
testrespository for instance), but compatibility with arbitrary ways
of running is pretty tricky. See for instance the
On Jul 01, 2011, at 01:00 AM, Mitar wrote:
I will not yet use dh as it looks too magical for me for now. I
would like to understand what is happening. And first have a working
package. Then I can play with cleaning it up. Or would it be easier to
just let dh do everything? I doubt it can be
Apologies for the delayed response.
On Jun 15, 2011, at 01:03 AM, Zygmunt Krynicki wrote:
W dniu 15.06.2011 00:04, Barry Warsaw pisze:
On Jun 14, 2011, at 05:53 PM, Zygmunt Krynicki wrote:
Can please we have standardized hooks to build sphinx documentation and run
setup.py test tests?
I'd
On Jul 01, 2011, at 09:23 AM, Christian Kastner wrote:
It's definitely preferable for an experienced packager, it can be
confusing as hell though to the commencing packager because in order to
understand dh syntax, you must first understand what debian/rules does,
ie the actual process of
On Jun 15, 2011, at 05:07 PM, Éric Araujo wrote:
Yes, last summer’s GSoC added a test command, which defaults to
unittest(2) test discovery and can be configured to use any test runner
on any test suite. It runs tests against the modules in the build
directory, to be able to work with code
On Jun 15, 2011, at 02:39 AM, Zygmunt Krynicki wrote:
I agree in the value but I don't want to assume that it is a default practice
or requirement. I package/hack on the webapp (django) side of tests and after
being spoiled with the goodness of python-testtools and python-testscenarios
I ventured
On Jun 30, 2011, at 08:20 AM, Ben Finney wrote:
Éric Araujo mer...@netwok.org writes:
Thanks to a new contributor agreement between Disney Enterprises and
the Python Software Foundation, the next versions of Python 2.6, 2.7,
3.1 and 3.2 as well as the first 3.3 release will be able to contain
Hi Piotr,
While converting the Oneiric version of gedit from pysupport to dhpy2 I
noticed something, which from reading the documentation and wiki page I'm not
sure is intended behavior. I wanted to check with you before I either submit
a bug report or update the wiki page.
Here's the relevant
There's a lot of similarity between these two wiki pages, and I often find
myself having to edit or open them both. I think it would make more sense to
combine them into one page.
http://wiki.debian.org/Python/PyCentral2DhPython2
http://wiki.debian.org/Python/PythonSupportToDHPython2
On Jun 28, 2011, at 10:23 AM, Piotr Ożarowski wrote:
[Barry Warsaw, 2011-06-28]
-dh_pysupport -pgedit /usr/lib/gedit/plugins
+dh_python2
+dh_python2 -pgedit /usr/lib/gedit/plugins
yes, that's intended behaviour
Awesome, thanks for the info.
-Barry
signature.asc
Description
On Jun 28, 2011, at 10:14 AM, Luca Falavigna wrote:
IIRC, at least python-support displays its transition page as part of
the deprecation message. In case we want to merge the two pages, we
should keep the old page names as redirect to the new ones.
Done.
The reorg is done now. I hope I've
On Jun 21, 2011, at 12:33 PM, Piotr Ożarowski wrote:
I can upload new python-support this weekend with one minor bug fixed
(the one fixed in svn) and a deprecation warning (with a link to
http://wiki.debian.org/Python/PythonSupportToDHPython2 and a note that
it's not a bad idea to wait with a
On Jun 21, 2011, at 12:33 PM, Piotr Ożarowski wrote:
I can upload new python-support this weekend with one minor bug fixed
(the one fixed in svn) and a deprecation warning (with a link to
http://wiki.debian.org/Python/PythonSupportToDHPython2 and a note that
it's not a bad idea to wait with a
On Jun 21, 2011, at 04:21 PM, Stefano Rivera wrote:
Well, everything usertagged python2.7 is an issue of some sort (and most
other debian-python usertags too), but they aren't blockers:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python2.7;users=debian-python@lists.debian.org
Thanks, I've
On Jun 14, 2011, at 12:02 AM, Piotr Ożarowski wrote:
it is fine and it is useful... as a submodule, not as a top-level module
Agreed! I think I get what you're driving at now. Some applications don't
put their Python code or tests in a package. In those cases, yes by all means
a private
On Jun 14, 2011, at 07:00 PM, Ben Finney wrote:
I think (as someone with no special authority on Python nor Debian) that
the people who know most detail about what's painful for packaging
Python software for Debian are burned out on the topic. They therefore
don't want to spend the effort to
On Jun 14, 2011, at 02:40 PM, Tshepang Lekhonkhobe wrote:
Have you guys looked at the new module, Packaging, in Python 3.3? Will
it solve all the problems that Debian Python packaging has, or is it
still lacking?
sidenote: the same tool will be available for earlier Python versions as
distutils2
501 - 600 of 752 matches
Mail list logo
