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:
> 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:
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:
> 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:
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 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:
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:
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:
The new build and tags for Windows are up.
--
___
Python tracker
<https://bugs.python.org/issue45007>
___
___
Python-bugs-list m
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
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
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
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
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:
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 :
--
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:
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&#
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:
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:
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
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:
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
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:
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:
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:
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:
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 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:
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:
> 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:
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:
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:
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:
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:
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
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:
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
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:
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:
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:
> 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
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:
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 :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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 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 :
--
resolution: -> third party
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45013>
___
___
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
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:
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:
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:
> 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:
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:
> 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:
I meant I don't think we want that path upstream, and you should keep it as
your own patch.
We don't have a "share" directory as part of CPython, but this would codify it.
That would then conflict with your use of it in conda-forge.
It
Steve Dower added the comment:
We'd need to implement some form of data store for values on Windows, which
currently are not compiled in anywhere, and it would need a substitution syntax
to be updated at runtime.
We're talking a big feature now, and you'd end up having just
Steve Dower added the comment:
Strings are already special in that str.index() and str.find() both find
substrings, while list.index() only finds a single element.
If .find() also searched for a substring of the list, I think this could be
helpful. Even more so if it used an efficient
Steve Dower added the comment:
I fully support implementing the core idea of Stackless Python :)
I spent a whole EuroPython a couple of years back discussing the idea with
(apparently) everyone except Mark.
Though I wouldn't like to lose the ability to extract the Python sta
Steve Dower added the comment:
Could we add a compile-time requirement (most likely checked in tests, rather
than at build) that _PyImport_FrozenModules be sorted? Then we can at least
bail out of the loop early, and one day someone could make it a binary search.
--
nosy
New submission from Steve Dower :
I noticed that Python/frozen.c includes posixpath as 'os.path'.
This is not correct, and shouldn't be necessary anyway, because os.path is just
an attribute in "os" and not a concrete module (see Lib/os.py#L95 for the bit
that mak
Steve Dower added the comment:
Can you attach the log files stored in your %TEMP% as a zip file? They should
all start with "Python".
Be aware that they may contain personal information, such as usernames or
machine names. Feel free to scrub those first if necessary.
-
Steve Dower added the comment:
Passing the metaclass as a slot seems like the right idea for this API, though
I recall there being some concern about the API (IIRC, mixing function pointers
and data pointers doesn't work on some platforms?) that mean it'll be
deprecated in
Steve Dower added the comment:
Seems like it would be better to not check the file open/closed state on
peek/read when there is still buffered data?
--
nosy: +steve.dower
___
Python tracker
<https://bugs.python.org/issue44
Steve Dower added the comment:
But at least if it's available as a slot then a module is *able* to use it with
limited ABI going backwards. A new function doesn't allow that.
And yeah, it means they have to write more complex code than just a static
array definition, but people a
Steve Dower added the comment:
That change makes me much happier :)
Do you think we need a specific test added for this case? I'd guess we have
plenty of coverage for the changed macro already, but clearly nothing that
showed the issue b
Steve Dower added the comment:
> SleepConditionVariableSRW() can't be interrupted in PyCOND_WAIT() and
> PyCOND_TIMEDWAIT()
This was my immediate reaction as well.
Unfortunately, we keep seeing that all waits need to be interruptible, so
either a WaitForMultipleObjects or a sl
Steve Dower added the comment:
> As a tangential point, I think that the DLL case on Windows may be a case
> where Windows is not compliant with the C standard
I wasn't aware the C standard covered dynamic symbol resolution? "static"
anything in C is completely irreleva
Steve Dower added the comment:
The section of documentation you reference explains that this behaviour is not
covered by the standard ("applied to a non-static variable like
PyBaseObject_Type() is not required to produce an address constant"), and so
static addresses of exported
Steve Dower added the comment:
> MSVC rejects this standard-conforming TU when __declspec(dllimport) is added:
> https://godbolt.org/z/GYrfTqaGn I am pretty sure this is out of compliance
> with C99.
Windows/MSVC defines DLLs as separate programs, with their own lifetime and
en
Steve Dower added the comment:
The goal is reduced stack depth, not reframing the entire call model around not
having a C stack.
We can't even reasonably rewrite getattr() without supporting callbacks from C
into Python, so further generalisation is very unlikely.
But if you inspec
Steve Dower added the comment:
This needs to be a feature request against the script that you're running. They
have the option of not verifying TLS certificates if they choose not to, but
they are explicitly enabling the checks right now.
We can't add a command line option to disa
Steve Dower added the comment:
Python doesn't include any trusted certificates - it reads them from the
operating system. So you'll need to get the operating system vendors to include
it if you want it to be trusted by default.
Additionally, some libraries include a copy of Mozill
Steve Dower added the comment:
Adding Christian, as he's our expert in this area, and was also driving the
other bug.
--
assignee: -> christian.heimes
components: +SSL
nosy: +christian.heimes
___
Python tracker
<https://bugs
Steve Dower added the comment:
Looks like you should take the discussion to issue35665, and this one can stay
closed.
--
___
Python tracker
<https://bugs.python.org/issue45
Steve Dower added the comment:
Thanks Adam.
This analysis is correct, and I think there are two parts to this.
First, we probably need to add an os.path.realpath(path_to_venv) before we try
and launch the environment. We *could* limit this to when it's under AppData,
but I think lim
Change by Steve Dower :
--
keywords: +patch
pull_requests: +27028
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28663
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
New changeset a450398933d265011e1e8eae7f771b70f97945fb by AngstyDuck in branch
'main':
bpo-44687: Ensure BufferedReader objects with unread buffers can peek even when
the underlying file is closed (GH-28457)
https://github.com/python/cpyt
Steve Dower added the comment:
Thanks for sticking through it! Sorry about the delays, but I think we ended up
with a good fix.
--
___
Python tracker
<https://bugs.python.org/issue44
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 6035d650a322cec9619b306af2a877f3cead1580 by Miss Islington (bot)
in branch '3.9':
bpo-44687: Ensure BufferedReader objects with unread buffers can peek even when
the underlying file is closed (GH-28457)
https://github.com/python/cpyt
Steve Dower added the comment:
Judging from https://github.com/libffi/libffi, they could do with more
contributors/support over there.
I see a bunch of reports along these lines from a few years back, apparently
someone has a test suite that covers it, but hasn't merged it into the l
Steve Dower added the comment:
This will be the change to make "special" filenames only be special when used
on their own, and not as part of a path (e.g. you shouldn't have any trouble
with "aux" or "com" filenames either). I had expected it to roll out
New submission from Steve Dower :
As seen in the release build for 3.11a1, an assertion is raised when attempting
to launch the debug build out of tree.
_RegenTestFrozenmain:
Regenerate test_frozenmain.h
D:\a\1\b\bin\amd64\python_d.exe Programs
Steve Dower added the comment:
I believe this is because getpath has hit its final fallback case of looking in
".\DLLs" and ".\Lib" for the standard library, and has not performed proper
normalisation on these paths. So after removing the last segment, the result is
&q
Change by Steve Dower :
--
keywords: +patch
pull_requests: +27083
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28735
___
Python tracker
<https://bugs.python.org/issu
New submission from Steve Dower :
Currently the release build of the CHM file runs on my dedicated build machine,
which means there's no way to do a test run without starting the machine
(normally clearing the code signing and PGO properties allows a build without
needing it).
Origi
Steve Dower added the comment:
New changeset de4052fe0633e3a053e66c8477f13677054d6ede by Jeremy Kloth in
branch 'main':
bpo-45354: Skip obsolete device name tests on Windows 11 (GH-28712)
https://github.com/python/cpython/commit/de4052fe0633e3a053e66c8477f136
Steve Dower added the comment:
Thanks, Jeremy! And thanks for being on top of getting the Win11 buildbot set
up!
--
resolution: -> fixed
stage: patch review -> backport needed
versions: +Python 3.10, Python 3.11, Python 3.9
___
Python t
Steve Dower added the comment:
New changeset 5146877623ebe8a2806411703b0de9c0aba179a1 by Steve Dower in branch
'main':
bpo-45375: Fix assertion failure due to searching for stdlib in unnormalised
paths (GH-28735)
https://github.com/python/cpyt
Steve Dower added the comment:
New changeset d0d0909a3a0b553826d1ddbb04a676fdabb61359 by Miss Islington (bot)
in branch '3.10':
bpo-45354: Skip obsolete device name tests on Windows 11 (GH-28712)
https://github.com/python/cpython/commit/d0d0909a3a0b553826d1ddbb04a676
Change by Steve Dower :
--
stage: backport needed -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45354>
___
___
Pyth
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
Yeah, we're getting close. I'll reopen this issue for tracking.
We still need that pip release and it'll have to be merged into ensurepip.
We'll also need better access to test systems than any of us currently have
(the buildbot i
Steve Dower added the comment:
The version number for "Windows 11" still starts with 10.0. Just like how
Windows 5.x and 6.x were around for a very long time each ;)
There are tables in platform module that map the specific version to the
release name. These probably need to be
Steve Dower added the comment:
> Hmm, but the "ver" output seems to have more information than those APIs.
It's always had build numbers, which the regular APIs do not, because the
regular APIs are meant for detecting incompatibilities rather than reporting.
Si
Steve Dower added the comment:
Thanks for mentioning it! New PR to fix
--
priority: release blocker -> high
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
pull_requests: +27104
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/28764
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45375>
___
___
Pyth
1101 - 1200 of 6138 matches
Mail list logo
