On Sep 08, 2011, at 11:37 PM, Piotr Ożarowski wrote:
>[Barry Warsaw, 2011-09-08]
>> >* build directory is not removed in clean target (and thus package
>> > cannot be build twice in a row)
>
>this one is fixed, but now I get changes in SOURCES.txt which
>includes.
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
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 woul
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: http://lists.d
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 lis
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 python-suppo
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.
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 worki
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 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
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
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 :
>
>http://anonscm.
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 re
On Nov 29, 2011, at 04:20 PM, Maciej Fijalkowski wrote:
>Bytecode format is an internal detail of a VM. For all I know it might
>completely disappear. CPython likes to change it's bytecode format
>every release and we usually follow changes, but we also have quite a
>few our own bytecodes. The thi
On Nov 29, 2011, at 02:19 PM, Matthias Klose wrote:
>On 11/29/2011 09:56 AM, Maciej Fijalkowski wrote:
>> For what is worth, the .py files (but not the .pyc files) can be
>> shared among pypy and cpython.
>
>IMO, patching pypy to lookup e.g. .pycp files before .pyc files would be
>appropriate for
On Nov 29, 2011, at 02:11 PM, Gustavo Niemeyer wrote:
>> I suppose it's not really that much work, but that would mean waiting
>> for another pypy release (which is probably 2-3 months away)
>
>The package may include a patch to enable that specifically, if necessary.
Right. We could cherrypick
On Dec 17, 2011, at 10:44 AM, Scott Kitterman wrote:
>The presumption behind the recommendation is that argparse provided as part
>of 2.7 makes python-argparse redundant/obsolete. I'm guessing from your
>comment that's not true?
It makes it largely unnecessary, but not incompatible (afaik).
-Ba
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
Hi Carlos,
As part of my work on Ubuntu, I have updated the feedparser package to include
a python3-feedparser binary package. Along the way, I also upgraded to
feedparser 5.1, and carried over our Ubuntu delta to use dh_python2. I also
updated the package to compat level 8, and simplified the r
I've had a few conversations about this between Scott and Jakub, but I think
it's worth opening up to all of debian-python.
Upstream, my flufl.* packages all have the following two lines at the top of
their setup.py files:
-snip snip-
import distribute_setup
distribute_setup.use_setuptool
On Jan 27, 2012, at 01:14 PM, Brian Sutherland wrote:
>Extra bonus points for getting PJE to change the DEFAULT_VERSION in
>setuptools trunk to something OK for most major distributions;)
Here's a thought:
What if we proposed a hook to get DEFAULT_VERSION from a file or environment
variable? Th
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 y
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
>&
On Jan 28, 2012, at 03:04 PM, Clint Byrum wrote:
>Can you recommend a good package to look at to implement this?
You can look at the flufl.enum (or any of the flufl.*) packages for this
(among others, I'm sure). I have enabled builds and tests for all supported
versions of Python, including both
On Jan 29, 2012, at 11:38 PM, Jakub Wilk wrote:
>* Barry Warsaw , 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
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:
>> >&g
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 upstre
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. Thi
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
On Feb 13, 2012, at 01:30 PM, Jakub Wilk wrote:
>* Barry Warsaw , 2012-02-07, 20:53:
>>http://wiki.debian.org/Python/LibraryStyleGuide
>
>* “The package […] should have a working setup.py or setup.cfg file” — err,
>* surely setup.cfg without setup.py is not enough.
It will be f
On Feb 24, 2012, at 12:24 PM, Jakub Wilk wrote:
>* Paul Wise , 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 lik
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 UNSUBSCR
On Mar 15, 2012, at 10:11 AM, Scott Kitterman wrote:
>Thomas Kluyver 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 use
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 tech-ct
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 chang
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. `ap
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-documen
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
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 resolut
On Apr 30, 2012, at 04:07 PM, Natalia Frydrych wrote:
>2012/4/29 Andrew Straw :
>> (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 programs tha
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 op
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 go
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 Stefan
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 w
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
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 cover
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
On May 04, 2012, at 07:16 PM, Thomas Kluyver wrote:
>On 4 May 2012 19:06, Dmitrijs Ledkovs 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
>setuptools
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 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
>SyntaxWar
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 th
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
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
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 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]
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 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
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 compla
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 ca
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 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
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:
https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/93
On Oct 25, 2012, at 07:05 PM, Jakub Wilk wrote:
>* Barry Warsaw , 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 r
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
On Oct 26, 2012, at 09:19 AM, Floris Bruynooghe wrote:
>On 25 October 2012 20:34, Piotr Ożarowski 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 gen
On Oct 26, 2012, at 12:33 PM, Jakub Wilk wrote:
>* Thomas Kluyver , 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 variables:
>
On Oct 27, 2012, at 06:53 PM, Jakub Wilk wrote:
>* Thomas Kluyver , 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 variables:
>
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.
http://anonscm.debian.
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 , 2012-11-09, 20:27:
>>http://anonscm.debian.org/viewvc/python-apps/packages/tox/trunk/
>
>I see some warnings in the build log:
&
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 hav
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
On Nov 13, 2012, at 02:25 AM, Jakub Wilk wrote:
>* Barry Warsaw , 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/ex
On Nov 14, 2012, at 11:46 AM, Thomas Kluyver wrote:
>On 14 November 2012 11:43, Jakub Wilk wrote:
>
>> I don't think so, sorry.
>
>Could you expand on this at all? Do you think that packaging should be left
>to the experts? Or that the existing systems are easy enough for newcomers
>to learn?
I
On Nov 14, 2012, at 11:44 AM, Thomas Kluyver wrote:
>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, setup.py checks the Python
>version and fails. Th
On Nov 14, 2012, at 02:14 PM, Jakub Wilk wrote:
>* Thomas Kluyver , 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, setup.p
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 pr
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 pr
On Nov 15, 2012, at 03:49 AM, Tristan Seligmann wrote:
>On Wed, Nov 14, 2012 at 5:42 PM, Tomás Di Domenico 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 Debian packaging.
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
>informat
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
Today in #debian-python we discussed bug #695707, which describes a breakage
in virtualenv with Python 2.7 in experimental due to multiarch. We explored a
few approaches for fixing this, centered around patching virtualenv itself,
but none of the solutions (including the one in PAPT svn :/ ) are e
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 exp
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
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 22, 2012, at 05:19 PM, Paul Tagliamonte wrote:
>Yeah, please don't use virtualenv, as much as I'd like to see a good way
>of using virtualenv in Debian.
Can you expand on that? It should be usable to develop code, but do you mean
something else?
Cheers,
-Barry
signature.asc
Description
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 t
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:
http://mail.python.org/pipermail/catalog-sig/2013-Februa
On Feb 06, 2013, at 04:12 PM, Thomas Kluyver wrote:
>I suggest that we encourage packagers to make team maintainership the norm,
>and individual maintainership the exception, to avoid this kind of problem.
>This is in line with plenty of other open source projects, where people
>talk about not bec
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_prox
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 li
On Feb 11, 2013, at 03:51 PM, Piotr Ożarowski wrote:
>[Jakub Wilk, 2013-02-11]
>> Great, so it's not too late to rename them to comply with Python
>> Policy §2.2:
>>
>> python3-imaging -> python3-pil
>> python3-imaging-tk -> python3-pil.imagetk
>> python3-imaging-sane -> python3-sane
>
>+1
>
>I'd
On Feb 10, 2013, at 06:14 PM, Jakub Wilk wrote:
>* Matthias Klose , 2013-02-10, 17:54:
>>Fixes should be easy and made in a way that works with both the old PIL
>>>modules and the new Pillow egg/package:
>>
>> import Image
>>
>>should become
>>
>> try:
>>from PIL import Image
>> except Imp
On Feb 11, 2013, at 05:05 PM, Piotr Ożarowski wrote:
>how about replacing python-imaging with python-pil in all packages that
>do not need compat code (anymore) - this way all packages that are still
>"broken" will have python-imaging as a dependency
+1
One minor question, should it be python{,3
On Feb 11, 2013, at 10:14 PM, Matthias Klose wrote:
>probably, because the egg is called pillow. However introducing the pillow
>name for the fork, which may be not permanent, doesn't sound like a good idea
>(the current packages do provide the pillow names). I'll stick to the
>original names for
On Feb 12, 2013, at 12:49 AM, Dmitrijs Ledkovs wrote:
>> Debian HPIJS and HPLIP maintainers
>>hplip
>>
>> Matthias Klose
>>python-reportlab
>>
>Does this mean that hplip & python-reportlab are now have all their
>dependenices ported to python3 and hence can also be ported? \o/
I *think*
On Feb 15, 2013, at 01:25 AM, Thomas Goirand wrote:
>All this is very far from being *forbidden* to send packages to the
>python module team using Git and maintain them this way.
Of the three main dvcs's, I personally dislike git the most, but I'm resigned
to the fact that it's essentially won th
On Feb 14, 2013, at 08:54 PM, Thomas Kluyver wrote:
>I don't think it's a particularly good example, though. Lots of packages
>continue to use the older helpers, and not due to a lack of time - attempts
>to move away from the deprecated helpers still seem to meet considerable
>resistance. That cau
On Feb 16, 2013, at 05:10 PM, Thomas Goirand wrote:
>3) Upstream uses Git, and I have already lots of git things inside my
>package and workflow (I already explained, I have no choice at all),
>plus I know there's others willing to use Git, and not having the
>possibility to do team work with them
On Feb 16, 2013, at 05:51 PM, Scott Kitterman wrote:
>You'd also have to get some consensus around full source or debian directory
>only branches. I don't think we can split on that either.
Agreed!
>Personally, I've found nothing but frustration from trying to manage both
>Debian packaging and
201 - 300 of 859 matches
Mail list logo
