Steve Dower added the comment:
It looks like manifests aren't generated with CRT version info anymore either,
so I'll take this opportunity to clean up the build process some more too.
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
I've simplified the manifest handling:
* embed by default, since we no longer need to filter CRT SxS info
* omit UAC info from DLLs
* use full PATH when running tools
* some other tidying
Not necessarily going to wait for lots of reviews, as I know ver
Steve Dower added the comment:
+Martin, who apparently never made it onto nosy.
You should clear those variables, run a Repair, and then uninstall. This error
typically is because pip has become corrupted and cannot be removed.
This does not affect Python 3.5 or later.
--
nosy
Steve Dower added the comment:
I need to see the detailed log to be any more helpful. Can you try running this
command and post the log here:
msiexec /l*vx log.txt /x {9529565F-E693-3F11-B3BF-8CD545F5F9A0}
(Note that the UUID is different from earlier because it matches 3.4.3.amd64
and the
Steve Dower added the comment:
Start from an elevated command prompt. There's only one 64-bit build, so
that'll be it. Our name for it is amd64, even though it applies to both Intel
and AMD.
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
Thanks. Unfortunately I can't get anything helpful from that log because it's
failing too early. It seems like you have some corruption in your Windows
installer database, since it isn't even getting far enough into the Python
installer. I
Steve Dower added the comment:
Made a couple more changes (including a fix for vcruntime140.dll embedding)
after testing numpy's build, but that worked fine with the final fixes.
--
resolution: -> fixed
stage: -> resolved
status: ope
Steve Dower added the comment:
This option is no longer set in 3.5/3.6 (which don't use msvc9compiler.py).
I'll get it for 2.7 and 3.4.
--
type: compile error -> behavior
versions: -Python 3.5
___
Python tracker
<http://bugs.pyth
Changes by Steve Dower :
--
assignee: tarek -> steve.dower
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pytho
Changes by Steve Dower :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue23970>
___
___
Python-bugs-list
Steve Dower added the comment:
Fixed this, and forgot I had a bug open for it so I didn't reference it from
the commit.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Steve Dower added the comment:
I did not get a helpful response from the compiler team, so the optimized
function will have to stay disabled for 3.5.
Moving this to 3.6 in the hope that we can figure it out by then.
--
versions: +Python 3.6 -Python 3.5
Changes by Steve Dower :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19450>
___
Steve Dower added the comment:
Done for 2.7, 3.5 and 3.6. Decided against touching 3.4 because it's not really
an issue with MSVC 10.0, just 9.0 and 14.0. And I used eryksun's suggested
approach.
--
resolution: -> fixed
stage: -> resolved
status
Steve Dower added the comment:
We won't really know until we've gotten feedback from people with b4 who
install rc1 - the upgrade step is the part that needs testing, and that takes
two releases.
If you want to pull the priority down though
New submission from Steve Dower:
platform._syscmd_ver() calls platform.popen() which raises a
DeprecationWarning. This causes tests with `@skip(platform.machine() == '...')`
decorators to fail.
The fix is to call `os.popen()` - patch attached. (platform.popen() just raises
the w
Steve Dower added the comment:
Have you opened up the repo yet? I'm getting "no access" errors from BB.
--
___
Python tracker
<http://bugs.pyt
Steve Dower added the comment:
PR is at
https://bitbucket.org/larry/cpython350/pull-requests/1/issue-24839-platform_syscmd_ver-raises/diff
(For my sanity, your 3.5 branch and the hg.p.o 3.5 branch *are* currently in
sync, yes? Any value in adding a 3.5.0 branch for your divergence so we can
Changes by Steve Dower :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
If this occurs in 3.5 then it needs to be fixed (though I thought I'd already
fixed it once...).
I'll take a look.
--
assignee: -> steve.dower
status: closed -> open
versions: +Python 3.5, Python
Steve Dower added the comment:
Yes, I see. Thanks for clarifying, it seems all the installers are fine but
Windows will generate associations that don't forward arguments.
--
assignee: steve.dower ->
resolution: -> not a bug
status: open -> closed
versions: -Python 3
Steve Dower added the comment:
I'm afraid there's no easy way to revert it. I may get to invest the time for
3.6's launcher[1] to make it available in Default Programs, but I've always
struggled to get that to work properly.
Explorer should always use the per-user comman
Steve Dower added the comment:
Updated the documentation and it should be in 3.5.0rc1's docs on using with
Windows.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Steve Dower added the comment:
I haven't seen this at all, so until we see a repro of it, I'm closing.
--
resolution: -> works for me
status: open -> closed
___
Python tracker
<http://bugs.py
Steve Dower added the comment:
Doesn't seem to be anything left to do here, so closing as fixed.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.pyth
Steve Dower added the comment:
It doesn't apply to 3.5 or later, so it's up to Martin whether he wants to
apply it for 3.4. (I suspect not, but I'm not about to preempt his call.)
--
versions: -Python 3.5
___
Python tracker
<http
Steve Dower added the comment:
Yep, this is my fix for the same issue pre-RC1 not quite working out (I'm
guessing some difference between my dev box and my build box).
If you go into your DLLs directory there's an extra subdirectory
(Microsoft.VC140.CRT or similar) with a single
Steve Dower added the comment:
Pull request for 3.5.0 is at
https://bitbucket.org/larry/cpython350/pull-requests/3/issue-24847-fixes-tcltk-installer-layout/diff.
When merged, this can change back to normal priority for the rest of the fix.
Long term (probably 3.5.1, possibly 3.5.0rc2 if I can
Steve Dower added the comment:
Zach has the best chance of being able to review, if only because he can
probably build the installer. I've added all the Windows experts just in case.
There's quite a bit of MSBuild magic involved here though - I have trouble
getting good reviews of
Steve Dower added the comment:
Mark, IIRC you've got VS 2015? Anyone with VS 2015 installed (or the full CRT
redistributable) is unaffected because the required file is already in their
system path - this includes my build machine, which is why all my tkinter tests
passed before pushin
Steve Dower added the comment:
Attaching two patches that fix the tcl/tk build to not require vcruntime140.dll
at all. This is the better fix, though I haven't yet tested it thoroughly
enough to convince myself that it's ready. One patch is for tcl/tk/tix
themselves (which I
Changes by Steve Dower :
Added file: http://bugs.python.org/file40169/remove_vc140_py.patch
___
Python tracker
<http://bugs.python.org/issue24847>
___
___
Python-bug
Steve Dower added the comment:
No, any machine with Visual Studio installed is unaffected by this. That
buildbot seems to have a previous failed/aborted build that still has some
files locked. A reboot is the easiest solution, but going through and killing
any extra processes is what's n
Steve Dower added the comment:
Those libraries will depend on vcruntime140.dll which is not installed with
CPython right now. In order for packages built with future compilers to work we
need to statically link that dependency but not ucrt, which there are linker
options for.
I'm thi
Steve Dower added the comment:
I'll submit them upstream if we decide they're what we want, as I've done with
other patches for them. Or if we want to figure out reliable builds with
avcxproj I'm okay with that too.
The fix that needs testing now is already checked in for
Steve Dower added the comment:
Rereading the discussion, there seems to be agreement that this is an
enhancement. It does not apply for Python 3.5 (which requires a compiler
without the bug that causes this), and Python 3.4 is no longer eligible for
enhancements. I'm closing this as o
Changes by Steve Dower :
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue24872>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Steve Dower:
The C Runtime used for Python 3.5 and later consists of two DLLs. One,
ucrtbase.dll, is an operating system component that can be assumed to be
available and up to date (or will be installed by the Python installer).
The second DLL is vcruntimeXXX.dll, where
Steve Dower added the comment:
Actually, that's a pretty good idea (I'd certainly use it), though it would
come with a big fat warning sign. I'll add an issue for it.
Whether it would fix this particular issue is unclear. I suspect this one is
due to environment variabl
New submission from Steve Dower:
On uninstallation, we should display a checkbox to aggressively clean up the
install. This would include:
* delete the main registry key and all children, regardless of whether we
created them or not
* delete the main install directory and all subdirectories
Steve Dower added the comment:
(Terry - FYI as it was your suggestion, but feel free to un-nosy yourself if
you want.)
--
nosy: +terry.reedy
___
Python tracker
<http://bugs.python.org/issue24
Steve Dower added the comment:
I can't vouch for Python 2.2, but Python 3.5 and later should not have any
interference with other Python versions unless you choose to add it to PATH. We
have kept all installed files and registry keys in their own versioned paths
for a long tim
Steve Dower added the comment:
I guess those imports are expected to come from vcruntime. Rebuilding the
static libraries may be the only option then, sorry (on the bright side, VC 14
has much better C99 support than earlier versions, so things should be better
once we get past the problems
Steve Dower added the comment:
I've made a build of rc1 with the installer fix that's currently being
considered for 3.5.0:
https://pythonbuilds.blob.core.windows.net/temp/python-24847-1.exe
(This is a test-marked build that *should not* affect another 3.5 install, but
if it does p
Steve Dower added the comment:
A second test build with the attached patches applied directly to 3.5.0rc1.
(You'll need to remove the first test build before installing this).
https://pythonbuilds.blob.core.windows.net/temp/python-24847-2.exe
Any confirmation that these work wou
Steve Dower added the comment:
#2 should be fixed with the new installer (not necessarily the 3.5.0a/b/rc
versions, but final 3.5.0->3.5.1 and upwards should be fine).
The problems with 3.4's installer seem to be largely due to the pip bootstrap
being a critical part of uninsta
Steve Dower added the comment:
Yeah, should have mentioned the smartscreen warning. The official builds are
Authenticode signed, which prevents that warning appearing.
I promise the installers are safe :)
--
___
Python tracker
<h
Steve Dower added the comment:
I expect that, but most extensions don't seem to be in that category so this
will help remove the administrator barrier.
Thanks for going through that tedious process. I'll put up a patch later today
and submit
Changes by Steve Dower :
--
components: +Documentation, Extension Modules
priority: release blocker -> high
___
Python tracker
<http://bugs.python.org/issu
Steve Dower added the comment:
Actually, on rereading this (during daylight hours, previous response was
before 6am my time) the patch wouldn't help. I need to write some porting notes
for rebuilding static libraries with suitable settings. I'll base it on my
initial post and find
Steve Dower added the comment:
Boost requires C++ anyway doesn't it? So the full redist will be required.
These options are only useful for pure C sources.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Probably I'm missing something. Maybe there's a subset of C++ that doesn't rely
on it - a decent amount of the standard template library is generated at
compile time.
If the dependency isn't there, it'll be fine.
Do you think it'
Steve Dower added the comment:
Unfortunately applocal deployment doesn't solve the versioning issue - you'll
always need to use VS 2015 to build for Python 3.5.
There are only a few more libraries that are affected by /MT. msvcp140.dll is
the most likely one here. Doing the same /no
Steve Dower added the comment:
We can't have Python run VCredist because it requires administrative privileges
and installing Python does not require those. This is actually one of the
biggest complaints about the current installer, but because it looks like the
design and not a bug it
Steve Dower added the comment:
> Why not [require administrative privileges]?
Because some people want to use Python and don't have administrative
permissions on their own machine (e.g. students, employees, researchers, etc.)
> The standard approach is to rebuild extension for
Steve Dower added the comment:
I'll withdraw my current pull request and make a new one tomorrow. I prefer to
check into 3.5.1 immediately, and especially since this one will be covered by
the buildbots, so I'll do that first.
--
___
Pyth
Steve Dower added the comment:
Posting the actual changes made to Tcl and Tk, mainly so I can link them from
the upstream issue I'm filing.
--
Added file: http://bugs.python.org/file40206/tcltk_ucrt_option.patch
___
Python tracker
Steve Dower added the comment:
I've been ignoring this because I wasn't assigned...
Here's the options. If we make it load ucrtbase.dll directly (which does still
have named exports, and also uses the API schema on Windows 10):
* some code that uses it will need updating (due
Steve Dower added the comment:
Larry - PR for you at
https://bitbucket.org/larry/cpython350/pull-requests/6/issue-24847-removes-vcruntime140dll/diff
The buildbots are happy with this change, and so am I. Zach also had a look at
the Tcl and Tk patches, and I've already heard back from ups
Steve Dower added the comment:
Switching distutils.spawn to simply use subprocess.Popen (probably keeping the
explicit path search) looks good to me.
Quoting rules are different when you call with shell=True (aka "cmd.exe /c"),
since then you also need to escape ^, | and > (with
Steve Dower added the comment:
FYI - the Tcl and Tk changes have been committed upstream:
http://core.tcl.tk/tcl/tktview/00189c4afcb9e2586301d711f71383e48817a72d
--
___
Python tracker
<http://bugs.python.org/issue24
Steve Dower added the comment:
Maybe a better starting point is to monkey-patch via setuptools? I know it's
nasty, but it'll give us a chance to actually iterate on this before committing
to a distutils change. (IMO the biggest problem with distutils is that it gets
basically
Steve Dower added the comment:
The problem is I can easily find plenty of cases where it won't work.
My biggest concern is that list2cmdline will require already-quoted arguments,
which is going to break anyone who's already worked around distutils failing to
do so (which makes
Steve Dower added the comment:
FWIW, the problem in the original post is that '-DMODULE_VERSION="1.0.5"' is
not quoted by distutils and the quotes are eaten.
This can be fixed by specifying '-DMODULE_VERSION=\"1.0.5\"'. There are no
spaces in the argu
New submission from Steve Dower:
The MSIs for debug symbols and binaries have the same descriptions as the main
installers, so you can't distinguish between the packages in lists like
(get-package python).Name (in Powershell):
Python 3.5.0rc1 Development Libraries (64-bit)
Python 3.5
Steve Dower added the comment:
That would break paths like "\" or "D:\" ("D:" != "D:\" - the backslash is
meaningful here), but I'm fairly sure _nt_quote_args could add '\\"' to the end
if it ends in a backslash already (to es
Changes by Steve Dower :
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.org/issue4709>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
I notice you say "adopt" rather than "vendor" - effectively removing distutils
from the stdlib?
It could work, but to really be able to move distutils forward we need some
sort of side-by-side versioning, such that a package can decla
Steve Dower added the comment:
Do you know where that time is being spent?
I'd guess it's in link.exe (or lib.exe) while it displays a "generating code"
message. You should be able to omit the "/LTCG" option from lib.exe when
building a static library, thoug
Steve Dower added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue24953>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Steve Dower added the comment:
Seems like a fairly obvious bug. From
https://docs.python.org/3/c-api/init.html#c.Py_SetPath
> This also causes ... sys.prefix and sys.exec_prefix to be empty.
> It is up to the caller to modify these if required after calling
> Py_Initialize().
Appar
Steve Dower added the comment:
The patch should just set it once in pyproject.props, not in each project.
Why is this necessary? Is there an option we should be exposing in some other
way?
--
___
Python tracker
<http://bugs.python.org/issue24
Steve Dower added the comment:
I assume you're referring to #24974? The default (for MSVC) is /fp:precise,
which should allow fenv_access, but maybe ICL uses /fp:fast by default for the
extra speed?
It's not a safe 3.5 change now, but compiling with /fp:fast by default and
usi
Steve Dower added the comment:
It should be defaulting to precise mode, but maybe ICC has a different default?
I wrote on #24973:
It's not a safe 3.5 change now, but compiling with /fp:fast by default and
using #pragma float_control(precise, push)/#pragma float_control(pop) around
Steve Dower added the comment:
fenv_access is not available when compiling with /fp:fast, which is apparently
ICC's default.
The proposed workaround here changes that default to /fp:strict, which is a
very different model, for all of CPython. I proposed using #pragma
float_control to
Steve Dower added the comment:
All environment variables are promoted to MSBuild properties, so if you "set
IncludeSSL=false" before building then it will show up (which is exactly how
the proposed patch is getting CFLAGS in).
Unfortunately, batch file argument parsing is pretty h
Changes by Steve Dower :
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.org/issue7175>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
It may be possible to dynamically link the Fortran library in a similar
fashion, though it depends on what code the compiler generates. For Python's
purposes, statically linking it probably isn't a bad idea.
I'll have to check out whether the
Steve Dower added the comment:
The FLS limit is definitely still there, and it still seems to be 127, which
would explain the issues.
Best fix I have for this is to build with /MD and force vcruntimeXXX.dll to
always be copied alongside builds. That will solve the installation issue and
the
Steve Dower added the comment:
I'd be happy to always disable assert dialogs/output in regrtest, and then use
"-n" to enable stderr output. That way people simply testing their own debug
builds don't think it's failed, and the buildbots keep all the ou
Steve Dower added the comment:
It'll have to be backed out. There may be a fix to salvage some of the
functionality, but it's certainly too significant at this stage.
--
___
Python tracker
<http://bugs.python.o
Steve Dower added the comment:
Here's an alternative to backing out the change, and it's simpler than I
expected when I said it would be too much for 3.5.0.
We add an 'arguments' parameter to os.startfile and use that instead of
subprocess.call(shell=True). The underlyi
Steve Dower added the comment:
Patch for backing out #8232's changes.
--
Added file: http://bugs.python.org/file40376/25005_2.patch
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Patch 1 also requires a minor update to Doc\library\os.rst:
-.. function:: startfile(path[, operation])
+.. function:: startfile(path[, operation[, arguments]])
...
+*arguments* is passed to the underlying :c:func:`ShellExecute`
+call. Its format is determined by
Steve Dower added the comment:
I'll do the PR.
--
___
Python tracker
<http://bugs.python.org/issue24917>
___
___
Python-bugs-list mailing list
Unsubscr
Steve Dower added the comment:
> Rather than debating about how various platforms handle malformed
> format strings for strftime(), and whether or not they crash, we
> should simply prevent the native strftime() function from seeing
> them in the first place.
The crash is nothin
Changes by Steve Dower :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
I actually made the default per-user, specifically for cases like this. With a
default install that the current user has done, pip does not need to be run as
admin.
If the system administrator has installed Python for all users, then --user
needs to be
Steve Dower added the comment:
I applied the AIX fix to 3.4 (introduced in #19634). Python 3.2 and 3.3 aren't
affected.
--
assignee: -> steve.dower
resolution: -> fixed
stage: patch review -> commit review
status: open -> closed
_
Steve Dower added the comment:
I'll fix the PEP 7 stuff (mostly inherited).
MSVC can also handle '%#' and '%' as format strings (producing '' in both
cases). If that matches libc behaviour, I see no reason to raise a ValueError
here apart from consistency
Steve Dower added the comment:
Whoops, must have done a bad copy-paste to get that DECREF in there (I couldn't
apply the patch directly because it didn't come from an HG repo, so I had to do
it by hand).
MSVC seems somewhat inconsistent about its response:
>>> strftime(
Steve Dower added the comment:
Having now read over this whole issue, I don't actually see where the security
vulnerability is (on Windows at least).
This is a user-mode read, so it can only access memory in the same process, and
it doesn't display it anywhere. The worst that can
Steve Dower added the comment:
I'll get my commits out of the way to make the buildbots green again.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Yeah, I came in late and in too much of a rush too :(
Backed out the broken changes, and now I'm off to bed. Not convinced there's
anything that needs fixing here, and IIRC we argued through the different
platform behaviours on the issue when I remove
Steve Dower added the comment:
Good to go!
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Steve Dower added the comment:
Larry: agreed, no crashing. We'll get the trivial fix in that doesn't raise any
error, and should probably stop suppressing the exception in the situation
eryksun describes. That will correctly expose the platform's strftime semantics.
Unless yo
Steve Dower added the comment:
Does that mean not shipping either of them in 3.5.0 at all? Do you need
convincing or a simpler patch?
--
___
Python tracker
<http://bugs.python.org/issue25
Steve Dower added the comment:
New patch attached that just breaks out of the scanning loop and lets the
system CRT handle invalid format strings. Fixes the condition that was
suppressing some errors on Windows.
Also fixed the PEP 7 issues around the changed code (I believe). No new test
Steve Dower added the comment:
FWIW, those macros prevent a certain class of "undefined behavior," which in
this case is to terminate the process rather than return an error code. They
don't do anything to prevent crashes due to exploitation or malicious code.
The place
Steve Dower added the comment:
How's this for the test (I added an explanatory comment, since it may look like
it isn't testing anything to someone who isn't familiar with the issue):
def test_strftime_format_check(self):
# Test that strftime does not crash on
4901 - 5000 of 5794 matches
Mail list logo
