Re: [gentoo-dev] [PATCH news v2] Add Python 3.9 news item
On 30.4.2021 3.50, Sam James wrote: >> On 29 Apr 2021, at 22:01, Michał Górny wrote: >> >> + >> + >> +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." > No offense, but your suggestion isn't an improvement here :P maybe the 2nd part (after ,) makes sense and should be added, but the first part of that sentence is a bit hard to read. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH news] Add Python 3.9 news item
On Thu, 2021-04-29 at 21:07 -0400, Wolfgang E. Sanyer wrote: > 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? The same issue applies to all uses of USE_EXPAND, though not all of them are using package defaults today. But if you move one of them, why not move them all? > 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 > The times when Gentoo had great documentation are long gone. Handbook is barely maintained these days. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH news v2] Add Python 3.9 news item
On Fri, 2021-04-30 at 01:50 +0100, Sam James wrote: > > > 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
[gentoo-dev] last-rite: dev-java/tagsoup
# Miroslav Šulc (2021-04-30) # no consumers # removal in 30 days # see bug: https://bugs.gentoo.org/787152 dev-java/tagsoup
Re: [gentoo-dev] [PATCH v2] Transitional changes to the kernel-2 eclass to support future CPU OPT
On 4/29/21 9:48 AM, mpag...@gentoo.org wrote:
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"
This has been committed
[gentoo-dev] last rites: some outdated perl-core/*
# Andreas K. Hüttel (2021-04-30) # Outdated, not pulled in by any virtuals anymore, no # keywords. Removal in 30 days. perl-core/Devel-PPPort perl-core/Time-Local perl-core/Unicode-Normalize -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] last rites: dev-perl/Sane
# Andreas K. Hüttel (2021-04-30) # Superceded by dev-perl/Image-Sane. Tests hang, bug 626594 # Removal in 30 days. dev-perl/Sane -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
