David Bolen added the comment:
I can help with a Win7 test of the installer, but my currently available
systems are all 32-bit - any chance at a 32-bit version of the installer?
--
___
Python tracker
<https://bugs.python.org/issue36
David Bolen added the comment:
Ok, I've verified that on a Win7 system with SP1 but without KB2533625 I get
the expected block screen at startup.
On my worker (SP1 with KB2533625) it proceeds to the regular installation main
dialog.
I'm attaching a copy of the install log in th
David Bolen added the comment:
Eric, I'm also seeing the same Win7 and Win10 worker failures with commit
b75b1a350 as last time (test_multiprocessing_spawn on both, and test_io on
Win7).
For test_multiprocessing_spawn, it fails differently than Victor since no core
file is generated,
David Bolen added the comment:
I just noticed that my last message referenced the wrong commit. My test
failures were against commit f13c5c8b9401a9dc19e95d8b420ee100ac022208 (the same
as Victor).
--
___
Python tracker
<https://bugs.python.
David Bolen added the comment:
Yes, it appears most likely to be the worker environment. I did upgrade the
kernel in between builds 250 (good) and 251 (bad), but reverting that still
fails, even with the same commit as in build 250.
My current suspicion is that a test I did recently with a
David Bolen added the comment:
Ok, I've resolved this, and the linker errors did actually point at the root
issue. They show trying to link extensions against
/usr/local/lib/libpython2.7.a which was my test static build of 2.7.16.
Arguably this seems an issue in the buildbot build pr
David Bolen added the comment:
I should mention that a high level of test parallelism on the part of my worker
might have be a contributing factor in this most recent case.
The worker was recently upgraded to a faster 4-core VM, but with limited I/O.
In a test run the test processes
David Bolen added the comment:
I think I'm the wrong David for this...
--
___
Python tracker
<https://bugs.python.org/issue36749>
___
___
Python-bugs-list m
David Bolen added the comment:
Nothing for my part, but there was an Azure "maintenance" on 4/16 where both
the Win8 and Win10 buildbots were migrated to "newer" hardware (the first
change to their physical machine for a really long time). No word on why. The
VM machine
David Bolen added the comment:
Disk space seems unlikely as a reason - the local disk is 60GB on each
buildbot, of which at least 50GB+ is generally free. So that shouldn't be a
problem (the WinXP/Win7 buildbots operate with far less, like 5-10GB).
I had also considered that pe
David Bolen added the comment:
I believe I've identified the issue, and put a workaround in place.
The 986b7ffc commit somehow affected which binary of mt.exe is being run (for
version 5.2.3790.2076, 2005), changing from:
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64\mt.exe
t
David Bolen added the comment:
Sure, I can certainly do that.
Does "basically a requirement" mean it should have been there all along (with
the VC9 installation), or just that trying to use VC9 on a recent system like
Win 10 safely requires it installed separately? I guess Win
David Bolen added the comment:
Sounds good. I must admit I hadn't actually gone looking for a standalone
installer yet, but just assumed it would exist.
The Win10 worker now has the .NET 3.5 feature installed (which also installed
2.0 and 3.0). Builds seem fine even after removin
David Bolen added the comment:
This seems to correlate with my upgrading to the latest Win10 SDK on those
workers (Steve pointed out I was still getting ucrt warnings during
compilation). So they both jumped from like 10240 up to 16299. But that's all
I changed.
Interestingly I onl
David Bolen added the comment:
Ok, so rc.exe appears truly not to be found when the test runs. The binary is
a bit buried in the Windows Kit directory tree, and I'm guessing something is
off after the upgrade (I'm not sure where it was in the tree before). I
manually placed a
David Bolen added the comment:
Yeah, I'm not sure if I can do anything on my side. It looks like it's an
issue with the build patch (issue30487, commit d8d6b91, assuming that's what
Zachary is referring to). The blurb complaint is about something that appears
should have be
David Bolen added the comment:
This commit appears to have broken OSX installer builds using the
build-installer.py script (as in the last two attempts on the bolen-dmg-3.x
builder), confirmed with a bisection from the first failing worker build
(covering the range 02a0a19..3327a2d)
It
David Bolen added the comment:
After some further testing, it does not appear to be configure related but
something environmental (maybe MACOSX_DEPLOYMENT_TARGET) - using the same
configure options manually as build-installer seems ok.
For what it's worth, since there do appear
David Bolen added the comment:
Apologies if this is obvious and already in progress, but the issue with
Windows and this change appears to be that the "utf-8.file" file is being
treated as text rather than binary.
So the line ending is expanding to CRLF. The working copy of utf-8.
David Bolen added the comment:
A longer timeout might be another workaround, but for myself, I tend to favor
Zachary's original suggestion of eliminating largefile tests for the moment as
simplest and most robust. It would also reduce the overall percentage of test
time currently spent
David Bolen added the comment:
I have migrated the win8 and win10 builders to a different machine type on
Azure, which seems to have restored more reasonable performance for the tests,
at least in the first set of builds. Assuming that continues to hold true, it
should resolve this issue
David Bolen added the comment:
The win7 builder isn't on Azure, so changing host type isn't an option at the
moment. For my part, I'd prefer removing the largefile tests for that one
rather than increasing timeout. The tests generate a huge amount of I/O, so my
guess i
David Bolen added the comment:
For my buildbots, I suspect win8/win10 should be ok at this point. Among any
other changes their local disk appears to be an SSD now, which makes a big
difference. I observed steady 250-300MB/s write I/O for the duration of the
mmap test, for example, so no
David Bolen added the comment:
It seems really unlikely to be related to this issue since I'm pretty sure
build-amd64 doesn't get used on XP-4.
>From the log it looks like it couldn't clean out and reuse the VS temporary
>build directory. Manually cleaning it out an
David Bolen added the comment:
With a local build on my buildbot of the tip of the default branch,
pkgutil.get_importer('') returns FileFilter('.'). The tests also passed.
However, after checking here and realizing the offending code had been removed
from the test, I p
David Bolen added the comment:
This generator script breaks the daily OSX DMG builds on my bolen-dmg
buildslave for the 3.x branch.
The issue is with the use of "with" as the slave uses Python 2.5 to build the
installer. Now, that's old, and I'm not even sure how necessa
David Bolen added the comment:
I've been trying to test this on the Ubuntu 8.04 buildbot, but so far, using
the latest hg default head, haven't gotten test_asyncio to hang even before the
patch. It also looks like the last 4 regular buildbot builds were fine too. I
even tried ro
David Bolen added the comment:
I've been experimenting with setting up a Windows 8.1 buildbot, and found this
ticket after finding a problem with test_threaded_import, testing against the
3.4 branch.
I seem to be have a low syscheckinterval issue similar to that discussed here
on
David Bolen added the comment:
Interesting - it's got a "Visual Studio Just-In-Time Debugger" dialog on the
screen for an unhandled win32 exception in the compiler (cl.exe).
That's a dialog my pop-up AutoIt script wasn't expecting, so I've added it to
the other
David Bolen added the comment:
Ok, the last spurt of exceptions on the XP buildbot in the 3.x branch were all
related to the fact that somehow the .hg folder in the 3.x branch build tree
was missing. The rest of the build files seemed present. I've removed the
build tree completely to
David Bolen added the comment:
I'm seeing an apparent side-effect of the new clean script (or it seems to
correlate). Since it started running, the Windows buildbots (both 7 and XP)
seem to always perform a full clone of the master repository for each build
rather than just a pull/u
David Bolen added the comment:
While troubleshooting an issue with test_distutils consistently failing on my
XP buildbot, I narrowed it down to the test.bat change to use run_tests.py. I
don't yet know fully what's happening, but after replacing the new test.bat
with the older ver
New submission from David Bolen :
This is a pretty tiny bug..
The test_reg_class test in test_msvc9compiler.py assumes that there is a
Notepad registry key on Windows systems. That appears to be false until
Notepad is run the very first time. I ran into this setting up a build
slave VM, where
David Bolen added the comment:
Well, I can at least start by comparing XP and Win7 immediately
post-installation. Any suggestions on guidelines to what can be chosen?
Does it have to be a DWORD, or a 0/1 value, or under HKCU for a
specific reason
David Bolen added the comment:
Since I was feeling bad for the Windows 7 build slave not being able to
pass the tests due to this (at least when other tests weren't failing),
I manually added a matching key on the slave pending any test changes.
In looking around, since this te
New submission from David Bolen :
As I mentioned in a recent python-dev post, I've noticed that the
Windows build slaves are skipping tests of external modules (like ssl
and bz2).
After finding an old 2.6a0 tree that I had locally built where things
worked fine, I stepped through some 2.6
David Bolen added the comment:
Our last comments may have crossed, but as I mentioned in my last one,
yes, as best I can tell from my slaves (XP+VS-Express, XP+VS-Standard,
Win7+VS-Standard), the Visual Studio key is present in a brand new
install. Note that it is not present in a brand new XP
David Bolen added the comment:
Oh, Tarek, something I missed in your last comment - for the "Build
Timing" key, it should probably permit the value to be either 0 or 1,
just as the current test does. Just in case someone happens to have
build timing
David Bolen added the comment:
The "Build Timing" key (not Build Time) is the only one at all under
HKCU/VisualStudio/9.0/VC (and actually the only key under the entire
HKCU/VisualStudio tree) on both my XP and Win7 new VS 2008 installation.
I can't rule out it being part
David Bolen added the comment:
Oh, BTW, you were missing the VC part of the path in your test. But if
I run the same code with that corrected on my Win7 box, I get:
>>> from distutils.msvc9compiler import Reg
>>> path = r'Software\Microsoft\VisualStudio\9.0
David Bolen added the comment:
Yes to both examples (the first on my VS 2008 full installs on XP and
Windows 7, and the second on my XP with VC++ Express).
Two caveats (that I don't think invalidates the result) though.
First, I can't use forward slashes in the path I supply to
Reg
David Bolen added the comment:
Oh, my bad - I was working on the assumption that test_msvc9compiler was
testing compiler related stuff, so obviously would have the compiler
installed. But it makes sense you might test support for that compiler
on a machine other than the one doing the building
David Bolen added the comment:
Looks like some sort of master side global rebuild was initiated but
without the proper SVN information. But I see a rebuild on 7.2 with
this patch revision that looks like it worked (still failed, but with a
different reason)
I'm not that familiar with the
David Bolen added the comment:
> David, I think we're ready to enable POSIX semaphore support on the
> FreeBSD 7.2 buildbot now, if you get the chance.
Done. I'll double check that the module remains loaded across restarts
when there's some id
David Bolen added the comment:
I don't think its OSX specific. My FreeBSD slaves (both 6.4 and 7.2)
have been getting the same error recently (sounds like probably around
the same time frame). The error always seems to be that member.gid (0)
is not matching os.getgid (1001). The os.g
David Bolen added the comment:
>From Tarek:
> Thanks for the digging David, I'll check for /tmp rights in that case.
> What's important in distutils, is to make sure it was able to create
> tarballs with various uid/gid using the new tarfile feature.
Right, and
David Bolen added the comment:
> I can generate the error on my iMac but not my laptop, which are
> equivalent versions/upgrades of Mac OS X AFAIK. The /tmp directory
> in both has drwxrwxrwt, and the subdirectories within which I'm doing
> the builds are drwxr-xr-x, so it d
David Bolen added the comment:
> I think that's difficult to implement, as the files are not there
> anymore when the check is made (only the tarfile); somebody correct
> me if I'm wrong.
The files are created during setup, and I think exist through the
duration of the test,
David Bolen added the comment:
2.7.12 (/usr/local/bin) is used for the build slave and main external commands
(such as hg and sphinx) and is in the buildslave path, but 2.5.1 is still the
default in /usr/bin so can get used for processes with a restricted
environment. Tiger's original 2
David Bolen added the comment:
Whoops, I just realized that the patch still needs adjusting to be 2.x
compatible, so obviously the extra build still won't work.
But at this point it should be safe to assume 2.6+ such as for the rest of the
sphinx proce
New submission from David Bolen:
The "make touch" step during the Mac installer builds on the bolen-dmg build
slave no longer works after the conversion to github, which breaks the daily
builds on the 3.* branches.
It looks like in issue 23404 Zachary disabled the touch step for the
David Bolen added the comment:
Yeah, the XP buildbot was pretty old, at nasm 2.02, so I updated to the same
2.09 as the Win7 buildbot, restarted the last build and it went through
compilation fine.
However, then it failed in test_ssl, and in checking, it looks like my Win7
buildbot is
David Bolen added the comment:
Both of my FreeBSD buildbots are quite ancient (particularly so with
FreeBSD/6.4), and mostly still exist because of lack of pressure to change
them, and at least for a while having an older, legacy FreeBSD buildbot was of
some use.
I have no plans on upgrading
David Bolen added the comment:
I suppose it depends on what the current policy (if any) is. Not sure how far
back we would officially claim to support even today. We have a 6.4 buildbot
due to history, but it's never made the stable list, and is probably in a
failing state as much or
David Bolen added the comment:
Just thought I'd add a note here that after the most recent changes, my
buildbots also appear to be back to quicker hg pulls rather than clones at the
start of the process (see msg222592). Still not sure why that behavior
changed, but we're back to th
David Bolen added the comment:
I've just brought a Windows 8 buildbot online (bolen-windows8) and can confirm
that this test does fail in the 3.4 and 3.x branches, and that it does so
consistently even if I execute the steps interactively.
--
nosy:
David Bolen added the comment:
I noticed this issue when checking on some recent 2.7 branch failures on my
buildbot. It might be worth noting this change to any Windows buildbot owners
since we all have existing trees now with a lot of stranded external folders
that can be removed.
For what
David Bolen added the comment:
The 2.7 back-ported version of this patch appears to have broken compilation on
the Windows XP buildbot, during the OpenSSL build process, when the newly built
Python is used to execute the build_ssl.py script.
After this patch, when that stage executes, and
David Bolen added the comment:
I ran a few more tests, and the generated executable hangs in both release and
debug builds. The closest I can get at the moment is that it's stuck importing
errno from the "import sys, errno" line in os.py - at least no matter how long
I wait a
David Bolen added the comment:
Oops, sorry, I had just followed the commit comment to this issue. For the
record here, it looks like Benjamin has committed an update (5e8fa1b13516) that
resolves the problem.
--
___
Python tracker
<h
David Bolen added the comment:
While running a manual test (make buildbottest) on my 2.7 Ubuntu buildbot, I
ran into an exception in this patch:
The tail end of the test run:
[401/401/1] test_signal
379 tests OK.
1 test failed:
test_curses
21 tests skipped:
test_aepack test_al
New submission from David Bolen:
It appears that the test host (sha256.tbs-internet.com) used by test_algorithms
in test_ssl.py no longer exists.
It was showing up as a certificate failure in the test because it ended up
falling back to a resolv.conf search path which yielded a host that did
David Bolen added the comment:
Ah, it appears that the transient_internet context manager in the test causes
it to be skipped if the host is unknown. So mine was just "lucky" in that it
fell back to connecting somewhere else.
I've removed my resolver search path on bolen-ub
David Bolen added the comment:
I'm including some comments here from an email thread I had with Victor about
this issue on the Win8 buildbot, which led to his recent changeset 2b25fa7e3b7a.
The Win8 3.x failure (the 5 != 4 length error) was due to the revision of
os._DummyDirEntry (intro
New submission from David Bolen:
I'd like to propose backporting the change in issue 22734 to the 2.7 branch.
The marshal recursion depth appears to be at the root of the failures of the
Windows 8 and 10 buildbots in test_marshal on that branch, which is still using
a depth of 2000.
Th
Changes by David Bolen :
--
nosy: +db3l
___
Python tracker
<http://bugs.python.org/issue23314>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Bolen added the comment:
It's been on the cusp of shutdown a few times now, but tweaks to maintain
compatibility for the occasional issue always seem to materialize (thanks to
Ned in many cases).
To Ned's question, the slave is currently operating under 2.5.1 which I must
h
David Bolen added the comment:
I've bumped the tiger default python to 2.7.12 and updated hg to use it
(bumping to 3.9.1 in the process). It appears to have fixed the current touch
and compile errors. I've restarted builds for the most recent commits.
The need for a tiger slave i
101 - 168 of 168 matches
Mail list logo
