Steve Dower added the comment:
Considering you've just been encountering issues with mismatched case, you're
likely aware of how much harder that will make it to fix.
First you'll need a proposal on how to ensure deprecation warnings reach those
who need them. I'd
Steve Dower added the comment:
Okay, so that means there's some code somewhere that has a lowercase "lib".
If you change it back to "Lib", can you do "python -m pip"? If that works, but
a direct "pip" does not, it'll be an issue in pip (or
Steve Dower added the comment:
As a quick (wild) guess, is it expecting the "Lib" directory to be lowercase
"lib"?
Could you try renaming that directory in your venv and see if it changes
anything?
--
___
Python tracker
<
Steve Dower added the comment:
> I do process the shebang to restrict searching, or did you mean something
> else?
That's what I meant. Guess I missed seeing it when scanning the code (probably
I should've read the docs :D )
> And registry support [is
> plann
Steve Dower added the comment:
> It would probably be better to skip tests if the filesystem of the current
> working directory doesn't support the test,
Yes, this would be good. Then whoever is configuring the test runner can
move where tests are run to make sure it is suppo
Steve Dower added the comment:
The sys module gets initialised in _PySys_UpdateConfig() in Python/sysmodule.c.
It gets called later in pylifecycle.c. But it ought to just copy directly from
the config.
However, it's the site.py module that actually updates sys.prefix for the venv.
S
Steve Dower added the comment:
I'd like to, the main challenge with that is it'd invalidate the code signature
on the file, which will make it basically unusable (at the very least, you'll
get warnings). A simple rename does not.
But yeah, it can probably go in. Hopefully
Steve Dower added the comment:
>> Why can't the filename of the "foo"-like file in the test be
>> simply os_helper.TESTFN, as done in some other tests?
>
> I suppose the current working directory will be fine. I was looking to keep
> the test on a NTFS
Steve Dower added the comment:
> If it's already turning into a rewrite, how feasible would it be to adopt
> Brett's `py` launcher?
I looked at it already, and I'd have to write literally the same code to
implement what's needed :) (as well as learning Rust and c
Steve Dower added the comment:
Hah, that's funny URL formatting. Let's see if this is any better:
<https://github.com/python/cpython/compare/main...zooba:bpo-46566>
--
___
Python tracker
<https://bugs.py
Steve Dower added the comment:
I'm working on what's become a rewrite of the launcher. If anyone would like to
follow along, you can see my changes at
https://github.com/python/cpython/compare/main...zooba:bpo-46566
It's still missing some functionality, and I'm not sur
Change by Steve Dower :
--
assignee: -> steve.dower
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
> Is there anything on our end we can do to prevent this kind of issue in the
> future?
Probably not, I think it's just a lesson learned about the capabilities of the
MSI format and its integration with Windows (well, we could hurry up moving
ever
Steve Dower added the comment:
> This could be problematic, adding a suitably named file outside of $PREFIX
> breaks the python installation.
Might be worth changing it then. I double/triple checked whether
searching up for the zip file was the old behaviour, and it sure seemed
to
Steve Dower added the comment:
New changeset 176835c3d5c70f4c1b152cc2062b549144e37094 by Steve Dower in branch
'main':
bpo-46932: Update bundled libexpat to 2.4.7 (GH-31736)
https://github.com/python/cpython/commit/176835c3d5c70f4c1b152cc2062b54
Change by Steve Dower :
--
keywords: +patch
pull_requests: +29853
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31736
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
New changeset e1639f361ee0dfbf08bb8538839d3d557c1a995c by Steve Dower in branch
'3.9':
bpo-44549: Update bzip2 to 1.0.8 in Windows builds to mitigate CVE-2016-3189
and CVE-2019-12900 (GH-31732)
https://github.com/python/cpyt
Change by Steve Dower :
--
nosy: +steve.dower
___
Python tracker
<https://bugs.python.org/issue46932>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Steve Dower :
--
pull_requests: +29851
pull_request: https://github.com/python/cpython/pull/31734
___
Python tracker
<https://bugs.python.org/issue44
Change by Steve Dower :
--
pull_requests: +29852
pull_request: https://github.com/python/cpython/pull/31735
___
Python tracker
<https://bugs.python.org/issue44
Change by Steve Dower :
--
pull_requests: +29850
pull_request: https://github.com/python/cpython/pull/31733
___
Python tracker
<https://bugs.python.org/issue44
Steve Dower added the comment:
New changeset 58d576a43cb1800dd68f06a429d7d41f746a8c01 by Steve Dower in branch
'3.10':
bpo-44549: Update bzip2 to 1.0.8 in Windows builds to mitigate CVE-2016-3189
and CVE-2019-12900 (GH-31732)
https://github.com/python/cpyt
Change by Steve Dower :
--
pull_requests: +29849
pull_request: https://github.com/python/cpython/pull/31732
___
Python tracker
<https://bugs.python.org/issue44
Steve Dower added the comment:
New changeset 105b9ac00174d7bcc653f9e9dc5052215e197c77 by Steve Dower in branch
'main':
bpo-44549: Update bzip2 to 1.0.8 in Windows builds to mitigate CVE-2016-3189
and CVE-2019-12900 (GH-31731)
https://github.com/python/cpyt
Steve Dower added the comment:
Good call on the batch file. It should be easy enough to make those options
case-insensitive, and to support both forms of x86 flag. I'll leave this issue
open for that if someone wants to have a go, otherwise I'll get to them at s
Steve Dower added the comment:
Adding RMs - this should get merged before we do any security releases for
issue46948
--
nosy: +lukasz.langa, pablogsal
versions: +Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue44
Change by Steve Dower :
--
pull_requests: +29848
pull_request: https://github.com/python/cpython/pull/31731
___
Python tracker
<https://bugs.python.org/issue44
Steve Dower added the comment:
cpython-source-deps was updated middle of last year, but apparently we never
merged the main repo change to use it. I'll do it now.
--
___
Python tracker
<https://bugs.python.org/is
Steve Dower added the comment:
New changeset 101a1bee1953b82339115c5e648e1717359c78eb by Steve Dower in branch
'3.9':
bpo-46948: Fix CVE-2022-26488 by ensuring the Windows Installer correctly uses
the install path during repair (GH-31728)
https://github.com/python/cpyt
Steve Dower added the comment:
New changeset 77446d2aa56e9e3262d9d22473420ff5e907 by Steve Dower in branch
'main':
bpo-46948: Fix CVE-2022-26488 by ensuring the Windows Installer correctly uses
the install path during repair (GH-31726)
https://github.com/python/cpyt
Steve Dower added the comment:
New changeset 136842c91b5783e205e217c4855baa9dadd4ad41 by Steve Dower in branch
'3.10':
bpo-46948: Fix CVE-2022-26488 by ensuring the Windows Installer correctly uses
the install path during repair (GH-31727)
https://github.com/python/cpyt
Steve Dower added the comment:
Yeah, this is fine to still be in alpha 6. Very unlikely that anyone is making
it a system-wide default anyway, and certainly not in secure/production systems.
--
___
Python tracker
<https://bugs.python.
Steve Dower added the comment:
> I have a patch that seems to do the right thing. It required adding
> WITH_NEXT_FRAMEWORK to the globals when evaluating getpath.py to detect this
> scenario.
I haven't had a chance to go through all your changes, and I'm only very
va
Change by Steve Dower :
--
pull_requests: +29847
pull_request: https://github.com/python/cpython/pull/31730
___
Python tracker
<https://bugs.python.org/issue46
Change by Steve Dower :
--
pull_requests: +29846
pull_request: https://github.com/python/cpython/pull/31729
___
Python tracker
<https://bugs.python.org/issue46
Change by Steve Dower :
--
pull_requests: +29845
pull_request: https://github.com/python/cpython/pull/31728
___
Python tracker
<https://bugs.python.org/issue46
Change by Steve Dower :
--
pull_requests: +29844
pull_request: https://github.com/python/cpython/pull/31727
___
Python tracker
<https://bugs.python.org/issue46
Change by Steve Dower :
--
keywords: +patch
pull_requests: +29843
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31726
___
Python tracker
<https://bugs.python.org/issu
New submission from Steve Dower :
CVE-2022-26488 is an escalation of privilege vulnerability in the Windows
installer for the following releases of CPython:
* 3.11.0a6 and earlier
* 3.10.2 and earlier
* 3.9.10 and earlier
* 3.8.12 and earlier
* All end-of-life releases of 3.5, 3.6 and 3.7
Steve Dower added the comment:
If you can build this on top of nt._path_splitroot then it could save a decent
amount of work, though at the same time I think it's worthwhile having a pure
Python implementation which is cross-platform.
Haven't looked at the PR yet (or Eryk's
Steve Dower added the comment:
New changeset 8f31bf46980956c735dd18f9914f3e7144e87c77 by Steve Dower in branch
'main':
bpo-46744: Move Windows ARM64 installation directory to correct ProgramFiles
(GH-31677)
https://github.com/python/cpython/commit/8f31bf46980956c735dd18f9914f3e
Steve Dower added the comment:
Posted half a PR for this, which is worth taking in itself, but doesn't
completely address the whole change. It will install to the correct
ProgramFiles folder on ARM64 now, but still with the suffix.
If we are to take the rest of the change (use "-
Change by Steve Dower :
--
keywords: +patch
pull_requests: +29797
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31677
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
Forget exactly when I did this, but I did it.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
It's looking for a precompiled bundled stdlib, rather than one that's been
generated from adjacent source files. This is deliberate (also quite an
advanced scenario, but it does get used).
--
components: -Documentation
resolution: -> no
Steve Dower added the comment:
> I've pasted the diff below because I'm not yet convinced that it is correct
> (in particular the value for "argv0".)
argv0 is literally what C sees in argv[0], which in the framework case I
believe is calculated by a launcher?
Steve Dower added the comment:
Eryk's post is useful background information, but not helpful for this
particular case ;)
>From Windows's POV, there is no "creating" process of the shared memory. If
>it's going away, it's because none of the other processe
Steve Dower added the comment:
> If there's a way to add a test for this case as well, that would be
> handy. Way too little documentation here.
There's definitely a way to add a test now, because test_getpath uses
completely fake initial conditions to verify that getpath.py
Steve Dower added the comment:
> Is sys._base_executable updated after running getpath.py?
It shouldn't be, but site.py might do it.
More likely it's in how getpath.py is handling the environment variable
overrides. It should be pretty easy to track down and change - the old
Steve Dower added the comment:
I'm working on this now.
--
assignee: -> steve.dower
___
Python tracker
<https://bugs.python.org/issue46566>
___
___
Py
Steve Dower added the comment:
The _base_executable change might be, though it should still be preferring the
environment variables here, but I don't think I touched anything that would
affect which symlinks are created by venv.
--
nosy: +vinay.
Steve Dower added the comment:
Yes, named memory mappings only exist on Windows until the last
reference is closed, so this is a difference due to the underlying OS.
The implementation of unlink() recognises this (the entire body is under
a _USE_POSIX check), but the docs do not reflect it
Steve Dower added the comment:
Build and tests were fine, and a test release build was too, so merging and
closing this.
Any new Tcl/Tk issues should get a new bug. If they only affect ARM64, just
mention that in the issue.
--
resolution: -> fixed
stage: patch review -> re
Steve Dower added the comment:
New changeset da7d99a4de72aac8d436cecedf16ab2676f9b785 by Steve Dower in branch
'main':
bpo-46567: Add Tcl/Tk build for Windows ARM64 (GH-31574)
https://github.com/python/cpython/commit/da7d99a4de72aac8d436cecedf16ab
Steve Dower added the comment:
I updated the builds in cpython-bin-deps and retriggered the PR tests.
--
___
Python tracker
<https://bugs.python.org/issue46
Steve Dower added the comment:
Thanks for the analysis. It should be fine to set PlatformToolset=v142 to
choose the older compiler, so I'll give that a go.
Anything I can do to help the compiler team figure out what's broken?
--
Steve Dower added the comment:
Despite the IDLE issue, I made a test release. Again, I don't have time to dig
into it before Monday, but if anyone does and would like to help out, here are
the installer files (for all platforms):
https://artprodcus3.artifacts.visualstudio.com/Ac0fc90aa
Steve Dower added the comment:
This is blocked on the IDLE issue in
https://github.com/python/cpython/runs/5334087871?check_suite_focus=true
==
ERROR: test_mousewheel (idlelib.idle_test.test_sidebar.ShellSidebarTest
Change by Steve Dower :
--
keywords: +patch
pull_requests: +29696
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31574
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
Getting this done with some help from colleagues. Tcl and Tk have been updated
to support it, and I've pulled down their patches into our source repo.
Hopefully I find time to get the build and setup updates done before the next
alpha... adding Pablo ju
Steve Dower added the comment:
So I'm the "team" that designed it the first time (with input from others, of
course, but it wasn't designed by a committee or anything), and the primary
goal was to enable a single-click install for the majority of users, biased
towards
Steve Dower added the comment:
> I am not sure but would say that the first two options are related to the
> py-launcher not the the python interpreter itself.
You correctly read the options, so we'll need a suggestion on how to make it
more clear without becoming impenetr
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 77f31a91d55df2df79ac767690738081f27ad476 by Steve Dower in branch
'main':
bpo-46822: Increase timeout for test_create_server_ssl_over_ssl to match
underlying timeouts (GH-31502)
https://github.com/python/cpyt
Change by Steve Dower :
--
keywords: +patch
pull_requests: +29630
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/31502
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
In fact, I only have to increase the test timeout to 15s to get it to pass
reliably.
I don't see any reason the test should time out quicker than the operations
it's testing though, right? So set
Steve Dower added the comment:
Looks like my issue is actually related to the timeouts added in issue44011.
I'm guessing it's an SSL shutdown timeout, because those are notoriously weird
on Windows/OpenSSL.
The timeout is now 30s, but the test aborts after 10s. If I increas
New submission from Steve Dower :
This causes a failure on one of my test machines where the firewall settings
forbid it.
However, the test itself seems designed to only listen on localhost. Even
tracing all call through socket, I don't see when or where it is attempting to
list
Steve Dower added the comment:
> one option would be to enhance PCbuild/get_external.py to add support
for a cache directory.
It should already have this support - set the EXTERNALS_DIR environment
variable before building. I use this in my own builds.
Though if there are speci
Steve Dower added the comment:
New changeset 98dd0aec2d0cb8971fb5363532c25041a5ba6fdc by Jeremy Kloth in
branch 'main':
bpo-46778: Enable multiprocess compilation for source files when building on
Windows (GH-31390)
https://github.com/python/cpyt
Steve Dower added the comment:
Easy, and thanks for the PR!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
Yeah, currently the only detection that happens is OS version, and just
so we can block (or at least log) users who are trying to install on
supported versions. The install directories are unconditional.
Any dynamic detection code would have to go into
Tools
Steve Dower added the comment:
Thanks for the additional info! I agree with the design you propose.
It would be much easier to make the ARM64 install use the tagged
directory though (C:\Program Files\Python 3.11-arm64). I'd rather not
get into the business of detecting platforms fro
Steve Dower added the comment:
Does Cygwin not use : as a path list separator? (What would normally be
; on Windows.)
Perhaps the CPython build needs to be patched specially here to handle
different separator character.
--
___
Python tracker
Steve Dower added the comment:
Thanks. This is being tracked in issue25166, and is waiting on a fix from our
installer toolset, who have previously indicated that they're not interested in
fixing it, but wouldn't rule it out in their next major version.
--
resolution: -&
Steve Dower added the comment:
This option may be disabled if you have already installed the launcher
for only the current user. In this case, we aren't able to replace it
with an all-users install.
Open Programs and Features and find the Python launcher, uninstall it,
and then try
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
All I can say is that I wasn't aware of this discussion, or it blurred into the
other discussions and didn't seem to need any attention from me.
Once I was pinged on the pull request (and I'm *trying* to be better at
checking GitHub notifi
Steve Dower added the comment:
It still unfortunately sounds like a Windows issue. All we do is specify that
there should be a file there, we have nothing to do with creating or removing
them. I'm not sure there's anything else we can do to help.
You could try reporting the issue
Steve Dower added the comment:
Probably. I searched for the CVE number and didn't find it anywhere, but that
issue only mentions the new release version.
--
resolution: -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder: -> Please update
New submission from Steve Dower :
libexpat recently fixed a security issue relating to some arithmetic:
https://github.com/libexpat/libexpat/pull/534
I assume we should take this fix, either by updating our entire bundled copy or
just backporting the patch.
--
components: XML
Steve Dower added the comment:
I think we want the scheme to be static and accessible on all platforms, like
the others. So it probably should be 'nt_venv' and 'posix_venv' with
additional/improved logic to help apps determine when they need each.
-
Steve Dower added the comment:
New changeset 76b072717a160c44cb8d54be3d5e878bc31f2c38 by Miss Islington (bot)
in branch '3.9':
bpo-46638: Makes registry virtualisation setting stable when building MSIX
packages (GH-31130)
https://github.com/python/cpyt
Steve Dower added the comment:
Only by following the link I posted and searching for issues that sound like
this one.
Which I just did for you: https://github.com/libffi/libffi/issues/367
There may be more, though. I just grabbed the first one that looked like a
match
Steve Dower added the comment:
New changeset 3a5afc14e16370c1f4f72d43cb553298ad9a1fa4 by Steve Dower in branch
'main':
bpo-46638: Makes registry virtualisation setting stable when building MSIX
packages (GH-31130)
https://github.com/python/cpyt
Steve Dower added the comment:
Didn't work on 1809, but it does work on 20H2, which is the earliest update
that will still be supported when 3.11 ships. I didn't try the ones in between,
but I think we're okay to ignore them.
Interestingly, double-clicking the MSIX on Window
Change by Steve Dower :
--
title: Inconsistent registry use in Windows Store package -> Inconsistent
registry virtualization in Windows Store package
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
keywords: +patch
pull_requests: +29309
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31130
___
Python tracker
<https://bugs.python.org/issu
Steve Dower added the comment:
Okay, so it doesn't install at all on 1803. However, that's out of support [1],
so I guess it doesn't matter.
In theory, 1809 should be the first one that supports it. I'll try that, but I
think we're okay to leave this turned on for 3
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Steve Dower :
The build of the Store package detects whether the build PC supports disabling
registry virtualisation or not when deciding whether to add it to the manifest.
Because our release builds just moved from the windows-2019 image to the
windows-2022 image, this
Steve Dower added the comment:
New changeset 9b4e3d94a5746af093392ed8e977b26fcc1bfd11 by Steve Dower in branch
'main':
bpo-46629: Update classicAppCompat.sccd for new signing certificate (GH-3)
https://github.com/python/cpython/commit/9b4e3d94a5746af093392ed8e977b2
Steve Dower added the comment:
They got back to me with the files, so I've added them to the PR. I'll run a
test (signed) build from my branch to validate.
--
___
Python tracker
<https://bugs.python.o
Steve Dower added the comment:
Closing this issue, as we have others to track individual tasks.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Steve Dower added the comment:
Posted the PR for openness, but it's not ready to merge yet.
The file that's been updated there (which unfortunately is not very Unix
friendly) now has the SHA256 hash of our signing certificate, and I've emailed
the file to storeops at Micro
Change by Steve Dower :
--
keywords: +patch
pull_requests: +29294
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/3
___
Python tracker
<https://bugs.python.org/issu
Change by Steve Dower :
--
components: +Windows
nosy: +paul.moore, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue46629>
___
___
Pytho
New submission from Steve Dower :
We need to update PC/classicAppCompat.can.xml for our new certificate and email
Microsoft to get it signed again.
--
assignee: steve.dower
messages: 412461
nosy: steve.dower
priority: normal
severity: normal
status: open
title: Cannot sideload MSIX
Change by Steve Dower :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
101 - 200 of 1001 matches
Mail list logo
