Re: [gentoo-dev] [PATCH news] Add Python 3.9 news item
On Thu, Apr 29, 2021 at 5:00 PM Michał Górny wrote: > > On Thu, 2021-04-29 at 14:44 +0200, Ulrich Mueller wrote: > > > > > > > On Thu, 29 Apr 2021, Michał Górny wrote: > > > > > +Title: Python 3.9 to become the default target on 2021-06-01 > > > > Title is longer than the maximum allowed by GLEP 42 (50 chars). > > > > > [...] > > > > > +If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared > > > +in make.conf, it is strongly recommended to remove the declarations > > > +and use package.use as presented above. Use of make.conf to set > > > flags > > > +is strongly discouraged as it does not respect package defaults. > > > > These sentences are somewhat redundant with each other, at least the > > "strongly recommended" / "strongly discouraged" part. > > Done and done. The second sentence is meant to explain why it is > discouraged. > > -- > Best regards, > Michał Górny > Is this strongly discouraged across-the-board, or strictly for this python stuff? How strongly is it discouraged? The handbook doesn't seem to mention anything about discouraging this practice, and indeed seems to encourage it: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Configuring_the_USE_variable
Re: [gentoo-dev] [PATCH news v2] Add Python 3.9 news item
> On 29 Apr 2021, at 22:01, Michał Górny wrote: > > Signed-off-by: Michał Górny > --- > .../2021-04-29-python3-9.en.txt | 93 +++ > 1 file changed, 93 insertions(+) > create mode 100644 2021-04-29-python3-9/2021-04-29-python3-9.en.txt > > diff --git a/2021-04-29-python3-9/2021-04-29-python3-9.en.txt > b/2021-04-29-python3-9/2021-04-29-python3-9.en.txt > new file mode 100644 > index 000..3075d72 > --- /dev/null > +++ b/2021-04-29-python3-9/2021-04-29-python3-9.en.txt > @@ -0,0 +1,93 @@ > +Title: Python 3.9 to become the default on 2021-06-01 > Thanks for working on this. I kept meaning to do one for 3.8 and then 3.9 got so close that I felt a bit daft doing it. > + > +We are planning to switch the default Python target of Gentoo systems > +on 2021-06-01, from Python 3.8 to Python 3.9. If you have not changed > +the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will > +have immediate effect on your system and the package manager will try > +to switch automatically on the next upgrade following the change. (Add a new line here). > +If you did change the values, prefer a safer approach or have problems > +with the update, read on. > + > +Please note that the default upgrade method switches packages to the new > +Python versions as they are rebuilt. This means that all interdependent > +packages have to support the new version for the upgrade to proceed, > +and that some programs may temporarily fail to find their dependencies > +throughout the upgrade (although programs that are already started > +are unlikely to be affected). > + > + I’d consider numbering or marking with a bullet point or ‘-‘ each of the possible options, in order of likely usefulness. So, we’d do e.g. 1) If you’ve not set anything, just upgrade as normal and then depclean. 2) In order to have both Python implementations enabled temporarily for safety ,… […] But this isn’t required. It’s just about making it easier for people to see what they need to do, and not misread it and then do silly things because they just copied and pasted the stuff which looked right (it happens). Let’s put all of the key information at the beginning, then the configurability/tweaking can be later on. > +If you wish to avoid changing Python targets at this moment, you can > +force the old targets by setting your /etc/portage/package.use to e.g.: > + > +*/* PYTHON_TARGETS: -* python3_8 > +*/* PYTHON_SINGLE_TARGET: -* python3_8 > + > +This will enforce Python 3.8 as the current target choice and block > +any future updates. However, please note that this solution will only > +be suitable for a few more months and you will eventually need to > +perform the migration. > + > + > +If you wish to use a safer approach to the migration and temporarily > +preserve the support for Python 3.8 and Python 3.9 simultaneously, > +set /etc/portage/package.use to: > + > +*/* PYTHON_TARGETS: -* python3_8 python3_9 > +*/* PYTHON_SINGLE_TARGET: -* python3_8 > + > +Afterwards, rebuild your system with emerge's --changed-use option or > +equivalent. This will cause your packages to gain Python 3.9 support > +while preserving Python 3.8 support whenever possible. Then, change > +the second line to: > + > +*/* PYTHON_SINGLE_TARGET: -* python3_9 > + > +This will switch packages that can not support two Python versions > +simultaneously, to use Python 3.9. Rebuild again. Finally, switch > +the first line to the final version: > + > +*/* PYTHON_TARGETS: -* python3_9 > + > +The next --changed-use rebuild will remove Python 3.8 support from your > +packages. > + > + > +You can also switch to Python 3.9 earlier by setting: > + > +*/* PYTHON_TARGETS: -* python3_9 > +*/* PYTHON_SINGLE_TARGET: -* python3_9 > + > +If you choose to follow this or the previous approach, you may want to > +remove the package.use overrides after the switch or just leave them > +in place to protect your system from the next automatic upgrade > +of Python. > + “It is especially important you do not forget IF you choose to add this, because it interferes with the natural rolling-with-the-defaults." > + > +The Python 3.8 cleanup requires that Python 3.8 is removed from complete > +dependency trees in batch. If some of the installed packages using > +an older Python version are not triaged for the upgrade, the package > +manager will throw dependency conflicts. This makes it important that > +the upgrade is carried via a --deep --changed-use @world upgrade, > +as well as that any stray packages are removed prior to it, e.g.: > + > +emerge --depclean > +emerge -1vUD @world > +emerge --depclean > + Let’s put this right at the beginning. > + > +By the time of the switch, it is quite probable that Python 3.10 will > +already be available in ~arch Gentoo. Users wishing a more bleeding > +edge experience may wish to switch to python3_10 target instead. > +However, this is currently discouraged on stable
[gentoo-dev] [PATCH news v2] Add Python 3.9 news item
Signed-off-by: Michał Górny --- .../2021-04-29-python3-9.en.txt | 93 +++ 1 file changed, 93 insertions(+) create mode 100644 2021-04-29-python3-9/2021-04-29-python3-9.en.txt diff --git a/2021-04-29-python3-9/2021-04-29-python3-9.en.txt b/2021-04-29-python3-9/2021-04-29-python3-9.en.txt new file mode 100644 index 000..3075d72 --- /dev/null +++ b/2021-04-29-python3-9/2021-04-29-python3-9.en.txt @@ -0,0 +1,93 @@ +Title: Python 3.9 to become the default on 2021-06-01 +Author: Michał Górny +Posted: 2021-04-29 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.7 +Display-If-Installed: dev-lang/python:3.8 + +We are planning to switch the default Python target of Gentoo systems +on 2021-06-01, from Python 3.8 to Python 3.9. If you have not changed +the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will +have immediate effect on your system and the package manager will try +to switch automatically on the next upgrade following the change. +If you did change the values, prefer a safer approach or have problems +with the update, read on. + +Please note that the default upgrade method switches packages to the new +Python versions as they are rebuilt. This means that all interdependent +packages have to support the new version for the upgrade to proceed, +and that some programs may temporarily fail to find their dependencies +throughout the upgrade (although programs that are already started +are unlikely to be affected). + + +If you wish to avoid changing Python targets at this moment, you can +force the old targets by setting your /etc/portage/package.use to e.g.: + +*/* PYTHON_TARGETS: -* python3_8 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +This will enforce Python 3.8 as the current target choice and block +any future updates. However, please note that this solution will only +be suitable for a few more months and you will eventually need to +perform the migration. + + +If you wish to use a safer approach to the migration and temporarily +preserve the support for Python 3.8 and Python 3.9 simultaneously, +set /etc/portage/package.use to: + +*/* PYTHON_TARGETS: -* python3_8 python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +Afterwards, rebuild your system with emerge's --changed-use option or +equivalent. This will cause your packages to gain Python 3.9 support +while preserving Python 3.8 support whenever possible. Then, change +the second line to: + +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +This will switch packages that can not support two Python versions +simultaneously, to use Python 3.9. Rebuild again. Finally, switch +the first line to the final version: + +*/* PYTHON_TARGETS: -* python3_9 + +The next --changed-use rebuild will remove Python 3.8 support from your +packages. + + +You can also switch to Python 3.9 earlier by setting: + +*/* PYTHON_TARGETS: -* python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +If you choose to follow this or the previous approach, you may want to +remove the package.use overrides after the switch or just leave them +in place to protect your system from the next automatic upgrade +of Python. + + +The Python 3.8 cleanup requires that Python 3.8 is removed from complete +dependency trees in batch. If some of the installed packages using +an older Python version are not triaged for the upgrade, the package +manager will throw dependency conflicts. This makes it important that +the upgrade is carried via a --deep --changed-use @world upgrade, +as well as that any stray packages are removed prior to it, e.g.: + +emerge --depclean +emerge -1vUD @world +emerge --depclean + + +By the time of the switch, it is quite probable that Python 3.10 will +already be available in ~arch Gentoo. Users wishing a more bleeding +edge experience may wish to switch to python3_10 target instead. +However, this is currently discouraged on stable as it will require +unmasking multiple ~arch packages as they gain Python 3.10 support. + +If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared +in make.conf, it is strongly recommended to remove the declarations +and use package.use as presented above. Use of make.conf to set flags +is discouraged as it does not respect package defaults. -- 2.31.1
Re: [gentoo-dev] [PATCH news] Add Python 3.9 news item
On Thu, 2021-04-29 at 09:08 -0700, Christopher Head wrote: > On Thu, 29 Apr 2021 13:43:41 +0200 > Michał Górny wrote: > > > +If you wish to use a safer approach to the migration and temporarily > > +preserve the support for Python 3.7 and Python 3.8 simultaneously, > > +set /etc/portage/package.use to: > > This should be talking about preserving support for 3.8 while adding > 3.9, right? (likewise the next handful of lines) > > > +You can also switch to Python 3.8 earlier by setting: > > Likewise, 3.9 here? > > > +The Python 3.7 cleanup requires that Python 3.7 is removed from > > 3.8 here? Good catch. I've fixed all the versions now, I think. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH news] Add Python 3.9 news item
On Thu, 2021-04-29 at 14:44 +0200, Ulrich Mueller wrote: > > > > > > On Thu, 29 Apr 2021, Michał Górny wrote: > > > +Title: Python 3.9 to become the default target on 2021-06-01 > > Title is longer than the maximum allowed by GLEP 42 (50 chars). > > > [...] > > > +If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared > > +in make.conf, it is strongly recommended to remove the declarations > > +and use package.use as presented above. Use of make.conf to set > > flags > > +is strongly discouraged as it does not respect package defaults. > > These sentences are somewhat redundant with each other, at least the > "strongly recommended" / "strongly discouraged" part. Done and done. The second sentence is meant to explain why it is discouraged. -- Best regards, Michał Górny
[gentoo-dev] last-rite: some java stuff
# Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786888 dev-java/zeus-jscl # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786864 dev-java/sun-jmx java-virtuals/jmx dev-util/jconfig # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786843 dev-java/sun-httpserver-bin # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786840 dev-java/stax-ex dev-java/xmlstreambuffer # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786831 dev-java/stax2-api # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786756 dev-java/nekohtml dev-java/boilerpipe # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786786 dev-java/spymemcached # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786783 dev-java/skinlf # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786780 dev-java/sblim-cim-client # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786774 dev-java/radeox # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bugs: https://bugs.gentoo.org/786771 dev-java/prefuse # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786768 dev-java/picocontainer # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786753 dev-java/msv dev-java/relaxngcc dev-java/wstx dev-java/jettison # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786744 dev-java/minlog # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786714 dev-java/libmatthew-java # Miroslav Šulc (2021-04-28) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/786711 dev-java/ldapsdk
Re: [gentoo-dev] [PATCH news] Add Python 3.9 news item
On Thu, 29 Apr 2021 13:43:41 +0200 Michał Górny wrote: > +If you wish to use a safer approach to the migration and temporarily > +preserve the support for Python 3.7 and Python 3.8 simultaneously, > +set /etc/portage/package.use to: This should be talking about preserving support for 3.8 while adding 3.9, right? (likewise the next handful of lines) > +You can also switch to Python 3.8 earlier by setting: Likewise, 3.9 here? > +The Python 3.7 cleanup requires that Python 3.7 is removed from 3.8 here? -- Christopher Head pgp_6ql8obmSt.pgp Description: OpenPGP digital signature
[gentoo-dev] [PATCH v2] Transitional changes to the kernel-2 eclass to support future CPU OPT
From: Mike Pagano
Thanks, Ulm, for the review. I have modified the code as suggested.
The CPU OPT patch now contains gcc ver checks within
the patch itself. This transitional change is to start supporting
just that patch while trying not to break the older versions.
The target state eclass code will *only* need the three line
gcc version check. We should be able to slowly remove the
legacy code as we stabilize kernels and remove old ones from the tree.
This will put cpu opt patch support in a much more maintainable state.
Signed-off-by: Mike Pagano
---
eclass/kernel-2.eclass | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 67ad4acc1..f1f23f6a0 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1241,8 +1241,32 @@ unipatch() {
local GCC_MAJOR_VER=$(gcc-major-version)
local GCC_MINOR_VER=$(gcc-minor-version)
- # optimization patch for gcc < 8.X and kernel > 4.13
- if kernel_is ge 4 13 ; then
+ # this section should be the target state to handle the
cpu opt
+ # patch for kernels > 4.19.189, 5.4.115, 5.10.33 and
5.11.17,
+ # 5.12.0 and gcc >= 9 The patch now handles the
+ # gcc version enabled on the system through the Kconfig
file as
+ # 'depends'. The legacy section can hopefully be
retired in the future
+ # Note the patch for 4.19-5.8 version are the same and
the patch for
+ # 5.8+ version is the same
+ # eventually we can remove everything except the gcc
ver <9 check
+ # based on stablization, time, kernel removals or a
combo of all three
+ if ( kernel_is eq 4 19 && kernel_is gt 4 19 189 ) ||
+ ( kernel_is eq 5 4 && kernel_is gt 5 4 115 ) ||
+ ( kernel_is eq 5 10 && kernel_is gt 5 10 33 ) ||
+ ( kernel_is eq 5 11 && kernel_is gt 5 11 17 ) ||
+ ( kernel_is eq 5 12 && kernel_is gt 5 12 0 );
then
+ UNIPATCH_DROP+="
5010_enable-additional-cpu-optimizations-for-gcc.patch"
+ UNIPATCH_DROP+="
5010_enable-additional-cpu-optimizations-for-gcc-4.9.patch"
+ UNIPATCH_DROP+="
5011_enable-cpu-optimizations-for-gcc8.patch"
+ UNIPATCH_DROP+="
5012_enable-cpu-optimizations-for-gcc91.patch"
+ UNIPATCH_DROP+="
5013_enable-cpu-optimizations-for-gcc10.patch"
+ if [[ ${GCC_MAJOR_VER} -lt 9 ]]; then
+ UNIPATCH_DROP+="
5010_enable-cpu-optimizations-universal.patch"
+ fi
+ # this legacy section should be targeted for
removal
+ # optimization patch for gcc < 8.X and kernel >
4.13 and < 4.19
+ elif kernel_is ge 4 13; then
+ UNIPATCH_DROP+="
5010_enable-cpu-optimizations-universal.patch"
if [[ ${GCC_MAJOR_VER} -lt 8 ]] && [[
${GCC_MAJOR_VER} -gt 4 ]]; then
UNIPATCH_DROP+="
5011_enable-cpu-optimizations-for-gcc8.patch"
UNIPATCH_DROP+="
5012_enable-cpu-optimizations-for-gcc91.patch"
@@ -1272,6 +1296,7 @@ unipatch() {
UNIPATCH_DROP+="
5013_enable-cpu-optimizations-for-gcc10.patch"
fi
else
+ UNIPATCH_DROP+="
5010_enable-cpu-optimizations-universal.patch"
UNIPATCH_DROP+="
5010_enable-additional-cpu-optimizations-for-gcc.patch"
UNIPATCH_DROP+="
5010_enable-additional-cpu-optimizations-for-gcc-4.9.patch"
UNIPATCH_DROP+="
5011_enable-cpu-optimizations-for-gcc8.patch"
--
2.26.3
Re: [gentoo-dev] [PATCH] Transitional changes to the kernel-2 eclass to support future CPU OPT
> On Thu, 29 Apr 2021, mpagano wrote:
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1241,8 +1241,32 @@ unipatch() {
> local GCC_MAJOR_VER=$(gcc-major-version)
> local GCC_MINOR_VER=$(gcc-minor-version)
>
> - # optimization patch for gcc < 8.X and kernel > 4.13
> - if kernel_is ge 4 13 ; then
> + # this section should be the target state to handle the
> cpu opt
> + # patch for kernels > 4.19.189, 5.4.115, 5.10.33 and
> 5.11.17,
> + # 5.12.0 and gcc >= 9 The patch now handles the
> + # gcc version enabled on the system through the Kconfig
> file as
> + # 'depends'. The legacy section can hopefully be
> retired in the future
> + # Note the patch for 4.19-5.8 version are the same and
> the patch for
> + # 5.8+ version is the same
> + # eventually we can remove everything except the gcc
> ver <9 check
> + # based on stablization, time, kernel removals or a
> combo of all three
> + if ((kernel_is eq 4 19 && kernel_is gt 4 19 189) ||
> + (kernel_is eq 5 4 && kernel_is gt 5 4 115) ||
> + (kernel_is eq 5 10 && kernel_is gt 5 10 33) ||
> + (kernel_is eq 5 11 && kernel_is gt 5 11 17) ||
> + (kernel_is eq 5 12 && kernel_is gt 5 12 0));
> then
Looks like the outermost pair of parentheses ( ) isn't needed here.
Also, when writing nested parentheses without a space, bash may
sometimes (but not always!) interpret them as an arithmetic expression.
This can cause unexpected results:
$ ((true) && (true)); echo $?
0
$ ( (true && true) ); echo $?
0
$ ((true && true)); echo $?
1
$ true=42
$ ((true && true)); echo $?
0
> [...]
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH news] Add Python 3.9 news item
> On Thu, 29 Apr 2021, Michał Górny wrote: > +Title: Python 3.9 to become the default target on 2021-06-01 Title is longer than the maximum allowed by GLEP 42 (50 chars). > [...] > +If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared > +in make.conf, it is strongly recommended to remove the declarations > +and use package.use as presented above. Use of make.conf to set flags > +is strongly discouraged as it does not respect package defaults. These sentences are somewhat redundant with each other, at least the "strongly recommended" / "strongly discouraged" part. signature.asc Description: PGP signature
[gentoo-dev] [PATCH] Transitional changes to the kernel-2 eclass to support future CPU OPT
From: Mike Pagano
The CPU OPT patch now contains gcc ver checks within
the patch itself. This transitional change is to start supporting
just that patch while trying not to break the older versions.
The target state eclass code will *only* need the three line
gcc version check. We should be able to slowly remove the
legacy code as we stabilize kernels and remove old ones from the tree.
This will put cpu opt patch support in a much more maintainable state.
---
eclass/kernel-2.eclass | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 67ad4acc1..f676e8421 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -1241,8 +1241,32 @@ unipatch() {
local GCC_MAJOR_VER=$(gcc-major-version)
local GCC_MINOR_VER=$(gcc-minor-version)
- # optimization patch for gcc < 8.X and kernel > 4.13
- if kernel_is ge 4 13 ; then
+ # this section should be the target state to handle the
cpu opt
+ # patch for kernels > 4.19.189, 5.4.115, 5.10.33 and
5.11.17,
+ # 5.12.0 and gcc >= 9 The patch now handles the
+ # gcc version enabled on the system through the Kconfig
file as
+ # 'depends'. The legacy section can hopefully be
retired in the future
+ # Note the patch for 4.19-5.8 version are the same and
the patch for
+ # 5.8+ version is the same
+ # eventually we can remove everything except the gcc
ver <9 check
+ # based on stablization, time, kernel removals or a
combo of all three
+ if ((kernel_is eq 4 19 && kernel_is gt 4 19 189) ||
+ (kernel_is eq 5 4 && kernel_is gt 5 4 115) ||
+ (kernel_is eq 5 10 && kernel_is gt 5 10 33) ||
+ (kernel_is eq 5 11 && kernel_is gt 5 11 17) ||
+ (kernel_is eq 5 12 && kernel_is gt 5 12 0));
then
+ UNIPATCH_DROP+="
5010_enable-additional-cpu-optimizations-for-gcc.patch"
+ UNIPATCH_DROP+="
5010_enable-additional-cpu-optimizations-for-gcc-4.9.patch"
+ UNIPATCH_DROP+="
5011_enable-cpu-optimizations-for-gcc8.patch"
+ UNIPATCH_DROP+="
5012_enable-cpu-optimizations-for-gcc91.patch"
+ UNIPATCH_DROP+="
5013_enable-cpu-optimizations-for-gcc10.patch"
+ if [[ ${GCC_MAJOR_VER} -lt 9 ]]; then
+ UNIPATCH_DROP+="
5010_enable-cpu-optimizations-universal.patch"
+ fi
+ # this legacy section should be targeted for
removal
+ # optimization patch for gcc < 8.X and kernel >
4.13 and < 4.19
+ elif kernel_is ge 4 13; then
+ UNIPATCH_DROP+="
5010_enable-cpu-optimizations-universal.patch"
if [[ ${GCC_MAJOR_VER} -lt 8 ]] && [[
${GCC_MAJOR_VER} -gt 4 ]]; then
UNIPATCH_DROP+="
5011_enable-cpu-optimizations-for-gcc8.patch"
UNIPATCH_DROP+="
5012_enable-cpu-optimizations-for-gcc91.patch"
@@ -1272,6 +1296,7 @@ unipatch() {
UNIPATCH_DROP+="
5013_enable-cpu-optimizations-for-gcc10.patch"
fi
else
+ UNIPATCH_DROP+="
5010_enable-cpu-optimizations-universal.patch"
UNIPATCH_DROP+="
5010_enable-additional-cpu-optimizations-for-gcc.patch"
UNIPATCH_DROP+="
5010_enable-additional-cpu-optimizations-for-gcc-4.9.patch"
UNIPATCH_DROP+="
5011_enable-cpu-optimizations-for-gcc8.patch"
--
2.26.3
[gentoo-dev] [PATCH news] Add Python 3.9 news item
Signed-off-by: Michał Górny --- .../2021-04-29-python3-9.en.txt | 92 +++ 1 file changed, 92 insertions(+) create mode 100644 2021-04-29-python3-9/2021-04-29-python3-9.en.txt diff --git a/2021-04-29-python3-9/2021-04-29-python3-9.en.txt b/2021-04-29-python3-9/2021-04-29-python3-9.en.txt new file mode 100644 index 000..29fdc9d --- /dev/null +++ b/2021-04-29-python3-9/2021-04-29-python3-9.en.txt @@ -0,0 +1,92 @@ +Title: Python 3.9 to become the default target on 2021-06-01 +Author: Michał Górny +Posted: 2021-04-29 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.7 +Display-If-Installed: dev-lang/python:3.8 + +We are planning to switch the default Python target of Gentoo systems +on 2021-06-01, from Python 3.8 to Python 3.9. If you have not changed +the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will +have immediate effect on your system and the package manager will try +to switch automatically on the next upgrade following the change. +If you did change the values, prefer a safer approach or have problems +with the update, read on. + +Please note that the default upgrade method switches packages to the new +Python versions as they are rebuilt. This means that all interdependent +packages have to support the new version for the upgrade to proceed, +and that some programs may temporarily fail to find their dependencies +throughout the upgrade (although programs that are already started +are unlikely to be affected). + + +If you wish to avoid changing Python targets at this moment, you can +force the old targets by setting your /etc/portage/package.use to e.g.: + +*/* PYTHON_TARGETS: -* python3_8 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +This will enforce Python 3.8 as the current target choice and block +any future updates. However, please note that this solution will only +be suitable for a few more months and you will eventually need to +perform the migration. + + +If you wish to use a safer approach to the migration and temporarily +preserve the support for Python 3.7 and Python 3.8 simultaneously, +set /etc/portage/package.use to: + +*/* PYTHON_TARGETS: -* python3_7 python3_8 +*/* PYTHON_SINGLE_TARGET: -* python3_7 + +Afterwards, rebuild your system with emerge's --changed-use option or +equivalent. This will cause your packages to gain Python 3.8 support +while preserving Python 3.7 support whenever possible. Then, change +the second line to: + +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +This will switch packages that can not support two Python versions +simultaneously, to use Python 3.8. Rebuild again. Finally, switch +the first line to the final form: + +*/* PYTHON_TARGETS: -* python3_8 + +The next --changed-use rebuild will remove Python 3.7 support from your +packages. + + +You can also switch to Python 3.8 earlier by setting: + +*/* PYTHON_TARGETS: -* python3_8 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +If you choose to follow this or the previous approach, you may want to +remove the package.use overrides after the switch or just leave them +in place to protect your system from the next automatic upgrade +of Python. + + +The Python 3.7 cleanup requires that Python 3.7 is removed from complete +dependency trees in batch. If some of the installed packages using +an older Python version are not triaged for the upgrade, the package +manager will throw dependency conflicts. This makes it important that +the upgrade is carried via a --deep --changed-use @world upgrade, +as well as that any stray packages are removed prior to it, e.g.: + +emerge --depclean +emerge -1vUD @world +emerge --depclean + + +By the time of the switch, it is quite probable that Python 3.10 will +already be available in ~arch Gentoo. Users wishing a more bleeding +edge experience may wish to switch to python3_10 target instead. + + +If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared +in make.conf, it is strongly recommended to remove the declarations +and use package.use as presented above. Use of make.conf to set flags +is strongly discouraged as it does not respect package defaults. -- 2.31.1
[gentoo-dev] Last rites: dev-python/pytest-testmon
# Michał Górny (2021-04-29) # The most recent release is still broken with current # dev-python/coverage. Inactive downstream maintainer. No revdeps. # Removal on 2021-05-29. Bug #78. dev-python/pytest-testmon -- Best regards, Michał Górny
[gentoo-dev] last-rite: media-sound/bladeenc
# Miroslav Šulc (2021-04-28) # security issues, last release in 2004 # removal in 30 days # see bug: https://bugs.gentoo.org/631394 media-sound/bladeenc
