[issue45258] sysroot_paths in setup.py does not consider -isysroot for macOS

2021-09-21 Thread Ned Deily


Ned Deily  added the comment:

See my comment on the PR.

--
components: +macOS -Build
nosy: +ned.deily, ronaldoussoren

___
Python tracker 
<https://bugs.python.org/issue45258>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44492] Building a C extension on Big Sur and SDK v10.15 fails

2021-09-09 Thread Ned Deily


Change by Ned Deily :


--
assignee:  -> ned.deily

___
Python tracker 
<https://bugs.python.org/issue44492>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44869] MacOS Monterrey malloc issue

2021-09-07 Thread Ned Deily


Ned Deily  added the comment:

The crash report you provide shows a crash in libstdc++ which is normally not 
called directly by the Python interpreter or standard library modules on macOS 
but appears to be being called by libopenblas as provided by the copy of numpy 
in use. Suggest you follow up with the numpy, openblas, or homebrew projects, 
if that's where you obtained numpy and friends. Keep in mind that the problem 
might still be related to the pre-release status of macOS Monterey.  Good luck!

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue44869>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27658] python 3.5.2 built from source fails to install completely on Mac OS X 10.11.6. Crashes subsequently.

2021-09-07 Thread Ned Deily


Change by Ned Deily :


--
stage:  -> resolved
status: pending -> closed

___
Python tracker 
<https://bugs.python.org/issue27658>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45111] whole website translation error

2021-09-06 Thread Ned Deily


Change by Ned Deily :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python

___
Python tracker 
<https://bugs.python.org/issue45111>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44848] Upgrade macOS and Windows installers to use SQLite 3.36.0

2021-09-05 Thread Ned Deily


Ned Deily  added the comment:


New changeset 5024dc1c6e08247693aea6ad6e225ec5dcaf0721 by Erlend Egeberg 
Aasland in branch 'main':
bpo-44848: Update macOS installer to use SQLite 3.36.0 (GH-27621)
https://github.com/python/cpython/commit/5024dc1c6e08247693aea6ad6e225ec5dcaf0721


--

___
Python tracker 
<https://bugs.python.org/issue44848>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44689] ctypes.util.find_library() does not find macOS 11+ system libraries when built on older macOS systems

2021-09-02 Thread Ned Deily


Ned Deily  added the comment:

Thanks for the updates!

>If the core developers say various cross-compiling scenarios aren't supported 
>build configuration any more, I'll accept that and work around the limitation 
>on my end. However, do note there is a significant possibility that Apple 
>stops selling Intel machines for various product models in a few weeks. I 
>suspect various people will want to continue their practice of building x86_64 
>only binaries for the indefinite future.

I think you make very good points. I also think that we all agree that we do 
need to work towards better supporting the coming primarily non-Intel Mac 
world. I would rather put it that there are cross-compiling scenarios that were 
never supported before (but also not necessarily fully documented as such) but 
may have worked coincidentally some of the time; moving forward, we need to 
identify the important scenarios and make sure we fully support them. We're not 
there yet but I have some ideas on how to do that which I will try to get 
written down soon.

--

___
Python tracker 
<https://bugs.python.org/issue44689>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44689] ctypes.util.find_library() does not find macOS 11+ system libraries when built on older macOS systems

2021-09-01 Thread Ned Deily


Ned Deily  added the comment:

I don't think we have ever claimed to support building on an older system with 
a newer SDK, as in building on 10.15 with an 11 SDK. I am sure there have been 
problems with trying to do this in the past for some releases.  It *may* work 
but there are no guarantees. If you want to build on an older system you should 
use the SDK for that system even if a newer version of Xcode / Command Line 
Tools is released that provides the newer SDK.  That said, I have no objection 
to trying to fix this issue but I think we should avoid claiming to support 
such configurations and I don't see this issue as needing to make a new 
release. I am willing to be convinced otherwise :)

--

___
Python tracker 
<https://bugs.python.org/issue44689>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45069] python 3.9.2 contains libcrypto-1_1.dll and libssl-1_1.dll associates CVE-2021-23840\CVE-2021-3450\CVE-2021-3711\CVE-2021-3712\CVE-2021-23841\CVE-2021-3449 of openssl-1.1.1i

2021-09-01 Thread Ned Deily


Ned Deily  added the comment:

What problem are you reporting here? Python 3.9.2 is no longer current nor 
supported; the most recent release is 3.9.7, which, among many other changes, 
now uses OpenSSL 1.1.1l.

https://www.python.org/downloads/
https://www.python.org/dev/peps/pep-0596/
https://www.python.org/downloads/

--
nosy: +ned.deily
resolution:  -> out of date
status: open -> pending
versions: +Python 3.9

___
Python tracker 
<https://bugs.python.org/issue45069>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

2021-08-31 Thread Ned Deily


Ned Deily  added the comment:

PRs merged in 3.7 branch for release in 3.7.12 and in 3.6 branch for release in 
3.6.15.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue44394>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

2021-08-31 Thread Ned Deily


Ned Deily  added the comment:


New changeset 910886a6448e4bf1edf49eeace4aa240b6403772 by Ned Deily in branch 
'3.6':
[3.6] bpo-44394: Update libexpat copy to 2.4.1 (GH-26945) (GH-28042) (GH-28080)
https://github.com/python/cpython/commit/910886a6448e4bf1edf49eeace4aa240b6403772


--

___
Python tracker 
<https://bugs.python.org/issue44394>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

2021-08-31 Thread Ned Deily


Change by Ned Deily :


--
pull_requests: +26523
pull_request: https://github.com/python/cpython/pull/28080

___
Python tracker 
<https://bugs.python.org/issue44394>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38965] test_stack_overflow (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10

2021-08-31 Thread Ned Deily


Ned Deily  added the comment:

I decided to also backport this fix for 3.6.15 since the problem causes test 
hangs when using GCC 10, as is now that case on one of my test machines. Note 
that the devguide says: "You should also consider fixing hard-failing tests in 
open security branches since it is important to be able to run the tests 
successfully before releasing."

https://devguide.python.org/devcycle/#security-branches

--
versions: +Python 3.6

___
Python tracker 
<https://bugs.python.org/issue38965>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38965] test_stack_overflow (test.test_faulthandler.FaultHandlerTests) is stuck with GCC10

2021-08-31 Thread Ned Deily


Ned Deily  added the comment:


New changeset 8934bb0c3179e4c020cd6f08dea64bccbf56ffa2 by Miss Islington (bot) 
in branch '3.6':
bpo-38965: Fix faulthandler._stack_overflow() on GCC 10 (GH-17467) (GH-28079)
https://github.com/python/cpython/commit/8934bb0c3179e4c020cd6f08dea64bccbf56ffa2


--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue38965>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44394] [security] CVE-2013-0340 "Billion Laughs" fixed in Expat >=2.4.0: Update vendored copy to expat 2.4.1

2021-08-30 Thread Ned Deily

Ned Deily  added the comment:


New changeset 79101b890ee021a901a8b6837a3a320d57adb725 by Łukasz Langa in 
branch '3.7':
[3.7] bpo-44394: Update libexpat copy to 2.4.1 (GH-26945) (GH-28042)
https://github.com/python/cpython/commit/79101b890ee021a901a8b6837a3a320d57adb725


--

___
Python tracker 
<https://bugs.python.org/issue44394>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43124] [security] smtplib multiple CRLF injection

2021-08-30 Thread Ned Deily


Ned Deily  added the comment:


New changeset 29d97d17fb7adab3b0df9e178b73f70292d1cf64 by Miss Islington (bot) 
in branch '3.6':
[3.6] bpo-43124: Fix smtplib multiple CRLF injection (GH-25987) (GH-28038)
https://github.com/python/cpython/commit/29d97d17fb7adab3b0df9e178b73f70292d1cf64


--

___
Python tracker 
<https://bugs.python.org/issue43124>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43124] [security] smtplib multiple CRLF injection

2021-08-30 Thread Ned Deily


Ned Deily  added the comment:


New changeset d2cc04cd3024869101e894f73307944d98d187c8 by Miss Islington (bot) 
in branch '3.7':
[3.7] bpo-43124: Fix smtplib multiple CRLF injection (GH-25987) (GH-28037)
https://github.com/python/cpython/commit/d2cc04cd3024869101e894f73307944d98d187c8


--

___
Python tracker 
<https://bugs.python.org/issue43124>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45001] Date parsing helpers in email module incorrectly raise IndexError for some malformed inputs

2021-08-30 Thread Ned Deily


Ned Deily  added the comment:

Thanks for the PR!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue45001>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45001] Date parsing helpers in email module incorrectly raise IndexError for some malformed inputs

2021-08-30 Thread Ned Deily


Ned Deily  added the comment:


New changeset da9d6c554697414b1d275c8502e00a07c2ce06e6 by Miss Islington (bot) 
in branch '3.6':
bpo-45001: Make email date parsing more robust against malformed input 
(GH-27946) (GH-27976)
https://github.com/python/cpython/commit/da9d6c554697414b1d275c8502e00a07c2ce06e6


--

___
Python tracker 
<https://bugs.python.org/issue45001>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45001] Date parsing helpers in email module incorrectly raise IndexError for some malformed inputs

2021-08-30 Thread Ned Deily


Ned Deily  added the comment:


New changeset e9b85afd7dc004460f6d914375ab67d617a8a7ff by Miss Islington (bot) 
in branch '3.7':
bpo-45001: Make email date parsing more robust against malformed input 
(GH-27946) (GH-27975)
https://github.com/python/cpython/commit/e9b85afd7dc004460f6d914375ab67d617a8a7ff


--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue45001>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue14088] sys.executable generating canonical path

2021-08-30 Thread Ned Deily


Ned Deily  added the comment:

> I'm not against making Python even better: attempt to normalize the path ;-)

I would be very cautious about doing that. I'm pretty sure it would break some 
existing code.

--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue14088>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44689] ctypes.util.find_library() does not find macOS 11+ system libraries when built on older macOS systems

2021-08-30 Thread Ned Deily


Change by Ned Deily :


--
assignee:  -> ned.deily
stage: patch review -> commit review
title: MacOS: Python binaries not portable between Catalina and Big Sur -> 
ctypes.util.find_library() does not find macOS 11+ system libraries when built 
on older macOS systems
versions: +Python 3.8

___
Python tracker 
<https://bugs.python.org/issue44689>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44689] MacOS: Python binaries not portable between Catalina and Big Sur

2021-08-30 Thread Ned Deily


Ned Deily  added the comment:


New changeset 71853a73024a98aa38a3c0444fe364dbd9709134 by Tobias Bergkvist in 
branch 'main':
bpo-44689: ctypes.util.find_library() now finds macOS 11+ system libraries when 
built on older macOS systems (#27251)
https://github.com/python/cpython/commit/71853a73024a98aa38a3c0444fe364dbd9709134


--

___
Python tracker 
<https://bugs.python.org/issue44689>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45007] OpenSSL 1.1.1l is released

2021-08-30 Thread Ned Deily


Change by Ned Deily :


--
pull_requests: +26495
pull_request: https://github.com/python/cpython/pull/28051

___
Python tracker 
<https://bugs.python.org/issue45007>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue40935] Links to Python3 docs for some libs return 404

2021-08-29 Thread Ned Deily


Change by Ned Deily :


--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue40935>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24388] Python readline module crashes in history_get on FreeBSD with libedit

2021-08-28 Thread Ned Deily


Change by Ned Deily :


--
pull_requests:  -26463

___
Python tracker 
<https://bugs.python.org/issue24388>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44809] Changelog missing removal of StrEnum etc.

2021-08-27 Thread Ned Deily


Change by Ned Deily :


--
nosy: +pablogsal

___
Python tracker 
<https://bugs.python.org/issue44809>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44997] [sqlite3] build fails on macOS 11.5.1

2021-08-25 Thread Ned Deily


Ned Deily  added the comment:

> I guess we could wrap this functionality with some preprocessor conditionals, 
> and/or adjust the configure script to not accept 
> --enable-loadable-sqlite-extensions for macOS 11.5.1 (11.5.x?).

FTR, this is only a problem if you link with the Apple-supplied system 
libsqlite3. So any change would need need to take into account the possibility 
of using your own or other third-party copy of libsqlite3, for example, like 
the python.org macOS binary installers do.

--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue44997>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45007] OpenSSL 1.1.1l is released

2021-08-25 Thread Ned Deily


New submission from Ned Deily :

OpenSSL 1.1.1l was released on 2021-08-24 so the Windows build and macOS binary 
installers should be updated to it.

https://www.openssl.org/source/

However, it appears that 1.1.1l introduced a build failure on older macOS 
systems that would affect some python.org macOS installer builds so we should 
wait for an official fix before updating the macOS builds. I will take care of 
that part.

https://github.com/openssl/openssl/issues/16407

--
assignee: christian.heimes
components: SSL, Windows, macOS
messages: 400307
nosy: christian.heimes, ned.deily, paul.moore, ronaldoussoren, steve.dower, 
tim.golden, zach.ware
priority: high
severity: normal
stage: needs patch
status: open
title: OpenSSL 1.1.1l is released
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue45007>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45002] won't match correct version of tcl/tk

2021-08-25 Thread Ned Deily


Ned Deily  added the comment:

It is difficult to offer suggestions based on minimal information. You may be 
running into an arch mismatch: since you are requesting a universal2 build 
(x86_64 and arm64), all the third-party libraries your build links with must 
also be built with both architectures. Or it still could be a mismatched path 
problem. You can use the otool -L command I suggested before on the renamed 
_tkinter.so file left in your build/lib.macosx-11.5-universal2-3.11 directory 
to determine what path to the Tcl and Tk libraries it is using; it should be an 
absolute path to the Homebrew libraries.  You can also use the "file" command 
on the _tkinter file and on the Tcl and Tk library files to determine which 
archs are present in each. If this is your first attempt at building Python on 
macOS, I suggest you start with a simpler ./configure command and then consider 
adding other options after you have that working. To start with you should only 
need something like:

./configure --prefix=... --with-openssl=... --with-tcltk-includes=... 
--with-tcltk-libs=...

--

___
Python tracker 
<https://bugs.python.org/issue45002>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45002] won't match correct version of tcl/tk

2021-08-25 Thread Ned Deily


Ned Deily  added the comment:

Can you be more specific about what you mean by "executable" and "library"?

In particular, please show the results of, where /path/to/python is replaced by 
the path to the python you have built or installed:

otool -L $(/path/to/python -c 'import _tkinter;print(_tkinter.__file__)')

Most likely the issue is that you need to use additional ./configure arguments 
rather than trying to modify CFLAGS et al:

  --with-tcltk-includes='-I...'
  override search for Tcl and Tk include files
  --with-tcltk-libs='-L...'
  override search for Tcl and Tk libs

or set up the path to pkg-config info for Homebrew's Tcl and Tk packages.  See 
the comments in setup.py for more info:

https://github.com/python/cpython/blob/main/setup.py#L1898

--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue45002>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44988] Use the newest tcl/tk support

2021-08-24 Thread Ned Deily


Ned Deily  added the comment:

Thanks for the suggestion but 8.7 isn't even in beta yet, the most recent 
official release was 8.7a5. So it is way too early to consider moving the 
python.org installers to it.

https://www.tcl.tk/software/tcltk/8.7.html

--
nosy: +ned.deily
resolution:  -> third party
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue44988>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27498] Regression in repr() of class object

2021-08-17 Thread Ned Deily


Change by Ned Deily :


--
pull_requests:  -26016

___
Python tracker 
<https://bugs.python.org/issue27498>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44933] python3.9-intel64 hardened runtime not enabled

2021-08-17 Thread Ned Deily

Ned Deily  added the comment:

The "python3.x-intel64" executable was added for macOS "universal2" builds by 
Issue44009 in the 3.9.5 and 3.8.10 releases. As described in the issue and the 
changelog entries, the rationale is:

"Provide “python3.x-intel64” executable to allow reliably forcing macOS 
universal2 framework builds to run under Rosetta 2 Intel-64 emulation on Apple 
Silicon Macs. This can be useful for testing or when universal2 wheels are not 
yet available."

We provided an analogous "python3.x-32" executable for macOS "intel" (x64_64 
and i386 archs) builds for a similar reason.

Although it is mentioned in the changelog (and the python.org macOS installer 
ReadMe), I didn't anticipate that there would be anyone attempting to build and 
submit a universal binary for Apple notarization and who would be affected by 
this change: sorry about that! You can just either add the new executable to 
your codesigning script or you could delete the file before codesigning if you 
don't have a need to provide it to your users: it isn't needed unless you want 
to reliably force running under Rosetta 2 Intel emulation on an Apple Silcon 
Mac.

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue44933>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33896] Document what components make up the filecmp.cmp os.stat signature.

2021-08-16 Thread Ned Deily


Change by Ned Deily :


--
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> filecmp.cmp(shallow=True) isn't actually shallow when only 
mtime differs
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.7, Python 
3.8

___
Python tracker 
<https://bugs.python.org/issue33896>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32937] Multiprocessing worker functions not terminating with a large number of processes and a manager

2021-08-16 Thread Ned Deily


Change by Ned Deily :


--
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue32937>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6

2021-08-06 Thread Ned Deily


Ned Deily  added the comment:

Thanks for looking into this, Marc.

--

___
Python tracker 
<https://bugs.python.org/issue44828>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44756] In ./Doc, "make html" and "make build" should depend on "make venv"

2021-08-06 Thread Ned Deily


Change by Ned Deily :


--
versions: +Python 3.10, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44756>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44756] In ./Doc, "make html" and "make build" should depend on "make venv"

2021-08-06 Thread Ned Deily


Ned Deily  added the comment:

There was a previous attempt at adding a dependency on venv that ended up being 
reverted (Issue30487 and 122fc136b34e11906466851e77bb6959946467ee0). Over the 
years we have had a number of iterations of tweaking Doc/Makefile to balance 
ease of use (by providing the venv) with those of more advanced users who build 
docs as part of their automated processeses. I think what we had prior to this 
most recent change worked reasonably well for all. The previous process is 
clearly documented, for example in the Dev Guide 
(https://devguide.python.org/documenting/?highlight=venv#building-the-documentation)
 and does not strike me as very onerous. I appreciate the motivation behind 
this change but I really think there isn't a problem here that needs to be 
solved and I would support reverting the change for 3.9 and 3.10 and *perhaps* 
reconsider something for 3.11.

--
nosy: +ned.deily
priority: normal -> release blocker
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 
<https://bugs.python.org/issue44756>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6

2021-08-05 Thread Ned Deily

Ned Deily  added the comment:

> I used brew.sh to install Python, which I think uses the universal installer

As far as I know, Homebrew builds its own Python and Tk.

> After I reinstall macOS, if you need further testing, i’m open to trying.

Thanks. I think the next step would be to try to reproduce just using Tcl and 
Tk as this most likely is an issue in Tk rather than Python.  It's also quite 
possible that the underlying problem will be fixed in a future Monterey beta. 
Alas, I don't have time to look further into this in the immediate future.  
Perhaps someone can follow up directly with the Tk folks.

--
nosy: +culler

___
Python tracker 
<https://bugs.python.org/issue44828>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44689] MacOS: Python binaries not portable between Catalina and Big Sur

2021-08-04 Thread Ned Deily


Ned Deily  added the comment:

> Regarding the "explicit weak linking" when building on MacOS Big Sur and 
> later; wouldn't this mean that a Big Sur build wouldn't work on Catalina?

No, if it is done correctly.  I think you are trying to solve the wrong problem 
here.  As Ronald noted earlier, we now fully support building Python on a newer 
version of macOS to run correctly on that version and on older versions (for 
current python.org-provided macOS binary installers, we support one build that 
runs on macOS 10.9 through 11 Big Sur). The key to this is weak-linking with 
the help of Apple-provided availability macros and by properly setting the 
MACOSX_DEPLOYMENT_TARGET variable when running ./configure to the oldest 
desired supported macOS release.

Because this area is neither well-understood nor well-documented, let me try to 
get it written down here at the risk of covering some familiar ground.

To support more than one version of macOS when building Python, there are 
basically two approaches: either build on the oldest targeted system and trust 
that Apple will continue to provide compatibility when running older binaries 
on new systems; or, build on the newest targeted system and dynamically test at 
runtime whether specific newer OS features are available and gracefully handle 
cases where they are not available (which we call "weak-linking" here for 
short).

Prior to Python 3.9.1, we did not support the latter approach, i.e. 
weak-linking for many APIs / features added in recent macOS releases.  So our 
practice and recommendation was to always build on the oldest macOS release to 
be supported.  That's the approach we took for many years, for example, with 
the macOS 64-bit Intel installer variant for 10.9+ systems.  Because Apple has 
had a very good track record of providing compatibility on newer systems (at 
least for the mostly C-based APIs CPython uses), that approached worked 
reasonably well. The main drawback was that certain new features added to 
Python, primarily in the os module, were not available when using the 
python.org installer binaries on newer (post-10.9) systems. That was not ideal 
but, for the most part, the missing features weren't commonly used yet and this 
was essentially only an issue if you were using the python.org-supplied 
binaries; you could always use or build a Python targeted for the system in use.

However, things changed with macOS 11 Big Sur and the removal of system library 
files which broke ctype's find_library() when searching for system files, the 
subject of this issue. There were a number of other changes needed in CPython 
to fully support Big Sur, as documented in Issue41100 and others. As part of 
that work, Ronald and Lawrence D'Anna bit the bullet and went through the 
interpreter and the standard library to finally properly support weak-linking 
for multiple macOS versions. That means, as of 3.9.1 with the introduction of 
Big Sur support, it is finally possible to build on newer systems but still 
work properly on older ones. For 3.9.1, we introduced a new python.org 
installer variant, the "universal2" variant, that provides Intel and Apple 
Silicon fat binaries that should work on all Macs that can run macOS 10.9 
through at least 11 with newer features conditionally tested at runtime.

So our recommendation has changed as of 3.9.1 to now use the second approach 
above (which previously could cause Python segfaults when running on older 
systems) and to deprecate and phase out the use of the first approach (which 
still works as before - i.e. missing some features - with the notable exception 
of find_library() with system libraries on Big Sur).  Note that the 
find_library() issue is only one reason for that change in recommendation.

How does this work? Here's a quick demo using current head of Python 3.10 
(although you should see similar results with Python 3.9.x as of 3.9.1), the 
latest versions of macOS 11, 10.15, and 10.9.  We'll build on 11 in all cases, 
then deploy and run test_ctypes and test_posix on 11, 10.15, and 10.9.


1. Default case, no MACOSX_DEPLOYMENT_TARGET specified.  If the deployment 
target is not specified, configure normally uses the operating system version 
the build is running on, so in this case, 11 Big Sur.

$ sw_vers
ProductName:macOS
ProductVersion: 11.5.1
BuildVersion:   20G80
$ ./configure --prefix=/tmp/py && make -j3 && make install
[...]
checking which MACOSX_DEPLOYMENT_TARGET to use... 11.5
[...]

# run on 11, works as expected
$ /tmp/py/bin/python3.10
Python 3.10.0rc1+ (heads/3.10:536e35ae6a, Aug  4 2021, 16:46:59) [Clang 12.0.5 
(clang-1205.0.22.11)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
$ /tmp/py/bin/python3.10 -m test test_ctypes
0:00:00 load avg: 1.86 Run tests sequentially
0:00:00 lo

[issue44828] Using tkinter.filedialog crashes on macOS 12 Monterey beta 4 with tk8.6.11 from python.org installers

2021-08-04 Thread Ned Deily


Ned Deily  added the comment:

Thanks for the report. I verified that the crash also occurs on an Intel Mac VM 
with Monterey beta 4 using the current python.org universal2 installers for 
3.9.6 and 3.10.0rc1; they both have a private copy of Tk 8.6.11; so the problem 
does not appear to be Apple Silicon (M1) related. For what it's worth, the 
legacy python.org 3.9.6 Intel-only installer, which uses a copy of Tk 8.6.8, 
does not crash the Monterey beta 4. And no such failures are observed using any 
of those installers on the current Big Sur 11.5.1 release.

--
title: Using tkinter.filedialog crashes on macOS Python 3.9.6 -> Using 
tkinter.filedialog crashes on macOS 12 Monterey beta 4 with tk8.6.11 from 
python.org installers
versions: +Python 3.10, Python 3.11

___
Python tracker 
<https://bugs.python.org/issue44828>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44037] Broad performance regression from 3.10a7 to 3.10b2 with python.org macOS binaries

2021-08-03 Thread Ned Deily


Ned Deily  added the comment:

Summary: With the 3.10.0rc1 release, this performance regression in the 
var_access_benchmark starting with the 3.10.0b1 binaries in the python.org 
macOS universal2 installer is now resolved. With the rc1 release, the 
performance of this micro benchmark has actually improved over alpha7 in many 
cases, most notably on Intel Macs.  We have also taken some steps to reduce the 
chances of significant performance regressions in future releases of the macOS 
binaries going undetected prior to release.

Details: All var_access_benchmark results (Appendix A and B) are from running 
macOS Big Sur 11.5.1 (the current release at the moment). The rc1 binaries were 
also built on 11.5.1 using the current Apple (Xcode) Command Line Tools 12.5.1. 
In general, we build the python.org macOS installers on the most current macOS 
and Command Line Tools that have been released by Apple prior to that Python 
release. The a7 and b2 released universal2 binaries were thus made on then 
current versions of macOS Big Sur and the Command Line Tools, each different 
from rc1.

To put these results in context, let me once again note that the primary goal 
of the python.org macOS installers for many years has been to provide a 
convenient way to run Python on macOS on as many different Mac systems as 
possible with one download. For 3.10, the universal2 installer variant we 
provide is designed to run natively on all Macs that can run any version of 
macOS from 10.9 through the current macOS 11 Big Sur (and soon to include macOS 
12 Monterey), both Intel and Apple Silicon (M1) Macs.  To be able to run on 
such a wide variety of systems obviously requires some compromises. Thus 
providing optimum performance in every situation has *never* been a goal for 
these installers.  That doesn't mean we should totally ignore performance 
issues and I am grateful to Raymond for bringing this issue forward.  But, and 
not to belabor the point: for those situations where optimum performance is 
important, there is no substitute to using a Python built and optimized 
explicitly for th
 at environment; in other words, don't look to the python.org binaries for 
those cases.

As an example, with 3.10.0b1, we introduced the first python.org macOS builds 
that use newer compile- and link-time optimizations (--enable-optimizations and 
--with-lto). There were some kinks with that that have been subsequently ironed 
out. But the performance improvements aren't uniform across all systems. It 
appears that Intel Macs see much more of an improvement than Apple Silicon Macs 
do. There are probably a couple of reasons for that: for one, the longer 
experience with the tool chain for Intel archs, but, perhaps more importantly, 
we currently build universal2 binaries on Intel-based Macs which means 
performance-based optimizations by the tool chain are based on the performance 
on an Intel arch which may not be the same as performance on an Apple Silicon 
(arm64) CPU. That's a topic for future investigation but it is an example of 
the potential pitfalls when looking at performance.

Another example is that while there are some significant differences in the 
var_access_benchmark results, which targets specific micro-operations in the 
Python virtual machine, there is a different story looking at the larger-scale 
"realworld" benchmarks in the pyperformance package.  When I first started 
looking at this issue, I ran pyperformance and var_access_benchmark and found 
that, in general, there were *significant* performance improvements in most 
pyperformance benchmarks between 3.10.0a7 and 3.10.0b2 even though the 
var_access_benchmark showed performance regressions.  For 3.10.0rc1, the 
pyperformance results have mostly improved even more.  I have with some 
trepidation included some pyperformance results in Appendix C (3.10.0a7 vs 
3.10.0b2) and Appendix D (3.10.0a7 vs 3.10.0rc1).  Note that these results were 
run on a different, faster Intel Mac than the var_access_benchmark results and 
were run under different updates of macOS 11 so they should be viewed 
cautiously; as al
 ways with performance issues, your mileage may vary.

So by now, one might be curious as to how the performance regression was fixed 
in rc1. The answer at the moment is: I'm not totally sure! There are a *lot* of 
moving parts in making a Python release and the binaries that we provide for 
macOS. While I do try to control the build environments as much as possible 
(for example, by using dedicated virtual machines for builds) and be 
conservative about making changes to the build process and environments, 
especially later in a development/release cycle, as noted above I normally try 
to keep up with the most recent Apple updates to a given macOS version and 
build tools to ensure everyone is getting the benefit of the latest security 
and performance fixes. There have been Apple updates along the way between a7, 
b2, and rc1. So I can't rule

[issue44804] Port fix of "issue44422" to Python3.6.x

2021-08-02 Thread Ned Deily


Ned Deily  added the comment:

Sorry you are running into this problem. Alas, Python 3.6 has been in the 
"security-fix-only" phase of its life cycle for over 2.5 years now and will 
reach end-of-life in several months at the end of 2021. Our criteria for 
changes to a "security" branch are:
"The only changes made to a security branch are those fixing issues exploitable 
by attackers such as crashes, privilege escalation and, optionally, other 
issues such as denial of service attacks. Any other changes are not considered 
a security risk and thus not backported to a security branch."

The problem referenced here does not seem to meet those criteria and thus the 
original fix was not considered for backporting to current security branches, 
i.e. 3.8, 3.7, and 3.6. Unless it can be shown that the problem can be 
exploited as an attack vector, it is not eligible to be officially backported 
to 3.6.

However, there is nothing stopping either you or a downstream supplier of 
Python 3.6 (like RedHat) from backporting it yourselves.

https://devguide.python.org/devcycle/#security-branches

--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue44804>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42235] [macOS] Use --enable-optimizations in build-installer.py

2021-08-01 Thread Ned Deily


Change by Ned Deily :


--
pull_requests:  -24521

___
Python tracker 
<https://bugs.python.org/issue42235>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44797] test_socket should expect warnings in truncated-data tests

2021-07-31 Thread Ned Deily


Ned Deily  added the comment:

Duplicate of Issue23828

--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue44797>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44726] Build macOS version with thin lto option

2021-07-23 Thread Ned Deily


Ned Deily  added the comment:

Thanks for the suggestion. I will do some testing and, if warranted, make the 
necessary changes.

--
assignee:  -> ned.deily

___
Python tracker 
<https://bugs.python.org/issue44726>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42854] OpenSSL 1.1.1: use SSL_write_ex() and SSL_read_ex()

2021-07-20 Thread Ned Deily


Change by Ned Deily :


--
nosy: +pablogsal
stage: resolved -> needs patch

___
Python tracker 
<https://bugs.python.org/issue42854>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44549] BZip 1.0.6 Critical Vulnerability

2021-07-20 Thread Ned Deily


Ned Deily  added the comment:

> Is it possible to update bz2 to 1.0.8 on macOS distribution?

Thanks for looking into this. As I commented on PR 27241, this change is not 
needed because current macOS python.org installers dynamically link to the 
system-provided copies of Bzip2; the code to build a private copy of BZip2 in 
build-installer.py was only used when building on very old versions of macOS, 
10.4 and earlier, versions for which we no longer support building installers. 
I've submitted another PR to remove that unused code to avoid future confusion.

--

___
Python tracker 
<https://bugs.python.org/issue44549>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue42581] Docs site redirection doesn't work for 3.9

2021-07-17 Thread Ned Deily


Change by Ned Deily :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42581>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44608] Memory use increase in function _tkinter._flatten

2021-07-12 Thread Ned Deily


Change by Ned Deily :


--
components: +Tkinter

___
Python tracker 
<https://bugs.python.org/issue44608>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44602] Issue with get_build_version in msvc9compiler.py in distutils

2021-07-12 Thread Ned Deily


Change by Ned Deily :


--
components: +Distutils, Windows
nosy: +dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 
<https://bugs.python.org/issue44602>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44587] argparse BooleanOptionalAction displays default=SUPPRESS unlike other action types

2021-07-09 Thread Ned Deily


Change by Ned Deily :


--
nosy: +rhettinger
title: BooleanOptionalAction displays default=SUPPRESS unlike other action 
types -> argparse BooleanOptionalAction displays default=SUPPRESS unlike other 
action types

___
Python tracker 
<https://bugs.python.org/issue44587>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27875] Syslogs /usr/sbin/foo as /foo instead of as foo

2021-07-09 Thread Ned Deily


Change by Ned Deily :


--
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> syslog: Default "ident" in syslog.openlog() shouldn't contain 
slash
versions: +Python 3.9 -Python 3.5, Python 3.6, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue27875>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44577] Probably defect in Python 3.7.11

2021-07-09 Thread Ned Deily


Ned Deily  added the comment:

That excerpt is not executable by itself.  Without a reproducible test case and 
better traceback info, there is not enough information here to investigate 
further.

--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue44577>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35277] Upgrade bundled pip/setuptools

2021-07-05 Thread Ned Deily


Ned Deily  added the comment:

Thanks for the comment. While the original intent of the issue was resolved (by 
updating the bundled pip), Serhiy's point about the size of the repo increasing 
is still an issue but there is a more recent issue, Issue36608, with a proposed 
change that addresses that aspect.

--
nosy: +ned.deily
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Replace bundled pip and setuptools with a downloader in the 
ensurepip module

___
Python tracker 
<https://bugs.python.org/issue35277>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue36608] Replace bundled pip and setuptools with a downloader in the ensurepip module

2021-07-05 Thread Ned Deily


Change by Ned Deily :


--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue36608>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44548] ttk Indeterminate Progressbar Not Animating Correctly After `start`

2021-07-01 Thread Ned Deily


Ned Deily  added the comment:

Phil, there are still some as yet unresolved differences between using Tk 8.6.8 
and 8.6.11, both positive and negative, and there are a few differences between 
using the two variants under all conditions that we want to resolve. So, at the 
moment, we will continue to supply the two variants for 3.9.x bugfix releases 
with the traditional (non-universal2) variant remaining the default but that 
may change in the future.

--
resolution: fixed -> third party
stage:  -> resolved
status: pending -> closed

___
Python tracker 
<https://bugs.python.org/issue44548>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44548] ttk Indeterminate Progressbar Not Animating Correctly After `start`

2021-07-01 Thread Ned Deily


Ned Deily  added the comment:

I can reproduce this behavior when using the current default 3.9.x macOS 
installer which uses Tk 8.6.8. It appears to work correctly if you instead use 
the alternate 3.9.x macOS universal2 installer which bundles Tk 8.6.11. The 
universal2 variant will be the default for Python 3.10 and may likely become 
the default for a future 3.9.x release. See if it solves the problem for you.

https://www.python.org/downloads/release/python-396/

--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue44548>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44492] Building a C extension on Big Sur and SDK v10.15 fails

2021-06-28 Thread Ned Deily


Change by Ned Deily :


--
components: +macOS
nosy: +ned.deily, ronaldoussoren

___
Python tracker 
<https://bugs.python.org/issue44492>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44440] logging does not work as documented (setLevel)

2021-06-28 Thread Ned Deily


Change by Ned Deily :


--
nosy: +vinay.sajip

___
Python tracker 
<https://bugs.python.org/issue0>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44516] Update bundled pip to 21.1.3

2021-06-27 Thread Ned Deily


Change by Ned Deily :


--
nosy: +lukasz.langa, pablogsal
priority: normal -> high

___
Python tracker 
<https://bugs.python.org/issue44516>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue32855] Add documention stating supported Platforms

2021-06-22 Thread Ned Deily


Ned Deily  added the comment:

While there's is useful information on that web page, I don't think it is a 
satisfactory answer to what I believe is being requrested here, namely, "How do 
I determine to what extent platform X is supported by cPython?"  First, the 
information on the web pate is somewhat out-of-date. But more importantly, the 
web page is not part of the official Python documentation or python.org web 
site. If we are going to better document what we support and in a way that 
implies some commitment on behalf of the cPython project, it needs to be 
published under the review and ultimate control of the steering council, like 
all other official documentation.

--
status: pending -> open

___
Python tracker 
<https://bugs.python.org/issue32855>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44458] Duplicate symbol _BUFFER_BLOCK_SIZE when statically linking multiple modules

2021-06-19 Thread Ned Deily


Change by Ned Deily :


--
nosy: +gregory.p.smith

___
Python tracker 
<https://bugs.python.org/issue44458>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44425] 'dirty' added to sys.version on Linux and Mac source builds depending on git version

2021-06-15 Thread Ned Deily


Change by Ned Deily :


--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue44425>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44388] venv API Docs for EnvBuilder.ensure_directories incorrectly describe behavior

2021-06-13 Thread Ned Deily


Change by Ned Deily :


--
nosy: +vinay.sajip

___
Python tracker 
<https://bugs.python.org/issue44388>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44386] importlib and math.pi interact strangely

2021-06-13 Thread Ned Deily


Change by Ned Deily :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue44386>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44340] Add support for building cpython with clang thin lto

2021-06-08 Thread Ned Deily


Change by Ned Deily :


--
components: +Build -Interpreter Core
nosy: +gregory.p.smith

___
Python tracker 
<https://bugs.python.org/issue44340>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44330] IDLE: Colorizer and output tests hang on macOS

2021-06-07 Thread Ned Deily


Ned Deily  added the comment:

I can reproduce test_idle hanging on all of the current python.org macOS 
universal2 variants (3.8.10, 3.9.5, 3.10.0b2) which use Tk 8.6.11 but not with 
the legacy 10.9 variants for 3.8.10 and 3.9.5 which use Tk 8.6.8.  I've tried 
it on a few older systems, as far back as 10.9, and they all seem to hang the 
same way.  For 3.9.5 (and 3.8.10 now in security-fix mode), the first hang 
seems to be in test_removecolors which I need to Ctrl-C out of:

/usr/local/bin/python3.9 -m test -v -uall test_idle
[...]
test_insert (idlelib.idle_test.test_colorizer.ColorDelegatorTest) ... ok
test_notify_range (idlelib.idle_test.test_colorizer.ColorDelegatorTest) ... ok
test_recolorize (idlelib.idle_test.test_colorizer.ColorDelegatorTest) ... ok
test_recolorize_main (idlelib.idle_test.test_colorizer.ColorDelegatorTest) ... 
ok
test_removecolors (idlelib.idle_test.test_colorizer.ColorDelegatorTest) ...

I also see the hangs with current MacPorts Pythons linked with their build of 
Tk 8.6.11.

--
priority: normal -> critical
versions: +Python 3.9

___
Python tracker 
<https://bugs.python.org/issue44330>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44022] urllib http client possible infinite loop on a 100 Continue response

2021-06-02 Thread Ned Deily


Ned Deily  added the comment:


New changeset 1b6f4e5e13ebd1f957b47f7415b53d0869bdbac6 by Miss Islington (bot) 
in branch '3.6':
bpo-44022: Improve the regression test. (GH-26503) (GH-26508)
https://github.com/python/cpython/commit/1b6f4e5e13ebd1f957b47f7415b53d0869bdbac6


--

___
Python tracker 
<https://bugs.python.org/issue44022>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44022] urllib http client possible infinite loop on a 100 Continue response

2021-06-02 Thread Ned Deily


Ned Deily  added the comment:


New changeset fee96422e6f0056561cf74fef2012cc066c9db86 by Miss Islington (bot) 
in branch '3.7':
bpo-44022: Improve the regression test. (GH-26503) (GH-26507)
https://github.com/python/cpython/commit/fee96422e6f0056561cf74fef2012cc066c9db86


--

___
Python tracker 
<https://bugs.python.org/issue44022>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44290] x86-64 macOS 3.x buildbot build failed with: No such file or directory: '/Users/buildbot/buildarea/3.x.billenstein-macos/build/target/include/python3.11d/pyconfig.h'

2021-06-02 Thread Ned Deily


Ned Deily  added the comment:

Alas, it looks like build 325 failed in the same way as build 322:

https://buildbot.python.org/all/#/builders/366/builds/325

I wonder if there might be a Makefile race condition.

--
resolution: out of date -> 
stage: resolved -> 
status: closed -> open

___
Python tracker 
<https://bugs.python.org/issue44290>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43568] Drop support for Mac OS X < 10.3 module linking

2021-06-02 Thread Ned Deily


Ned Deily  added the comment:


New changeset 991693a217363243b0bd33887852d6b3959b99a1 by Joshua Root in branch 
'3.9':
[3.9] bpo-43568: Relax distutils MACOSX_DEPLOYMENT_TARGET check (GH-25827) 
(GH-26001)
https://github.com/python/cpython/commit/991693a217363243b0bd33887852d6b3959b99a1


--

___
Python tracker 
<https://bugs.python.org/issue43568>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44290] x86-64 macOS 3.x buildbot build failed with: No such file or directory: '/Users/buildbot/buildarea/3.x.billenstein-macos/build/target/include/python3.11d/pyconfig.h'

2021-06-02 Thread Ned Deily


Ned Deily  added the comment:

Perhaps one of the buildbot experts can help?  Zach? Pablo? Victor?

--
nosy: +pablogsal, zach.ware

___
Python tracker 
<https://bugs.python.org/issue44290>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44290] x86-64 macOS 3.x buildbot build failed with: No such file or directory: '/Users/buildbot/buildarea/3.x.billenstein-macos/build/target/include/python3.11d/pyconfig.h'

2021-06-02 Thread Ned Deily


Ned Deily  added the comment:

Can you say at what point you did the upgrade, i.e. between which two builds 
here?

https://buildbot.python.org/all/#/builders/366

--

___
Python tracker 
<https://bugs.python.org/issue44290>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44290] x86-64 macOS 3.x buildbot build failed with: No such file or directory: '/Users/buildbot/buildarea/3.x.billenstein-macos/build/target/include/python3.11d/pyconfig.h'

2021-06-02 Thread Ned Deily


Ned Deily  added the comment:

Hmm, I just tried to restart it from the builbot page but the build request is 
just sitting there ATM.

https://buildbot.python.org/all/#/builders/366

--

___
Python tracker 
<https://bugs.python.org/issue44290>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44286] venv activate script would be good to show failure.

2021-06-02 Thread Ned Deily


Change by Ned Deily :


--
nosy: +vinay.sajip

___
Python tracker 
<https://bugs.python.org/issue44286>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44290] x86-64 macOS 3.x buildbot build failed with: No such file or directory: '/Users/buildbot/buildarea/3.x.billenstein-macos/build/target/include/python3.11d/pyconfig.h'

2021-06-02 Thread Ned Deily


Ned Deily  added the comment:

I can't reproduce that failure with that checkout and I'm not even entirely 
sure where that error is coming from. My guess it that something went wrong 
during the previous build that resulted in the connection lost (a system crash 
perhaps?) that left the build area or the file system in an unusual state.

@mattbillenstein, could you check the buildbot and perhaps delete the build 
directory?

--
nosy: +mattbillenstein

___
Python tracker 
<https://bugs.python.org/issue44290>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?

2021-05-31 Thread Ned Deily


Change by Ned Deily :


--
components: +Windows -Documentation
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 
<https://bugs.python.org/issue44275>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44274] Installation problem for python-3.6.4rc1-macosx10.6.pkg-('python cannot be opened because of a problem') in my MacOS11.4

2021-05-31 Thread Ned Deily


Ned Deily  added the comment:

It appears you are trying to use a very old version of Python 3.6.4 from a 
python.org installer, and a release candidate at that.  This particular 
installer version will not run on current macOS systems. Note that Python 3.6 
has been in the security-fix-only phase of its life cycle for some years now 
and will reach end-of-life at the end of this year. The current supported 
version of Python 3 is now 3.9.5. If at all possible, you should upgrade to it 
as soon as possible.

If you feel you must use Python 3.6, the last macOS binary installers for it 
were produced for 3.6.8 in 2018; there are two installers for that release but 
only the "10.9 and later" installer variant will even launch at all on macOS 11 
Big Sur. But keep in mind that there are known issues with trying to run Python 
3.6 on macOS 11 (i.e. it is not officially supported) and there have been many 
bug and security fixes to Python 3 since that installer was built. You should 
think twice about trying to use it.

https://www.python.org/downloads/
https://www.python.org/dev/peps/pep-0494/

--
nosy: +ned.deily
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue44274>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43964] ctypes CDLL search path issue on MacOS

2021-05-30 Thread Ned Deily


Ned Deily  added the comment:

Thanks for the report! I've spent some time investigating it and the story 
behind it turns out to be a bit complicated, so bear with me. It's all tied in 
to Apple's attempts to improve the security of macOS.

As of macOS 10.15 Catalina, Apple introduced new requirements for downloadable 
installer packages, like those we provide for macOS on python.org; in order for 
such packages to be installed with the macOS installer, they would now have to 
be "notarized" by Apple. The notarization process is somewhat similar in 
concept to the process that an app has to go through to be submitted to the Mac 
App Store but with less stringent requirements. In particular, the installer 
package is automatically inspected to ensure that all executables are 
codesigned, are linked with the more-secure "hardened runtime", and do not 
request certain less-secure entitlements. Although originally announced for 
enforcement starting with the release of Catalina in the fall of 2019, Apple 
delayed the enforcement until February 2020 to give application developers more 
time to modify their packages to meet the new requirements. (See, for example, 
https://developer.apple.com/news/?id=12232019a).

The first python.org macOS installers that conformed to the new requirements 
and were notarized were for the 3.8.2 and 3.7.7 releases, staring in 2020-02. 
In those first releases, we used two entitlements:

com.apple.security.cs.disable-library-validation
com.apple.security.cs.disable-executable-page-protection

Some issues were reported (like Issue40198) when using those first releases, so 
we added two additional entitlements for subsequent releases:

com.apple.security.automation.apple-events
com.apple.security.cs.allow-dyld-environment-variables

While we didn't realize it until your issue, that did have an effect on ctype's 
behavior when trying to find shared libraries and frameworks. Using the 
hardened runtime, as now required for notarization, causes the system dlopen() 
interface, which ctypes uses, to no longer search relative paths. The dlopen 
man page (for macOS 11, at least) includes this warning:

  Note: If the main executable is a set[ug]id binary or codesigned with
  entitlements, then all environment variables are ignored, and only a
  full path can be used.

After some experimentation, it looks like that statement isn't exactly correct 
at least on macOS 11 Big Sur: unprefixed paths can still be used to find 
libraries and frameworks in system locations, i.e. /usr/lib and 
/System/Library/Frameworks. But it is true that, when using the hardened 
runtime, dlopen() no longer searches the user-controlled paths /usr/local/lib 
or /Library/Frameworks by default. And there apparently is no way for a 
notarized executable to revert to the previous behavior by adding other 
entitlements (https://developer.apple.com/forums/thread/666066).

With the allow-dyld-environment-variables entitlement included after the 
initial releases, it *is* now possible to change this behavior externally, if 
necessary, by explicitly setting the DYLD_LIBRARY_PATH and/or 
DYLD_FRAMEWORK_PATH environment variables (see man 1 dyld).

To demonstrate using a third-party library in /usr/local/lib (similar results 
with third-party frameworks in /Library/Frameworks):

# -- python.org 3.7.6, not codesigned --
$ /usr/local/bin/python3.7
Python 3.7.6 (v3.7.6:43364a7ae0, Dec 18 2019, 14:18:50)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.cdll.LoadLibrary('libsodium.dylib')


# -- python.org 3.7.7, first notarized release --
$ /usr/local/bin/python3.7
Python 3.7.7 (v3.7.7:d7c567b08f, Mar 10 2020, 02:56:16)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.cdll.LoadLibrary('libsodium.dylib')
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py",
 line 442, in LoadLibrary
return self._dlltype(name)
  File 
"/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py",
 line 364, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(libsodium.dylib, 6): no suitable image found.  Did find:
file system relative paths not allowed in hardened programs

$ DYLD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python3.7
Python 3.7.7 (v3.7.7:d7c567b08f, Mar 10 2020, 02:56:16)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> ctypes.cdll.LoadLibrary('libsodium.dylib')
[...]
OSError: dlo

[issue44254] Change turtledemo button colors

2021-05-28 Thread Ned Deily


Ned Deily  added the comment:

I also just did a quick test of PR 25448. The current version seems to have 
swapped one problem for another: now button labels are legible when the Light 
mode appearance is in effect but the labels blend into the button background 
when in Dark mode, the opposite of the current behavior.

--

___
Python tracker 
<https://bugs.python.org/issue44254>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44254] Change turtledemo button colors

2021-05-28 Thread Ned Deily


Ned Deily  added the comment:

I did a quick check and it looks like the code may not be needed on the latest 
macOS and Tk versions; however, I did not go back and check it on older systems 
and, in any case, it doesn't cause seem to cause any harm and it still does 
what it is supposed to do: ensure that the turtledemo process is the frontmost, 
active one regardless of what the OS or Tk may do.

--

___
Python tracker 
<https://bugs.python.org/issue44254>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44254] Change turtledemo button colors

2021-05-28 Thread Ned Deily


Ned Deily  added the comment:

One quick comment: one shouldn't assume what colors are being used on current 
macOS systems and a current Tk, like on macOS 11 Big Sur and Tk 8.6.11.  The 
foreground and background colors can depend on what system appearance is 
selected by the user (System Preferences -> General -> Appearance: 
Light/Dark/Auto). Changing the system appearance to Dark causes the Turtle Demo 
buttons to have a darker background and so the white text labels are now quite 
visible.  I don't know what the best solution is but it shouldn't be based on 
the assumption that the colors are fixed.

--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue44254>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44253] tkinter searches for tk.tcl in wrong directory

2021-05-28 Thread Ned Deily


Ned Deily  added the comment:

Correction: "In a standard Python build, tkinter has a Python component that 
calls a private C-language extension module helper named _tkinter that does all 
the C-level calls to Tk and Tcl [not Tkinter!]."

--

___
Python tracker 
<https://bugs.python.org/issue44253>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44253] tkinter searches for tk.tcl in wrong directory

2021-05-28 Thread Ned Deily


Ned Deily  added the comment:

tkinter does not find Tk; the linker at build time (ld) and usually the dynamic 
linker (dyld) at run time do all the work. Typically on macOS, the linkers 
prefer to dynamically link to libraries, deferring the decision to dyld at run 
time exactly which dynamic library will be linked to rather than statically 
linking in a library at build time. The expected shared library name (or path) 
is recorded at build time into the executables generated. The 
--with-tcltk-includes Python ./configure option is passed at build time to the 
C compiler chain to add the directories(s) for Tcl and Tk header files, if not 
otherwise found, and the --with-tcltk-libs option gives the locations of the 
libraries to add directories with Tcl and Tk libraries for ld to link against 
including generating the shared library file paths in the binaries produced.

In a standard Python build, tkinter has a Python component that calls a private 
C-language extension _module helper named _tkinter that does all the C-level 
calls to Tk and Tkinter. You can find the file name of the _tkinter extension 
module by importing it in the interpreter and looking at its __file__ 
attribute. With that you can use the Xcode / Command Line Tools "otool" utility 
to examine the binary to find the shared library names it is linked with and 
expecting to find at run time.

An example with a current python.org macOS Python:

$ /usr/local/bin/python3.9
Python 3.9.5 (v3.9.5:0a7dcbdb13, May  3 2021, 13:05:53)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import _tkinter
>>> _tkinter.__file__
'/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_tkinter.cpython-39-darwin.so'
>>> ^D
$ otool -L 
'/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_tkinter.cpython-39-darwin.so'
/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_tkinter.cpython-39-darwin.so:
/Library/Frameworks/Python.framework/Versions/3.9/lib/libtcl8.6.dylib 
(compatibility version 8.6.0, current version 8.6.11)
/Library/Frameworks/Python.framework/Versions/3.9/lib/libtk8.6.dylib 
(compatibility version 8.6.0, current version 8.6.11)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1292.100.5)

In this case, the libtcl and libtk shared libraries are included within the 
python.org distribution installed in /Library/Frameworks.

Another example with a MacPorts python built from source:

$ otool -L $(/opt/macports/bin/python3.9 -c "import 
_tkinter;print(_tkinter.__file__)")
/opt/macports/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/_tkinter.cpython-39-darwin.so:
/opt/macports/lib/libtcl8.6.dylib (compatibility version 8.6.0, current 
version 8.6.11)
/opt/macports/lib/libtk8.6.dylib (compatibility version 8.6.0, current 
version 8.6.11)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1292.100.5)

In this case, the _tkinter module was linked with libtcl and libtk included in 
the MacPorts distribution.

Unlike many other platforms, the shared library names seen in macOS binaries 
are usually absolute path names although they can be relative paths.  It is 
possible to use environment variables to override the default search paths used 
by dyld at run time and it is also possible to ask dyld to display debug info 
about exactly what files it ends up using, among other things.  See the dyld 
man page for lots of useful info.  An example:

$ DYLD_PRINT_LIBRARIES=1 /opt/macports/bin/python3.9 -c "import 
_tkinter;print(_tkinter.__file__)" 2>&1 | grep 'libt'
dyld: loaded:  
/opt/macports/lib/libtcl8.6.dylib
dyld: loaded: <403FAC32-CB24-3ED3-B680-02AE4FBB11A7> 
/opt/macports/lib/libtk8.6.dylib

Hope this helps!

--

___
Python tracker 
<https://bugs.python.org/issue44253>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44253] tkinter searches for tk.tcl in wrong directory

2021-05-27 Thread Ned Deily


Ned Deily  added the comment:

The message is coming from Tcl/Tk; tkinter is just passing it along and is 
otherwise not involved AFAIK. You don't need to use framework builds for Tcl or 
Tk on macOS but you should follow the recommendation of how to do a Unix build 
of Tcl and Tk as far as configure options and placement of directories. When 
built properly Tcl should have no trouble finding Tk and the tk.tcl file.

--
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: crash -> 

___
Python tracker 
<https://bugs.python.org/issue44253>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44242] enum.IntFlag regression: missing values cause TypeError

2021-05-26 Thread Ned Deily


Change by Ned Deily :


--
nosy: +pablogsal

___
Python tracker 
<https://bugs.python.org/issue44242>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44234] Debugging with LLDB doesn't work for universal2 installer on macOS Big Sur

2021-05-26 Thread Ned Deily


Ned Deily  added the comment:

There's a reason for that. What the discussion in that link fails to note is 
that elsewhere Apple warns that that entitlement is understandably prohibited 
in distributions submitted to the Apple notarization service. See the "Avoid 
the Get-Task-Allow Entitlement" section here: 
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues.
 I haven't verified that that is still the case but I'd be surprised if it 
weren't.

I think one solution (and possibly the best) might be to manually re-codesign 
the installed binaries if you need to use lldb with the python.org binaries. If 
someone comes up with something that works, we could document it somewhere with 
appropriate warnings about security risks and advice to reinstall when finished.

--

___
Python tracker 
<https://bugs.python.org/issue44234>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43109] When using Apple Clang, --with-lto builds should not check for llvm-ar

2021-05-24 Thread Ned Deily


Ned Deily  added the comment:


New changeset 3af61a7176a68bfeb349eeed314b9c3d7ebc3ad5 by Miss Islington (bot) 
in branch '3.9':
bpo-43109: Fix --with-lto configure option on macOS (GH-26341) (GH-26343)
https://github.com/python/cpython/commit/3af61a7176a68bfeb349eeed314b9c3d7ebc3ad5


--

___
Python tracker 
<https://bugs.python.org/issue43109>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue44093] compiler detection on macOS seems to be incorrect

2021-05-24 Thread Ned Deily


Change by Ned Deily :


--
keywords: +patch
pull_requests: +24932
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26341

___
Python tracker 
<https://bugs.python.org/issue44093>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue43109] When using Apple Clang, --with-lto builds should not check for llvm-ar

2021-05-24 Thread Ned Deily


Change by Ned Deily :


--
pull_requests: +24931
pull_request: https://github.com/python/cpython/pull/26341

___
Python tracker 
<https://bugs.python.org/issue43109>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41282] Deprecate and remove distutils

2021-05-24 Thread Ned Deily


Ned Deily  added the comment:

Petr's analysis and PR looked good and the PR is now merged to main and to 3.10 
for 3.10.0b2.  Thanks, Petr! Downgrading back to normal priority.

--
priority: release blocker -> normal

___
Python tracker 
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41282] Deprecate and remove distutils

2021-05-24 Thread Ned Deily


Ned Deily  added the comment:

Er, make that "GH-26327 attempts to fix the problem ... " but I see from the CI 
that it causes test_distutils to fail in the simpler case of running the test 
from the build directory (rather than from an installed location which does 
pass). I have run out of time right now but I will get back to it later today 
unless someone gets to it first.

--

___
Python tracker 
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41282] Deprecate and remove distutils

2021-05-24 Thread Ned Deily


Ned Deily  added the comment:

It looks like 341e8a939aca6e9f59ffb0e6daee5888933694ed (GH-24549) incorrectly 
deleted an important check in sysconfig that is needed for building the cpython 
standard library on unix-y systems. The chain of events is somewhat complicated 
but the problem can be easily seen by carefully examining the output of a 
simple build and install, like:

./configure --prefix=/tmp/testbuild
make
make install

As of 3.10.0b1, this results in the standard library module being built twice, 
once by the make step and once by the make install step.

GH-26237 attempts to fix the problem with minimal changes to the approach taken 
in GH-24549 to consolidate Lib/sysconfig.py and Lib/distutils/sysconfig.py. 
Frankly, I am not confident it is the best approach so it should be carefully 
reviewed. There probably should also be a test added at some point for this 
case but I will let someone else deal with that and a test should not hold up 
3.10.0b2. But I think the build failure is serious enough that b2 should be 
held for a fix.

--
priority: normal -> release blocker
versions: +Python 3.11

___
Python tracker 
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue41282] Deprecate and remove distutils

2021-05-24 Thread Ned Deily


Change by Ned Deily :


--
pull_requests: +24919
pull_request: https://github.com/python/cpython/pull/26327

___
Python tracker 
<https://bugs.python.org/issue41282>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31767] Windows Installer fails with error 0x80091007 when trying to install debugging symbols

2021-05-21 Thread Ned Deily


Ned Deily  added the comment:

Any updates on this or can it be closed?

--
nosy: +ned.deily

___
Python tracker 
<https://bugs.python.org/issue31767>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33213] crypt function not hashing properly on Mac (uses a specific salt)

2021-05-21 Thread Ned Deily


Change by Ned Deily :


--
components: +macOS
versions: +Python 3.11 -Python 3.6, Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue33213>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

2021-05-21 Thread Ned Deily


Ned Deily  added the comment:

Since 3.5 has now reached end-of-life, this issue will not be fixed there so it 
looks like it can be closed.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5

___
Python tracker 
<https://bugs.python.org/issue37228>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29788] [Security] tarfile: Add absolute_path option to tarfile, disabled by default

2021-05-21 Thread Ned Deily


Change by Ned Deily :


--
versions: +Python 3.11 -Python 3.7

___
Python tracker 
<https://bugs.python.org/issue29788>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



  1   2   3   4   5   6   7   8   9   10   >