Hi Scott,
thanks for bringing this up (again :) ).
On Wed, Jun 30, 2010 at 22:41, Scott Kitterman wrote:
> As I had said I would after the last round, I asked the release team about any
> specific requirements they might have for Python version specification. They
> don't. My summary of the thr
"Scott Kitterman" wrote:
>As I had said I would after the last round, I asked the release team about any
>specific requirements they might have for Python version specification. They
>don't. My summary of the thread is "We want it to be easy". The thread
>starts here for those interested:
On Jun 30, 2010, at 06:02 PM, Scott Kitterman wrote:
>I don't want to break a lot of packages. Both implicit and explicit
>all are widely used in Python packages. I think we have more freedom
>to do the "right" thing for Python 3.
That's what I expected (i.e. "cleans up a wart"). +1
Thanks,
-Ba
"Barry Warsaw" wrote:
>On Jun 30, 2010, at 04:58 PM, Scott Kitterman wrote:
>
>>On Wednesday, June 30, 2010 04:51:38 pm Piotr Ożarowski wrote:
>>> [Scott Kitterman, 2010-06-30]
>>>
>>> > For Python3:
>>> >
>>> > 1. A new field called X-Python3-Version: It does not support lists of
>>> > ver
On Jun 30, 2010, at 04:58 PM, Scott Kitterman wrote:
>On Wednesday, June 30, 2010 04:51:38 pm Piotr Ożarowski wrote:
>> [Scott Kitterman, 2010-06-30]
>>
>> > For Python3:
>> >
>> > 1. A new field called X-Python3-Version: It does not support lists of
>> > versions (e.g. (3.0, 3.1)). Acceptabl
On Wednesday, June 30, 2010 04:51:38 pm Piotr Ożarowski wrote:
> [Scott Kitterman, 2010-06-30]
>
> > For Python3:
> >
> > 1. A new field called X-Python3-Version: It does not support lists of
> > versions (e.g. (3.0, 3.1)). Acceptable values are a single version (e.g
> > 3.1), greater than or
[Scott Kitterman, 2010-06-30]
> For Python3:
>
> 1. A new field called X-Python3-Version: It does not support lists of
> versions (e.g. (3.0, 3.1)). Acceptable values are a single version (e.g
> 3.1),
> greater than or equal to a version (e.g. >= 3.1), or strictly less than a
> version (e.g
As I had said I would after the last round, I asked the release team about any
specific requirements they might have for Python version specification. They
don't. My summary of the thread is "We want it to be easy". The thread
starts here for those interested:
http://lists.debian.org/debian-
Dear Debian Python Maintainers Team,
I am looking for a sponsor for my package "python-libgearman".
* Package name: python-libgearman
Version : 0.13.2-1
Upstream Author : Monty Taylor
* URL : http://pypi.python.org/pypi/python-libgearman/
* License : BSD
Sec
Hello DPMT...
I'm Clint, I work for Canonical, and I want to help! :)
I am interested in joining the DPMT, in part to improve python module
support for server applications in Debian and Ubuntu. Specifically I'd
like to start by helping to facilitate the upload and maintenance of
python-libgearma
Hi,
I made a tentative package for psycopg2 2.2.1, (I just copied 2.0.14-1
debian directory) and ran it throught pbuilder.
http://playground.mekensleep.com/~proppy/psycopg2_2.2.1-1.dsc
Feel free to tell me if it needs additional love in order to be
uploaded to debian unstable.
--
Johan Euphrosi
Hi Bernd and Yaroslav, hi again debian-python,
So, if I summarize:
Bernd Zeimetz wrote:
> On 06/28/2010 04:34 PM, Yaroslav Halchenko wrote:
>> AFAIK:
>>
>> - regular python build symbols files are useful for anyone willing to
>> troubleshoot the problem which is not too complicated and he wou
On 06/28/2010 04:34 PM, Yaroslav Halchenko wrote:
> AFAIK:
>
> - regular python build symbols files are useful for anyone willing to
> troubleshoot the problem which is not too complicated and he wouldn't
> need to explore the state of Python at the troublesome moment.
>
> - _d* files for pyt
13 matches
Mail list logo
