Hello,
We only have a x86 Tiger OS X buildbot left. People wanting to see OS X
supported may decide to maintain a buildbot that will help us avoid
regressions.
See http://wiki.python.org/moin/BuildBot
Regards
Antoine.
___
Python-Dev mailing list
Py
Antoine Pitrou writes:
> Well, the reason it can't qualify for the stable list right now is that
> there's a recurrent test_logging failure on it:
> http://bugs.python.org/issue14644
Yeah, I don't know that I'm necessarily suggesting it be in the stable
set as just mentioning that there is at le
On Sat, 21 Apr 2012 15:50:03 -0400
David Bolen wrote:
> Antoine Pitrou writes:
>
> > For the record, we don't have any stable OS X buildbots anymore.
> > If you want to contribute a build slave (I hear we may have Apple
> > employees reading this list), please take a look at
> > http://wiki.pyth
Antoine Pitrou writes:
> For the record, we don't have any stable OS X buildbots anymore.
> If you want to contribute a build slave (I hear we may have Apple
> employees reading this list), please take a look at
> http://wiki.python.org/moin/BuildBot
I realize it may not qualify for the official
Antoine Pitrou wrote:
> For the record, we don't have any stable OS X buildbots anymore.
Sigh. That's me again. We are currently installing a virtual private
cloud at our workspace, and I'm seeing a lot of intermittent failures in
that server room. I need to work out a way in which buildbot r
Hello,
For the record, we don't have any stable OS X buildbots anymore.
If you want to contribute a build slave (I hear we may have Apple
employees reading this list), please take a look at
http://wiki.python.org/moin/BuildBot
Regards
Antoine.
___
P
[Barry Warsaw]
> As an aside, I wonder if it would make sense to create an Ubuntu/Debian
> package that essentially just depended on all those -dev packages. That way
> you could install this python-uber-dev package and get everything you needed
> to build a sumo Python.
I don’t know. Any Debian
Brett Cannon wrote:
> On Wed, Jun 30, 2010 at 15:01, "Martin v. Löwis"
> wrote:
When Tim Peters added it, he wanted it to tell him whether he
did the Windows build correctly, INCLUDING ALL OPTIONAL
PACKAGES that can possibly work on Windows. If you try to
generalize this beyond
On Wed, Jun 30, 2010 at 15:20, Nick Coghlan wrote:
> On Thu, Jul 1, 2010 at 7:55 AM, Brett Cannon wrote:
>> So it isn't that it's "unexpected", it's that a dependency is missing.
>> So it seems the terminology needs to get tweaked.
>
> More that the phrase "expected skip" isn't clearly defined an
On Jul 01, 2010, at 07:52 AM, Nick Coghlan wrote:
>Note that it works this way on Linux as well. On Kubuntu (for example)
>you need another half dozen or so additional *-dev packages installed
>to avoid unexpected test skips.
>
>Cheers,
>Nick.
>
>P.S. For anyone curious, I posted the list of extra
On Thu, Jul 1, 2010 at 7:55 AM, Brett Cannon wrote:
> So it isn't that it's "unexpected", it's that a dependency is missing.
> So it seems the terminology needs to get tweaked.
More that the phrase "expected skip" isn't clearly defined and people
sometimes guess wrong as to what it means. As Mart
On Wed, Jun 30, 2010 at 15:01, "Martin v. Löwis" wrote:
>>> When Tim Peters added it, he wanted it to tell him whether he did the
>>> Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
>>> possibly work on Windows. If you try to generalize this beyond Windows,
>>> then the only skip
>> When Tim Peters added it, he wanted it to tell him whether he did the
>> Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
>> possibly work on Windows. If you try to generalize this beyond Windows,
>> then the only skips that are expected are the ones for tests that
>> absolutely
On Wed, Jun 30, 2010 at 14:52, Nick Coghlan wrote:
> On Thu, Jul 1, 2010 at 5:53 AM, "Martin v. Löwis" wrote:
>> When Tim Peters added it, he wanted it to tell him whether he did the
>> Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
>> possibly work on Windows. If you try to ge
On Thu, Jul 1, 2010 at 5:53 AM, "Martin v. Löwis" wrote:
> When Tim Peters added it, he wanted it to tell him whether he did the
> Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
> possibly work on Windows. If you try to generalize this beyond Windows,
> then the only skips that
On Wed, Jun 30, 2010 at 12:53, "Martin v. Löwis" wrote:
>> The whole "unexpected" skipping is somewhat of a mess. In an ideal
>> situation modules that are optionally built should be allowed to skip,
>
> While this may be the wide-spread interpretation, it is definitely *not*
> the original intent
Martin v. Löwis wrote:
> > The whole "unexpected" skipping is somewhat of a mess. In an ideal
> > situation modules that are optionally built should be allowed to skip,
>
> While this may be the wide-spread interpretation, it is definitely *not*
> the original intention of the feature.
>
> When
> The whole "unexpected" skipping is somewhat of a mess. In an ideal
> situation modules that are optionally built should be allowed to skip,
While this may be the wide-spread interpretation, it is definitely *not*
the original intention of the feature.
When Tim Peters added it, he wanted it to t
On Wed, Jun 30, 2010 at 09:03, Bill Janssen wrote:
> Martin v. Löwis wrote:
>
>> > Seems to work fine. So this I don't understand. Any ideas, anyone?
>>
>> Didn't we discuss this before?
>
> Possibly, but I don't recall doing so.
>
>> The buildbot slave has no controlling
>> terminal anymore, h
On 06:46 pm, exar...@twistedmatrix.com wrote:
On 04:44 pm, solip...@pitrou.net wrote:
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen wrote:
So, my question then is, why are these skips "unexpected"? Seems to
me
that if this is the case, this test will never run on any platform.
You can c
On 05:29 pm, mar...@v.loewis.de wrote:
Am 30.06.2010 13:32, schrieb exar...@twistedmatrix.com:
On 05:24 am, mar...@v.loewis.de wrote:
Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before? The buildbot slave has no controlling
terminal anymore, hen
On 04:26 pm, jans...@parc.com wrote:
exar...@twistedmatrix.com wrote:
Could the test be rewritten (or supplemented) to use a pty? Most or
perhaps all of the same operations should be supported.
Buildbot seems to be explicitly not using a PTY. From the the top of
the test output:
make buildb
On 04:44 pm, solip...@pitrou.net wrote:
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen wrote:
So, my question then is, why are these skips "unexpected"? Seems to
me
that if this is the case, this test will never run on any platform.
You can change the value of the "usepty" option in your
Am 30.06.2010 13:32, schrieb exar...@twistedmatrix.com:
> On 05:24 am, mar...@v.loewis.de wrote:
>>> Seems to work fine. So this I don't understand. Any ideas, anyone?
>>
>> Didn't we discuss this before? The buildbot slave has no controlling
>> terminal anymore, hence it cannot open /dev/tty. If
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen wrote:
>
> So, my question then is, why are these skips "unexpected"? Seems to me
> that if this is the case, this test will never run on any platform.
You can change the value of the "usepty" option in your buildbot.tac.
(you will also have to rest
exar...@twistedmatrix.com wrote:
> Could the test be rewritten (or supplemented) to use a pty? Most or
> perhaps all of the same operations should be supported.
Buildbot seems to be explicitly not using a PTY. From the the top of
the test output:
make buildbottest
in dir /Users/buildbot/build
Martin v. Löwis wrote:
> > Seems to work fine. So this I don't understand. Any ideas, anyone?
>
> Didn't we discuss this before?
Possibly, but I don't recall doing so.
> The buildbot slave has no controlling
> terminal anymore, hence it cannot open /dev/tty. If you are curious,
> just patch
Guido van Rossum wrote:
> On Tue, Jun 29, 2010 at 7:55 PM, Bill Janssen wrote:
> > My Leopard and Tiger PPC buildbots are momentarily green! But I'm
> > looking into why I'm skipping some tests. My buildbots are up-to-date
> > OS-wise and very vanilla, with the latest applicable Xcode.
> >
> >
On 05:24 am, mar...@v.loewis.de wrote:
Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before? The buildbot slave has no controlling
terminal anymore, hence it cannot open /dev/tty. If you are curious,
just patch your checkout to output the exact errn
> Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before? The buildbot slave has no controlling
terminal anymore, hence it cannot open /dev/tty. If you are curious,
just patch your checkout to output the exact errno (e.g. to stdout),
and trigger a build
On Tue, Jun 29, 2010 at 7:55 PM, Bill Janssen wrote:
> My Leopard and Tiger PPC buildbots are momentarily green! But I'm
> looking into why I'm skipping some tests. My buildbots are up-to-date
> OS-wise and very vanilla, with the latest applicable Xcode.
>
> 4 skips unexpected on darwin:
> te
My Leopard and Tiger PPC buildbots are momentarily green! But I'm
looking into why I'm skipping some tests. My buildbots are up-to-date
OS-wise and very vanilla, with the latest applicable Xcode.
4 skips unexpected on darwin:
test_gdb test_ioctl test_readline test_ttk_guionly
Three of these
I've repeated this setup with OS X 10.4 (Tiger). Some changes to the
XML file were necessary, because I'd installed a non-system Python,
twisted, and zope.interface on this machine, and because on Tiger,
launchd daemon were not allowed to set their group ID. Here's the Tiger
version, which again
Bill Janssen wrote:
> I can find no evidence that the buildbot installation process given on
> the wiki will cause the buildbot slave to be restarted after a reboot of
> the machine. To accomplish this, you should also undertake the work
> described in
>
> http://buildbot.net/trac/wiki/Using
I can find no evidence that the buildbot installation process given on
the wiki will cause the buildbot slave to be restarted after a reboot of
the machine. To accomplish this, you should also undertake the work
described in
http://buildbot.net/trac/wiki/UsingLaunchd
On my Leopard slave, I cr
35 matches
Mail list logo
