On 08.09.2010 13:48, Neil McGovern wrote:
On Mon, Sep 06, 2010 at 10:54:45PM +0200, Piotr Ożarowski wrote:
[Adam D. Barratt, 2010-09-06]
So upstream have verified the result of 2to3 on their software?
yes
On a related note, will the build system allow for the result of 2to3 to
be easily
On Thu, Sep 09, 2010 at 11:25:30AM +0200, Matthias Klose wrote:
Sometimes 2to3 will find a place in your source code that needs to be
changed, but 2to3 cannot fix automatically. In this case, 2to3 will
print a warning beneath the diff for a file. You should address the
warning in order to have
On Thu, Sep 09, 2010 at 03:54:56PM +0100, Neil McGovern wrote:
On Thu, Sep 09, 2010 at 11:25:30AM +0200, Matthias Klose wrote:
Sometimes 2to3 will find a place in your source code that needs to be
changed, but 2to3 cannot fix automatically. In this case, 2to3 will
print a warning beneath
On 09.09.2010 16:54, Neil McGovern wrote:
On Thu, Sep 09, 2010 at 11:25:30AM +0200, Matthias Klose wrote:
Sometimes 2to3 will find a place in your source code that needs to be
changed, but 2to3 cannot fix automatically. In this case, 2to3 will
print a warning beneath the diff for a file. You
On Thu, Sep 09, 2010 at 05:53:59PM +0200, Moritz Muehlenhoff wrote:
On Thu, Sep 09, 2010 at 03:54:56PM +0100, Neil McGovern wrote:
On Thu, Sep 09, 2010 at 11:25:30AM +0200, Matthias Klose wrote:
Sometimes 2to3 will find a place in your source code that needs to be
changed, but 2to3 cannot
On Thu, Sep 09, 2010 at 06:43:42PM +0200, Matthias Klose wrote:
The upstream policy for the python branches is to fix documentation
and bugs, not to introduce new features or change semantics of
existing features. lib2to3 does evolve in in the py3k branch only.
Plus, the 2.6 now only sees
On Mon, Sep 06, 2010 at 10:54:45PM +0200, Piotr Ożarowski wrote:
[Adam D. Barratt, 2010-09-06]
So upstream have verified the result of 2to3 on their software?
yes
On a related note, will the build system allow for the result of 2to3 to
be easily overridden? For example, if whilst
[Neil McGovern, 2010-09-08]
I'm slightly worried by:
Sometimes 2to3 will find a place in your source code that needs to be
changed, but 2to3 cannot fix automatically. In this case, 2to3 will
print a warning beneath the diff for a file. You should address the
warning in order to have compliant
On Fri, 2010-09-03 at 20:50 +0200, Piotr Ożarowski wrote:
[Adam D. Barratt, 2010-09-03]
On Sat, 2010-08-21 at 00:44 +0200, Piotr Ożarowski wrote:
We plan to upload such NEW versions of Squeeze packages to experimental²
(one of ftp-team members, who is a member of our team, will help us
[Adam D. Barratt, 2010-09-06]
So upstream have verified the result of 2to3 on their software?
yes
On a related note, will the build system allow for the result of 2to3 to
be easily overridden? For example, if whilst building an update the
security team discover that there's a problem with
On Sat, 2010-08-21 at 00:44 +0200, Piotr Ożarowski wrote:
Squeeze will support Python 3.1 as the first Python 3.X version in
Debian. Unfortunately, we didn't have much time to start preparing
packages with 3rd party modules/extensions for Python 3.X (python2.6
transition was completed not
[Adam D. Barratt, 2010-09-03]
On Sat, 2010-08-21 at 00:44 +0200, Piotr Ożarowski wrote:
We plan to upload such NEW versions of Squeeze packages to experimental²
(one of ftp-team members, who is a member of our team, will help us with
that), test it there and if everything will be ok -
* Piotr Ożarowski (pi...@debian.org) [100821 00:45]:
Please note that in most (all?) cases 2to3 tool (which converts
python2.X code to python3.X one) will have to be used (again, no new
upstream versions) so patching the code in Squeeze (security bugs, etc.)
will not have to be done twice (at
Hi Release Team,
[I asked you about this issue at DebConf10 and was told to ask via
e-mail again, hence my mail]
Squeeze will support Python 3.1 as the first Python 3.X version in
Debian. Unfortunately, we didn't have much time to start preparing
packages with 3rd party modules/extensions for
14 matches
Mail list logo
