Steve Dower added the comment:
> I've already installed for all users, just not into the default "C:\Program
> Files\", but instead "C:\Programs\Python\"
Ah yes, that indeed rules out my first suspicion.
> Fixing tests is not enough, because it is often
Steve Dower added the comment:
Yes, unfortunately the external build was not referencing a tag in those
sources but a branch, so when the newer version was pushed they picked it up.
We fixed the pin in
https://github.com/python/cpython/commit/8c3a10e58b12608c3759fee684e7aa399facae2a
You
Steve Dower added the comment:
> This change has been discussed, but I don't know whether or not it's just a
> pipe dream
Still a bit of a pipe dream, but I'll add this issue as something that would be
fixed by it (to stack up against the list of things
Steve Dower added the comment:
New changeset 5846c9b71ee9277fe866b1bdee4cc6702323fe7e by Erlend Egeberg
Aasland in branch 'main':
bpo-44848: Update Windows installer to use SQLite 3.36.0 (GH-27622)
https://github.com/python/cpython/commit/5846c9b71ee9277fe866b1bdee4cc6
Steve Dower added the comment:
I'd guess that these tests are assuming that sys.executable contains only ASCII
characters. All the tests run in a non-ASCII working directory, so it's only
the runtime that is not tested propersy here.
The easiest way for Ming Hua to test this is
Steve Dower added the comment:
That looks like a relocatable path anyway, which means you wouldn't want to
compile it into the binary. Your patch to select a default value at runtime is
probably better.
The compile-time option is meant for a system dire
Steve Dower added the comment:
New changeset ef9e22b253253615098d22cb49141a2a1024ee3c by Steve Dower in branch
'main':
bpo-45055: Add retry when downloading externals on Windows (GH-28399)
https://github.com/python/cpython/commit/ef9e22b253253615098d22cb49141a
Change by Steve Dower :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45013>
___
___
Steve Dower added the comment:
I think the PR is basically ready, unfortunately it's stuck behind a CI issue
we only just fixed, and needs to merge from main before it'll clear.
Posting here once CI is green will get attention faster than on GitHub.
--
versions: +Python 3.
Change by Steve Dower :
--
keywords: +patch
pull_requests: +26813
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28399
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
I (finally) posted the updated SQLite sources to the repo, so PR 27622 should
build now. (I also retriggered CI)
That said, it *might* need to merge from main again to take a fix for a
CI-blocking issue
Steve Dower added the comment:
Thanks for the PR.
Just wanted to acknowledge that we've seen it. Unfortunately, I'm not feeling
confident to take this change right now - encodings are a real minefield, and
we need to think through the implications. It's been a while since
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
New changeset f4b94b1f57827083990272b5f282aa1493ae2bf4 by Steve Dower in branch
'main':
bpo-45220: Avoid automatically selecting the Windows 11 SDK preview when
building (GH-28393)
https://github.com/python/cpyt
Change by Steve Dower :
--
keywords: +patch
pull_requests: +26805
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28393
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
> C:\Program Files (x86)\Windows Kits\10\Include\10.0.22000.0\um\winnt.h
This appears to be the Windows 11 preview SDK, so most likely it's a bug in
that. We'll obviously need some logic to not automatically upgrade to this
Steve Dower added the comment:
The build order change was not backported (and should not be), so it's
unrelated to the failures on 3.9 and 3.10.
More likely this is either a problematic compiler update, or some additional
data leaking into the build information (e.g. I could see
Steve Dower added the comment:
I agree with Raymond. Let's stop throwing more code at this until we've figured
out what's going on and revert the change for now.
--
___
Python tracker
<https://bugs.pyt
Steve Dower added the comment:
Should be able to, yeah. Though I didn't test that.
--
___
Python tracker
<https://bugs.python.org/issue45188>
___
___
Pytho
Steve Dower added the comment:
New changeset 09b4ad11f323f8702cde795e345b75e0fbb1a9a5 by Steve Dower in branch
'main':
bpo-45188: Windows now regenerates frozen modules at the start of build instead
of late (GH-28322)
https://github.com/python/cpyt
Change by Steve Dower :
--
keywords: +patch
pull_requests: +26731
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/28322
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
Only thing I'd add is that you should just be able to list the required .c
files in _freeze_module.vcxproj (formerly known as freeze_importlib.vcxproj)
rather than depending on pythoncore.vcxproj.
That will generate twice as many .obj files for those mo
Steve Dower added the comment:
At this point, this isn't a helpful bug report anymore.
--
resolution: -> out of date
stage: -> resolved
status: pending -> closed
___
Python tracker
<https://bugs.pyth
Steve Dower added the comment:
Also, can you include your full task definition? There are a lot of options
there which could cause it to launch in a different working directory (which
will mess with your relative paths) or as a different user (which could mess
with whether you can import
Steve Dower added the comment:
Going to just decide that we won't backport the update. If a big enough
security issue is found we can consider it, but it would have to justify the
potential-but-unlikely breaking change for users who are relying on the name of
the DLL.
--
resol
Steve Dower added the comment:
Yep, this is malware. Don't download the file.
If this is a CPython issue that you want fixed, please provide a script to
generate the MSI.
--
resolution: -> rejected
stage: -> resolved
status: ope
Steve Dower added the comment:
> I'm not sure if PGO builds are reproducible, since there is a training step
> which requires to run a non-deterministic workload (the Python test suite
> which is somehow randomized by I/O timings and other stuffs).
I'm 99% sure it
Steve Dower added the comment:
New changeset 4dc4300c686f543d504ab6fa9fe600eaf11bb695 by giovanniwijaya in
branch 'main':
bpo-45022: Fix libffi DLL name in Windows installer sources (GH-28203)
https://github.com/python/cpython/commit/4dc4300c686f543d504ab6fa9fe600
Steve Dower added the comment:
The underlying issue is known and tracked by issue25166
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
superseder: -> Windows All Users installation places uninstaller in u
Steve Dower added the comment:
It should also be possible to reduce the stack size of each frame. We've done
that before, because there were multiple temporary buffers allocated on the
stack that were trivially moved into functions. I bet we can also reduce the
number of indirection
Steve Dower added the comment:
The test fix looks good to me. That resolves this issue, yes? The other work is
going on elsewhere?
--
nosy: -miss-islington
___
Python tracker
<https://bugs.python.org/issue45
Steve Dower added the comment:
New changeset 19871fce3b74fc3f37e334a999e00d0ef65a8f1e by Nikita Sobolev in
branch 'main':
bpo-45052: Unskips a failing `test_shared_memory_basics` test (GH-28182)
https://github.com/python/cpython/commit/19871fce3b74fc3f37e334a999e00d
Steve Dower added the comment:
I strongly disagree. If CI needs to be faster, please just change the CI
configuration. If contributors have to wait a few minutes longer, they can wait
- they'll save that time in local compilations.
Local debugging absolutely relies on debug builds. You
Steve Dower added the comment:
So on one hand, this change applies cleanly and it appears nothing needs to
change to adopt the newer version.
On the other hand, because the libffi DLL has a different name, it changes the
layout on disk. I know we don't do that (except in except
Steve Dower added the comment:
New changeset 6f8bc464e006f672d1aeafbfd7c774a40215dab2 by Steve Dower in branch
'main':
bpo-45022: Update libffi to 3.4.2 in Windows build (GH-28146)
https://github.com/python/cpython/commit/6f8bc464e006f672d1aeafbfd7c774
Change by Steve Dower :
--
pull_requests: +26585
pull_request: https://github.com/python/cpython/pull/28146
___
Python tracker
<https://bugs.python.org/issue45
Steve Dower added the comment:
The build for Windows is mostly automated, but it's triggered and monitored by
hand. The build steps are all in the source repo, and the builds themselves are
public at https://dev.azure.com/Python/cpython/_build?definitionId=21, but I'm
the only cor
Steve Dower added the comment:
I use git worktree as well (it's great for backporting - I have all the release
branches checked out all the time), but it likely means that you are regularly
downloading and extracting these files.
So whatever app is keeping the file handle open is pro
Steve Dower added the comment:
As the human "build bot" in question, yes, I do get tired :)
--
___
Python tracker
<https://bugs.python.org/issue45079>
___
__
Steve Dower added the comment:
This looks like a typical "lingering open handle" issue, though I can't tell
whether it's in the destination or the source.
Probably just needs a bit of retry logic (personally I'd be fine putting in
CPython itself, though that doesn&#
Change by Steve Dower :
--
keywords: +patch
pull_requests: +26451
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/28009
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
Realised that 3.8 needs the change to ensure it keeps using the same build of
libffi. Obviously it won't be getting the new one (and since the new one is
apparently a new API version, it may not even go into
Change by Steve Dower :
--
pull_requests: +26444
pull_request: https://github.com/python/cpython/pull/28001
___
Python tracker
<https://bugs.python.org/issue45
Steve Dower added the comment:
New changeset 969ae7f7356584e30667b4e490ffa2ffa1810429 by Steve Dower in branch
'main':
bpo-45022: Pin current libffi build to fixed version in preparation for
upcoming update (GH-27982)
https://github.com/python/cpyt
Steve Dower added the comment:
This first PR is just to avoid accidentally upgrading old builds. Otherwise, as
soon as I push the new build into the cpython-bin-deps repository, it'll take
precedence.
This one needs backporting into 3.10 and 3.9, but should be a
Change by Steve Dower :
--
keywords: +patch
pull_requests: +26430
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/27982
___
Python tracker
<https://bugs.python.org/issu
New submission from Steve Dower :
libffi is doing releases again! We're a few versions behind, so should pull in
the latest. https://github.com/libffi/libffi/
Adding RMs for opinions on backporting, and Ned in case this impacts the macOS
build.
--
components: Build, Windows, c
Steve Dower added the comment:
The new build and tags for Windows are up.
--
___
Python tracker
<https://bugs.python.org/issue45007>
___
___
Python-bugs-list m
Steve Dower added the comment:
That looks to me like no impact at all, which is great to see!
--
___
Python tracker
<https://bugs.python.org/issue44381>
___
___
Steve Dower added the comment:
Removing environment variables is "known" to be unreliable - another reason I
don't like modifying them from an installer. It's meant to remove the item from
the list based on value, so if anything has changed then it's not a huge
su
Steve Dower added the comment:
I don't think we upload the artifact from the MSI builds, sorry.
If Visual Studio has an option for the older version of .NET, then yeah,
that'll do it. But because it was an OS component, you may have to do it
through the OS dialog in the lin
Steve Dower added the comment:
Oh I remember this one. The Wix toolset still requires .NET 3.5, which you have
to install manually these days. Because it's being launched as a console app,
the UI never gets triggered.
I thought we had this in the devguide already... but maybe not (o
Steve Dower added the comment:
> I think you could also test this out by going to my fork ...
Good point, and I can't trigger a build on your fork.
This seems okay to me.
--
___
Python tracker
<https://bugs.python.org
Steve Dower added the comment:
I kicked off the build on the PR so we can see what errors it finds. Nothing
jumps out as obviously wrong in the changes, but it only takes one missing
reference to a file to break it all.
If you want to share the errors from your test machine, copy-pasting
Steve Dower added the comment:
> first-time contributors need a maintainer to approve the workflows for their
> PRs
This is an important security consideration, so I'd rather not go and change it.
On the main request, provided the workflow_dispatch is only triggerable by
non-c
Steve Dower added the comment:
That branch looks like you're on the right track. The build scripts in
Tools/msi should Just Work, so I'd be interested to see the error you get.
You can also submit it as a PR and the MSI will be built automatically.
One thing I noticed is updatin
Steve Dower added the comment:
The logic is probably simplest if you clone the Tools/msi/path project entirely
as pathappend. That will technically allow people to both prepend and append if
they set both flags, but I think it's okay to say "don't do that", especially
i
Steve Dower added the comment:
> why is this confusion not written here
>From https://docs.python.org/3/using/windows.html#configuring-python
> While the installer provides an option to configure the PATH and PATHEXT
> variables for you, this is only reliable for a single,
Steve Dower added the comment:
Prepending is used because it makes the most recently installed version of
Python the "active" one. It also ensures that a deliberate install is going to
override any applications that may have put their own copy on PATH
(deliberately or otherwise).
Steve Dower added the comment:
Timothy - are you able to share your install logs? Look for all log files
starting with "Python" in your %TEMP% directory.
We definitely do not (and without an installer rewrite, cannot) support
simultaneous per-user and per-machine installs o
Steve Dower added the comment:
I get stack overflows all the way back to 3.7, so it's probably not anything
new. But our stack overflow detection is clearly not going to catch this case.
It's really only set up for a direct call within Python code, but this is going
through many
Steve Dower added the comment:
I guess we've got a new path through the interpreter loop that takes more stack
space than before and isn't part of our existing recursion tests.
It's probably somewhere in the vector call changes. Capturing the stack at
overflow point should
Steve Dower added the comment:
Seems reasonable, contributions welcome.
I think it is not possible to add it as part of a per-machine install, since
there's no way to specify a user folder in the system key (environment
variables are not expanded as you might assume).
--
ver
Steve Dower added the comment:
Adding a new browser should be pretty easy, and it seems like that's all that
is needed here. It has to go into a few places though to support each platform,
and unfortunately it's only good for 3.11, and not any of the existing releases.
-
Steve Dower added the comment:
Yep, it's just a thank you and acknowledgement that was in the installer, so I
brought it forward.
However, we removed it a couple of versions ago (with Mark's permission). So
it's certainly not an issue that needs to b
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
New changeset 0b984d19547c2c16203e9ab2b2959fbabcde by Steve Dower in branch
'3.10':
bpo-44479: Do not regenerate files during a PGO build as it will invalidate the
profile. (GH-27462)
https://github.com/python/cpyt
Change by Steve Dower :
--
pull_requests: +25985
pull_request: https://github.com/python/cpython/pull/27462
___
Python tracker
<https://bugs.python.org/issue44
Steve Dower added the comment:
New changeset 3edec5d142365f2340865b4f12652e6aa627818a by Steve Dower in branch
'main':
bpo-44479: Do not regenerate files during a PGO build as it will invalidate the
profile. (GH-27460)
https://github.com/python/cpyt
Steve Dower added the comment:
> I suppose checking the file type in io._WindowsConsoleIO.isatty() could be
> useful in case the file descriptor gets reassigned to a non-console file
> (e.g. via os.close or os.dup2).
Pretty sure we currently don't support these anyway. Wi
Change by Steve Dower :
--
pull_requests: +25983
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/27460
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
New changeset 899e37b202c8b096d55e2e3c300c9759ebfe7f7a by Miss Islington (bot)
in branch '3.9':
bpo-40263: Fixes an off-by-one error in _winapi_WaitForMultipleObjects_impl
(GH-19501)
https://github.com/python/cpyt
Steve Dower added the comment:
We could also provide a better check in WindowsConsoleIO.isatty, since that
should have already handled most of the previous checks (I wouldn't want to do
a typecheck in getpass, though). But yeah, this seems like "sys.stdin and
sys.stdin.isatty
Steve Dower added the comment:
Fixed, better late than never.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
New changeset 92b5dc780db968f6277f42cb06926dddb7475dc6 by Ray Donnelly in
branch 'main':
bpo-40263: Fixes an off-by-one error in _winapi_WaitForMultipleObjects_impl
(GH-19501)
https://github.com/python/cpython/commit/92b5dc780db968f6277f42cb06926d
Steve Dower added the comment:
> do you know what the correct usage of importlib.util.spec_from_file_location
> is to match importlib.import_module ?
Maybe I'm misreading your example, but isn't the correct usage here to pass an
absolute location= argument? Or are you
Steve Dower added the comment:
> Would it be OK to run python in externals folder instead ?
No, because it needs to freeze with the current build. However, we should
definitely not regenerate anything when "$(Configuration) == 'PGUpdate'".
Checking that in regen.tar
Steve Dower added the comment:
> Maybe it would be useful to implement something like this in time.sleep()
> itself, but I don't know whether the need in a few cases warrants the
> increased complexity and cost in general.
It certainly wouldn't be worth the power and CP
Steve Dower added the comment:
Thanks for the contribution!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
New changeset 5fc784e28ab9cd02c30395d1973ff825b787efa2 by Miss Islington (bot)
in branch '3.9':
bpo-44572: On Windows, disconnect STDIN in platform._syscmd_ver() to prevent
erroneous STDIN consumption (GH-27092)
https://github.com/python/cpyt
Steve Dower added the comment:
Apart from the duplication, is there some reason why this is a problem?
The name is used in a number of other places where the version number is very
helpful. I'm not sure we can separate the variables i
Steve Dower added the comment:
I'm sure it will help, but official support will continue to be blocked by
availability of CI/CD systems for first- and third-party packages/testing.
--
___
Python tracker
<https://bugs.python.org/is
Steve Dower added the comment:
New changeset 0ee0a740e12ec8568aafa033aa6bb08b265afe26 by Konstantin-Glukhov in
branch 'main':
bpo-44572: On Windows, disconnect STDIN in platform._syscmd_ver() to prevent
erroneous STDIN consumption (GH-27092)
https://github.com/python/cpyt
Steve Dower added the comment:
msvc9compiler.py has been deprecated ever since _msvccompiler.py was
introduced, so no code should be using it (it was always internal anyway).
And now all of distutils is also deprecated, so you probably need to report
this to the setuptools project at https
Steve Dower added the comment:
Dropping the 3.9 backport. Pretty sure it only needs a clinic regen, but it's
also not worth the risk of changed behaviour.
We could consider it again after 3.10 has shipped if people really want it (and
can help validate it).
--
resolution: -&g
Steve Dower added the comment:
New changeset bbf2fb6c7ae78f40483606f467739a58cd747270 by Steve Dower in branch
'main':
bpo-44582: Accelerate mimetypes.init on Windows with a native accelerator
(GH-27059)
https://github.com/python/cpython/commit/bbf2fb6c7ae78f40483606f467739a
Steve Dower added the comment:
Huh, interesting that the email reply is identical to the one above from
Константин, but the email I received had no reference to bpo in it...
Okay, consider my reply above identical to the one I sent off list
Steve Dower added the comment:
Some quotes from my reply to an off-list email that may be useful for other
people who encounter this issue:
---
Apps that use Python-based plugins we can't make Just Work - it's up to the
host application to work with Python installs (or to bund
Steve Dower added the comment:
mimetypes doesn't _really_ support clearing, but `python.exe -m timeit "import
mimetypes as M; M.types_map.clear(); M.init()"` is pretty close.
Without the accelerator: 133ms
With the acce
Steve Dower added the comment:
It's only a rough benchmark, but my timings for `python -c "import mimetypes;
mimetypes.init()` were ~200ms without the accelerator and ~100ms with the
accelerator.
Since that includes all of startup, it's actually a better than 50%
Change by Steve Dower :
--
components: +Windows
nosy: +paul.moore, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue44582>
___
___
Pytho
Change by Steve Dower :
--
keywords: +patch
pull_requests: +25614
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/27059
___
Python tracker
<https://bugs.python.org/issu
New submission from Steve Dower :
mimetypes.init is slow on Windows because of the big registry search, which
involves touching thousands of entries in order to add a few hundred into the
initial table.
Things get even worse when audit hooks are enabled, because the winreg methods
need to
Steve Dower added the comment:
New changeset f2491c647937fc0871a473c19e3d5cb5392cfca0 by Steve Dower in branch
'3.10':
bpo-44479: Simplified LICENSE.txt regeneration in Windows build (GH-27056)
https://github.com/python/cpython/commit/f2491c647937fc0871a473c19e3d5c
Steve Dower added the comment:
You found your way to the issue tracker where we can help, which is more
enlightened than most of our other ~20 million users :)
Nuget allows you to download the packages directly. Go to the page I linked and
choose your version, then find the download link
Change by Steve Dower :
--
pull_requests: +25613
pull_request: https://github.com/python/cpython/pull/27058
___
Python tracker
<https://bugs.python.org/issue44
Steve Dower added the comment:
New changeset 3d3027c5fcc683c14ee55ad231d79971ba12b24d by Steve Dower in branch
'main':
bpo-44479: Simplified LICENSE.txt regeneration in Windows build (GH-27056)
https://github.com/python/cpython/commit/3d3027c5fcc683c14ee55ad231d799
Change by Steve Dower :
--
pull_requests: +25612
pull_request: https://github.com/python/cpython/pull/27056
___
Python tracker
<https://bugs.python.org/issue44
Steve Dower added the comment:
Didn't even realise we had a test for it. Maybe it only runs in install-like
layouts?
I'll simplify the regeneration by just doing it every time. Nothing else
depends on the license file, so it won't matter if we touch i
Steve Dower added the comment:
> Why does it have to be so complicated? What is the rationale behind
> prohibiting different patches in separate folders?
Most users don't want different patches in separate folders - they want to
update to the latest and greatest and use it
501 - 600 of 5794 matches
Mail list logo
