Gregory P. Smith wrote:
> FWIW, thats an old BerkeleyDB (yes it'll still work). Python 2.5
> should ship built with BerkeleyDB 4.4.20 so thats what buildbot should
> use if it builds the module.
The buildbots now fetch bsddb automatically from
http://svn.python.org/projects/external/db-4.4.20/
On 3/29/06, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
> This is an ideal job for VMWare on an existing linux build machine if
> someone can ante up a win xp and msvc++ license to the cause.
It probably isn't great from a practical point of view if you wanted
to run buildbot for both the server
Gregory P. Smith wrote:
> On Sat, Mar 11, 2006 at 07:08:14PM +0100, Thomas Heller wrote:
>> Martin v. L?wis wrote:
>>> Josiah Carlson told me had has given up getting a Windows
>>> buildbot running, because every time he installed VS.NET
>>> on his machine, the installation would immediately crash.
On Sun, Mar 12, 2006 at 06:48:13PM -0500, Tim Peters wrote:
> [Trent]
> > :)
> > Did you apply the Berkeley DB patches to your db-4.2.52 sources?
>
> Ah, _which_ patches? As with my buildbot Wiki page, I write down
> everything I do if there's a good chance I may need to do it again.
> So, e.g.,
On Sat, Mar 11, 2006 at 07:08:14PM +0100, Thomas Heller wrote:
> Martin v. L?wis wrote:
> > Josiah Carlson told me had has given up getting a Windows
> > buildbot running, because every time he installed VS.NET
> > on his machine, the installation would immediately crash.
> >
> > So if anybody wan
> So PythonWin needs to be installed on a Windows buildbot slave, right?
FWIW, we are having reasonable success with buildbot service packaged as a
py2exe application - just unzip into a directory and go! This has the
primary advantage (to me!) of not using the Python installed on the box,
thereb
[Trent Mick, on changing test_winsound to expect RuntimeError on
a box without a sound card]
> Done now (finally).
Cool -- thanks! I merged that to the 2.4 branch, and (of course) your
buildbot slave passes the tests on that too now. Green is a lovely
color :-)
_
[Trent Mick wrote]
> [Martin v. Loewis wrote]
> > Tim Peters wrote:
> > > I'd say instead that they should never be skipped: the real
> > > difference on your box is the expected _outcome_ in the third
> > > category.
> >
> > That is indeed more reasonable than what I proposed.
>
> I'll do this
[Martin v. Löwis]
> So PythonWin needs to be installed on a Windows buildbot slave, right?
It must, since that's what my wiki page says ;-):
http://wiki.python.org/moin/BuildbotOnWindows
...
o Install a matching version of pywin32.
...
_
On Wed, 15 Mar 2006 20:18:28 +0100, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>Martin v. L� wrote:
>
>> Jean-Paul Calderone wrote:
>> > It should actually be using TerminateProcess (depending on the
>> > Twisted version being used, the relevant code is either in
>> > twisted/internet/_dumbwin32proc.
> Martin v. L?wis wrote:
> > So PythonWin needs to be installed on a Windows buildbot slave, right?
PyWin32 you mean. PythonWin is the IDE-thing that is part of PyWin32.
[Fredrik Lundh wrote]
> unless someone hacks Twisted to use _subprocess.TerminateProcess
> instead of the win32all version...
Martin v. Löwis wrote:
> Jean-Paul Calderone wrote:
> > It should actually be using TerminateProcess (depending on the
> > Twisted version being used, the relevant code is either in
> > twisted/internet/_dumbwin32proc.py or
> > twisted/internet/win32eventreactor.py, in the signalProcess method in
Jean-Paul Calderone wrote:
> It should actually be using TerminateProcess (depending on the
> Twisted version being used, the relevant code is either in
> twisted/internet/_dumbwin32proc.py or
> twisted/internet/win32eventreactor.py, in the signalProcess method in
> either case)
So PythonWin needs
On Wed, 15 Mar 2006 00:00:06 -0500, Tim Peters <[EMAIL PROTECTED]> wrote:
>[Trent Mick]
>> Yes I've noticed it too. I've had to kill python_d.exe a few times. I
>> haven't yet had the chance to look into it. I am NOT getting this error
>> on another Windows Python build slave that I am running in-h
Trent Mick wrote:
> Yes I've noticed it too. I've had to kill python_d.exe a few times. I
> haven't yet had the chance to look into it. I am NOT getting this error
> on another Windows Python build slave that I am running in-house for
> play.
I believe this originated from a test run not terminati
[Uncle Timmy]
...
> Looks like it was running test_bsddb at the time, and the test
> framework gave up after waiting 20 minutes for more output. I had one
> of those "recently" that waited 20 minutes for output after starting
> test_shelve, but it's scrolled off the page. Berkeley DB is fishy.
W
[Trent Mick]
> Yes I've noticed it too. I've had to kill python_d.exe a few times. I
> haven't yet had the chance to look into it. I am NOT getting this error
> on another Windows Python build slave that I am running in-house for
> play.
The last run on your Win2K slave that got beyond the compile
[Tim Peters wrote]
>...
> I see that your Win2K buildbot slave always dies in the compile step now, with
>
> """
> -- Build started: Project: pythoncore, Configuration: Debug Win32 --
>
> Compiling resources...
> generate buildinfo
> cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -
[Trent Mick, on test_winsound]
> I'll do this tonight or tomorrow.
Cool!
I see that your Win2K buildbot slave always dies in the compile step now, with
"""
-- Build started: Project: pythoncore, Configuration: Debug Win32 --
Compiling resources...
generate buildinfo
cl.exe -c -D_WIN32 -
[Martin v. Loewis wrote]
> Tim Peters wrote:
> > I'd say instead that they should never be skipped: the real
> > difference on your box is the expected _outcome_ in the third
> > category.
>
> That is indeed more reasonable than what I proposed.
I'll do this tonight or tomorrow.
Trent
--
Tren
Tim Peters wrote:
> I'd say instead that they should never be skipped: the real
> difference on your box is the expected _outcome_ in the third
> category.
That is indeed more reasonable than what I proposed.
Regards,
Martin
___
Python-Dev mailing list
[Mark Hammond]
> Maybe the following VBScript "port" of the above will work:
>
> -- check_soundcard.vbs
> rem Check for a working sound-card - exit with 0 if OK, 1 otherwise.
> set wmi = GetObject("winmgmts:")
> set scs = wmi.InstancesOf("win32_sounddevice")
> for each sc in scs
> set status =
[Trent Mick]
> I have a patch in the works that defaults to "yes, this machine does
> have a soundcard" if cscript.exe cannot be found on the PATH.
>
> However, one wrinkle: test_winsound.py is made up of three test cases:
> BeepTest
> MessageBeepTest
> PlaySoundTest
> only the last nee
Trent Mick wrote:
> 1. Use TestSkipped and skip all three test cases if there is not sound
>card. Running the test suite will actually show that something is
>being skipped.
This is best. The sound tests are not that important that they
absolutely need to be run.
Regards,
Martin
_
[Mark Hammond wrote]
> Maybe the following VBScript "port" of the above will work:
> ...
Cool, yes that works.
> Running "cscript.exe check_soundcard.vbs" and checking the return code
> should work. cscript.exe comes with all modern Windows variants, and
> although there may be ways to install W
> Roger on python-win32 had an answer which works for me:
>
> [Roger Upole wrote]
> > WMI can list sound devices.
> >
> > import win32com.client
> > wmi=win32com.client.GetObject('winmgmts:')
> > scs=wmi.InstancesOf('win32_sounddevice')
> > for sc in scs:
> > print
[Martin v. Loewis wrote]
> Trent Mick wrote:
> > I do have a sound card in that box, however, the "Sounds and Multimedia
> > Properties" dialog (off Control Panel) says that there are "No Playback
> > Devices" for Sound Playback. So I guess that is it. Maybe the sound card
> > in that box is not ho
Trent Mick wrote:
> I do have a sound card in that box, however, the "Sounds and Multimedia
> Properties" dialog (off Control Panel) says that there are "No Playback
> Devices" for Sound Playback. So I guess that is it. Maybe the sound card
> in that box is not hooked up. Grrr. I certainly don't ca
[Martin v. Loewis wrote]
> I took an approach with a little more automation:
> Tools/buildbot/external.bat gradually learns how to fetch and build
> the necessary prerequisites; to avoid moving URLs, these come from
> the external/ directory of the projects svn (in case of bsddb,
> this already has
Trent Mick wrote:
>>This touches on something we (including Martin) should think about:
>>it's very painful to build a full Python on Windows because of these
>>external packages...
>
>
> Yup. That is part of what I meant by updating PCBuild\readme.txt below:
> to improve the instructions so the
[Thomas Heller wrote]
> Trent Mick wrote:
>
> > Yup. Looks like my build worked. Another TODO now though:
> >
> > - Figure out why usage of:
> > winsound.PlaySound(, winsound.SND_ALIAS)
> > fails on my Win2k box. This is why the test suite fails on that box.
> >
>
> Doesn't that always fa
Trent Mick wrote:
> Yup. Looks like my build worked. Another TODO now though:
>
> - Figure out why usage of:
> winsound.PlaySound(, winsound.SND_ALIAS)
> fails on my Win2k box. This is why the test suite fails on that box.
>
Doesn't that always fail when there is no soundcard in the machi
[Tim Peters wrote]
> This touches on something we (including Martin) should think about:
> it's very painful to build a full Python on Windows because of these
> external packages...
Yup. That is part of what I meant by updating PCBuild\readme.txt below:
to improve the instructions so the build-d
[Tim]
>> Setup is hellish,
[Trent]
> Agreed, though I have everything going with my own testing buildbot
> master (everything for the trunk build that is). My only remaining
> problem is that I can't connect to python.org's master. (Following up
> with Martin.)
Looks like that got fixed.
>> The
Trent Mick wrote:
> Adding the /useenv means that one's PATH actually gets through. This is
> important for the _ssl.vproj build. It calls build_ssl.py which tries to
> find a Perl to use. Without "/useenv" Visual Studio is getting a PATH
> from somewhere else (presumably from its internal environm
[Tim Peters wrote]
> Setup is hellish
Any objections to:
Index: Tools/buildbot/build.bat
===
--- build.bat (revision 42982)
+++ build.bat (working copy)
@@ -1,3 +1,3 @@
@rem Used by the buildbot "compile"
[Tim Peters wrote]
> Setup is hellish,
Agreed, though I have everything going with my own testing buildbot
master (everything for the trunk build that is). My only remaining
problem is that I can't connect to python.org's master. (Following up
with Martin.)
> The second-worst part was figuring o
Tim Peters wrote:
>>It seems like the buildbot needs even more hand-holding on Windows:
>>it apparently doesn't survive a master stop/start cycle. While the
>>Unix buildbots reconnect, the Windows one doesn't.
>
>
> What makes us believe that?
The slave was reported as "idle" just before I resta
[Martin v. Löwis]
> It seems like the buildbot needs even more hand-holding on Windows:
> it apparently doesn't survive a master stop/start cycle. While the
> Unix buildbots reconnect, the Windows one doesn't.
What makes us believe that? My box was hibernating from 03:12 to
11:54 EST today, and c
Tim Peters wrote:
> That would be great. A dupe of WinXP would also be great: I'm not
> going to keep my buildbot slave up all the time, or anywhere near all
> the time.
It seems like the buildbot needs even more hand-holding on Windows:
it apparently doesn't survive a master stop/start cycle. W
[Trent Mick]
> I'm keen. However, it looks like Tim is most of the way there already:
The first 100% clean (ignoring _ctypes warnings) Windows builbot test
run just finished. Yippee! Setup is hellish, although you've already
done the worst of it if you regularly build+test full Python on
Windows
Thomas Heller wrote:
> Are there any estimates how much network traffic a buildbot would generate?
It will need to download the entire source code twice (once for the
trunk, and once for 2.4). After that, it currently does only svn up, on
each commit.
> And how must it be connected to the interne
[Thomas Heller]
> Are there any estimates how much network traffic a buildbot would generate?
It should be trivial except for the initial checkout of the Python code base.
> And how must it be connected to the internet - I assume it must be reachable
> from the outside.
The slave opens a socket
Martin v. Löwis wrote:
> Josiah Carlson told me had has given up getting a Windows
> buildbot running, because every time he installed VS.NET
> on his machine, the installation would immediately crash.
>
> So if anybody wants to contribute both a machine and time
> to operate it (including the lik
Josiah Carlson told me had has given up getting a Windows
buildbot running, because every time he installed VS.NET
on his machine, the installation would immediately crash.
So if anybody wants to contribute both a machine and time
to operate it (including the likely very tedious phase to
get any r
45 matches
Mail list logo
