I just verified with our ActivePython build that 2.6.4rc2 builds fine on Linux,
Windows, Mac, HP-UX, AIX and Solaris. 3.1.2rc1 builds fine except on AIX[1] and
HP-UX[2] but those issues existed in 3.1.1 too, I believe.
-srid
[1] http://bugs.python.org/issue6645
[2] http://bugs.python.org/issue5
Hi everyone,
The source tarballs and Windows installer for Python 2.6.5 release candidate 2
are now available:
http://www.python.org/download/releases/2.6.5/
As usual, please download, install, and test them with your favorite projects
and environments. A number of regressions and build problem
Hi Python hackateers!
It looks like we finally have no more release blockers for 2.6.5rc2. I would
like to tag the tree tonight for rc2 so that Martin can build the Windows
installer for a release tomorrow. I am also moving the final release back to
Friday March 19.
-Barry
signature.asc
Descr
We are definitely going to need a 2.6.5 rc 2. We've had a number of critical
issues fixed since rc1 and we have two more critical patches approved for
landing which fix issues on OS X. I've given Ronald approval in the tracker
to land these two patches.
8066 OS X installer: readline module break
Hello everyone,
The source tarballs and Windows installer for Python 2.6.5 release candidate 1
are now available:
http://www.python.org/download/releases/2.6.5/
Please download them, install them, and try to use them with your favorite
projects and environments. If no regressions are found, we
Hello everybody! I hope you all had as great a time at Pycon 2010 as I did.
No time to begin recovering though, we're on to Python 2.6.5 rc 1, which I
would like to release on Monday. We have one showstopper still open, and I'll
try to respond to that asap.
http://bugs.python.org/issue7250
Le Thu, 11 Feb 2010 10:36:22 -0500, Barry Warsaw a écrit :
>
> Unless other details come to light, I agree. This one isn't worth
> holding up the release for.
Ok, since everyone seems to agree on this, I've downgraded the priority
of the issue. Thanks for an insightful discussion :-)
cheers
A
On Feb 11, 2010, at 10:05 PM, Nick Coghlan wrote:
>When I've kicked issues in the RM's direction for a decision, I've
>generally tried to make sure my last comment makes it clear exactly what
>decision I'm asking them to make.
Yes, this is an *excellent* point!
-Barry
signature.asc
Description
On Feb 10, 2010, at 11:46 PM, Martin v. Löwis wrote:
>That would require that Barry actually *can* judge the issue at hand. In
>the specific case, I would expect that Barry would defer the specifics
>of the Windows issue to Windows experts, and then listen to what they
>say.
Yep, absolutely.
>I'
Martin v. Löwis wrote:
>> If a committer or triage
>> person sets an issue to release blocker it should mean that they think
>> the release manager should make a decision about that issue before the
>> next release. That decision may well be that it shouldn't be a blocker.
>
> I think it's (sligh
Antoine Pitrou wrote:
> As for setting keywords, there doesn't seem to be much you could have an
> authority to decide as a non-committer. You might think (and perhaps with good
> reason) that the patch is ready for commit into the SVN, but it's precisely a
> committer's job to decide that.
There
> If a committer or triage
> person sets an issue to release blocker it should mean that they think
> the release manager should make a decision about that issue before the
> next release. That decision may well be that it shouldn't be a blocker.
I think it's (slightly) worse. For the release man
On Wed, 10 Feb 2010 13:57:31 +0200, anatoly techtonik
wrote:
> On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou wrote:
> >
> > Besides, as Barry said, classifying a bug as blocker is also a good way
> > to attract some attention on it. Other classifications, even "critical",
> > don't have the sa
On Tue, Feb 9, 2010 at 21:24, Barry Warsaw wrote:
> On Feb 9, 2010, at 4:55 PM, Martin v. Löwis wrote:
>
>>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this
one - http://bugs.python.org/issue6608 Is i
On Feb 10, 2010, at 01:57 PM, anatoly techtonik wrote:
>Unfortunately, not many people have privilege to change bug properties
>to attract attention to the issues. For example, this patch -
>http://bugs.python.org/issue7582 is ready to be committed, it is
>trivial, not a release blocker, but would
anatoly techtonik writes:
> Is it possible to make exploits out of crashers?
Depends on how you define "exploit". If your definition includes
denial of service, yes, crashing a server application would count.
Privilege escalation is harder to achieve. The general answer is
"yes", but each cas
Antoine Pitrou writes:
> Besides, as Barry said, classifying a bug as blocker is also a good way
> to attract some attention on it. Other classifications, even "critical",
> don't have the same effect.
If done for the sole purpose of attracting attention, it's no
different from spam. Opinions
anatoly techtonik gmail.com> writes:
>
> Unfortunately, not many people have privilege to change bug properties
> to attract attention to the issues. For example, this patch -
> http://bugs.python.org/issue7582 is ready to be committed, it is
> trivial, not a release blocker, but would be nice be
On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou wrote:
>
> Besides, as Barry said, classifying a bug as blocker is also a good way
> to attract some attention on it. Other classifications, even "critical",
> don't have the same effect.
Unfortunately, not many people have privilege to change bug p
Le mercredi 10 février 2010 à 05:26 +0100, "Martin v. Löwis" a écrit :
>
> Maybe I'm being pedantic, but I really think there should be more
> objective criteria for such things.
Well we could try to find objective criteria but I'm not sure we'll find
agreement on them.
> We could set a policy
anatoly techtonik gmail.com> writes:
>
> Is it possible to make exploits out of crashers?
It depends which ones. If it's something like a buffer overflow or a memory
management problem, it may be possible to exploit it through carefully crafted
input (in order to make the interpreter execute arb
> On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" wrote:
>>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this
one - http://bugs.python.org/issue6608 Is it ok to release new versions
that are kn
On Feb 9, 2010, at 9:54 PM, anatoly techtonik wrote:
>
> Is it possible to make exploits out of crashers?
The crashers involve creating convoluted python code,
but then if you're in a position to execute arbitrary
Python code, then you don't have to resort to any
tricks to do something nasty wit
On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" wrote:
>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>>> one - http://bugs.python.org/issue6608 Is it ok to release new versions
>>> that are known to
On Feb 9, 2010, at 5:20 PM, Martin v. Löwis wrote:
> Of course, the release manager can always declare anything a release
> blocker, so that may have been the reason (I don't recall the details).
I should probably clarify my last statement. I will sometimes mark an issue
"release blocker" becau
On Feb 9, 2010, at 4:55 PM, Martin v. Löwis wrote:
>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>>> one - http://bugs.python.org/issue6608 Is it ok to release new versions
>>> that are known to crash?
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> IOW, I feel that release blockers should only be used if something
>> really bad would happen that can be prevented by not releasing. If
>> nothing actually gets worse by the release, the release shouldn't be
>> blocked.
>
> I think
Martin v. Löwis v.loewis.de> writes:
>
> IOW, I feel that release blockers should only be used if something
> really bad would happen that can be prevented by not releasing. If
> nothing actually gets worse by the release, the release shouldn't be
> blocked.
I think most blocking bugs we've had
>>> I've changed this issue to release blocker. What are the other issues?
>> For a bug fix release, it should (IMO) be a release blocker *only* if
>> this is a regression in the branch or some recent bug fix release over
>> some earlier bug fix release.
>
> As far as I remember, I think we have h
Le mardi 09 février 2010 à 22:55 +0100, "Martin v. Löwis" a écrit :
> > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
> >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> >> one - http://bugs.python.org/issue6608 Is it ok to release new versions
> >> that
> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>> one - http://bugs.python.org/issue6608 Is it ok to release new versions
>> that are known to crash?
>
> I've changed this issue to release blocker. What a
> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> one - http://bugs.python.org/issue6608 Is it ok to release new
> versions that are known to crash?
As a general principle: yes, that's ok. We even distribute known
crashers with every release.
Regards,
Martin
___
On Tue, Feb 9, 2010 at 06:45, anatoly techtonik wrote:
> On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou
> wrote:
> > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
> >>
> >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> >> one - http://bugs.python.org
On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou wrote:
> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>
>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>> one - http://bugs.python.org/issue6608 Is it ok to release new versions
>> that are known to cra
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>
> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> one - http://bugs.python.org/issue6608 Is it ok to release new versions
> that are known to crash?
I've changed this issue to release blocker. What are the
On Tue, Feb 2, 2010 at 8:08 PM, Barry Warsaw wrote:
> I'm thinking about doing a Python 2.6.5 release soon. I've added the
> following dates to the Python release schedule Google calendar:
>
> 2009-03-01 Python 2.6.5 rc 1
> 2009-03-15 Python 2.6.5 final
>
> This allows us to spend some time on 2.
On Feb 4, 2010, at 4:59 AM, Barry Warsaw wrote:
> I still think this should go in 2.6.5. The patch does not apply to the
> current 2.6 branch because of changes in setup.py. If the patch is ported,
> reviewed and works with no regressions (when libreadline is both installed on
> OS X 10.5 and
On Feb 03, 2010, at 11:50 PM, Ronald Oussoren wrote:
>> Barry's answer was "yes" back in October.
>
>I will backport the patch if Barry says it's fine. Feel free to ping me if
>that doesn't happen before the end of next week.
I still think this should go in 2.6.5. The patch does not apply to th
On 3 Feb, 2010, at 21:27, Zvezdan Petkovic wrote:
> On Feb 3, 2010, at 3:07 PM, Martin v. Löwis wrote:
>
>>> This patch is still waiting a review and backporting from trunk.
>>>
>>> http://mail.python.org/pipermail/python-dev/2009-October/092771.html
>>>
>>> Can we get it in?
>>
>> Only if on
On Feb 3, 2010, at 3:07 PM, Martin v. Löwis wrote:
>> This patch is still waiting a review and backporting from trunk.
>>
>> http://mail.python.org/pipermail/python-dev/2009-October/092771.html
>>
>> Can we get it in?
>
> Only if one of the Mac people checks it in.
It's already checked in the
> This patch is still waiting a review and backporting from trunk.
>
> http://mail.python.org/pipermail/python-dev/2009-October/092771.html
>
> Can we get it in?
Only if one of the Mac people checks it in. As they are *REALLY* scarce,
the answer is probably "no".
I'd offer a special version of
On Feb 2, 2010, at 1:08 PM, Barry Warsaw wrote:
> I'm thinking about doing a Python 2.6.5 release soon. I've added the
> following dates to the Python release schedule Google calendar:
>
> 2009-03-01 Python 2.6.5 rc 1
> 2009-03-15 Python 2.6.5 final
>
> This allows us to spend some time on 2.6.
+1
On Feb 2, 2010, at 10:08 AM, Barry Warsaw wrote:
> I'm thinking about doing a Python 2.6.5 release soon. I've added the
> following dates to the Python release schedule Google calendar:
>
> 2009-03-01 Python 2.6.5 rc 1
> 2009-03-15 Python 2.6.5 final
>
> This allows us to spend some time on
I'm thinking about doing a Python 2.6.5 release soon. I've added the
following dates to the Python release schedule Google calendar:
2009-03-01 Python 2.6.5 rc 1
2009-03-15 Python 2.6.5 final
This allows us to spend some time on 2.6.5 at Pycon if we want. Please let me
know if you have any conc
44 matches
Mail list logo
