[gentoo-dev] Packages up for grabs: x11-misc/arandr
Dear all the following packages are up for grabs after dropping desktop-misc: x11-misc/arandr https://packages.gentoo.org/packages/x11-misc/arandr -- Best, Jonas
[gentoo-dev] [PATCH] toolchain-funcs.eclass: include riscv bitness in tc-arch
This makes tc-arch identify RISC-V systems as either "riscv64" or
"riscv32". It will still return "riscv" for the kernel arch or if
bitness is not given in the host triplet.
This fixes the expected values of cpu_family in meson projects:
https://mesonbuild.com/Reference-tables.html#cpu-families
Signed-off-by: David Michael
---
Hi,
When building systemd from Git, it now relies on the "stable" cpu_family
value for riscv64[0]. Meson gets this value from tc-arch. From a quick
grep, it looked like the only place that compared tc-arch output with
"riscv" was toolchain.eclass, but there may be some other subtle issue I
haven't encountered. Does this look okay to apply?
Thanks.
David
[0]
https://github.com/systemd/systemd/commit/a00ff2e1b596f0d08d32b8ca9cefe8aca1212604
eclass/toolchain-funcs.eclass | 10 +-
eclass/toolchain.eclass | 2 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 267cf5cfce3..5dd6dcbd658 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -687,7 +687,15 @@ ninj() { [[ ${type} == "kern" ]] && echo $1 || echo $2 ; }
echo ppc
fi
;;
- riscv*) echo riscv;;
+ riscv*)
+ if [[ ${type} != "kern" && ${host} == riscv32* ]] ; then
+ echo riscv32
+ elif [[ ${type} != "kern" && ${host} == riscv64* ]] ;
then
+ echo riscv64
+ else
+ echo riscv
+ fi
+ ;;
s390*) echo s390;;
score*) echo score;;
sh64*) ninj sh64 sh;;
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index f41ce22c591..b1d2e671917 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1084,7 +1084,7 @@ toolchain_src_configure() {
# https://gcc.gnu.org/PR93157
[[ ${CTARGET} == powerpc64-*-musl ]] && confgcc+=(
--with-abi=elfv2 )
;;
- riscv)
+ riscv*)
# Add --with-abi flags to set default ABI
confgcc+=( --with-abi=$(gcc-abi-map ${TARGET_DEFAULT_ABI}) )
;;
--
2.26.3
[gentoo-dev] [PATCH news v3] Add Python 3.9 news item
Signed-off-by: Michał Górny --- .../2021-04-29-python3-9.en.txt | 119 ++ 1 file changed, 119 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..fc55427 --- /dev/null +++ b/2021-04-29-python3-9/2021-04-29-python3-9.en.txt @@ -0,0 +1,119 @@ +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 have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared +in make.conf, please remove these declarations as they will interfere +with the package.use samples provided below. Using make.conf for Python +targets is discouraged as it prevents package defaults from applying +when necessary. This news item assumes using /etc/portage/package.use +or your package manager's equivalent file for configuration. + + +At this point, you have a few configuration options to choose from: + +1. If you wish Python upgrades to apply automatically, you can remove + PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations. When + the defaults change, your package manager should handle the upgrade + automatically. However, you may still need to run the update + commands if any problems arise. + +2. If you wish to defer the upgrade for the time being, you can + explicitly set the old values in package.use. + +3. If you wish to force the upgrade earlier, you can explicitly set + the new values and run the upgrade commands. + +4. If you wish to use a safer approach (i.e. less likely to temporarily + break packages during the upgrade), you can perform a multi-step + upgrade as outlined below. + +5. Finally, you can use an arbitrary combination of PYTHON_TARGETS + and PYTHON_SINGLE_TARGET. + + +Deferring the upgrade += +To defer the upgrade, explicitly set the old targets: + +*/* PYTHON_TARGETS: -* python3_8 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +This will enforce Python 3.8 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. + + +Forcing the upgrade +=== +To force the upgrade earlier, explicitly set Python 3.9 targets: + +*/* PYTHON_TARGETS: -* python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +However, it is important to remember to remove this after the defaults +change, as it will interfere with the automatic switch to the next +Python version in the future. + + +Safer upgrade procedure +=== +A safer approach is to add Python 3.9 support to your system first, +and only then remove Python 3.8. However, note that involves two +rebuilds of all the affected packages, so it will take noticeably +longer. + +First, enable both Python 3.8 and Python 3.9, and then run the upgrade +commands: + +*/* PYTHON_TARGETS: -* python3_8 python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_8 + +Then switch PYTHON_SINGLE_TARGET and run a second batch of upgrades: + +*/* PYTHON_TARGETS: -* python3_8 python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +Finally, switch to the final version and upgrade: + +*/* PYTHON_TARGETS: -* python3_9 +*/* PYTHON_SINGLE_TARGET: -* python3_9 + +You may wish to remove the target overrides after the defaults switch. +Alternatively, you can keep them to block the next automatic upgrade +to Python 3.10, and upgrade manually then. + + +Upgrade commands + +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.: + +emer
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] [News item review v2] Exim >=4.94 transports: tainted not permitted
Title: Exim>=4.94 transports: tainted not permitted Author: Fabian Groffen Posted: 2021-05-?? Revision: 1 News-Item-Format: 2.0 Display-If-Installed: mail-mta/exim The Message Transfer Agent Exim disallows tainted variables in transport configurations since version 4.94. Existing exim.conf configurations in /etc/exim need to be reviewed for breakage prior to upgrading to >=mail-mta/exim-4.94 to avoid error conditions at runtime. Since the release of Exim-4.94, transports refuse to use tainted data in constructing a delivery location. If you use this in your transports, your configuration will break, causing errors and possible downtime. Particularly, the use of $local_part in any transport, should likely be updated with $local_part_data. Check your local_delivery transport, which historically used $local_part. Unfortunately there is not much documentation on "tainted" data for Exim[1], and to resolve this, non-official sources need to be used, such as [2] and [3]. [1] https://lists.exim.org/lurker/message/20201109.222746.24ea3904.en.html [2] https://mox.sh/sysadmin/tainted-filename-errors-in-exim-4.94/ [3] https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/ -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted
On 02-05-2021 12:23:30 +0200, Ulrich Mueller wrote: > > On Sun, 02 May 2021, Fabian Groffen wrote: > > > Title: Exim >=4.94 disallows tainted variables in transport configurations > > Title is too long (GLEP 42 allows 50 chars max). ah, missed that > I have no idea what this news item is trying to tell me. But I don't use > Exim, so probably that's the reason. :) Maybe mention at least that Exim > is a mailer? Fair point. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted
> On Sun, 02 May 2021, Fabian Groffen wrote: > Title: Exim >=4.94 disallows tainted variables in transport configurations Title is too long (GLEP 42 allows 50 chars max). > Author: Fabian Groffen > Posted: 2021-05-?? > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: mail-mta/exim > Since the release of Exim-4.94, transports refuse to use tainted data in > constructing a delivery location. If you use this in your transports, > your configuration will break, causing errors and possible downtime. > Particularly, the use of $local_part in any transport, should likely be > updated with $local_part_data. Check your local_delivery transport, > which historically used $local_part. > Unfortunately there is not much documentation on "tainted" data for > Exim[1], and to resolve this, non-official sources need to be used, such > as [2] and [3]. I have no idea what this news item is trying to tell me. But I don't use Exim, so probably that's the reason. :) Maybe mention at least that Exim is a mailer? Ulrich > [1] https://lists.exim.org/lurker/message/20201109.222746.24ea3904.en.html > [2] https://mox.sh/sysadmin/tainted-filename-errors-in-exim-4.94/ > [3] > https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/ signature.asc Description: PGP signature
[gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted
Title: Exim >=4.94 disallows tainted variables in transport configurations Author: Fabian Groffen Posted: 2021-05-?? Revision: 1 News-Item-Format: 2.0 Display-If-Installed: mail-mta/exim Since the release of Exim-4.94, transports refuse to use tainted data in constructing a delivery location. If you use this in your transports, your configuration will break, causing errors and possible downtime. Particularly, the use of $local_part in any transport, should likely be updated with $local_part_data. Check your local_delivery transport, which historically used $local_part. Unfortunately there is not much documentation on "tainted" data for Exim[1], and to resolve this, non-official sources need to be used, such as [2] and [3]. [1] https://lists.exim.org/lurker/message/20201109.222746.24ea3904.en.html [2] https://mox.sh/sysadmin/tainted-filename-errors-in-exim-4.94/ [3] https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/ -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
