ZHU Xiang writes:
> ===
> Steps to reproduce
>
> # 1/ pre-install python on server1 (server 1 is a windows os)
> # 2/ from a powershell console on server0, type below 2 commands:
> enter-pssession server1
> python
>
> Expected behavior
> # The python >>> prompt app
Larry Hastings writes:
>> Is MSVS 2015 the only supported compiler for Python 3.5 on Windows?
>> What's the other buildbot using MSVS 2015?
For a while I think the only buildbot was my 8.1 slave, but I believe
at this point Jeremy may also have it on his 7 slave. The latest on
my 7 slave is sti
Victor Stinner writes:
> Would it be possible to fix this buildbot, or to turn it off?
(...)
> By the way, do we seriously want to support Windows XP? I mean, *who*
> will maintain it (no me sorry!). I saw recent changes to explicitly
> *drop* support for Windows older than Visa (stop using GetT
On Mon, Nov 24, 2014 at 11:07 AM, Benjamin Peterson wrote:
>
> On Mon, Nov 24, 2014, at 00:33, David Bolen wrote:
>> Yeah, it definitely needs it. Historically it was intentional as my own
>> servers were all on 8.04, but the last of those moved 12.04 last year.
>>
>
Yeah, it definitely needs it. Historically it was intentional as my own
servers were all on 8.04, but the last of those moved 12.04 last year.
I think there's already a 12.04 buildbot, so perhaps 14.04 would be
better? I do prefer sticking with an LTS.
It'll need to move to 64-bit given the hos
Steve Dower writes:
> Starting with just the Win7 or Win8 one would be fine. Python 3.5
> won't support XP, and VS 2015 doesn't support XP (though I believe
> it will still be able to build for XP, just not *on* XP).
Ok, I'll probably try the Win8 buildbot first then. I'll let you know
when it'
Steve Dower writes:
> Also, who currently owns the Windows buildbots and are you
> willing/able to add a VS 2015 Preview installation (or give me
> access so I can do it)? (...)
I've got several of the Windows buildbots, and could add this. Is there
benefit to just starting with one (I've got
Ned Deily writes:
> Update: after consulting with Donald on IRC, it appears that the problem
> was on the python.org end and is now fixed. David, is it now working
> again for you?
Sorry for the delay - yes, it appears to be working again for me as
well. And it looks like clones during the b
As another data point, I've tried cloning randomly selected other
repositories from hg.python.org, and smaller repositories (distutils2,
peps, jython to name a few) are all working fine under XP, even though
with jython for example, the clone takes longer in terms of wall time
than I'll often see c
Donald Stufft writes:
> I have an idea, can you run https://bpaste.net/show/c5d7cd102f5b and
> tell me what it outputs? Both on a machine that works and one that
> doesn’t.
All but Linux (so XP/7 buildbots, XP standalone, OSX) return:
('DHE-RSA-AES128-SHA', 'TLSv1/SSLv3', 128)
My Linux (Ubunt
Do you mean your local repo? If so, I don't have a local repo at this
point - the failure is during the first clone.
-- David
On Sat, Oct 25, 2014 at 1:19 AM, Steve Dower
wrote:
> I was seeing this recently and had to run recover on my repo (not sure
> what the command line is for that - Tor
Donald Stufft writes:
> What version of OpenSSL is it using.
I'm using the pre-built Windows Mercurial installer, but if I unpack
the included library.zip, the SSLEAY32.DLL shows version 0.9.8r.
This is from the 3.1.2 install I just did a few hours ago. It appears
that hg 2.5.2 on my other XP
David Bolen writes:
> which appears to die mid-stream while receiving the manifests.
>
> So I'm sort of hoping there might be some record server-side as to why
> things are falling apart mid-way.
Just to follow-up to myself, I get the same same error trying to do a
clone from m
Antoine Pitrou writes:
> Have you tried running the hg clone manually from the buildbot?
> You could try to add --debug to get more info where the thing breaks.
Yes, I had but pretty much got the same output as the buildbot slave.
But I just tried --traceback and it's definitely complaining abou
Donald Stufft writes:
> Is this using HTTPS or SSH.
Um, good question - whatever the buildbot build process uses.
Looking at the slave log on buildbot.python.org (I don't get the hg
output locally), appears to be http (it's cloning
http://hg.python.org/cpython) - though I thought I saw it using
Starting yesterday, my XP buildbot began failing to execute clone
operations against hg.python.org. There's not a lot of data being
given aside from a transaction abort message (and my buildbot log
showing the hg command exiting), and I'm wondering if something may be
amiss on the server or its co
Brian Curtin writes:
> On Mon, May 12, 2014 at 5:16 PM, Claudiu Popa wrote:
(...)
>> - If we can acquire the privilege by elevating our process, does the
>> Windows buildbots have UAC
>> enabled and if so, how's the notification setting configured? For
>> instance, elevating a process will
>>
Terry Reedy writes:
> On 9/1/2013 5:04 PM, Antoine Pitrou wrote:
>> Probably because they don't have the hgeol extension enabled.
Yes, I believe that's correct, at least for my Windows buildbots.
> Since the tests also failed on installed Python, it seems that the
> .msi installer is created in
Richard Oudkerk writes:
> On 11/08/2013 11:00am, Antoine Pitrou wrote:
>> You've got the answer at the bottom:
>>
>>"program finished with exit code 0"
>>
>> So for some reason, the test suite crashed, but with a successful exit
>> code. Buildbot thinks it ran fine.
>
> Was the test terminate
"Eric V. Smith" writes:
>> http://buildbot.python.org/all/builders/x86%20Tiger%202.7/builds/2030
>> http://buildbot.python.org/all/builders/x86%20Tiger%203.3/builds/742
>> http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/6522
>> http://buildbot.python.org/all/builders/bolen-dmg-3.
Antoine Pitrou writes:
> I've upgraded the Mercurial version on hg.python.org. If there any
> problems, don't hesitate to post here.
> (apart from the connectivity problems we seem to have from time to time
> and which shouldn't be related)
I'm not sure if this is related to the upgrade specific
mar...@v.loewis.de writes:
> We once had nightly builds of the Windows installers. It required a
> dedicated buildbot operator, since the process tended to break.
For what it's worth, I'd be willing to try to re-institute the daily
Windows installer builds if they'd see usage, but I suspect I'll
Ned Deily writes:
> In article <20121001211812.4c40a...@pitrou.net>,
> Antoine Pitrou wrote:
>
>> Hello,
>>
>> It seems that the daily DMG builds have been failing for some time on
>> the default branch:
>> http://buildbot.python.org/daily-dmg/
>>
>> Since there has been no report or complain
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
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
I've been receiving 503 errors from the buildbot web status pages
beneath www.python.org/dev/buildbot for a day or two now - is there
perhaps something that needs a bit of a kick-start?
Thanks.
-- David
___
Python-Dev mailing list
Python-Dev@python.org
Victor Stinner writes:
> But today I saw a a buildbot timeout without any traceback: a possible hang
> in
> test_io on "x86 FreeBSD 7.2 3.x" buildbot, "command timed out: 3900 seconds
> without output". I realized that some buildbots (all buildbots?) override the
> TESTOPTS variable ("make bu
I was wondering if it might be possible to have a channel (message
here, email to a list of slave owners or whatever) to mention when the
set of builders for the slaves is getting adjusted? A new builder
tree can burn a good deal of disk space in some cases for example
(each tree adds in the neigh
Nick Coghlan writes:
> On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou wrote:
>> You mean in the "-j" option itself or in "make test"?
>
> I was actually suggesting that -j be the *default* in regrtest itself,
> with an option to turn it off or force a particular number of
> processes.
Just on
Victor Stinner writes:
> Le lundi 14 mars 2011 à 15:36 -0400, David Bolen a écrit :
>>
>> Speaking of bbreport, I sometimes use the published page on that site
>> (http://code.google.com/p/bbreport/wiki/PythonBuildbotReport) to check
>> over things, but looking at
Nick Coghlan writes:
> I don't want to give up completely on the idea just yet, but I'll
> experiment in the sandbox before I turn it back on.
If you get to that point again, I'd also be willing to pick a time to
manually check out the right branch or whatever and try it manually
on one of two o
Antoine Pitrou writes:
> I've enabled the button to cancel pending builds in the Web UI. You
> should be able to bring back the Ubuntu slave online. You can do the
> same (cancel pending builds) for other slaves if needed.
Thanks. Is that a single button somewhere or do I need to cancel the
pen
I've run out of virtual memory on my Ubuntu buildbot today (and I
think the FreeBSD buildbots a few days ago). Those have physically
OOMd/restarted the VM. The Windows buildbots have been giving me
VM warnings, but appear to have gotten through it.
I believe it's the test_crashers test, which wh
Nick Coghlan writes:
> On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou wrote:
>> This has broken many buildbots.
>
> I'm pretty sure I know which one is the problem child, so I just
> pushed a fix which should get that one dying reliably on more
> platforms.
On my Windows buildbots it appears
Antoine Pitrou writes:
> I suggest you try http://code.google.com/p/bbreport/, which provides a
> very nice command-line interface.
Speaking of bbreport, I sometimes use the published page on that site
(http://code.google.com/p/bbreport/wiki/PythonBuildbotReport) to check
over things, but lookin
Bill Janssen writes:
> David Bolen wrote:
>
>> There used to be a way to request a "ping" from the master side (I
>> think on the same page you could manually run a build from) that I
>> would used to force it to recognize a slave was really down, but after
>
Bill Janssen writes:
> David Bolen wrote:
>
>> Bill Janssen writes:
>>
>> > I'm trying to get a new buildbot in the swim of things, and it keeps
>> > getting into this state where the buildslave process seems caught in an
>> > endless loop.
Bill Janssen writes:
> I'm trying to get a new buildbot in the swim of things, and it keeps
> getting into this state where the buildslave process seems caught in an
> endless loop. Perhaps someone here knows why?
Do you have any information as to what it is doing while in the loop?
I think th
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
Brian Curtin writes:
> http://bugs.python.org/issue9116 covers this issue.
>
> The reason it doesn't fail on any of the build slaves is because they modify
> a registry value for Windows Error Reporting to not display the pop-up
> window, or at least mine does. I think I got the idea from one of
"Martin v. Löwis" writes:
>> 1. Does it still fail on FreeBSD 7.3+?
>
> Yes, it still fails. The limits (30 semaphores) haven't
> changed. It also remains untunable.
Yeah, my recollection about 7.3 appears to have been remembering when
the kernel module was included by default as opposed to need
"Martin v. Löwis" writes:
>> I don't have a good suggestion (or a computer with a keyboard
>> anywhere near me) right now, but making a migration/fallback to SYSV
>> style semaphores a release blocker seems like a mistake to me.
>
> And indeed, I don't propose to make that a release blocker. Inst
Hirokazu Yamamoto writes:
> Yes, but test can freeze. In that case, I'm worried that
> (snip)
> rt.bat # freeze here (will be halt by buildbot)
> vcbuild & kill_python_d # Will this be called?
> in test.bat.
Yeah, you're right. It may be impossible to completely eliminate the
ri
Tres Seaver writes:
> Maybe belt-and-suspenders it in both places.
The clean batch file is also called from the build step, so relocating it
there should maintain the existing behavior as well.
Hirokazu (ocean-city) pointed out in my new issue an earlier issue he
created (#9973) that included a
I previously wrote:
> I suspect the problem may be on the "identify which process to kill"
> rather than the "kill it" part, but it's definitely going to take time
> to figure that out for sure. While the approach kill_python takes is
> much more appropriate, since we don't currently have multipl
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
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
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 -
"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
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
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
Jeroen Ruigrok van der Werven writes:
> -On [20101108 00:36], David Bolen (db3l@gmail.com) wrote:
>>Well, I think the SYSV semaphores are either less limited or at least
>>more adjustable. They've certainly been around longer in FreeBSD.
>>The POSIX semaphore
Victor Stinner writes:
> You wrote that the "POSIX" semaphore are very limited. Do it mean that there
> is another kind of semaphore will an higher limit?
Well, I think the SYSV semaphores are either less limited or at least
more adjustable. They've certainly been around longer in FreeBSD.
The
Giampaolo Rodolà writes:
> In such cases I would find more easy to be able to connect to the
> machine and test myself rather than create a separate branch, commit,
> schedule a buildbot run, wait for it to complete and see whether
> everything is "green".
I agree with both Stephen and Martin's
On Sat, Nov 6, 2010 at 7:19 AM, Victor Stinner
>
> I noticed "OSError: [Errno 23] Too many open files in system" errors on your
> FreeBSD buildbot. I would like to know if you configured a limit on the open
> files or maybe of child processes on this buildbot or not, or if it is a
> failure in Pyt
"Martin v. Löwis" writes:
> People will never ever test nightly builds. Been there, done that.
> Instead, the nightly build process will break, and nobody will fix
> it for months (or even complain, for that matter).
Certainly seems to be past experience.
I know Martin knows this, but for other
"Martin v. Löwis" writes:
> Please be aware that Windows poses its own challenges. Often, builds
> or testsuite runs end up with popup windows, which then hang subsequent
> builds. You often get dozens of them to click away. So operating a
> Windows slave is much more tedious than a Unix one.
Fo
Antoine Pitrou writes:
> (...)
>
> test test_ssl failed -- Can't read certificate file
> b'D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows7\\build\\lib\\test\\keycert.pem'
>
> But the aforementioned certificate file is in the SVN tree and other
> buildslaves have no problem reading it. Can y
Hirokazu Yamamoto writes:
> Hello. I've sent following mail to buildbot manager,
> but I found that buildbot page saids the problem of unsable
> bot should be sent to python-...@python.org. So I'll do it.
(I'm fine with direct email for any of my build slaves, and it's
probably the quickest way
Since the recent history of my two Windows buildbots has turned ugly,
I figured I'd mention that they both (XP and Windows 7) have started
generating quite a few GUI C++ RTL runtime pop-up assertions, which
has been throwing a wrench into things until they get manually
cleared. I first noticed the
Michael Foord writes:
> I would be interested in hearing from other Mac users as to where they
> would look for configuration files for command line tools - in ~ or in
> ~/Library/Preferences?
My primary personal machine has been OSX for years now, and as someone
who lives in the command line (w
As one of the beneficiaries of the efforts (much appreciated) last
year to obtain Microsoft MSDN subscriptions for developers/testers (in
my case, primarily buildbot operation), I was wondering if anyone
might know if those subscriptions will be able to be renewed this
year?
-- David
Paul Moore writes:
> Thanks for the alert. I've killed the stuck test and should see some
> runs going through now. Shame, really, I was getting used to seeing a
> nice page of all green results...
In my experience, my OSX and Windows buildbots need some manual TLC on
an ongoing basis. I kill o
Bill Janssen writes:
>Ronald Oussoren wrote:
>> As Antoine noted the test failures are unexpected, could you check if
>> the tests pass if you do the build and testrun manually?
> What about readline? Darwin doesn't have it (or rather, it has a
> different one). Why is that 'skip' unexpected
Michael Foord writes:
> Hmmm... looks like a 32 / 64 bit issue, which I believe may be the
> expected result when trying to build on Snow Leopard (?).
I think so - I haven't tried a 64-bit build myself, but there's a
comment in setup.py indicating that none of the Tcl/Tk framework
builds support
Michael Foord writes:
> 10.6.3 and yes I have Tcl and Tk in /Library/Frameworks. How do I
> determine which versions they are?
You can use "info patchlevel" in tclsh - assuming you're running a
tclsh linked to your /Library version (a normal Tcl install puts this
in /usr/local/bin I think).
Or,
Antoine Pitrou writes:
> Does it include a license for Windows itself?
> Does it allow me to install and run it in a VM?
> If so, I'm interested.
Yes, in fact, it's due to the availability of this license that I was
able to set up the Win7 buildbot.
-- David
___
Ronald Oussoren writes:
> On 18 Apr, 2010, at 17:17, Martin v. Löwis wrote:
>
>> Ronald Oussoren wrote:
>>>
>>> That *is* trivial: use Mac/BuildScript/build-installer.py on OSX 10.5.
>>
>> Hmm. When I tried it (on some 2.5 release), it took me two days until it
>> produced something.
>
> It sho
"Martin v. Löwis" writes:
>> I do currently have a DMG built for 2.7 Beta 1, if it would be useful.
>
> As I said before: if you would plan to do this on a regular basis, for
> all upcoming releases, that would certainly be a good thing.
No argument - just figured I'd offer to get past the near
"Martin v. Löwis" writes:
> This actually happened on Windows - some people now
> recommend to run the buildbot scripts on a regular developer checkout,
> because they supposedly do the right things.
I have to admit that I'm guilty of this (though to be fair most of my
test
"Martin v. Löwis" writes:
> Not sure what you mean by "make available" - I thought this is just a
> matter of configure options?
Building as a framework, yes. But I think there's some steps to take
to then have the test python binary use the locally built framework
while running the tests (sinc
Ronald Oussoren writes:
> Speaking of which... I have a mac-mini that could be used for a
> buildbot. How much work is needed to kickstart a buildbot, taking
> into account that I'd prefer to have a buildbot with different
> configure-flags that the default unix build (that is, I want to test
> a
Brian Curtin writes:
> The tests are run on a native Win32 build as compiled by VS2008. The
> functionality is Win32 specific and wouldn't work on Cygwin, so the tests
> are skipped there. I believe Cygwin is used for kicking off the tests and
> other buildbot stuff, but they don't actually run t
Steven D'Aprano writes:
> Personally, I can't imagine ever wanting to ship a .pyc module without
> the .py, but since Python already gives people the opportunity to shoot
> themselves in the foot, meh, we're all adults here.
Not sure I've seen it mentioned in this thread, but for myself, I've
Mark Dickinson writes:
> I'm not seeing the test_distutils failure you report on my own
> 10.5 machine, for some reason.
I don't think it's OSX specific. My FreeBSD slaves (both 6.4 and 7.2)
have been getting the same error.
It seems related to the sticky bit on /tmp and the fact that the
acco
"Martin v. Löwis" writes:
> It was too difficult to get right, plus nobody was interested in
> using the daily MSI files.
>
> At some point, it was broken for several months (IIRC), with nobody
> reporting that breakage. So when we noticed, we just turned the service
> off.
Sounds right - the da
Paul Moore writes:
> Hmm, wasn't me :-) The reason field on the build is blank, so this
> looks like it's an automatic build.
If it's got an SVN tag indicated, and you can checkout that tag on
your slave, then it's probably not the scenario that I was thinking
of.
In my case, it's almost always
Paul Moore writes:
> buildbot.interfaces.BuildSlaveTooOldError: This buildslave
> (moore-windows) does not know about multiple branches, and using
> mode=update would probably build the wrong tree. Refusing to build.
> Please upgrade the buildslave to buildbot-0.7.0 or newer.
>
> This is very odd
Antoine Pitrou writes:
> I've submitted a patch (*) to add an optional timeout to locking
> operations (Lock.acquire() etc.). Since it's a pretty basic
> functionality, I would like to know if there was any good reason for
> not doing it.
I always assumed it was because as a least-common-denomin
"R. David Murray" writes:
> The buildbot pages appear to be pretty messed up now. I get many 404s
> (ex: the above url, the all stable builders page), although some seem to
> work (ex: the all builders page), and if I stick an 'all' into the URL
> for my buildbot page I can get to it, though tha
David Bolen writes:
> (...)
> I would have sworn they used to get run, but now I'm not so sure.
> Perhaps I'm remembering older Python releases with VS.NET 2003, since
> the MSVC9 versions of the CRT and the SXS stuff was new with VS 2008 I
> think.
>
> Does anyon
While working with the Windows (and now Windows 7) build slaves I've
been noticing that a number of "unexpected" test skips are occurring,
mostly for external modules like ssl, bz2, tk, etc...
However, I know for a fact that those libraries are being fetched and
built, so I was a little perplexed
I think in a prior discussion, it was suggested that build slave
updates were ok for this list - I apologize to those who may not be
interested.
I've just completed some updates to my two build slaves.
XP-4 is now running XP Pro SP3 (was SP2) and is using the full version
of VS 2008 (was previous
MRAB writes:
> Couldn't you write a script to check the status periodically?
Sure, I suppose scraping the web status page would work. If it
happened frequently I'd probably be forced to do something like that,
but it's relatively low frequency (though I guess it does have a big
impact in terms
exar...@twistedmatrix.com writes:
> This sounds like something that should be reported
> upstream. Particularly if you know how to reproduce it. Has it been?
No, largely because I can't reproduce it at all. It's happened maybe
4-5 times in the past 2 years or so. All that I see is that my end
f, but I'm not sure whether that mechanism
> might have been removed. For the system messages, there is a way to
> turn them off in the parent process. David Bolen (IIRC) had developed
> a patch, but I think this patch only runs on his system(s).
Yes, process-stopping dialogs have pro
exar...@twistedmatrix.com writes:
> It's easy for someone to volunteer to set up a new slave. It's even
> easy to make sure it keeps running for 6 months. But it's not as easy
> to keep it running indefinitely. This isn't about the software
> involved (at least not entirely). It's about someon
Chris Withers writes:
> Is the Express Edition of Visual C++ 2008 suitable for compiling
> packages for Python 2.6 on Windows?
> (And Python 2.6 itself for that matter...)
Yes - it's currently being used on my buildbot, for example, to build
Python itself. Works for 2.6 and later.
> Ditto for
Christian Heimes writes:
> Steve Holden wrote:
>> I sent fourteen requests for licenses in to Microsoft. I've asked them
>> to let me know which they grant (since they may choose to limit the
>> number) and will inform you all personally when I hear their decision.
>
> I've received my MSDN subsc
Antoine Pitrou writes:
> Only one of the py3k buildbots seems up:
> http://www.python.org/dev/buildbot/3.x.stable/
Strange - everything looks good on my buildbot end (XP-4), including
an established TCP session back to dinsdale. Not sure why the master
thinks it's offline. Although I'm pretty
Aahz writes:
> It sounds like Wave requires a high-powered browser, similar to Google
> Maps. That makes me -1 because I want to continue using Lynx.
I'm not sure - I think you can implement your own choices at different
points.
What's interesting to me so far is less the current UI/flashiness
David Bolen writes:
> Ooops, that's mine. Geez - it's a VM, but has a 10GB C: drive, and
> the actual build slave has its working directory on a separate virtual
> drive. Wonder what the heck has filled up the system drive. I'm
> working on it now though.
Well
Tarek Ziadé writes:
> - x86 XP-4 (trunk and 3x) is throwing an "no space left on device"
> error when it compiles the sqlite module in its temp dir
Ooops, that's mine. Geez - it's a VM, but has a 10GB C: drive, and
the actual build slave has its working directory on a separate virtual
drive. W
Kristján Valur Jónsson writes:
> But again, it shows how useful assertions can be and why we ought
> not to disable them.
Note that just to be clear, I'm certainly not advocating the disabling
of CRT assertions - just the redirection of them so they don't prevent
unattended test runs from comple
"Martin v. Löwis" writes:
> Notice, however, that the feature was never present in the trunk.
Yep - would be nice if it were to get backported to trunk at some
point but that's a separate discussion ... presumably at some point
py3k will be the trunk anyway, and for better or worst (perhaps due
Kristján Valur Jónsson writes:
> Btw, I am working on finding out the test suite failures for
> test_multiprocessing.
This is all well and good, but I still haven't seen any plausible
reason for not preventing these popups (in favor of stderr failures)
during buildbot test runs? I don't get it
Hirokazu Yamamoto writes:
> CRT Assertion was totally disabled before, but recently was enabled,
> and workarounds were patched for problematic functions. (ex: fdopen
> and dup) Probably this *patch* is not perfect. See
> http://bugs.python.org/issue4804
Ah - that ticket may explain why my build
David Bolen writes:
>>From what I can see though, the tools/buildbot/test.bat file no longer
> adds the -n option that it used to, although I'm unclear on why it
> might have been removed. Perhaps this was just a regression that was
> accidentally missed, as it appears
Curt Hagenlocher writes:
> The variation that goes through assert.c should write to stderr for a
> console-mode application, so it's reasonable to assume that we're
> hitting the other code path -- and that Mark's suggestion to use
> CrtSetReportMode would address the issue.
Which is pretty much
Mark Hammond writes:
> The issue was that Python unconditionally changed the behaviour of the
> CRT, not only during the test suite.
Hmm... I was more or less referring to the state of the py3k tree as
of, say, r57823 back in 2007. It appeared to just add access to the
necessary functions in th
1 - 100 of 118 matches
Mail list logo
