[Python-Dev] Re: macOS issues with 3.8.7rc1

[Ronald Oussoren via Python-Dev]

> On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:
> 
> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding macOS.
> 
> Without the changes from https://github.com/python/cpython/pull/22855 
>  backported, attempting to 
> build a portable binary on macOS 11 (e.g. by setting 
> `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is 
> only available on macOS 10.13 or newer [-Wunguarded-availability-new]` 
> warnings during the build. This warning could be innocuous if there is 
> run-time probing in place (the symbols in question are weakly linked, which 
> is good). But if I'm reading the code correctly, run-time probing was 
> introduced by commits like eee543722 and isn't present in 3.8.7rc1.
> 
> I don't have a machine with older macOS sitting around to test, but I'm 
> fairly certain the lack of these patches means binaries built on macOS 11 
> will blow up at run-time when run on older macOS versions.
> 
> These same patches also taught CPython to build and run properly on Apple ARM 
> hardware. I suspect some people will care about these being backported to 3.8.
> 
We know. Backporting the relevant changes to 3.8 is taking more time than I had 
hoped. It doesn’t help that I’ve been busy at work and don’t have as much 
energy during the weekend as I’d like.

The backport to 3.9 was fairly easy because there were few changes between 
master and the 3.9 branch at the time. Sadly there have been conflicting 
changes since 3.8 was forked (in particular in posixmodule.c).

The current best practice for building binaries that work on macOS 10.9 is to 
build on that release (or rather, with that SDK).  That doesn’t help if you 
want to build Universal 2 binaries though.


> I suspect people in the Python application packaging/distribution space will 
> be significantly affected by this (I know I am with PyOxidizer). Is it worth 
> making the backport of these patches a 3.8.7 release blocker or a trigger for 
> a special 3.8.8 release shortly thereafter?


Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6R2OIQAFFJ2E2IYH3U5PPGLHQ5CYBCUC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Simon Cross]

On Wed, Dec 9, 2020 at 2:17 PM Ronald Oussoren via Python-Dev
 wrote:
> We know. Backporting the relevant changes to 3.8 is taking more time than I 
> had hoped. It doesn’t help that I’ve
> been busy at work and don’t have as much energy during the weekend as I’d 
> like.

Thank you for all your hard work on this! I've been in similar
positions as a maintainer in the past (long work days and too tired to
get to open source fixes in the evenings or on weekends).

Please look after yourself -- it's better for everyone if the patch is
delayed some months than to have you get burned out (or even just not
enjoy contributing).

Many open source contribution journeys begin with someone scratching
an itch, so it's okay if there are itches for people to scratch. :D
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/27MUX65R52HZNGSIPNBRCC2ITFJUFMKM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Gregory Szorc]

On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren 
wrote:

>
>
> On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:
>
> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding
> macOS.
>
> Without the changes from https://github.com/python/cpython/pull/22855
> backported, attempting to build a portable binary on macOS 11 (e.g. by
> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:
> 'XXX' is only available on macOS 10.13 or newer
> [-Wunguarded-availability-new]` warnings during the build. This warning
> could be innocuous if there is run-time probing in place (the symbols in
> question are weakly linked, which is good). But if I'm reading the code
> correctly, run-time probing was introduced by commits like eee543722 and
> isn't present in 3.8.7rc1.
>
> I don't have a machine with older macOS sitting around to test, but I'm
> fairly certain the lack of these patches means binaries built on macOS 11
> will blow up at run-time when run on older macOS versions.
>
> These same patches also taught CPython to build and run properly on Apple
> ARM hardware. I suspect some people will care about these being backported
> to 3.8.
>
> We know. Backporting the relevant changes to 3.8 is taking more time than
> I had hoped. It doesn’t help that I’ve been busy at work and don’t have as
> much energy during the weekend as I’d like.
>
> The backport to 3.9 was fairly easy because there were few changes between
> master and the 3.9 branch at the time. Sadly there have been conflicting
> changes since 3.8 was forked (in particular in posixmodule.c).
>
> The current best practice for building binaries that work on macOS 10.9 is
> to build on that release (or rather, with that SDK).  That doesn’t help if
> you want to build Universal 2 binaries though.
>

Thank you for your hard work devising the patches and working to backport
them.

I personally care a lot about these patches and I have the technical
competency to perform the backport. If you need help, I could potentially
find time to hack on it. Just email me privately (or ping @indygreg on
GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely
cherry pick the patches for
https://github.com/indygreg/python-build-standalone. And I'm sure other
downstream packagers will want them as well. So having them in an
unreleased 3.8 branch is better than not having them at all.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Gregory P. Smith]

As a meta question: Is there a good reason to support binaries running on
macOS earlier than ~ $latest_version-1?

Aren't systems running those old releases rather than upgrading unsupported
by Apple, never to be patched, and thus not wise to even have on a network?

Yes, that means some very old hardware becomes useless as Apple drops
support. But that is what people signed up for when they bought it. Why
should that be our problem?

(It sounds like y'all will make it work, that's great! I'm really just
wondering where the motivation comes from)

-gps

On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc  wrote:

> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren 
> wrote:
>
>>
>>
>> On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:
>>
>> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding
>> macOS.
>>
>> Without the changes from https://github.com/python/cpython/pull/22855
>> backported, attempting to build a portable binary on macOS 11 (e.g. by
>> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:
>> 'XXX' is only available on macOS 10.13 or newer
>> [-Wunguarded-availability-new]` warnings during the build. This warning
>> could be innocuous if there is run-time probing in place (the symbols in
>> question are weakly linked, which is good). But if I'm reading the code
>> correctly, run-time probing was introduced by commits like eee543722 and
>> isn't present in 3.8.7rc1.
>>
>> I don't have a machine with older macOS sitting around to test, but I'm
>> fairly certain the lack of these patches means binaries built on macOS 11
>> will blow up at run-time when run on older macOS versions.
>>
>> These same patches also taught CPython to build and run properly on Apple
>> ARM hardware. I suspect some people will care about these being backported
>> to 3.8.
>>
>> We know. Backporting the relevant changes to 3.8 is taking more time than
>> I had hoped. It doesn’t help that I’ve been busy at work and don’t have as
>> much energy during the weekend as I’d like.
>>
>> The backport to 3.9 was fairly easy because there were few changes
>> between master and the 3.9 branch at the time. Sadly there have been
>> conflicting changes since 3.8 was forked (in particular in posixmodule.c).
>>
>> The current best practice for building binaries that work on macOS 10.9
>> is to build on that release (or rather, with that SDK).  That doesn’t help
>> if you want to build Universal 2 binaries though.
>>
>
> Thank you for your hard work devising the patches and working to backport
> them.
>
> I personally care a lot about these patches and I have the technical
> competency to perform the backport. If you need help, I could potentially
> find time to hack on it. Just email me privately (or ping @indygreg on
> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely
> cherry pick the patches for
> https://github.com/indygreg/python-build-standalone. And I'm sure other
> downstream packagers will want them as well. So having them in an
> unreleased 3.8 branch is better than not having them at all.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Brett Cannon]

On Wed, Dec 9, 2020 at 10:16 AM Gregory P. Smith  wrote:

>
>
> As a meta question: Is there a good reason to support binaries running on
> macOS earlier than ~ $latest_version-1?
>
> Aren't systems running those old releases rather than upgrading
> unsupported by Apple, never to be patched, and thus not wise to even have
> on a network?
>

I don't know if Apple has a written policy on support for older versions of
macOS.

Looking at https://support.apple.com/en-us/HT201222 it suggests that macOS
10.13 High Sierra got an update last month, but 10.12 has not been updated
since September 2019.


>
> Yes, that means some very old hardware becomes useless as Apple drops
> support. But that is what people signed up for when they bought it. Why
> should that be our problem?
>
> (It sounds like y'all will make it work, that's great! I'm really just
> wondering where the motivation comes from)
>

I would be supportive of saying our support policy for macOS is up to one
year after the last security update which would mean we would support 10.13
and newer which was released September 2017. (Honestly, I would be fine
with 6 months since Apple seems to make security releases frequently enough
to use that as an indicator that they have dropped support, but one year
seems more "reasonable" as a way to not accidentally cut support off
prematurely.)

-Brett


>
> -gps
>
> On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc 
> wrote:
>
>> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren 
>> wrote:
>>
>>>
>>>
>>> On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:
>>>
>>> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding
>>> macOS.
>>>
>>> Without the changes from https://github.com/python/cpython/pull/22855
>>> backported, attempting to build a portable binary on macOS 11 (e.g. by
>>> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:
>>> 'XXX' is only available on macOS 10.13 or newer
>>> [-Wunguarded-availability-new]` warnings during the build. This warning
>>> could be innocuous if there is run-time probing in place (the symbols in
>>> question are weakly linked, which is good). But if I'm reading the code
>>> correctly, run-time probing was introduced by commits like eee543722 and
>>> isn't present in 3.8.7rc1.
>>>
>>> I don't have a machine with older macOS sitting around to test, but I'm
>>> fairly certain the lack of these patches means binaries built on macOS 11
>>> will blow up at run-time when run on older macOS versions.
>>>
>>> These same patches also taught CPython to build and run properly on
>>> Apple ARM hardware. I suspect some people will care about these being
>>> backported to 3.8.
>>>
>>> We know. Backporting the relevant changes to 3.8 is taking more time
>>> than I had hoped. It doesn’t help that I’ve been busy at work and don’t
>>> have as much energy during the weekend as I’d like.
>>>
>>> The backport to 3.9 was fairly easy because there were few changes
>>> between master and the 3.9 branch at the time. Sadly there have been
>>> conflicting changes since 3.8 was forked (in particular in posixmodule.c).
>>>
>>> The current best practice for building binaries that work on macOS 10.9
>>> is to build on that release (or rather, with that SDK).  That doesn’t help
>>> if you want to build Universal 2 binaries though.
>>>
>>
>> Thank you for your hard work devising the patches and working to backport
>> them.
>>
>> I personally care a lot about these patches and I have the technical
>> competency to perform the backport. If you need help, I could potentially
>> find time to hack on it. Just email me privately (or ping @indygreg on
>> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely
>> cherry pick the patches for
>> https://github.com/indygreg/python-build-standalone. And I'm sure other
>> downstream packagers will want them as well. So having them in an
>> unreleased 3.8 branch is better than not having them at all.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Messag

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Steve Holden]

A general wish not to disadvantage those with older hardware any more than
they already are?

Just a shot in the dark.


On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith  wrote:

>
>
> As a meta question: Is there a good reason to support binaries running on
> macOS earlier than ~ $latest_version-1?
>
> Aren't systems running those old releases rather than upgrading
> unsupported by Apple, never to be patched, and thus not wise to even have
> on a network?
>
> Yes, that means some very old hardware becomes useless as Apple drops
> support. But that is what people signed up for when they bought it. Why
> should that be our problem?
>
> (It sounds like y'all will make it work, that's great! I'm really just
> wondering where the motivation comes from)
>
> -gps
>
> On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc 
> wrote:
>
>> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren 
>> wrote:
>>
>>>
>>>
>>> On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:
>>>
>>> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding
>>> macOS.
>>>
>>> Without the changes from https://github.com/python/cpython/pull/22855
>>> backported, attempting to build a portable binary on macOS 11 (e.g. by
>>> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:
>>> 'XXX' is only available on macOS 10.13 or newer
>>> [-Wunguarded-availability-new]` warnings during the build. This warning
>>> could be innocuous if there is run-time probing in place (the symbols in
>>> question are weakly linked, which is good). But if I'm reading the code
>>> correctly, run-time probing was introduced by commits like eee543722 and
>>> isn't present in 3.8.7rc1.
>>>
>>> I don't have a machine with older macOS sitting around to test, but I'm
>>> fairly certain the lack of these patches means binaries built on macOS 11
>>> will blow up at run-time when run on older macOS versions.
>>>
>>> These same patches also taught CPython to build and run properly on
>>> Apple ARM hardware. I suspect some people will care about these being
>>> backported to 3.8.
>>>
>>> We know. Backporting the relevant changes to 3.8 is taking more time
>>> than I had hoped. It doesn’t help that I’ve been busy at work and don’t
>>> have as much energy during the weekend as I’d like.
>>>
>>> The backport to 3.9 was fairly easy because there were few changes
>>> between master and the 3.9 branch at the time. Sadly there have been
>>> conflicting changes since 3.8 was forked (in particular in posixmodule.c).
>>>
>>> The current best practice for building binaries that work on macOS 10.9
>>> is to build on that release (or rather, with that SDK).  That doesn’t help
>>> if you want to build Universal 2 binaries though.
>>>
>>
>> Thank you for your hard work devising the patches and working to backport
>> them.
>>
>> I personally care a lot about these patches and I have the technical
>> competency to perform the backport. If you need help, I could potentially
>> find time to hack on it. Just email me privately (or ping @indygreg on
>> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely
>> cherry pick the patches for
>> https://github.com/indygreg/python-build-standalone. And I'm sure other
>> downstream packagers will want them as well. So having them in an
>> unreleased 3.8 branch is better than not having them at all.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7ZSZVIVUVM35GELRKGXWAJ3HLYU6G6OJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Gregory Szorc]

On Wed, Dec 9, 2020 at 10:10 AM Gregory P. Smith  wrote:

>
>
> As a meta question: Is there a good reason to support binaries running on
> macOS earlier than ~ $latest_version-1?
>
> Aren't systems running those old releases rather than upgrading
> unsupported by Apple, never to be patched, and thus not wise to even have
> on a network?
>
> Yes, that means some very old hardware becomes useless as Apple drops
> support. But that is what people signed up for when they bought it. Why
> should that be our problem?
>
> (It sounds like y'all will make it work, that's great! I'm really just
> wondering where the motivation comes from)
>

FWIW The patches are necessary to target 10.15 when building on 11.0. So
the value of the patches is very real to target audiences today, especially
since many developers have already adopted 11.0 out of necessity.

While I think there are merits to having a discussion around macOS version
support policy, may I ask that it take place in a different thread so it
doesn't derail the more immediate conversation centering around the 3.8.7
release?


>
> On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc 
> wrote:
>
>> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren 
>> wrote:
>>
>>>
>>>
>>> On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:
>>>
>>> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding
>>> macOS.
>>>
>>> Without the changes from https://github.com/python/cpython/pull/22855
>>> backported, attempting to build a portable binary on macOS 11 (e.g. by
>>> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:
>>> 'XXX' is only available on macOS 10.13 or newer
>>> [-Wunguarded-availability-new]` warnings during the build. This warning
>>> could be innocuous if there is run-time probing in place (the symbols in
>>> question are weakly linked, which is good). But if I'm reading the code
>>> correctly, run-time probing was introduced by commits like eee543722 and
>>> isn't present in 3.8.7rc1.
>>>
>>> I don't have a machine with older macOS sitting around to test, but I'm
>>> fairly certain the lack of these patches means binaries built on macOS 11
>>> will blow up at run-time when run on older macOS versions.
>>>
>>> These same patches also taught CPython to build and run properly on
>>> Apple ARM hardware. I suspect some people will care about these being
>>> backported to 3.8.
>>>
>>> We know. Backporting the relevant changes to 3.8 is taking more time
>>> than I had hoped. It doesn’t help that I’ve been busy at work and don’t
>>> have as much energy during the weekend as I’d like.
>>>
>>> The backport to 3.9 was fairly easy because there were few changes
>>> between master and the 3.9 branch at the time. Sadly there have been
>>> conflicting changes since 3.8 was forked (in particular in posixmodule.c).
>>>
>>> The current best practice for building binaries that work on macOS 10.9
>>> is to build on that release (or rather, with that SDK).  That doesn’t help
>>> if you want to build Universal 2 binaries though.
>>>
>>
>> Thank you for your hard work devising the patches and working to backport
>> them.
>>
>> I personally care a lot about these patches and I have the technical
>> competency to perform the backport. If you need help, I could potentially
>> find time to hack on it. Just email me privately (or ping @indygreg on
>> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely
>> cherry pick the patches for
>> https://github.com/indygreg/python-build-standalone. And I'm sure other
>> downstream packagers will want them as well. So having them in an
>> unreleased 3.8 branch is better than not having them at all.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BVZ6YZVMHRICX5WLATCBJLSL3XA55QKQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Guido van Rossum]

+1

On Wed, Dec 9, 2020 at 11:03 AM Steve Holden  wrote:

> A general wish not to disadvantage those with older hardware any more than
> they already are?
>
> Just a shot in the dark.
>
>
> On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith  wrote:
>
>>
>>
>> As a meta question: Is there a good reason to support binaries running on
>> macOS earlier than ~ $latest_version-1?
>>
>> Aren't systems running those old releases rather than upgrading
>> unsupported by Apple, never to be patched, and thus not wise to even have
>> on a network?
>>
>> Yes, that means some very old hardware becomes useless as Apple drops
>> support. But that is what people signed up for when they bought it. Why
>> should that be our problem?
>>
>> (It sounds like y'all will make it work, that's great! I'm really just
>> wondering where the motivation comes from)
>>
>> -gps
>>
>> On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc 
>> wrote:
>>
>>> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren 
>>> wrote:
>>>


 On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:

 Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding
 macOS.

 Without the changes from https://github.com/python/cpython/pull/22855
 backported, attempting to build a portable binary on macOS 11 (e.g. by
 setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:
 'XXX' is only available on macOS 10.13 or newer
 [-Wunguarded-availability-new]` warnings during the build. This warning
 could be innocuous if there is run-time probing in place (the symbols in
 question are weakly linked, which is good). But if I'm reading the code
 correctly, run-time probing was introduced by commits like eee543722 and
 isn't present in 3.8.7rc1.

 I don't have a machine with older macOS sitting around to test, but I'm
 fairly certain the lack of these patches means binaries built on macOS 11
 will blow up at run-time when run on older macOS versions.

 These same patches also taught CPython to build and run properly on
 Apple ARM hardware. I suspect some people will care about these being
 backported to 3.8.

 We know. Backporting the relevant changes to 3.8 is taking more time
 than I had hoped. It doesn’t help that I’ve been busy at work and don’t
 have as much energy during the weekend as I’d like.

 The backport to 3.9 was fairly easy because there were few changes
 between master and the 3.9 branch at the time. Sadly there have been
 conflicting changes since 3.8 was forked (in particular in posixmodule.c).

 The current best practice for building binaries that work on macOS 10.9
 is to build on that release (or rather, with that SDK).  That doesn’t help
 if you want to build Universal 2 binaries though.

>>>
>>> Thank you for your hard work devising the patches and working to
>>> backport them.
>>>
>>> I personally care a lot about these patches and I have the technical
>>> competency to perform the backport. If you need help, I could potentially
>>> find time to hack on it. Just email me privately (or ping @indygreg on
>>> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely
>>> cherry pick the patches for
>>> https://github.com/indygreg/python-build-standalone. And I'm sure other
>>> downstream packagers will want them as well. So having them in an
>>> unreleased 3.8 branch is better than not having them at all.
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe send an email to python-dev-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7ZSZVIVUVM35GELRKGXWAJ3HLYU6G6OJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- p

[Python-Dev] NEWS, changelog, and blurb -- a teaching moment

[Ethan Furman]

Greetings!

I'm hoping somebody can alleviate my confusion.  I had thought that the blurb tool was created to resolve the 
near-constant push races when the NEWS file was updated; but it appears that it only affects the change log.


If I have a change that really needs to be in the NEWS file itself, do I need 
to directly edit that file?

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DHJN4N2VOX7WGCWLK7L6P2234PZMGRNS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Ronald Oussoren via Python-Dev]

> On 9 Dec 2020, at 19:10, Gregory P. Smith  wrote:
> 
> 
> 
> As a meta question: Is there a good reason to support binaries running on 
> macOS earlier than ~ $latest_version-1?
> 
> Aren't systems running those old releases rather than upgrading unsupported 
> by Apple, never to be patched, and thus not wise to even have on a network?

There’s no documented policy about which versions are supported, but N-2 would 
be a good guess (even if Apple mostly just publishes patches for N-1).   What 
worries me a little about dropping older macOS versions is that I haven’t found 
good information about upgrade rates, but have seen annecdotes about users not 
upgrading or upgrading late. 

That said. We support older versions because its fairly easy to do and to keep 
supporting users stuck at older versions for other reasons.  
> 
> Yes, that means some very old hardware becomes useless as Apple drops 
> support. But that is what people signed up for when they bought it. Why 
> should that be our problem?
> 
> (It sounds like y'all will make it work, that's great! I'm really just 
> wondering where the motivation comes from)

The basic work is needed for N-1 (build on macOS 11, deploy to 10.15), doing 
the same for macOS 10.9 was fairly straightforward. This is work that needs to 
be done once, and is clearly labelled after that (making it easy to identify 
when we decide to move the minimal version forward). 

One reason to support 10.9 for the universal2 installers is that this allows us 
to move all users over, the universal2 installer can be used on all systems 
where the current x86_64 installers can be used and should be faster because we 
also (finally) enabled LTO/PGO for the macOS installer.

BTW. Removing support for old versions is also work. The universal2 patches 
finally dropped support for weak linking a couple of APIs that were introduced 
in macOS 10.4, which we haven’t supported in a very long while.

Ronald

> 
> -gps
> 
> On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc  > wrote:
> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren  > wrote:
> 
> 
>> On 8 Dec 2020, at 19:59, Gregory Szorc > > wrote:
>> 
>> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding 
>> macOS.
>> 
>> Without the changes from https://github.com/python/cpython/pull/22855 
>>  backported, attempting to 
>> build a portable binary on macOS 11 (e.g. by setting 
>> `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 'XXX' is 
>> only available on macOS 10.13 or newer [-Wunguarded-availability-new]` 
>> warnings during the build. This warning could be innocuous if there is 
>> run-time probing in place (the symbols in question are weakly linked, which 
>> is good). But if I'm reading the code correctly, run-time probing was 
>> introduced by commits like eee543722 and isn't present in 3.8.7rc1.
>> 
>> I don't have a machine with older macOS sitting around to test, but I'm 
>> fairly certain the lack of these patches means binaries built on macOS 11 
>> will blow up at run-time when run on older macOS versions.
>> 
>> These same patches also taught CPython to build and run properly on Apple 
>> ARM hardware. I suspect some people will care about these being backported 
>> to 3.8.
>> 
> We know. Backporting the relevant changes to 3.8 is taking more time than I 
> had hoped. It doesn’t help that I’ve been busy at work and don’t have as much 
> energy during the weekend as I’d like.
> 
> The backport to 3.9 was fairly easy because there were few changes between 
> master and the 3.9 branch at the time. Sadly there have been conflicting 
> changes since 3.8 was forked (in particular in posixmodule.c).
> 
> The current best practice for building binaries that work on macOS 10.9 is to 
> build on that release (or rather, with that SDK).  That doesn’t help if you 
> want to build Universal 2 binaries though.
> 
> Thank you for your hard work devising the patches and working to backport 
> them.
> 
> I personally care a lot about these patches and I have the technical 
> competency to perform the backport. If you need help, I could potentially 
> find time to hack on it. Just email me privately (or ping @indygreg on 
> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely 
> cherry pick the patches for 
> https://github.com/indygreg/python-build-standalone 
> . And I'm sure other 
> downstream packagers will want them as well. So having them in an unreleased 
> 3.8 branch is better than not having them at all.
> ___
> Python-Dev mailing list -- python-dev@python.org 
> 
> To unsubscribe send an email to python-dev-le...@python.org 
> 
> https://mail.python.org/mailman3/lists/python-dev.pytho

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Jakub Stasiak]

> On 9 Dec 2020, at 19:59, Steve Holden  wrote:
> 
> A general wish not to disadvantage those with older hardware any more than 
> they already are?
> 
> Just a shot in the dark.
> 
> 
> On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith  wrote:
> 
> 
> As a meta question: Is there a good reason to support binaries running on 
> macOS earlier than ~ $latest_version-1?
> 
> Aren't systems running those old releases rather than upgrading unsupported 
> by Apple, never to be patched, and thus not wise to even have on a network?
> 
> Yes, that means some very old hardware becomes useless as Apple drops 
> support. But that is what people signed up for when they bought it. Why 
> should that be our problem?
> 
> (It sounds like y'all will make it work, that's great! I'm really just 
> wondering where the motivation comes from)
> 
> -gps
> 
> On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc  wrote:
> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren  wrote:
> 
> 
>> On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:
>> 
>> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding 
>> macOS.
>> 
>> Without the changes from https://github.com/python/cpython/pull/22855 
>> backported, attempting to build a portable binary on macOS 11 (e.g. by 
>> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning: 
>> 'XXX' is only available on macOS 10.13 or newer 
>> [-Wunguarded-availability-new]` warnings during the build. This warning 
>> could be innocuous if there is run-time probing in place (the symbols in 
>> question are weakly linked, which is good). But if I'm reading the code 
>> correctly, run-time probing was introduced by commits like eee543722 and 
>> isn't present in 3.8.7rc1.
>> 
>> I don't have a machine with older macOS sitting around to test, but I'm 
>> fairly certain the lack of these patches means binaries built on macOS 11 
>> will blow up at run-time when run on older macOS versions.
>> 
>> These same patches also taught CPython to build and run properly on Apple 
>> ARM hardware. I suspect some people will care about these being backported 
>> to 3.8.
>> 
> We know. Backporting the relevant changes to 3.8 is taking more time than I 
> had hoped. It doesn’t help that I’ve been busy at work and don’t have as much 
> energy during the weekend as I’d like.
> 
> The backport to 3.9 was fairly easy because there were few changes between 
> master and the 3.9 branch at the time. Sadly there have been conflicting 
> changes since 3.8 was forked (in particular in posixmodule.c).
> 
> The current best practice for building binaries that work on macOS 10.9 is to 
> build on that release (or rather, with that SDK).  That doesn’t help if you 
> want to build Universal 2 binaries though.
> 
> Thank you for your hard work devising the patches and working to backport 
> them.
> 
> I personally care a lot about these patches and I have the technical 
> competency to perform the backport. If you need help, I could potentially 
> find time to hack on it. Just email me privately (or ping @indygreg on 
> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely 
> cherry pick the patches for 
> https://github.com/indygreg/python-build-standalone. And I'm sure other 
> downstream packagers will want them as well. So having them in an unreleased 
> 3.8 branch is better than not having them at all.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/
> Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/
> Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/7ZSZVIVUVM35GELRKGXWAJ3HLYU6G6OJ/
> Code of Conduct: http://python.org/psf/codeofconduct/


I wouldn’t be surprised if there’s a group of people that won’t ever upgrade to 
10.15+ for variety of reasons (including loss of 32-bit application support) so 
there’s also that.

Jakub
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-d

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Guido van Rossum]

On Wed, Dec 9, 2020 at 12:15 PM Jakub Stasiak  wrote:

> I wouldn’t be surprised if there’s a group of people that won’t ever
> upgrade to 10.15+ for variety of reasons (including loss of 32-bit
> application support) so there’s also that.
>

In my experience Apple hardware is very reliable and way outlives the OS
updates. Even if an OS updates is still available, the newer OS often needs
more memory, which can be a problem (most Apple hardware is hard to add
memory to). What are people supposed to do? Just throw away their expensive
computer?

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MKYINSTDY6SUVMG6EA2VHMVOOUF5KBKT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NEWS, changelog, and blurb -- a teaching moment

[Terry Reedy]

On 12/9/2020 2:19 PM, Ethan Furman wrote:

Greetings!

I'm hoping somebody can alleviate my confusion.  I had thought that the 
blurb tool was created to resolve the near-constant push races when the 
NEWS file was updated; but it appears that it only affects the change log.


Unreleased blurbs are put in Misc/NEWS.d/next.

For each release of a branch, the blurb are removed from .../next and 
consolidated into Misc/NEWS.d/x.y.z??, such as 3.10.0a3.  PRs changing 
these file should only correct errors and not any other files.  There 
should also never be push races.


If I have a change that really needs to be in the NEWS file itself, do I 
need to directly edit that file?


By NEWS, do you mean, for instance, Doc/whatsnew/3.10.rst?  If you want 
to make sure that a new feature you merge is included, yes, add it to 
the file,  Because of the fewer number of entries and much finer 
categorization, and hence more random insert locations, conflicts happen 
much less often than with the old news logs.  Also, contributors do not 
usually add a What's New entry unless and until asked, and that can be 
delayed until a PR is sure to be merged somewhat soon.


Anything you write may be edited by the release manager or other editor. 
 If the devguide says anything about this file, I could not find it. 
The devguide index only indexes PEP references.


--
Terry Jan Reedy

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GH47YTRTT7GAXNFSY4D4MQRUWGRZJW7Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Ivan Pozdeev via Python-Dev]

The best way to deal with EOL platforms that I've seen is "best effort": do not guarantee continued operability but accept patches that fix 
breakages -- as long as they don't add maintenance burden beyond a comfortable level.


So if there's a person willing to backport changes (and test them themselves since we're not testing on that old platform), I don't see a 
problem.


On 10.12.2020 0:28, Guido van Rossum wrote:

On Wed, Dec 9, 2020 at 12:15 PM Jakub Stasiak mailto:ja...@stasiak.at>> wrote:

I wouldn’t be surprised if there’s a group of people that won’t ever 
upgrade to 10.15+ for variety of reasons (including loss of
32-bit application support) so there’s also that.


In my experience Apple hardware is very reliable and way outlives the OS updates. Even if an OS updates is still available, the newer OS 
often needs more memory, which can be a problem (most Apple hardware is hard to add memory to). What are people supposed to do? Just throw 
away their expensive computer?


--
--Guido van Rossum (python.org/~guido )
/Pronouns: he/him //(why is my pronoun here?)/ 


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MKYINSTDY6SUVMG6EA2VHMVOOUF5KBKT/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Regards,
Ivan

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/73RLAFWBBDKDSK3QMEDWUK3YWVYTU3ZL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NEWS, changelog, and blurb -- a teaching moment

[Larry Hastings]

On 12/9/20 11:19 AM, Ethan Furman wrote:

Greetings!

I'm hoping somebody can alleviate my confusion.  I had thought that 
the blurb tool was created to resolve the near-constant push races 
when the NEWS file was updated; but it appears that it only affects 
the change log.



NEWS /is/ the changelog.  The "changelog" you see on the web site, e.g.:

   https://docs.python.org/3/whatsnew/changelog.html#changelog

is basically the NEWS file run through "rst2html".


If I have a change that really needs to be in the NEWS file itself, do 
I need to directly edit that file?


a) No.  Run "blurb" as normal to add your change.

b) You can't anyway.  NEWS is no longer checked in.


The process is: when you run "blurb", it adds a file containing that 
text to "Misc/NEWS.d/next".  Then, when the release manager makes the 
next release, they'll run "blurb release", which merges all those 
individual text files into one big version-specific aggregate file of 
news blurbs stored in "Misc/NEWS.d/.rst".  Finally, when 
the release manager builds the source distribution (for tarballs etc), 
they run "blurb merge", which merges all the 
"Misc/NEWS.d/.rst" files together into one big glorious 
NEWS file.  "Misc/NEWS" is no longer checked in, it's generated on 
demand using "blurb merge".



//arry/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BE5RK35TZG5H5QZSJMMHBOVVLOU3KNGE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NEWS, changelog, and blurb -- a teaching moment

[Ethan Furman]

On 12/9/20 5:01 PM, Larry Hastings wrote:

> "Misc/NEWS" is no longer checked in, it's generated on demand using "blurb 
merge".

So if I understand correctly, blurb makes NEWS, but `whatsnew` is still done by 
hand.

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YZO7PU6UR5PDTYU3QKFEQE2AWBV5K7P2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NEWS, changelog, and blurb -- a teaching moment

[Larry Hastings]

On 12/9/20 5:21 PM, Ethan Furman wrote:

On 12/9/20 5:01 PM, Larry Hastings wrote:

> "Misc/NEWS" is no longer checked in, it's generated on demand using 
"blurb merge".


So if I understand correctly, blurb makes NEWS, but `whatsnew` is 
still done by hand.



Correct.  You'll notice that each "whatsnew" lists its "editor"; for 
example, Lukasz edited the whatsnew document for 3.9.  If you want to 
ensure there is "whatsnew" coverage for your change you should contact 
the relevant editor for that version.



//arry/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DYLP6YAW23JSQNCQ5WZL4B5KKIWN6MXW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Greg Ewing]

On 10/12/20 10:28 am, Guido van Rossum wrote:
In my experience Apple hardware is very reliable and way outlives the OS 
updates. Even if an OS updates is still available, the newer OS often 
needs more memory, which can be a problem


Another problem, for me at least, is that OS updates often seem
to remove functionality that I like and rely on. I stuck with
10.6 for a very long time, because it did everything I wanted,
and there were some third party extensions I used that stopped
working in 10.7 and there were no good replacements available.

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/57DWVZDDJNXBNT6UKGSFH5STJHYREAHO/
Code of Conduct: http://python.org/psf/codeofconduct/