Re: [gentoo-dev] How to structure our RISC-V support

[Yixun Lan]

On 22:01 Thu 06 May , Andreas K. Huettel wrote:
> Howdy. 
> 
> I'm sending this not only to the team members on the alias, but also 
> to the whole dev list for discussion. 
> 
> So far I've been trying to support in Gentoo the full risc-v multilib 
> directory structure and the ABI sets supported by glibc. According to 
> specs this means for riscv64 
> 
> -mabi=rv64gc -march=lp64d 
>   libdir = lib64/lp64d
>   ("hardfloat")
> 
> -mabi=rv64imac -march=lp64
>   libdir = lib64/lp64
>   ("softfloat")
> 
> and theoretically similar for riscv32 (which just landed in glibc and 
> is still broken in qemu-user).
> 
> However, this leads to several levels of pain (and I definitely dont 
> have time to deal with it myself):
> 
> a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads 
> to difficulties in build systems. Right now Qt5 and CMake are still 
> somewhat broken (in *Gentoo*).
> 
> b) Rust only supports rv64gc/lp64d. (Which is arguably what you should 
> have for decent Linux support.)
> 
> I'm pretty sure these are not the only things, but they are somewhat 
> symptomatic.
> 
> So, I would like to bring two proposals up for discussion.
> 
> 1) We stop caring about anything except rv64gc/lp64d.
> People can still bootstrap other stuff with crossdev etc, but the 
> Gentoo tree and the riscv keyword reflect that things work with above 
> -mabi and -march settings.
> 
fine by me, for current software/upstream state, it's probably the most 
practical way 
to only support lp64d, this will significantly ease our life ..
besides, it's relatively easy if people want to support more (lp64/lp32..) later

> 2) We drop the multilib paths and use "normal" lib64, with additional 
> "safety symlinks" (/usr)/lib64/lp64d -> .
> This is what SuSE and (I think) Fedora already does. The symlink 
> should be there since "lib64" is NOT an official fallback coded into 
> gcc/glibc/binutils; the only fallback present is "lib" ...
> 
can we use different scheme for non-multilib vs multilib?
1) non-multilibe: just use "normal" lib64, keep align with other ARCHs (amd64)?
2) multilib: just stick to current two level lib path

> -- 
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer
> (council, toolchain, base-system, perl, libreoffice)



-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [gentoo-dev] How to structure our RISC-V support

[Yixun Lan]

On 22:30 Thu 06 May , Andreas K. Huettel wrote:
> > 
> > Haven't I told you using two-level libdirs is stupid?  So yes,
> > please do that and let us be happy once again.
> > 
> > That said, where does lp64gc land?  Or isnon-multilib
> > one-or-the-other the goal?
> 
> It would be non-multilib one-or-the-other then for us.
> The main relevant combination is rv64gc/lp64d, which is arguably what 
> a linux machine "should have".
> 
> (I could also imagine to keep rv64imac/lp64 profile and stages (also 
> using lib64), these would have to mask stuff like rust then though.)
> 
I'm fine with rust masked in lp64/other profile..
but in my opinion: it's really up to upstream should fix/support it

> (Unless Palmer et al come up with a fix for the libdirs on the 
> upstream side of things. Already e.g. libdir=lib64-lp64d would be much 
> easier to handle I suspect.)

using one level path (eg. lib64-lp64d) won't fix the problem,
the root cause is that we use a 'non-standard' lib path (QT5, Cmake issue),
not matter it's one level or two level path, see bug here [1]

[1] https://bugs.gentoo.org/781134
https://gitlab.kitware.com/cmake/cmake/-/issues/22138

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [gentoo-dev] last-rite: some java stuff

[Miroslav Šulc]

i'm sorry but this package is pretty old, i could not find a working 
homepage for it and we have no purpose for it. it would be better if 
copied to the science overlay.


fordfrog


Dne 07. 05. 21 v 1:50 Alessandro Barbieri napsal(a):


# Miroslav Šulc mailto:fordf...@gentoo.org>>
(2021-04-28)
# no consumers
# removal in 30 days
# see bug: https://bugs.gentoo.org/786783

dev-java/skinlf


It's needed for scilab[gui] from the science overlay. It may be worth 
keeping it or moving it to science

Re: [gentoo-dev] last-rite: some java stuff

[Alessandro Barbieri]

>
> # Miroslav Šulc  (2021-04-28)
> # no consumers
> # removal in 30 days
> # see bug: https://bugs.gentoo.org/786783
> dev-java/skinlf
>

It's needed for scilab[gui] from the science overlay. It may be worth
keeping it or moving it to science

>

Re: [gentoo-dev] How to structure our RISC-V support

[Palmer Dabbelt]

On Thu, 06 May 2021 13:30:45 PDT (-0700), dilfri...@gentoo.org wrote:


Haven't I told you using two-level libdirs is stupid?  So yes,
please do that and let us be happy once again.

That said, where does lp64gc land?  Or isnon-multilib
one-or-the-other the goal?


It would be non-multilib one-or-the-other then for us.
The main relevant combination is rv64gc/lp64d, which is arguably what 
a linux machine "should have".


(I could also imagine to keep rv64imac/lp64 profile and stages (also 
using lib64), these would have to mask stuff like rust then though.)


(Unless Palmer et al come up with a fix for the libdirs on the 
upstream side of things. Already e.g. libdir=lib64-lp64d would be much 
easier to handle I suspect.)


TBH: I'm not really going to come up with something better beacuse I 
came up with the current (and likely broken) scheme and I still don't 
fully understand why.  So if you have suggestions as to something that 
would actually work that would be great, as otherwise I'm just going to 
come up with something broken again ;)


Is the constraint just "no sub-directories for libraries"?  IIRC we did 
that because someone else was already doing it and it seems to be less 
of a FHS break that adding a bunch of first-level directories.  I can 
totally buy I was just wrong, though.  If that's all we need then this 
shouldn't be that hard to fix upstream, of course it'll take a while to 
get everyone updated but at least we'll have a way to steer everyone.

Re: [gentoo-dev] How to structure our RISC-V support

[Andreas K. Huettel]

> 
> Haven't I told you using two-level libdirs is stupid?  So yes,
> please do that and let us be happy once again.
> 
> That said, where does lp64gc land?  Or isnon-multilib
> one-or-the-other the goal?

It would be non-multilib one-or-the-other then for us.
The main relevant combination is rv64gc/lp64d, which is arguably what 
a linux machine "should have".

(I could also imagine to keep rv64imac/lp64 profile and stages (also 
using lib64), these would have to mask stuff like rust then though.)

(Unless Palmer et al come up with a fix for the libdirs on the 
upstream side of things. Already e.g. libdir=lib64-lp64d would be much 
easier to handle I suspect.)

-- 
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.

Re: [gentoo-dev] How to structure our RISC-V support

[Michał Górny]

On Thu, 2021-05-06 at 22:01 +0200, Andreas K. Huettel wrote:
> Howdy. 
> 
> I'm sending this not only to the team members on the alias, but also 
> to the whole dev list for discussion. 
> 
> So far I've been trying to support in Gentoo the full risc-v multilib 
> directory structure and the ABI sets supported by glibc. According to 
> specs this means for riscv64 
> 
> -mabi=rv64gc -march=lp64d 
>   libdir = lib64/lp64d
>   ("hardfloat")
> 
> -mabi=rv64imac -march=lp64
>   libdir = lib64/lp64
>   ("softfloat")
> 
> and theoretically similar for riscv32 (which just landed in glibc and 
> is still broken in qemu-user).
> 
> However, this leads to several levels of pain (and I definitely dont 
> have time to deal with it myself):
> 
> a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads 
> to difficulties in build systems. Right now Qt5 and CMake are still 
> somewhat broken (in *Gentoo*).
> 
> b) Rust only supports rv64gc/lp64d. (Which is arguably what you should 
> have for decent Linux support.)
> 
> I'm pretty sure these are not the only things, but they are somewhat 
> symptomatic.
> 
> So, I would like to bring two proposals up for discussion.
> 
> 1) We stop caring about anything except rv64gc/lp64d.
> People can still bootstrap other stuff with crossdev etc, but the 
> Gentoo tree and the riscv keyword reflect that things work with above 
> -mabi and -march settings.
> 
> 2) We drop the multilib paths and use "normal" lib64, with additional 
> "safety symlinks" (/usr)/lib64/lp64d -> .
> This is what SuSE and (I think) Fedora already does. The symlink 
> should be there since "lib64" is NOT an official fallback coded into 
> gcc/glibc/binutils; the only fallback present is "lib" ...
> 
> Opinions?
> 

Haven't I told you using two-level libdirs is stupid?  So yes, please do
that and let us be happy once again.

That said, where does lp64gc land?  Or isnon-multilib one-or-the-other
the goal?

-- 
Best regards,
Michał Górny

[gentoo-dev] Re: How to structure our RISC-V support

[Palmer Dabbelt]

On Thu, 06 May 2021 13:01:23 PDT (-0700), dilfri...@gentoo.org wrote:
Howdy. 

I'm sending this not only to the team members on the alias, but also 
to the whole dev list for discussion. 

So far I've been trying to support in Gentoo the full risc-v multilib 
directory structure and the ABI sets supported by glibc. According to 
specs this means for riscv64 

-mabi=rv64gc -march=lp64d 
  libdir = lib64/lp64d

  ("hardfloat")

-mabi=rv64imac -march=lp64
  libdir = lib64/lp64
  ("softfloat")

and theoretically similar for riscv32 (which just landed in glibc and 
is still broken in qemu-user).


However, this leads to several levels of pain (and I definitely dont 
have time to deal with it myself):


a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads 
to difficulties in build systems. Right now Qt5 and CMake are still 
somewhat broken (in *Gentoo*).


b) Rust only supports rv64gc/lp64d. (Which is arguably what you should 
have for decent Linux support.)


I'm pretty sure these are not the only things, but they are somewhat 
symptomatic.


So, I would like to bring two proposals up for discussion.

1) We stop caring about anything except rv64gc/lp64d.
People can still bootstrap other stuff with crossdev etc, but the 
Gentoo tree and the riscv keyword reflect that things work with above 
-mabi and -march settings.


IMO dropping multilib is fine from a "working on real hardware" 
perspective, as that's all anyone is going to have for the forseeable 
future -- at least for the sort of hardware you'd want to run a 
desktop/server style Linux distro on (something like buildroot might be 
interested in other ISA/ABI combos).


That said, it seems like a lot of the distros are punting on multilib 
because of this path issue.  If that's really the worry then I wouldn't 
be opposed to just fixing it in GCC/glibc.  Ideally we'd be able to just 
add paths so we don't break the ABI, but if the ABI we came up with 
really hasn't been used by anyone then I wouldn't be opposed to breaking 
it if it means we can actually get multilib up and running -- we'd have 
to talk with a lot of people for that, though.


In the long run I think we will want multilib to work, as we're likely 
to end up with some ISA extensions that are useful enough to want to 
build general code for but not so useful that everyone has them -- B and 
V, for example.  We're a long way away from having good code gen for V 
(at least for arbitrary code, some special libraries might show up 
sooner), but B is a bit closer and might be amenable to having a system 
built with it.  That may be a bit less interesting for Gentoo, where 
we're building things locally (and there shouldn't be any -bin packages 
on RISC-V yet, we're not getting ports of proprietary stuff yet), but if 
we can be a forcing function to put together a multlib ABI that actually 
works then that's a win for everyone.


2) We drop the multilib paths and use "normal" lib64, with additional 
"safety symlinks" (/usr)/lib64/lp64d -> .
This is what SuSE and (I think) Fedora already does. The symlink 
should be there since "lib64" is NOT an official fallback coded into 
gcc/glibc/binutils; the only fallback present is "lib" ...


IMO we can just fix that one upstream.  If all the distros are going to 
do it anyway then it'd be better to just fix it, there's not a lot of 
sense in forcing everyone to patch these things.  IIUC that one would be 
an ABI-compatible addition, but again we'd need to talk about it in 
GCC/glibc land (and with some other distro folks).


Sorry this is such a mess!

Re: [gentoo-dev] How to structure our RISC-V support

[Andreas K. Huettel]

> 
> -mabi=rv64gc -march=lp64d
should be -march=rv64gc -mabi=lp64d

>   libdir = lib64/lp64d
>   ("hardfloat")
> 
> -mabi=rv64imac -march=lp64
should be -march=rv64imac -mabi=lp64

>   libdir = lib64/lp64
>   ("softfloat")
> 

(but that doesnt change the rest of the argument)

-- 
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] How to structure our RISC-V support

[Andreas K. Huettel]

Howdy. 

I'm sending this not only to the team members on the alias, but also 
to the whole dev list for discussion. 

So far I've been trying to support in Gentoo the full risc-v multilib 
directory structure and the ABI sets supported by glibc. According to 
specs this means for riscv64 

-mabi=rv64gc -march=lp64d 
  libdir = lib64/lp64d
  ("hardfloat")

-mabi=rv64imac -march=lp64
  libdir = lib64/lp64
  ("softfloat")

and theoretically similar for riscv32 (which just landed in glibc and 
is still broken in qemu-user).

However, this leads to several levels of pain (and I definitely dont 
have time to deal with it myself):

a) In many places the two-level libdir (e.g., /usr/lib64/lp64d) leads 
to difficulties in build systems. Right now Qt5 and CMake are still 
somewhat broken (in *Gentoo*).

b) Rust only supports rv64gc/lp64d. (Which is arguably what you should 
have for decent Linux support.)

I'm pretty sure these are not the only things, but they are somewhat 
symptomatic.

So, I would like to bring two proposals up for discussion.

1) We stop caring about anything except rv64gc/lp64d.
People can still bootstrap other stuff with crossdev etc, but the 
Gentoo tree and the riscv keyword reflect that things work with above 
-mabi and -march settings.

2) We drop the multilib paths and use "normal" lib64, with additional 
"safety symlinks" (/usr)/lib64/lp64d -> .
This is what SuSE and (I think) Fedora already does. The symlink 
should be there since "lib64" is NOT an official fallback coded into 
gcc/glibc/binutils; the only fallback present is "lib" ...

Opinions?

Cheers,
Andreas



-- 
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.

Re: [gentoo-dev] [News item review] Exim >=4.94 transports: tainted not permitted

[Fabian Groffen]

On 06-05-2021 15:01:33 +0200, Andreas K. Huettel wrote:
> > 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].
> 
> This is a safety mechanism that is part of Perl (essentially a way of 
> tracking data that is derived from "insecure" sources).
> 
> So it probably would make sense to at least point towards that concept 
> in Perl.

I think the concept is clear to most from the descriptions one can find.
The big problem however is the solution, how to fix one's configuration.

Luckily it seems people find their way to Exim's bugtracker to get help
there.

Thanks for the suggestion though,
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

[Andreas K. Huettel]

Am Sonntag, 2. Mai 2021, 11:56:34 CEST schrieb Fabian Groffen:
> 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].

This is a safety mechanism that is part of Perl (essentially a way of 
tracking data that is derived from "insecure" sources).

So it probably would make sense to at least point towards that concept 
in Perl.

https://perldoc.perl.org/perlsec



-- 
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.

Re: [gentoo-dev] [PATCH news v3] Add Python 3.9 news item

[Alexey Sokolov]

Oops, I thought I did that. Fixed.

чт, 6 мая 2021 г. в 07:57, Michał Górny :
>
> On Thu, 2021-05-06 at 01:13 +0100, Alexey Sokolov wrote:
> > Here's the Russian version
> >
>
> Could you include a copyright signoff, please?  This is pretty major
> work.
>
> --
> Best regards,
> Michał Górny
>
>
>
From 1bd30ecd61096a683f71533669c539d42b655bfe Mon Sep 17 00:00:00 2001
From: Alexey Sokolov 
Date: Thu, 6 May 2021 01:05:38 +0100
Subject: [PATCH] Translate python3-9 to Ru

Signed-off-by: Alexey Sokolov 
---
 .../2021-05-05-python3-9.ru.txt   | 113 ++
 1 file changed, 113 insertions(+)
 create mode 100644 2021-05-05-python3-9/2021-05-05-python3-9.ru.txt

diff --git a/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt
new file mode 100644
index 000..cfef9d4
--- /dev/null
+++ b/2021-05-05-python3-9/2021-05-05-python3-9.ru.txt
@@ -0,0 +1,113 @@
+Title: Python 3.9 станет питоном по умолчанию 2021-06-01
+Author: Michał Górny 
+Translator: Alexey Sokolov 
+Posted: 2021-05-05
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Installed: dev-lang/python:3.7
+Display-If-Installed: dev-lang/python:3.8
+
+1 июня 2021 года мы собираемся переключить Python по умолчанию на системах
+Gentoo с версии 3.8 на версию 3.9.  Если вы не меняли значения PYTHON_TARGETS и
+PYTHON_SINGLE_TARGET, изменение затронет систему сразу: пакетный менеджер
+попытается применить изменение при следующем обновлении системы.
+
+Если же вы изменили эти значения, предпочитаете более безопасный подход, или
+при обновлении возникли проблемы, продолжайте читать.
+
+Пожалуйста, обратите внимание, что метод обновления по умолчанию переключает
+пакеты на новую версию питона, когда они пересобираются.  Это означает, что для
+пересборки пакета все зависимые пакеты должны уже поддерживать новую версию, и
+некоторые программы временно могут не находить свои зависимости во время
+обновления (однако, скорее всего, уже запущенные программы будут в порядке).
+
+Если PYTHON_TARGETS или PYTHON_SINGLE_TARGET объявлены в вашем make.conf,
+пожалуйста, удалите их оттуда, потому что они будут конфликтовать с показанными
+далее кусками из package.use.  Мы не рекомендуем использовать make.conf для
+этих переменных, поскольку они мешают применяться значениям по умолчанию для
+пакетов, где это необходимо.  В этой новости мы подразумеваем, что вы
+используете /etc/portage/package.use или его эквивалент для вашего пакетного
+менеджера.
+
+У вас есть выбор из следующих вариантов:
+
+1. Если вы хотите, чтобы питон обновлялся сам, вы можете удалить объявленные
+   PYTHON_TARGETS и PYTHON_SINGLE_TARGET. Когда значения по умолчанию
+   изменятся, пакетный менеджер должен сам всё обновить. Но если возникнут
+   проблемы, вам всё равно может прийтись запустить команды обновления.
+
+2. Если вы хотите пока отложить обновление, вы можете явно указать старые
+   значения в package.use.
+
+3. Если вы хотите обновиться раньше, вы можете явно указать новые значения и
+   запустить команды обновления.
+
+4. Если вы хотите более безопасный подход, у которого меньше шансов поломать
+   пакеты во время обновления, вы можете произвести последовательность шагов,
+   описанных далее.
+
+5. Наконец, вы можете произвольным образом комбинировать значения
+   PYTHON_TARGETS и PYTHON_SINGLE_TARGET.
+
+
+Откладывание обновления
+===
+Чтобы отложить обновление, явно укажите старые значения:
+
+*/* PYTHON_TARGETS: -* python3_8
+*/* PYTHON_SINGLE_TARGET: -* python3_8
+
+Это заставит систему использовать Python 3.8 и предотвратит будущие обновления.
+Однако, такое решение сойдёт только на несколько месяцев; когда-нибудь вам
+всё-таки нужно будет обновиться.
+
+
+Принудительное обновление
+=
+Чтобы обновиться до Python 3.9 раньше, явно укажите новые значения:
+
+*/* PYTHON_TARGETS: -* python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_9
+
+При этом важно не забыть удалить эти строки после смены значений по умолчанию,
+иначе они помешают будущим автоматическим обновлениям до следующих версий
+питона.
+
+
+Процедура безопасного обновления
+
+Более безопасный подход такой: сначала добавляется в систему поддержка Python
+3.9, а затем удаляется Python 3.8.  Однако, все затронутые пакеты будут
+пересобраны дважды, и это заметно дольше.
+
+Сначала включите и Python 3.8, и Python 3.9 и запустите команды обновления:
+
+*/* PYTHON_TARGETS: -* python3_8 python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_8
+
+Затем замените PYTHON_SINGLE_TARGET и ещё раз запустите команды:
+
+*/* PYTHON_TARGETS: -* python3_8 python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_9
+
+Наконец, вот окончательная версия, и не забудьте запустить команды:
+
+*/* PYTHON_TARGETS: -* python3_9
+*/* PYTHON_SINGLE_TARGET: -* python3_9
+
+После смены значений по умолчанию вы можете удалить эти настройки. Или же вы
+можете оставить их, предотвращая автоматическое обновлени

[gentoo-dev] sci-libs/cbflib & sci-chemistry/rasmol: last-rites

[Joonas Niilola]

sci-libs/cbflib: Doesn't compile with GCC-10 or GCC-11. Was never ported
to work with GCC-10+. sci-chemistry/rasmol depends on cbflib.

Both packages have updates ignored in Gentoo, and their ebuilds pretty
much untouched during git-era. Both had their latest upstream version
release in 2018.

Both EAPI-5 etc.

Removal in ~30 days. Bug: https://bugs.gentoo.org/788508

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Initial Python 3.10 porting notes

[Michał Górny]

On Thu, 2021-05-06 at 09:31 +0200, Michał Górny wrote:
> Hi,
> 
> As you have probably noticed, the first Python 3.10.0 beta has landed
> (which means no major changes anymore, only bug fixes), and I've started
> adding python3.10 target to various packages.  So far I've managed to
> reach pytest which is a good sign but there are still many broken
> (upstream) packages.
> 
> You can try porting some low-hanging fruit already but please note
> the following:
> 
> 1. The target is stable-masked and won't be stable for at least another
> half a year (final 3.10.0 release is planned in September).
> 
> 2. Remember to test packages.  In my very short experience, 3.10 breaks
> more stuff than 3.9 or 3.8 did (but then, I've started testing earlier).
> 
> 3. Do *not* revbump when adding 3.10.  It's stable-masked, so you don't
> have to worry about breaking stable.
> 
> 4. If you're about to bump what looks like low-hanging fruit, it's
> a good idea to try porting the current version first.  More versions
> with py3.10 support to choose from, less problems later on.  Though
> I suppose it doesn't matter much given that it won't go stable in a few
> months.
> 
> 5. If stuff fails, try upstream's VCS -- there might be some easy
> backports available.
> 
> 6. Note that urllib3 is not yet ready which means a significant portion
> of packages is blocked anyway.
> 
> If you have any problems, feel free to ping me.
> 

Oh, and if you're using pkgcheck, it will give you a PythonCompatUpdate
result if the package in question has all the deps ready.


-- 
Best regards,
Michał Górny

[gentoo-dev] Initial Python 3.10 porting notes

[Michał Górny]

Hi,

As you have probably noticed, the first Python 3.10.0 beta has landed
(which means no major changes anymore, only bug fixes), and I've started
adding python3.10 target to various packages.  So far I've managed to
reach pytest which is a good sign but there are still many broken
(upstream) packages.

You can try porting some low-hanging fruit already but please note
the following:

1. The target is stable-masked and won't be stable for at least another
half a year (final 3.10.0 release is planned in September).

2. Remember to test packages.  In my very short experience, 3.10 breaks
more stuff than 3.9 or 3.8 did (but then, I've started testing earlier).

3. Do *not* revbump when adding 3.10.  It's stable-masked, so you don't
have to worry about breaking stable.

4. If you're about to bump what looks like low-hanging fruit, it's
a good idea to try porting the current version first.  More versions
with py3.10 support to choose from, less problems later on.  Though
I suppose it doesn't matter much given that it won't go stable in a few
months.

5. If stuff fails, try upstream's VCS -- there might be some easy
backports available.

6. Note that urllib3 is not yet ready which means a significant portion
of packages is blocked anyway.

If you have any problems, feel free to ping me.

-- 
Best regards,
Michał Górny