Ned Deily added the comment:
Thanks for the report. At first glance, it does look like it's broken on macOS
10.15. I'll look into it.
--
assignee: -> ned.deily
___
Python tracker
<https://bugs.pytho
Change by Ned Deily :
--
assignee: -> terry.reedy
components: +IDLE -macOS
nosy: +terry.reedy
___
Python tracker
<https://bugs.python.org/issue40508>
___
_
Ned Deily added the comment:
Thanks for submitting the version of IDLE you were using. It appears to be a
Python 3.6.1 from 2017; the version is very old-of-date and no longer
supported. Python 3.6.x is now in security fix mode only; Python 3.8.2 is now
current. Unless you have a
Ned Deily added the comment:
See the long discussion in Issue34602 for more details. The investigation there
showed that there are now conditions when running in newer versions of macOS
(apparently as of 10.14.4) where trying to increase the stack limit at run time
using
Ned Deily added the comment:
> (A) Ensure that _uuid works on macOS, FreeBSD and Linux, especially in the
> macOS installer of python.org.
FWIW, a spot check shows that _uuid builds and test_uuid passes both sets of
its tests, e.g. TestUUIDWithExtModule and TestUUIDWithoutExtModule
Ned Deily added the comment:
See proposed PR 19925 for further discussion.
--
components: +macOS -Build
nosy: +ned.deily, ronaldoussoren
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue40
Change by Ned Deily :
--
nosy: +davin, pitrou
___
Python tracker
<https://bugs.python.org/issue40379>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ned Deily :
--
components: +Build
___
Python tracker
<https://bugs.python.org/issue40516>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Ned Deily :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue40
Ned Deily added the comment:
Zain and/or Raymond: can you please give the exact steps to reproduce this
problem, including exactly how you invoke IDLE, the Python version info and
build date info from the IDLE shell window, the details of exactly how you
invoke Save As (i.e whether via
Ned Deily added the comment:
As of current Python 3 releases, like 3.8, the python build no longer vendors a
copy of libffi for most Unix systems and for those systems the
--with-system-ffi configure option is ignored, i.e. configure and setup.py will
always try to find an external libffi
Ned Deily added the comment:
As of Python 3.7.0, we no longer "vendor" a copy of the libffi source for
Unix-y platforms so I believe this issue of passing the right flag values into
cpython's libffi build is no longer relevant.
--
nosy: +ned.deily
resolution: ->
Ned Deily added the comment:
As of Python 3.7, Python source releases no longer "vendor" the source of
libffi for Linux platforms; you need to use either a system-supplied libffi or,
if really necessary, build and link with your own copy (not always easy to do).
As the supp
Ned Deily added the comment:
Paul, it looks like your changes were included upstream in libffi 3.3.0 which
is now being used for python.org Windows builds. If that is true, can we now
close this issue?
--
nosy: +ned.deily
resolution: -> out of date
stage: -> resolved
status
Ned Deily added the comment:
Sorry for the long delay in answering this issue: ctypes and libffi issues do
not get a lot of attention currently. I assume you must have long ago found a
solution to the problem but, just for the record and assuming I understand the
problem correctly, if you
Change by Ned Deily :
--
resolution: -> out of date
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue1648957>
___
___
Change by Ned Deily :
--
resolution: out of date -> third party
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue36944>
___
___
Pyth
Ned Deily added the comment:
As of Python 3.7, we no longer "vendor" a copy of the libffi source in Python
source releases; you either need to use a system-supplied libffi, a third-party
binary, or build it youself. Also Python 2.7 has reached end-of-life and is
now frozen.
Ned Deily added the comment:
Thanks for the patch and sorry for the long delay in replying. As you may
know, as of Python 3.7, we no longer "vendor" a copy of the libffi source in
Python source releases; you now have to use either a system-supplied version of
libffi or otherw
Ned Deily added the comment:
Thanks for the suggested patch and sorry that it has not been replied to
earlier. As of Python 3.7, the libffi source for Unix-y platforms is no longer
"vendored" in Python source releases; building ctypes now requires an external
copy of libffi,
Ned Deily added the comment:
See also earlier discussions in Issue31710, Issue34823, Issue40488, and
Issue40535, closed as duplicated of this issue.
--
stage: -> needs patch
type: enhancement ->
___
Python tracker
<https://bugs.p
Ned Deily added the comment:
Thanks for the report and for the analysis. There have been a number of reports
over the years about problems trying to build and/or execute Pythons with an
external copy of libffi. They have become more pressing now that we no longer
vendor the source of libffi
Ned Deily added the comment:
Thanks for the report and for the analysis. There have been a number of reports
over the years about problems trying to build and/or execute Pythons with an
external copy of libffi. They have become more pressing now that we no longer
vendor the source of libffi
Ned Deily added the comment:
Thanks for the report and for the analysis. There have been a number of reports
over the years about problems trying to build and/or execute Pythons with an
external copy of libffi. They have become more pressing now that we no longer
vendor the source of libffi
Ned Deily added the comment:
Thanks for the report and for the analysis. There have been a number of reports
over the years about problems trying to build and/or execute Pythons with an
external copy of libffi. They have become more pressing now that we no longer
vendor the source of libffi
Change by Ned Deily :
--
nosy: +mdk, willingc
___
Python tracker
<https://bugs.python.org/issue40562>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
That enabling FullDiskAccess makes a difference makes some sense but that is
not something we should be recommending without better understanding what's
going on here. We still need a reproducible test case; I still am not able to
reproduce. Raymond, your
Ned Deily added the comment:
>To debug, and test Raymond's hypothesis, someone please try this minimal
>(IDLE-free) code to show the dialog and print the return.
>This does not display a preview, even after selecting a location, such as
>Documents, on the 3rd line.
Terr
Ned Deily added the comment:
An update on this: it turns out there are two different problems with the
launcher app as a result of security changes introduced in macOS 10.15 Catalina.
The first is that the launcher did not execute files launched with it (for
example, by double-clicking on
Ned Deily added the comment:
Glenn, you will need to change the Interpreter setting in the Launcher
Preferences panel. In the box that says "/usr/bin/pythonw", type
"/usr/local/bin/python3"; that setting will then be remembered on
Ned Deily added the comment:
> After your final fix, if I understood you correctly, we will no longer have
> to open Terminal?
That's correct. That's the way the Launcher works on previous version on macOS.
> will it ever be possible to not have the terminal run in the
Ned Deily added the comment:
Thanks for the report. Unfortunately, you are not actually building Python 3.6
here. Revision f3a5b7a is on the master branch, not 3.6. The fact that you are
seeing a failure of test_peg_generator confirms that you are building from
master (i.e. a pre-release
Ned Deily added the comment:
P.S. If you *do* want to build the current HEAD of the 3.6 branch including as
yet unreleased fixes:
git checkout 3.6
If you want to build a specific release, use the v^ tags provided for each
release:
git checkout v3.6.8
Change by Ned Deily :
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue33797>
___
Ned Deily added the comment:
New changeset 9a45bfe6f4aedd2a9d94cb12aa276057b15d8b63 by Erlend Egeberg
Aasland in branch 'master':
bpo-35569: Expose RFC 3542 IPv6 socket options on macOS (GH-19526)
https://github.com/python/cpython/commit/9a45bfe6f4aedd2a9d94cb12aa2760
Ned Deily added the comment:
Thanks for the PR! Merged for 3.9.0b1
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
title: OSX: Enable IPV6_RECVPKTINFO -> Expose RFC 3542 IPv6 socket options on
macOS
versions:
Change by Ned Deily :
--
pull_requests: +19451
pull_request: https://github.com/python/cpython/pull/20146
___
Python tracker
<https://bugs.python.org/issue35
Ned Deily added the comment:
New changeset fa098b6bc8662cceb944ad5a4a3e5eb63d3cb517 by Ned Deily in branch
'master':
bpo-35569: add Erlend to Misc/ACKS (GH-20146)
https://github.com/python/cpython/commit/fa098b6bc8662cceb944ad5a4a3e5e
Change by Ned Deily :
--
keywords: +patch
pull_requests: +19470
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/20171
___
Python tracker
<https://bugs.python.org/issu
Ned Deily added the comment:
New changeset 1731d6da263e9a2d6e783e87a8a5d5ce58fda46d by Ned Deily in branch
'master':
bpo-34956: Fix macOS _tkinter use of Tcl/Tk in /Library/Frameworks (GH-20171)
https://github.com/python/cpython/commit/1731d6da263e9a2d6e783e87a8a5d5
Change by Ned Deily :
--
pull_requests: +19474
pull_request: https://github.com/python/cpython/pull/20176
___
Python tracker
<https://bugs.python.org/issue26
Ned Deily added the comment:
New changeset 0da546665075aefbb476e192ed64122d340164f4 by Ned Deily in branch
'master':
bpo-26317: Support OBJC and OBJCXX configure command line variables (GH-20176)
https://github.com/python/cpython/commit/0da546665075aefbb476e192ed6412
Ned Deily added the comment:
Thanks everyone for their comments and reviews and a very big thank you to
Jeffrey for working through the details and providing a solid PR. The change
will appear in the 3.9.0b1 pre-release.
--
resolution: -> fixed
stage: patch review -> re
Ned Deily added the comment:
Thanks for the report and the PR. Yes, detect_tkinter_darwin() had a number of
problems due mainly to how Apple has first deprecated and more recently removed
the option to have header files installed in the running system. Plus some
nasty quirks of how the Tcl
Change by Ned Deily :
--
pull_requests: -19480
___
Python tracker
<https://bugs.python.org/issue34956>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Sorry about that! Looking now.
--
___
Python tracker
<https://bugs.python.org/issue26317>
___
___
Python-bugs-list mailin
Change by Ned Deily :
--
pull_requests: +19483
pull_request: https://github.com/python/cpython/pull/20182
___
Python tracker
<https://bugs.python.org/issue26
Ned Deily added the comment:
I believe the Windows builds are still using 1.1.1f.
--
___
Python tracker
<https://bugs.python.org/issue40164>
___
___
Python-bug
Ned Deily added the comment:
I'm not sure yet exactly what the problem is but it's almost certainly a
difference between GNU make and BSD make and something that needs to be checked
on FreeBSD. With the 3.9.0b1 cutoff coming very soon, I likely won't be able to
test on Free
Ned Deily added the comment:
New changeset 951ab58024de9b5a21f0b979cdbea51e1049d781 by Ned Deily in branch
'master':
Revert "bpo-26317: Support OBJC and OBJCXX configure command line variables
(GH-20176)" (GH-20182)
https://github.com/p
Ned Deily added the comment:
I've installed the 11.1 beta (of 2020-11-17) on an Intel-64 virtual machine and
installed and run the test suite for the recently released 3.9.1rc1 Universal2
binaries from python.org. The tests, including tkinter tests, run similarly to
how they do on 1
Ned Deily added the comment:
If Homebrew links against the Apple-supplied Tcl and Tk frameworks, which are
in /System/Library/Frameworks, all bets are off as those are deprecated and
hopelessly out-of-date versions of Tcl/Tk 8.5. If tkinter is linked to Tcl and
Tk frameworks in /Library
Ned Deily added the comment:
Christian, ping?
--
___
Python tracker
<https://bugs.python.org/issue41837>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ned Deily :
As of 3.9.1rc1 (and coming soon to 3.10.x and 3.8.x), we now provide a new
additional macOS universal2 installer variant that, for various reasons,
provides a built-in version of Tcl/Tk 8.6.10, instead of 8.6.8 as has been
provided with the 10.9 installer
Change by Ned Deily :
--
nosy: +serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue42507>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ned Deily :
An IDLE installation manual smoke test gives odd behavior when run on macOS
using the Tcl/Tk 8.6.10 introduced with the new macOS universal2 installer
variant as of 3.9.1rc1. The test behaves as expected (without the duplicate
and spurious error messages
Ned Deily added the comment:
I tested on 3.9 with the backport of GH-23474 merged. The six failures are
still there plus there is now an additional failure:
==
FAIL: test_horizontal_range
Change by Ned Deily :
--
nosy: +steve.dower
___
Python tracker
<https://bugs.python.org/issue42523>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Thanks for checking, Kevin. Is there any update on when we can expect a Tk
8.6.11? It's been over a year now since 8.6.10 and there have been so many
macOS-related changes that have gone into Tk since then. It's really not fair
to ask downstream packa
Ned Deily added the comment:
Terry:
> It might be the tk/tkinter build, not the tests, that is at fault.
Can you elaborate?
--
___
Python tracker
<https://bugs.python.org/issu
Ned Deily added the comment:
New changeset 5291639e611dc3f55a34666036f2c3424648ba50 by FX Coudert in branch
'master':
bpo-42504: fix for MACOSX_DEPLOYMENT_TARGET=11 (GH-23556)
https://github.com/python/cpython/commit/5291639e611dc3f55a34666036f2c3
Change by Ned Deily :
--
versions: +Python 3.10, Python 3.8
___
Python tracker
<https://bugs.python.org/issue42504>
___
___
Python-bugs-list mailing list
Unsub
Change by Ned Deily :
--
components: +Distutils, macOS
nosy: +dstufft, eric.araujo, ned.deily, ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue42
Ned Deily added the comment:
I agree with Ronald that it would be safest if the sysconfigs (all of them)
always returned deployment target as a string and I would be fine with a PR
that did that. That doesn't mean that the already applied PR needs to be
changed, though, right? Just
Ned Deily added the comment:
OK, thanks for the clarification, Terry. Considering that our tkinter tests
make assumptions about the underlying Tk widgets behavior, assumptions not
necessarily shared by the Tk developers :), these kind of version-dependent
failures are a risk of and
Ned Deily added the comment:
I agree that moving forward (using an unreleased 8.6.10+ snapshot) is better
than moving backwards (back to 8.6.9). Perhaps Marc or Kevin can suggest Tcl
and Tk dev heads to use.
--
nosy: +culler
___
Python tracker
Change by Ned Deily :
--
pull_requests: +22517
pull_request: https://github.com/python/cpython/pull/23649
___
Python tracker
<https://bugs.python.org/issue41
Ned Deily added the comment:
New changeset 29afab6c5f656f07ac85c9b2cf089631b2557a11 by Ned Deily in branch
'master':
bpo-41116: Fix setup.py test for macOS Tcl/Tk frameworks (GH-23649)
https://github.com/python/cpython/commit/29afab6c5f656f07ac85c9b2cf0896
Ned Deily added the comment:
New changeset 06002b3f0d4570424feef37103c7e9b7d16bd63d by Miss Islington (bot)
in branch '3.9':
[3.9] bpo-41116: Fix setup.py test for macOS Tcl/Tk frameworks (GH-23649)
(GH-23650)
https://github.com/python/cpython/commit/06002b3f0d4570424feef37103c7e9
Change by Ned Deily :
--
nosy: +mdk
___
Python tracker
<https://bugs.python.org/issue42581>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Ned Deily :
--
nosy: +mdk
___
Python tracker
<https://bugs.python.org/issue42579>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Ned Deily added the comment:
New changeset 57e511361047895231f5ee7abfdfbbc60e11d2db by Terry Jan Reedy in
branch 'master':
bpo-42508: Keep IDLE running on macOS (GH-23577)
https://github.com/python/cpython/commit/57e511361047895231f5ee7abfdfbb
Ned Deily added the comment:
New changeset 2a9a883d361d37b40fb0b0011dd300bb83ceb73c by Miss Islington (bot)
in branch '3.9':
bpo-42508: Keep IDLE running on macOS (GH-23577) (GH-23669)
https://github.com/python/cpython/commit/2a9a883d361d37b40fb0b0011dd300
Change by Ned Deily :
--
nosy: +ned.deily
___
Python tracker
<https://bugs.python.org/issue42603>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
Also, I have seen test_socket hang like this in the past on Debian when
building with older versions of openssl 1.1.0. If possible, try upgrading to a
later or current version of openssl 1.1.0.
--
nosy: +ned.deily
Ned Deily added the comment:
> Are there plans to backport PR 22855 to any branches older than 3.9?
The plan is to also support 3.8 on Big Sur and Apple Silicon as 3.8 is still in
bugfix mode. There are no plans to backport support to 3.7 and 3.6 which are
in the security-fix-only phase
Ned Deily added the comment:
New changeset 674fa0a740151e0416c9383f127b16014e805990 by Joshua Root in branch
'master':
bpo-42598: Fix implicit function declarations in configure (GH-23690)
https://github.com/python/cpython/commit/674fa0a740151e0416c9383f127b16014e805990
-
Ned Deily added the comment:
New changeset 3dcdbdeb4833e45430ccc9cb3432f779a6fd8c94 by Miss Islington (bot)
in branch '3.9':
bpo-42598: Fix implicit function declarations in configure (GH-23690) (GH-23756)
https://github.com/python/cpython/commit/3dcdbdeb4833e45430ccc9cb3432f7
Ned Deily added the comment:
New changeset 9feda9f871498463fe502d63204cf9cd6c1f4706 by Miss Islington (bot)
in branch '3.8':
bpo-42598: Fix implicit function declarations in configure (GH-23690) (GH-23757)
https://github.com/python/cpython/commit/9feda9f871498463fe502d63204cf9
Ned Deily added the comment:
Thanks for noticing the failures and for the PR!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8
___
Python tracker
<https://bugs.python.or
Ned Deily added the comment:
New changeset 8bef9ebb1b88cfa4b2a38b93fe4ea22015d8254a by Miss Islington (bot)
in branch '3.6':
bpo-40791: Make compare_digest more constant-time. (GH-23438) (GH-23767)
https://github.com/python/cpython/commit/8bef9ebb1b88cfa4b2a38b93fe4ea2
Ned Deily added the comment:
> Any reason this wasn't backported to 3.6?
Just an oversight. Thanks for pointing it out.
--
versions: +Python 3.6
___
Python tracker
<https://bugs.python.org
Ned Deily added the comment:
The problem here undoubtedly is that the Python you are using is linked with
the Apple-provided system version of Tk 8.5.9 which exhibits this nasty
behavior of crashing when pressing a composing key. The system version of Tk is
woefully out of date with other
Ned Deily added the comment:
> Which version of TK 8.5.X fixes this, 8.5.18.0?
Yes, that version of Tk 8.5 does not have this problem. But Tk 8.5 is no longer
supported by the Tcl project; we recommend the use of Tk 8.6. In general, you
usually cannot just swap Tk versions; the Pyt
Change by Ned Deily :
--
Removed message: https://bugs.python.org/msg383146
___
Python tracker
<https://bugs.python.org/issue19733>
___
___
Python-bugs-list m
Change by Ned Deily :
--
Removed message: https://bugs.python.org/msg383147
___
Python tracker
<https://bugs.python.org/issue19733>
___
___
Python-bugs-list m
Change by Ned Deily :
--
Removed message: https://bugs.python.org/msg383148
___
Python tracker
<https://bugs.python.org/issue19733>
___
___
Python-bugs-list m
Change by Ned Deily :
Removed file: https://bugs.python.org/file49686/IMAG0215(5).jpg
___
Python tracker
<https://bugs.python.org/issue19733>
___
___
Python-bugs-list m
Change by Ned Deily :
--
hgrepos: -395
___
Python tracker
<https://bugs.python.org/issue19733>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ned Deily added the comment:
New changeset 00278d4e616315e64557bff014574c079e6e96ff by Miss Islington (bot)
in branch '3.7':
bpo-17140: Document multiprocessing's ThreadPool (GH-23812) (GH-23836)
https://github.com/python/cpython/commit/00278d4e616315e64557bff01
Ned Deily added the comment:
Thanks, Matt, for the documentation PR.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6
___
Python tracke
Ned Deily added the comment:
As explained above, this crash will happen with any Python that links to the
deprecated Apple-supplied system Tk framework in macOS versions from macOS 10.7
to 11 Big Sur. If you want to use tkinter, you need to use a Python that links
to a newer version of Tk
Ned Deily added the comment:
@fxcoudert: If you are trying to link with the Apple-provided system Tcl and Tk
frameworks, don't. They have been seriously broken since macOS 10.7 and stuck
at Tk 8.5.9. The only visible Apple action has been to deprecate them. Any
Python on macOS that c
Ned Deily added the comment:
This is the same sort of crash of a Homebrew Python as reported in Issue42480
and the root cause is the same: the Homebrew recipe is allowing building and
linking with the known faulty and deprecated Apple-provided system Tcl and Tk
8.5.9 frameworks. It needs to
Ned Deily added the comment:
Note also that Python 3.7 is now in the security-fix-only phase of its
lifecycle meaning it no longer receives non-security bug fixes and binary
installers for it will no longer be produced. In particular, Pygthon 3.7 has
not been updated for macOS 11 and Apple
Change by Ned Deily :
--
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42704>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Ned Deily :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42701>
___
___
Python-bugs-list
Ned Deily added the comment:
> I have tried to update tcl-tk with the homebrew, but in command line I see 8.5
> Could you please help me to fix this tcl-tk problem?
You should check with the Homebrew project; we have no insight into or control
over their packaging choices. Goo
Ned Deily added the comment:
If you are not using Tcl and Tk framework builds installed in /Library, you use
the configure or make options:
--with-tcltk-includes='-I...'
override search for Tcl and Tk include files
--with-tclt
Ned Deily added the comment:
> Should I do something with this now or just wait for updates?
I'd wait for a Homebrew recipe update.
--
___
Python tracker
<https://bugs.python.org
1801 - 1900 of 6927 matches
Mail list logo
