Steve Dower added the comment:
I must have missed something when I merged files to create the diffs. In any
case, you'll still require VC9 or VC10 to be able to build something compatible
with a CPython release (though maybe that doesn't matter for Cython? I don't
know).
When
Steve Dower added the comment:
I believe that is all that is missing from the patches I posted, though I'd
have thought that having Visual C++ 2010 Express installed would be sufficient
without the patch (though you didn't mention C++, so maybe you have a diff
Changes by Steve Dower :
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.org/issue1284316>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
I just tried it and had no trouble building and running the ssl tests on
Windows.
> python Lib\test\regrtest.py -u network -v test_ssl
> ...
> Ran 38 tests in 7.700s
>
> OK (skipped=2)
--
___
Python
New submission from Steve Dower:
#20406 changed the icon used by IDLE, but forgot to include the new file in the
Windows installer. As a result, IDLE won't start.
I've attached a patch. 3.4 is unaffected, probably because msi.py changed
significantly at some point.
(I don
Steve Dower added the comment:
Martin - sent. I think I need some bits flipped on my account here too.
Will/can you take care of that for me?
Tim - thanks. My next task was to figure out who else has an interest in this
area. I wasn't sure if the 'windows' tag was accurate, but
Steve Dower added the comment:
Currently it's an entirely manual process, which is something I intend to work
on for 3.5 and beyond. As far as post-mortem on this issue goes, Martin would
have found it as well, since I was doing exactly what he said he normally does.
The "real&quo
Steve Dower added the comment:
> Yes, by all means, commit it.
Obviously I spent too long writing my last comment :)
Pushed.
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Steve Dower :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue21467>
___
___
Python-bugs-list
Steve Dower added the comment:
As far as Python 2.7 is concerned, I will be avoiding making any changes to the
installer at all.
For Python 3.5 I'm trying to work out a few of the install issues, one of them
being not installing into Program Files. I think symlinks may be the way to
Steve Dower added the comment:
> there's a bug in Explorer that breaks opening symbolic links to EXE, COM,
> CMD, and BAT files
Do you know which versions of Windows this applies to? It works fine for me
(though I'm up to date), and the file associations have not changed.
Steve Dower added the comment:
Apparently there's a distinction between absolute and relative symlinks. Do you
see a difference between:
> mklink python2.7.exe python.exe
and
> mklink python2.7.exe C:\Python27\python.exe
?
--
___
Pyt
Steve Dower added the comment:
I noticed the same thing testing the 2.7.7rc1 installer, so I've got a fix for
2.7.7. The same issue exists for imghdrdata (which was added quite recently, it
seems).
Patch attached - any concerns?
--
keywords: +patch
nosy: +benjamin.pet
Steve Dower added the comment:
FWIW, the installers are about 130kb larger with the files included.
--
___
Python tracker
<http://bugs.python.org/issue19
Steve Dower added the comment:
Thanks for catching this.
Do I need a specific version of Cygwin or will the latest version suffice?
--
___
Python tracker
<http://bugs.python.org/issue21
Steve Dower added the comment:
I installed mingw32-binutils and it seems to work fine. 2.7.7 will have the
file again.
--
___
Python tracker
<http://bugs.python.org/issue21
Steve Dower added the comment:
I can commit it, though I don't know how it'll affect Benjamin's release branch?
(Obviously the build will be fine either way - I had the patch applied for
2.7.7rc1.)
--
___
Python tracker
<http
Steve Dower added the comment:
Has the first log been abbreviated at all? It looks like it's trying to build
the tests before building the library...
(Nosied Martin, since he's managed to build this version of OpenSSL with VC10
and may have encountered this. I've only dealt
Steve Dower added the comment:
eryksun's analysis is correct. If the component is marked 64-bit then it will
not install on a 32-bit OS. This needs to be switched for the 32-bit installer.
(I also don't see why you'd want to set the 64-bit SharedDLLs key for a 32-bit
DLL. Is th
Steve Dower added the comment:
That reasoning makes sense. I don't see any other way to achieve the same thing
without requiring a newer version of Windows Installer on the machine
(msidbComponentAttributesDisableRegistryReflection requires 4.0).
Having a second component for 32-bit OS m
Steve Dower added the comment:
I compiled with COMPILERFLAGS=-DWINVER=0x0500 OPTS=noxp DEBUG=0 for tcl and
tix, and with just COMPILERFLAGS=-DWINVER=0x0500 DEBUG=0 for tk. These should
have matched the buildbot scripts, and I'm fairly sure they haven't changed
since 2.7.6, which
Steve Dower added the comment:
You're right, I had OPTS for tk and tix. I think I'm going to modify my build
scripts to use the buildbot scripts wherever possible. I also need to
parameterise msi.py a bit so I don't have to modify
Steve Dower added the comment:
The buildbot scripts don't build tix and the build_tkinter.py script has a
blatant error which prevents it from ever working (and old version numbers). I
have no experience with the buildbots, but I don't see how they can possibly be
producing correct
Steve Dower added the comment:
That's fine for 2.7.
I'm working on streamlining the project files for 3.5 to make my life easier
dealing with both installers and the multiple compiler situation, so I'll no
doubt poke that project at some point until my grand vision of
singl
Steve Dower added the comment:
The only reason to do it is to help out those who build from source, which I
suspect is an incredibly small group on Windows. We'd also be signing up to
keep doing it, and implying that it's been tested.
I say don't bother.
__
Steve Dower added the comment:
The two 'correct' options are adding the manifest or doing nothing (based on a
number of very passionate internal discussions I was able to dig up).
Without the manifest, various APIs may behave differently - it's the new way
that Windows dec
Steve Dower added the comment:
test_memoryview_assign seems to be okay, but the two test_lzma tests still fail
with the same message. Both pass without PGO.
I'll get in touch with the PGO team and try and get it fixed. I haven't
checked, but it looks consistent with Stefan's
Steve Dower added the comment:
> So have platform.win32_ver() return the true version is acceptable ?
>
> Note that the platform module is meant for identifying the platform,
> not the runtime compatibility environment, so it has a slightly
> different target audience
Yes, and
Steve Dower added the comment:
I've noticed this as well. I'm hoping to do a significant rework of the
installer for 3.5 and will keep this in mind, but I honestly have no idea how
to diagnose this in the current setup.
Windows Installer is responsible for the missing entries, and
Steve Dower added the comment:
This may actually be a Windows issue... the keys for uninstall are being
written to the Wow6432Node of the registry (on a 64-bit machine), and
apparently the Programs and Features panel does not read them from there.
The 64-bit installers should be fine (testing
Steve Dower added the comment:
Apparently keys in Wow6432Node are actually okay, so I'm not much closer to
figuring this out. As far as I can tell, the entry I have for Python 2.6.6
(which doesn't appear) has identical information to IronPython 2.7.4 (which
d
Steve Dower added the comment:
Okay, now it looks to me like the install that 'works' ran under the SYSTEM
account while the one that didn't work ran under my (admin) user account.
This may be caused by running the installer from an elevated command prompt. If
it detects t
Steve Dower added the comment:
It's actually bad code generation for the switch statement in
build_filter_spec() in _lzmamodule.c.
I've filed a bug, so hopefully it will be fixed, but if not then it should be
easy enough to exclude that function (or even the whole module - _lz
Steve Dower added the comment:
> Isn't PyLong_FromUnsignedLongLong() still involved through spec_add_field()?
The two issues were unrelated - the 'invalid filter ID' (4611686018427387905 ==
0x4000_0001) is the correct value but the wrong branch in the switch
was tak
Steve Dower added the comment:
I can certainly improve this for 3.5 as part of the move to VC14 (which will
require changes to distutils anyway). The installer won't touch it.
For earlier Python versions, I'd quite like to see setuptools take over
detection from distutils and p
Steve Dower added the comment:
If we wanted to migrate the instructions to 2.7/3.5 as suggested then there's
some updating to do, but if there's no plan to update them then I agree,
there's nothing to do here.
FWIW, the 3.5 installer will accept the same command line opti
Steve Dower added the comment:
My usual way of doing this is to use taskkill.exe, but that only uses process
name and not the full path, which may hurt people who are building with other
versions of Python open.
I'd rather use GetFullPathName than the current patch, but if wontfix i
Steve Dower added the comment:
> I'd be fine to reconsider if a previously-demonstrated bug is now
> demonstrated-fixed. However, if the actual bug persists, optimization
> should be disabled for all code, not just for the code that allows to
> demonstrate the bug.
I&#x
Steve Dower added the comment:
I don't have any extra insight into this. The documented resolution for mtime
on NTFS is 100ns (2s on FAT32), so without delaying by at least that long
you're not going to see an official change. The noise is probably from
floating-point conve
Steve Dower added the comment:
> 7. verify original_mtime - 0.001 < p.stat().st_mtime < original_mtime + 0.001
Actually, don't check the upper-bound here... that's a bad idea :)
--
___
Python tracker
<http://bugs
Steve Dower added the comment:
The "000" or "500" still smells of floating point rounding to me. Windows
appears to round-trip the values provided perfectly:
import ctypes
def do_test(t):
h = ctypes.windll.kernel32.CreateFileW("test.txt", 0xC000, 7, None
Steve Dower added the comment:
Or as Martin suggested earlier, time.time() could be returning different values
to what the system uses when it creates the file (which I assume is
GetSystemTimeAsFileTime/SetFileTime or the kernel-mode equivalent).
I only looked briefly at the touch
Steve Dower added the comment:
My understanding is that the best way to write Unicode to the console is
through WriteConsoleW(), which seems to be where this discussion ended up. The
only apparent sticking point is that this would cause an ordering
incompatibility with `stdout.write
Steve Dower added the comment:
Thanks Nick, but this has a pretty clear scope that may help the Unicode
situation in cmd but doesn't directly relate to it.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
The difference may be the "ALLUSERS=1" option. Windows Installer is supposed to
auto-detect this when an installer is run as an admin, but maybe something in
our authoring is preventing this detection?
When I get a chance I'll try both and see i
Steve Dower added the comment:
It's described at
http://msdn.microsoft.com/en-us/library/aa367559(v=vs.85).aspx, and frankly it
is incredibly confusing.
It is possible to reset ALLUSERS on the command line by specifying ALLUSERS=""
--
___
Steve Dower added the comment:
No idea, TBH, though I'd guess that the behaviour comes from the installed
version of Windows Installer and the database schema comes from the authored
version.
Nonetheless, if the solution is to add "ALLUSERS=1" to the command line when
doing
Steve Dower added the comment:
This has been confirmed as a bug in VC14 (and earlier) and there'll be a fix
going in soon.
For those interested, here's a brief rundown of the root cause:
* the switch in build_filter_spec() switches on a 64-bit value
* one case is 0x40
Steve Dower added the comment:
Should be there for 3.5 because I'm rewriting the installer.
Up to Martin whether he wants to change it for 3.4.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Probably, but that work is not going to be checked in for a while (until we
have guarantees that we'll be able to use VC14 and there's a 'go-live' version
available). If this is causing problems now, it should be fixed.
The patch looks fin
Steve Dower added the comment:
Looks pretty good. I'm happy to see more move into PCBuild - ideally, people
building a Python release should never have to look anywhere else.
buildmsi.bat can probably go away completely if the buildbots aren't using it.
3.5 will eventually have a .
Steve Dower added the comment:
Looks like a legitimate issue to me, and the patch is fine. It's probably
something that ought to be fixed in default too, since I don't see how it is
restricted to session 0 - any Python service will incorrectly treat these
notifications as interrupti
Steve Dower added the comment:
Looks like tools/demo just isn't included. I'm totally okay with including it -
looks like a few nice examples in there that I've never seen before.
If someone wants to do a patch for msi.py that's fine, but I'm intending to
have a com
Steve Dower added the comment:
The build environment won't help here, this requires some significant rewrites
within Python to remove usage of Windows APIs that don't work under the WinRT
sandbox (similar to the projects to embed Python in Chromium et al.)
I'd still like to s
New submission from Steve Dower:
In pythonrun.c, the is_valid_fd() function checks whether fileno(std*) are
valid before attempting to create IO objects for them. However, the class
created also checks using fstat().
In pythonw.exe built with VS 2013 (or 14, maybe 2012), the fstat() check
Steve Dower added the comment:
The fix is certainly needed in default, though I already have it in my fork for
porting to VC14.
I'm okay with the HAVE_ROUND change, but I think the VS2013 project files are
better off kept separate. We won't be rebuilding 2.x with a newer compiler
Steve Dower added the comment:
Yeah, I patched my msi.py to get the build going but haven't checked it in (it
was already after the tag...).
I'll fill out the next few minor versions and check it in.
--
___
Python tracker
<http://bu
Steve Dower added the comment:
This is definitely the same as #17797, so I'll close this as a dup. Over on
that issue, it's confirmed as fixed in VC14 (and it is - I've checked).
--
resolution: -> duplicate
status: open -> closed
_
Changes by Steve Dower :
--
nosy: +steve.dower
___
Python tracker
<http://bugs.python.org/issue16561>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
Automatically quoting arguments is more complicated than simply concatenating
quotes, unfortunately, and people are guaranteed to have come up with ways to
make it work already.
My vote is for leaving this alone and letting the higher level functions be
more
Steve Dower added the comment:
That last message should have been on #20451 :)
My thoughts on pyvenv are that it should be in Scripts\ if anywhere, but I'm
not desperate to have it on PATH. I would rather not start putting more files
alongside pytho
Steve Dower added the comment:
Automatically quoting arguments is more complicated than simply concatenating
quotes, unfortunately, and people are guaranteed to have come up with ways to
make it work already.
My vote is for leaving this alone and letting the higher level functions be
more
Steve Dower added the comment:
Also agreed with not exposing a side-channel to set errno.
I'd expect this to no longer be an issue with the stable CRT, but I'm not 100%
confident about saying that yet. In theory, there will only ever be one CRT
loaded in the future, but there's
Steve Dower added the comment:
msvc9compiler should not look for any versions of MSVC other than 9.0, since
extensions built using other versions will be subtly (or dramatically)
incompatible with Python unless you also rebuild Python itself with the same
MSVC version.
You can set
Steve Dower added the comment:
With 2.7 and 3.4 (same for 32- and 64-bit):
>>> f = open('test.bin', 'wb')
>>> f.write(b' ' * (1024*1024*100))
104857600
>>> f.close()
>>> import os
>>> os.stat('test.bin').st_si
Steve Dower added the comment:
I don't know enough about the SQLite API to determine whether we can safely
upgrade from 3.6.21 in Python 2.7, but since this doesn't appear to be a
security issue I don't see any solid justification for doing it anyway.
If someone else does it
Changes by Steve Dower :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue19450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
Yes. I don't have permission to close issues.
--
___
Python tracker
<http://bugs.python.org/issue21959>
___
___
Python-bugs-l
Steve Dower added the comment:
You can always deselect pip from the installation. Running it separately after
installation will no doubt show what the actual problem is.
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
At one point the version of OpenSSL on svn.python.org did not have the correct
makefiles for a 64-bit Windows build, but this was resolved. You also don't
need 64-bit Perl to generate these files, and the file has been renamed to
"prepare_ssl.py"
Steve Dower added the comment:
That installer doesn't even try and set PATHEXT, and the 3.4 installer appears
to set it correctly (for .PY, but not .PYW).
Are you sure it was an installer from python.org that overwrote your setting?
--
___
P
Steve Dower added the comment:
I don't think this is an appropriate fix, since in most cases there is no need
to prevent other Python threads running while inside RegSetValue. There are
also other ways that a context switch may occur during the enumeration which
will put the progr
Steve Dower added the comment:
Presumably the value for subkeyname being passed to OpenKey contains an
embedded null, which I believe is legal for the registry in general, but
doesn't make much sense in this context and is quite possibly a corruption
issue on your machine.
We can cert
Steve Dower added the comment:
FWIW, on my machine I don't have embedded nulls in any of the values that
enum_keys is looking for:
>>> import winreg
>>> hkcr=winreg.OpenKey(winreg.HKEY_CLASSES_ROOT, '')
>>> n = []
>>> i = 0
>>> wh
Steve Dower added the comment:
The 2.7 installer will be fine whenever the release manager asks for it
--
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
Agreed on both points, but we need to find someone willing to fix the 3.4
installer (I'm completely focused on the 3.5 installer, which won't suffer from
the first point).
There's a separate issue tracker for pip which would be the place to get th
Steve Dower added the comment:
Not in future 2.7 installers, certainly.
As for 3.5 and later, I'm not a fan of the global install anyway. I'd much
rather Python applications install a private copy of python##.dll, and I count
python.exe as just another application that should have
Steve Dower added the comment:
It should be fixable. In general, Unicode in the console is fine, but the CRT
doesn't handle it well (as shown by the _setmode extension being able to fix
it).
The 'correct' fix for Unicode in the console is at
http://www.siao2.com/2010/04/07/9
Steve Dower added the comment:
There is other work going on that will make the patches unnecessary. One
problem is that vcvarsall.bat isn't where msvc9compiler.py is looking, which
can be fixed with monkey patching in setup.py or in setuptools. The other
problem is that VC9 is hard t
Steve Dower added the comment:
Is resolve() using an *A() API rather than *W()? The \\?\ prefix does not work
with *A() APIs.
Also, names that are all dots are not supported by Windows at all. I'd expect
mkdir() to fail on that, but the \\?\ prefix disables some validation, so it's
Steve Dower added the comment:
Removing the _ext_to_normal() call in resolve() looks like the right fix to me.
--
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
I've been working on the rewrite for 3.5 already (progress at
http://hg.python.org/sandbox/steve.dower) - redoing the installer completely
was one of the conditions for when I signed on to own it.
Martin is still responsible for 3.4, and I'm build
Steve Dower added the comment:
Antoine almost certainly thought about this with pathlib and may know about the
change, or at least have some decent context on it.
I'm more inclined to think that os.path.isabs(r"\\server") should also return
False, since it's not a pat
Steve Dower added the comment:
Patch attached. (Kinda feel like this was too simple...)
--
keywords: +patch
Added file: http://bugs.python.org/file36549/22299_1.patch
___
Python tracker
<http://bugs.python.org/issue22
Steve Dower added the comment:
My experience says the main reason people want to know whether the path is
absolute is to figure out whether to do `Path.cwd() / path` or not. According
to that MSDN page, they shouldn't because the path starts with "//" (that is,
the last ch
Steve Dower added the comment:
Just did a double-take, but that output for Path('server\\').parts[0] is
actually correct...
>>> Path('server\\').parts[0]
'server'
>>> print(Path('server\\').parts[0])
\\server\\
Steve Dower added the comment:
Ah, thought it was too simple. I didn't realise that _getfinalpathname adds the
prefix.
New patch soon.
--
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Strips the prefix if it wasn't in the original path - otherwise, keeps it.
--
Added file: http://bugs.python.org/file36550/22299_2.patch
___
Python tracker
<http://bugs.python.org/is
Steve Dower added the comment:
Actually, I'd be inclined to never use the prefix within pathlib and then add
it on if necessary when converting to a string. That would also solve a problem
like:
>>> p = Path("C:\\") / ('a'*150) / ('a'*150)
>
Steve Dower added the comment:
If anyone wanted to test that really long path, here's the incantation to
create it:
>>> import os, pathlib
>>> os.mkdir("C:\\a")
>>> os.mkdir("C:\\a\\" + "a"*150)
>>> os.rename("C
Steve Dower added the comment:
It's no less expected than having OS functions fail because the path is too
long.
Using it to maintain dots at the end of directory/file names is a little less
safe and may break some code. Maybe pathlib should strip these if there is no a
prefix? (For ex
Steve Dower added the comment:
> This would only work for fully-qualified paths, right? Not relative ones.
Correct, and I think we're most of the way there with how drives are handled.
Since the prefix only works with absolute paths, why not treat it as part of
the dr
Steve Dower added the comment:
Right, what the prefix actually means is "treat this path as a blob and don't
do any processing". Some of the things that 'processing' includes are:
* CWD
* invalid names ('foo.' -> 'foo')
* adjacent backslashes (&
Changes by Steve Dower :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue22381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steve Dower added the comment:
Another alternative is to always leave the prefix there after calling resolve()
(as opposed to the current behaviour which is to always remove it). If the
Win32 API says that the path should include the prefix, then it should. There's
no reliable way
New submission from Steve Dower:
This patch has some minor changes to the build scripts for Python 2.7 on
Windows. They're fully tested on my build machine, but I wanted someone who's
more familiar with how the buildbots are set up to either confirm that the
Tools/msi scripts are n
Steve Dower added the comment:
Thanks for confirming. Somehow I never noticed the import config line - guess
that's a pattern I'm not really used to seeing. Still, I prefer having the env
variables there as I invoke the scripts through some batch files (very specific
to
Changes by Steve Dower :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue22398>
___
___
Python-bugs-list
Steve Dower added the comment:
Can you try running this command and then post the log file after installation
fails:
> msiexec /l*vx log.txt /i ""
--
___
Python tracker
<http://bugs.pytho
Steve Dower added the comment:
You almost certainly have a corrupted download. I'd try downloading the
installer again, perhaps with a different browser?
--
___
Python tracker
<http://bugs.python.org/is
4101 - 4200 of 5794 matches
Mail list logo
