Re: [gentoo-dev] [PATCH 1/3] ruby-ng.eclass: improve error when no valid Ruby in USE_RUBY
Hans de Graaff writes: > [[PGP Signed Part:Undecided]] > On Wed, 2023-03-29 at 16:39 +0100, Sam James wrote: >> This means we don't get confusing *DEPEND/REQUIRED_USE errors about >> it being >> unparseable and instead just get a straightforward die message >> indicating >> the problem. > > > All three patches look good to me. Thanks! I'm going to rework the IUSE test stuff based on the feedback as it's apparently fragile to do at all. > > Hans > > [[End of PGP Signed Part]] signature.asc Description: PGP signature
[gentoo-dev] Re: Confirm subscription to gentoo-dev@lists.gentoo.org
-- Arsen Arsenović
[gentoo-dev] Re: sys-libs/glibc: RDEPENDs
Raul Rangel writes:
> On Fri, Mar 31, 2023 at 11:03 AM Sam James wrote:
>>
>>
>>
>> > On 31 Mar 2023, at 17:07, Raul Rangel wrote:
>> >
>> > Hello,
>> > I was looking at the glibc
>> > [ebuild](https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.37-r1.ebuild#n136)
>> > and noticed that it contains a lot of RDEPEND:
>> >RDEPEND="${COMMON_DEPEND}
>> >app-arch/gzip
>> >sys-apps/grep
>> >app-alternatives/awk
>> >sys-apps/gentoo-functions
>> >!> >!> >"
>> > Are gzip, grep, awk just legacy from before the EAPI7 era, or does
>> > glibc actually invoke grep, awk, etc? I'm working in a cross-compiled
>> > environment (not cross- packages) and wanted to avoid pulling in the
>> > additional dependencies if they aren't necessary.
>> >
>>
>> I suspect some of these may be IDEPEND candidates for locale-gen.
>
> https://bugs.gentoo.org/740750#c12 sheds a bit of light. It looks like
> /usr/sbin/locale-gen is a bash script that invokes grep, awk etc.
> Hence the reason for the RDEPEND. What are your thoughts on splitting
> off locale-gen into its own package, or adding a USE flag to
> conditionally install locale-gen?
I'd personally be open to it (without having investigated it) but
I'd need to see what dilfridge@ and others think first.
(The main thing I'm wondering is why it isn't already, as it feels
natural).
Could you maybe file a new bug with that suggestion (and reference
the other one)?
>
> As for the IDEPEND I put together
> https://github.com/gentoo/gentoo/commit/78edfcea3d38d869dff85ff2b2109f53b3137fa2?diff=split.
> I haven't tested it since I don't have an EAPI8 capable system
> available right now :/
I think this looks right, actually. Fancy doing a PR (mark it as a
draft) and I can take it from there?
>>
>> > Thanks,
>> > Raul
best,
sam
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH gentoo-news] 2023-04-01-python3-11: add news item
Signed-off-by: Michał Górny --- .../2023-04-01-python3-11.en.txt | 125 ++ 1 file changed, 125 insertions(+) create mode 100644 2023-04-01-python3-11/2023-04-01-python3-11.en.txt diff --git a/2023-04-01-python3-11/2023-04-01-python3-11.en.txt b/2023-04-01-python3-11/2023-04-01-python3-11.en.txt new file mode 100644 index 000..84a3860 --- /dev/null +++ b/2023-04-01-python3-11/2023-04-01-python3-11.en.txt @@ -0,0 +1,125 @@ +Title: Python 3.11 to become the default on 2023-05-01 +Author: Michał Górny +Posted: 2023-04-01 +Revision: 1 +News-Item-Format: 2.0 +Display-If-Installed: dev-lang/python:3.9 +Display-If-Installed: dev-lang/python:3.10 + +We are planning to switch the default Python target of Gentoo systems +on 2023-05-01, from Python 3.10 to Python 3.11. 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). + +At the same time, the support for Python 3.9 target will be removed +from the eclasses. The interpreter package will remain supported +for as long as feasible though. PyPy3.9 will remain supported until +PyPy3.10 comes out and becomes stable. + + +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_10 +*/* PYTHON_SINGLE_TARGET: -* python3_10 + +This will enforce Python 3.10 and block any future updates. However, +please note that this is only a temporary solution and you will +eventually need to perform the migration. + + +Forcing the upgrade +=== +To force the upgrade earlier, explicitly select the Python 3.11 targets: + +*/* PYTHON_TARGETS: -* python3_11 +*/* PYTHON_SINGLE_TARGET: -* python3_11 + +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.11 support to your system first, +and only then remove Python 3.10. However, note that this involves two +rebuilds of all the affected packages, so it will take noticeably +longer. + +First, enable both Python 3.10 and Python 3.11, and then run the upgrade +commands: + +*/* PYTHON_TARGETS: -* python3_10 python3_11 +*/* PYTHON_SINGLE_TARGET: -* python3_10 + +Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades: + +*/* PYTHON_TARGETS: -* python3_10 python3_11 +*/* PYTHON_SINGLE_TARGET: -* python3_11 + +Finally, switch to the final version and upgrade: + +*/* PYTHON_TARGETS: -* python3_11 +*/* PYTHON_SINGLE_TARGET: -* python3_11 + +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.11, and upgrade manually then. + + +Upgrade commands + +The Python 3.10 cleanup requires that Python 3.10 is removed from +the complete dependency trees in batch. If some of the +installed packages using an older
[gentoo-dev] Re: sys-libs/glibc: RDEPENDs
> On 31 Mar 2023, at 17:07, Raul Rangel wrote:
>
> Hello,
> I was looking at the glibc
> [ebuild](https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.37-r1.ebuild#n136)
> and noticed that it contains a lot of RDEPEND:
>RDEPEND="${COMMON_DEPEND}
>app-arch/gzip
>sys-apps/grep
>app-alternatives/awk
>sys-apps/gentoo-functions
>!!"
> Are gzip, grep, awk just legacy from before the EAPI7 era, or does
> glibc actually invoke grep, awk, etc? I'm working in a cross-compiled
> environment (not cross- packages) and wanted to avoid pulling in the
> additional dependencies if they aren't necessary.
>
I suspect some of these may be IDEPEND candidates for locale-gen.
> Thanks,
> Raul
[gentoo-dev] Python 3.11 to become the default and Python 3.9 to be disabled on 2023-05-01
Hi, everyone. Since everything is going smoother than anticipated, I've been approached about moving the planned switchover date sooner. Therefore, the current plan becomes to: - switch the default Python target from 3.10 to 3.11 - disable Python 3.9 target (the interpreter will stay) both on 2023-05-01, i.e. one month from now. If anyone sees a good reason not to, please speak now or forever hold your peace. This is also a very good time to look at your packages, in case they don't support 3.11 yet. The usual set of helpful links follows: list of packages not ported from 3.10 yet: https://qa-reports.gentoo.org/output/gpyutils/310-to-311.txt graph of packages not ported from 3.10 yet: https://qa-reports.gentoo.org/output/gpyutils/310-to-311.svg the relevant tracker: https://bugs.gentoo.org/896398 some CI results for testing on 3.11 (warning: you need to triple check them, the testing wasn't very thorough): https://github.com/mgorny/python-bump-testing/issues -- Best regards, Michał Górny
[gentoo-dev] Last rites: dev-python/booleanOperations, dev-python/defcon, dev-python/nototools
# Michał Górny (2023-03-31) # Packages with non-functional tests and no py3.11 support. They were # only needed for media-fonts/noto-emoji[buildfont], and that variant # was removed, so they have no revdeps now. # Removal on 2023-04-30. Bug #719882. dev-python/booleanOperations dev-python/defcon dev-python/nototools -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH 1/3] ruby-ng.eclass: improve error when no valid Ruby in USE_RUBY
On Wed, 2023-03-29 at 16:39 +0100, Sam James wrote: > This means we don't get confusing *DEPEND/REQUIRED_USE errors about > it being > unparseable and instead just get a straightforward die message > indicating > the problem. All three patches look good to me. Hans signature.asc Description: This is a digitally signed message part
