Can we clean up the buildbots please?
Right now we have eight online buildbots for Python trunk. Of those, currently *six* are reporting errors in either the compile or test phases. http://buildbot.python.org/all/waterfall?category=3.x.stable There's one platform ("AMD64 Snow Leop") where the failures are sporadic "stack overflow" errors encountered during the test suite. But the other five platforms have consistent failures, build after build. Those platforms: AMD64 OpenIndiana AMD64 Windows7 SP1 x86 Windows Server 2003 [SB] x86 Windows7 x86 XP-4 That includes *all* of the Windows buildbots. Gosh, it sure would be nice if Beta 1 didn't fail on Windows, wouldn't it? Could some Windows core devs take a look at the failures and see about cleaning them up? Naturally the OpenIndiana and OS X devs are invited to fix the errors on those platforms too, //arry/ p.s. My apologies for not bringing attention to this sooner. But, well, we still have a day left, right?
The Windows 7 buildbots are failing on test_asdl_parser, but I have no idea why – the test works for me just fine. Yury and Benjamin made the most recent changes to Python.asdl, but I have no idea what effect they would have here, or why it’s Windows only. The WS2K3 machine needs a reboot – I pinged Trent about that months ago – and the XP one isn’t supported for 3.5. Pending the test_asdl_parser fix, I’d also like to see AMD64 Windows 8 (http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x) be promoted to stable, as it’s one of only two currently using the right compiler. Cheers, Steve Coming to PyData Seattle 2015http://conf.pydata.org/seattle2015/? Hosted by Microsoft on our Redmond campus, July 24-26 From: python-committers [mailto:python-committers-bounces+steve.dower=microsoft.com@python.org] On Behalf Of Larry Hastings Sent: Friday, May 22, 2015 1444 To: Python Dev; python-committers Subject: [python-committers] Can we clean up the buildbots please? Right now we have eight online buildbots for Python trunk. Of those, currently *six* are reporting errors in either the compile or test phases. http://buildbot.python.org/all/waterfall?category=3.x.stable There's one platform ("AMD64 Snow Leop") where the failures are sporadic "stack overflow" errors encountered during the test suite. But the other five platforms have consistent failures, build after build. Those platforms: AMD64 OpenIndiana AMD64 Windows7 SP1 x86 Windows Server 2003 [SB] x86 Windows7 x86 XP-4 That includes *all* of the Windows buildbots. Gosh, it sure would be nice if Beta 1 didn't fail on Windows, wouldn't it? Could some Windows core devs take a look at the failures and see about cleaning them up? Naturally the OpenIndiana and OS X devs are invited to fix the errors on those platforms too, /arry p.s. My apologies for not bringing attention to this sooner. But, well, we still have a day left, right?
On 05/22/2015 03:06 PM, Steve Dower wrote:
The Windows 7 buildbots are failing on test_asdl_parser, but I have no idea why – the test works for me just fine. Yury and Benjamin made the most recent changes to Python.asdl, but I have no idea what effect they would have here, or why it’s Windows only.
The WS2K3 machine needs a reboot – I pinged Trent about that months ago – and the XP one isn’t supported for 3.5.
Pending the test_asdl_parser fix, I’d also like to see AMD64 Windows 8 (http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x) be promoted to stable, as it’s one of only two currently using the right compiler.
So what you seem to be saying is, the Windows buildbots provide no useful signal and should be ignored? Is MSVS 2015 the only supported compiler for Python 3.5 on Windows? What's the other buildbot using MSVS 2015? //arry/
Two of them are useless (x86 Windows Server 2003 [SB] and x86 XP-4, to be precise), but the fact that everything other than test_asdl_parser passes is a very valuable signal. AMD64 Windows 7 SP1 is also using the correct compiler. Since some of our core developers are yet to upgrade, I’m not against keeping the one VS 2010 buildbot around for now. When MSFT comes up with a better way of getting the compiler than installing 8GB+ of interactive environment, then I’ll be more forceful about it (and yes, I’m helping encourage the relevant teams). Cheers, Steve Coming to PyData Seattle 2015http://conf.pydata.org/seattle2015/? Hosted by Microsoft on our Redmond campus, July 24-26 From: Larry Hastings [mailto:larry@midwinter.com] On Behalf Of Larry Hastings Sent: Friday, May 22, 2015 1530 To: Steve Dower; Python Dev; python-committers Cc: Yury Selivanov; Benjamin Peterson Subject: Re: [python-committers] Can we clean up the buildbots please? On 05/22/2015 03:06 PM, Steve Dower wrote: The Windows 7 buildbots are failing on test_asdl_parser, but I have no idea why – the test works for me just fine. Yury and Benjamin made the most recent changes to Python.asdl, but I have no idea what effect they would have here, or why it’s Windows only. The WS2K3 machine needs a reboot – I pinged Trent about that months ago – and the XP one isn’t supported for 3.5. Pending the test_asdl_parser fix, I’d also like to see AMD64 Windows 8 (http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x) be promoted to stable, as it’s one of only two currently using the right compiler. So what you seem to be saying is, the Windows buildbots provide no useful signal and should be ignored? Is MSVS 2015 the only supported compiler for Python 3.5 on Windows? What's the other buildbot using MSVS 2015? /arry
*From:*Larry Hastings [mailto:larry@midwinter.com] *On Behalf Of *Larry Hastings *Sent:* Friday, May 22, 2015 1530 *To:* Steve Dower; Python Dev; python-committers *Cc:* Yury Selivanov; Benjamin Peterson *Subject:* Re: [python-committers] Can we clean up the buildbots please?
Is MSVS 2015 the only supported compiler for Python 3.5 on Windows? What's the other buildbot using MSVS 2015?
I'll answer my own question here. According to PCbuild/readme.txt: This script will use the env.bat script to detect one of Visual Studio 2015, 2013, 2012, or 2010, any of which may be used to build Python, though only Visual Studio 2015 is officially supported. I'll admit I'm puzzled by the wisdom of using unsupported compilers on buildbots. I guess it's a historical thing. But I gently suggest that we should either upgrade those buildbots to a supported compiler or remove them entirely. Definitely we should remove unsupported the two unsupported platforms from the buildbots--that's just crazy. //arry/
On Fri, May 22, 2015 at 10:06:48PM +0000, Steve Dower wrote:
The Windows 7 buildbots are failing on test_asdl_parser, but I have no idea why – the test works for me just fine. Yury and Benjamin made the most recent changes to Python.asdl, but I have no idea what effect they would have here, or why it’s Windows only.
The WS2K3 machine needs a reboot – I pinged Trent about that months ago – and the XP one isn’t supported for 3.5.
Gave it a little bit of love just then (haven't been able to access it for months as the main switch needed a reboot). There were like, 155 cl.exe processes wedged and a bunch of error reporting dialogs. Do we still support WS2K3? (Can I even install VS 2015 on that? I would have thought not.) Trent.
On 05/22/2015 05:11 PM, Trent Nelson wrote:
Do we still support WS2K3? (Can I even install VS 2015 on that? I would have thought not.)
According to PCbuild/readme.txt, no. It says: This directory is used to build CPython for Microsoft Windows NT version 6.0 or higher (Windows Vista, Windows Server 2008, or later) on 32 and 64 bit platforms. //arry/
On Fri, May 22, 2015 at 05:24:53PM -0700, Larry Hastings wrote:
On 05/22/2015 05:11 PM, Trent Nelson wrote:
Do we still support WS2K3? (Can I even install VS 2015 on that? I would have thought not.)
According to PCbuild/readme.txt, no. It says:
This directory is used to build CPython for Microsoft Windows NT version 6.0 or higher (Windows Vista, Windows Server 2008, or later) on 32 and 64 bit platforms.
Ah, yeah, thought so. Pity, that box is probably the only one that hasn't had any form of hardware failure during its tenure ;-) Tried to get the W2K8 one back up on Monday when I had some remote hands but alas, no luck. Think it has balked HDDs or something. The Solaris 11 AMD64 one Solaris 10 SPARC ones are back up now though and I just cleared out their 700+ build backlogs, FWIW. Trent.
Larry Hastings
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 still 2010 (which is still working, sans recent test failures).
I'll answer my own question here. According to PCbuild/readme.txt:
This script will use the env.bat script to detect one of Visual Studio 2015, 2013, 2012, or 2010, any of which may be used to build Python, though only Visual Studio 2015 is officially supported.
I'll admit I'm puzzled by the wisdom of using unsupported compilers on buildbots. I guess it's a historical thing. But I gently suggest that we should either upgrade those buildbots to a supported compiler or remove them entirely. Definitely we should remove unsupported the two unsupported platforms from the buildbots--that's just crazy.
To be fair, VS 2015 hasn't been officially released yet. It only recently (as in a few weeks ago) reached RC stage. Given the size of installing it, and earlier uncertainty about upgrading during the pre-release cycle, plus some early issues with the build process, for my part I've opted to hold off with my older slaves until it hits release status, using only the 8.1 slave until then. (Arguably the current RC is supposed to be at most a minor update away from full release, so we're probably close) Along the way it was concluded that XP just wasn't worth making work for the 3.5+ development, but the slave was still valuable for the 2.7 branch, so would be left around for now for that purpose. It is a bit misleading to still be trying to build the 3.x branch on it but I suspect eliminating the branch from that slave is just an oversight, or nobody with the proper access has had time yet. -- David
participants (4)
-
David Bolen -
Larry Hastings -
Steve Dower -
Trent Nelson