Ned Deily wrote:
> In article <87zkmcalt8@uwakimon.sk.tsukuba.ac.jp>,
> "Stephen J. Turnbull" wrote:
> > Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the
> > bots update? If so, I'm impressed, and "thank you!" to all involved.
> > Apple and MacPorts have long since wash
On 5/24/2011 6:27 AM, Nick Coghlan wrote:
On Tue, May 24, 2011 at 7:56 PM, Antoine Pitrou wrote:
Thank you very much! What a beautiful sight this is:
http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable
(until a sporadic failure comes up, that is)
I could turn test_crashers b
On Tue, May 24, 2011 at 7:56 PM, Antoine Pitrou wrote:
> Thank you very much! What a beautiful sight this is:
> http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable
>
> (until a sporadic failure comes up, that is)
I could turn test_crashers back on if you like ;)
Great work to al
On Mon, 23 May 2011 19:16:36 +0200
Tarek Ziadé wrote:
>
> I have now completed the cleanup and we're back on green-land for the
> stable bots.
>
> The red slaves should get green when they catch up with the latest rev
> (they are slow). If they're not and they are failing in packaging or
> sysco
In article <87zkmcalt8@uwakimon.sk.tsukuba.ac.jp>,
"Stephen J. Turnbull" wrote:
> Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the
> bots update? If so, I'm impressed, and "thank you!" to all involved.
> Apple and MacPorts have long since washed their hands of that releas
On Tue, 24 May 2011 11:12:35 +0900, "Stephen J. Turnbull"
wrote:
> Tarek Ziadé writes:
>
> > I have now completed the cleanup and we're back on green-land for the
> > stable bots.
>
> Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the
> bots update? If so, I'm impressed, a
Tarek Ziadé writes:
> I have now completed the cleanup and we're back on green-land for the
> stable bots.
Are you saying you expect Mac OS X 10.4 "Tiger" to go green once the
bots update? If so, I'm impressed, and "thank you!" to all involved.
Apple and MacPorts have long since washed their h
On Mon, May 23, 2011 at 8:48 AM, Tarek Ziadé wrote:
> On Mon, May 23, 2011 at 3:00 AM, Bill Janssen wrote:
>> Tarek Ziadé wrote:
>>
>>> Yes, I am aware of this. I have fixed today most remaining issues, and
>>> fixing the final ones right now.
>>
>> Just FYI: the "AMD64 Snow Leopard" buildbot a
On Mon, May 23, 2011 at 3:00 AM, Bill Janssen wrote:
> Tarek Ziadé wrote:
>
>> Yes, I am aware of this. I have fixed today most remaining issues, and
>> fixing the final ones right now.
>
> Just FYI: the "AMD64 Snow Leopard" buildbot and "PPC Leopard" buildbots
> are now green, but the "PPC Tige
Tarek Ziadé wrote:
> Yes, I am aware of this. I have fixed today most remaining issues, and
> fixing the final ones right now.
Just FYI: the "AMD64 Snow Leopard" buildbot and "PPC Leopard" buildbots
are now green, but the "PPC Tiger" buildbot is still failing for all
branches because of packagi
On Sat, May 21, 2011 at 4:37 PM, Antoine Pitrou wrote:
>
> Hello,
>
> We recently got a couple of new stable buildbots:
> - R. David Murray's "x86 Gentoo" machine, which builds in non-debug
> mode and therefore checks that release Pythons work fine
> - Stefan Krah's "AMD64 FreeBSD 8.2" machine
>
Hello,
We recently got a couple of new stable buildbots:
- R. David Murray's "x86 Gentoo" machine, which builds in non-debug
mode and therefore checks that release Pythons work fine
- Stefan Krah's "AMD64 FreeBSD 8.2" machine
- Bill Janssen's "AMD64 Snow Leopard" machine
Many stable buildbots
On 30 January 2011 20:50, David Bolen wrote:
> I haven't been able to - as you say there's no good way to hook into
> the build process in real time as the changes have to be external or
> they'll get zapped on the next checkout. I suppose you could rapidly
> try to monitor the output of the buil
Hello,
> I'm pretty sure the best long term fix is to move the kill processing
> into the clean script (as per issue 9973) rather than where it
> currently is in the build script, but so far I don't think the idea
> has been able to attract the interest of anyone who can actually
> commit such a
Paul Moore writes:
> Presumably, you're inserting a pskill command somewhere into the
> actual build process. I don't know much about buildbot, but I thought
> that was controlled by the master and/or the Python build scripts,
> neither of which I can change.
>
> If I want to add a pskill command
On 23 November 2010 23:18, David Bolen wrote:
> Trent Nelson writes:
>
>> That's interesting. (That kill_python.exe doesn't kill the wedged
>> processes, but pskill does.) kill_python is pretty simple, it just
>> calls TerminateProcess() after acquiring a handle with the relevant
>> PROCESS_TER
Trent Nelson writes:
> That's interesting. (That kill_python.exe doesn't kill the wedged
> processes, but pskill does.) kill_python is pretty simple, it just
> calls TerminateProcess() after acquiring a handle with the relevant
> PROCESS_TERMINATE access right. (...)
>
> Are you calling pskill
On 14-Nov-10 3:48 AM, David Bolen wrote:
This is a completely separate issue, though probably around just as
long, and like the popup problem its frequency changes over time. By
"hung" here I'm referring to cases where something must go wrong with
a test and/or its cleanup such that a python_d p
Ned Deily wrote:
> In article <30929.1289879...@parc.com>, Bill Janssen
> wrote:
>
> > Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
> > Looking at the changes since the last success, I can't see anything
> > which would obviously affect that... Any suspects?
>
> It app
In article <30929.1289879...@parc.com>, Bill Janssen
wrote:
> Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
> Looking at the changes since the last success, I can't see anything
> which would obviously affect that... Any suspects?
It appears to be a duplicate of Issue8458
Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
Looking at the changes since the last success, I can't see anything
which would obviously affect that... Any suspects?
Here's what's failing:
==
ERROR: test_run
Brian Curtin writes:
> Is the dialog closer script available somewhere? I'm guessing this is the
> same script that closes the window which pops up during test_capi's crash?
Not sure about that specific test, as I won't normally see the windows.
If the failure is causing a C RTL pop-up, then ye
On Sun, Nov 14, 2010 at 02:48, David Bolen wrote:
> Nick Coghlan writes:
>
> > Do we have any idea why the workaround to avoid the popup windows
> > stopped working? (assuming it ever worked reliably - I thought it did,
> > but that impression may have been incorrect)
>
> Oh, the pop-up handling
Paul Moore writes:
> Do you run your slave as a service? (And for that matter, what do
> other Windows slave owners do?) Are there any "best practices" for
> ongoing admin of a Windows buildslave that might be worth collecting
> together? (I'll try to put some notes on what I've found together -
On 14 November 2010 02:40, David Bolen wrote:
> There's been a bit of an uptick in the past few weeks with hung
> python_d processes (not a new issue, but it ebbs and flows), so I'm
> going to try to pull together a monitor script this weekend to start
> killing them off automatically. Should at
"Martin v. Löwis" writes:
> This is what kill_python.exe is supposed to solve. So I recommend to
> investigate why it fails to kill the hanging Pythons.
Yeah, I know, and I can't say I disagree in principle - not sure why
Windows doesn't let the kill in that module work (or if there's an
issue a
> This is a completely separate issue, though probably around just as
> long, and like the popup problem its frequency changes over time. By
> "hung" here I'm referring to cases where something must go wrong with
> a test and/or its cleanup such that a python_d process remains
> running, usually s
Nick Coghlan writes:
> Do we have any idea why the workaround to avoid the popup windows
> stopped working? (assuming it ever worked reliably - I thought it did,
> but that impression may have been incorrect)
Oh, the pop-up handling for the RTL dialogs still seems to be working
fine (at least I
On Sun, Nov 14, 2010 at 12:40 PM, David Bolen wrote:
> Antoine Pitrou writes:
>
>> (even though the Windows buildbots give
>> a rather unconventional meaning to the word "stability").
>
> Nag, nag, nag :-)
>
> There's been a bit of an uptick in the past few weeks with hung
> python_d process
Antoine Pitrou writes:
> (even though the Windows buildbots give
> a rather unconventional meaning to the word "stability").
Nag, nag, nag :-)
There's been a bit of an uptick in the past few weeks with hung
python_d processes (not a new issue, but it ebbs and flows), so I'm
going to try to
Hi,
Just to let you know that we now have 8 stable buildbots, including
Barry's own PPC Ubuntu machine (even though the Windows buildbots give
a rather unconventional meaning to the word "stability").
Right now they are mostly green:
http://www.python.org/dev/buildbot/all/waterfall?category=3.x.
On Wed, Mar 26, 2008 at 9:04 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> On Mar 26, 2008, at 8:14 AM, Facundo Batista wrote:
> > 2008/3/26, Neal Norwitz <[EMAIL PROTECTED]>:
> >
> >> We need to get the tests for Python to be more stable s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2008, at 8:14 AM, Facundo Batista wrote:
> 2008/3/26, Neal Norwitz <[EMAIL PROTECTED]>:
>
>> We need to get the tests for Python to be more stable so we can push
>> out solid releases. In order to achieve this result, we need tests
>> that
2008/3/26, Neal Norwitz <[EMAIL PROTECTED]>:
> We need to get the tests for Python to be more stable so we can push
> out solid releases. In order to achieve this result, we need tests
> that are *100% reliable* and fail _only when there is a problem with
+1
> Python_. While we aren't near
We need to get the tests for Python to be more stable so we can push
out solid releases. In order to achieve this result, we need tests
that are *100% reliable* and fail _only when there is a problem with
Python_. While we aren't nearly as close to that goal as we need to
be, we have to work towa
35 matches
Mail list logo
