Re: python-cryptography vs. stainless steel ports

--000000000000ac72200613686f01
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le lun. 11 mars 2024 =C3=A0 20:17, Thorsten Glaser <[email protected]> a =C3=A9=
crit :

> Hi,
>
> we have still the situation that the current python-cryptography,
> having rather heavy rust ecosystem dependencies, cannot be built
> on some debian-ports architectures.
>
> This situation is not likely to go away:
>
> =E2=80=A2 some ports are unlikely to meet the dependencies soon
> =E2=80=A2 new ports won=E2=80=99t meet them at first even if they may mee=
t
>   them later (riscv64 and loong64 now meet them)
>
> For the t64 transition, I *think* I can just binNMU the last
> version that worked and porter-upload that, but that=E2=80=99s not a
> workable long-term solution, especially when python transitions
> come, etc.
>
> Is there a chance your team could fork the old python-cryptography
> source package (3.4.8-2) and do something like:
>
> =E2=80=A2 rename its python3-cryptography binary package to
>   python3-cryptography-rustless or something
> =E2=80=A2 let that Provide python3-cryptography in the same version
>
> Making python3-cryptography-rustless available on all arches
> has the benefit that people can test that their code will work
> on ports arches without having to bother installing one of them.
>
> I=E2=80=99m not entirely sure that having python3-cryptography-rustless
> Provides python3-cryptography, then other packages B-D/Depends
> python3-cryptography will work; IIRC, there was something about
> the first alternative must not be virtual and buildds won=E2=80=99t use
> second+ alternatives. In that case, we=E2=80=99ll instead need the
> python3-cryptography-rustless source package to build a second
> binary package python3-cryptography either as arch:all but in a
> lower version than the python-cryptography=E2=80=99s (if that=E2=80=99s o=
kay),
> or as arch:any on just the affected architectures (which will
> end up being an annoying to maintain whitelist) that Depends
> python3-cryptography-rustless, to keep things installable on
> the buildds.
>
> With this in unstable proper, debian-ports will have a much
> easier job, and maintainers (both of the python3-cryptography
> ecosystem/packages and of software using it) can more easily
> test things work, and your team can apply whatever new policy
> changes, dh-* helpers, etc. to the 3.4.8-based package, and
> backport bugfixes, etc. (and perhaps there=E2=80=99s even an upstream
> fork?).
>
> The arches currently split as:
>
> =E2=80=A2 alpha         3.4.8-2
> =E2=80=A2 hppa          3.4.8-2
> =E2=80=A2 hurd-amd64    3.4.8-2
> =E2=80=A2 hurd-arm64    unknown, probably 3.x
> =E2=80=A2 hurd-i386     3.4.8-2
> =E2=80=A2 ia64          3.4.8-2
> =E2=80=A2 loong64       41.0.7-5
> =E2=80=A2 m68k          3.4.8-2
> =E2=80=A2 powerpc       41.0.7-3
> =E2=80=A2 ppc64         41.0.7-5
> =E2=80=A2 sh4           3.4.8-2
> =E2=80=A2 sparc64       41.0.7-5
> =E2=80=A2 x32           38.0.4-4
>
> (x32 seems to be lagging in the rust department, too=E2=80=A6)
>
> Since this exists mostly to help d-ports, it would be fine to
> open an RC bug against it early to prevent it from showing up
> in releases, if desired.
>
> Thanks for considering,
> //mirabilos, helping out m68k for the time_t transition again
> --
> When he found out that the m68k port was in a pretty bad shape, he did
> not, like many before him, shrug and move on; instead, he took it upon
> himself to start compiling things, just so he could compile his shell.
> How's that for dedication. -- Wouter, about my Debian/m68k revival
>

While I'm very much concerned about architectures and compatibility,
it seems that for python-cryptography, it's a sinking boat:
The end of a very discussion dates from february, 2021 - 3 years ago:
https://github.com/pyca/cryptography/issues/5771#issuecomment-775990406

--000000000000ac72200613686f01
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 11 mars 2024 =C3=A0=C2=
=A020:17, Thorsten Glaser &lt;<a href=3D"mailto:[email protected]">[email protected]=
g</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">Hi,<br>
<br>
we have still the situation that the current python-cryptography,<br>
having rather heavy rust ecosystem dependencies, cannot be built<br>
on some debian-ports architectures.<br>
<br>
This situation is not likely to go away:<br>
<br>
=E2=80=A2 some ports are unlikely to meet the dependencies soon<br>
=E2=80=A2 new ports won=E2=80=99t meet them at first even if they may meet<=
br>
=C2=A0 them later (riscv64 and loong64 now meet them)<br>
<br>
For the t64 transition, I *think* I can just binNMU the last<br>
version that worked and porter-upload that, but that=E2=80=99s not a<br>
workable long-term solution, especially when python transitions<br>
come, etc.<br>
<br>
Is there a chance your team could fork the old python-cryptography<br>
source package (3.4.8-2) and do something like:<br>
<br>
=E2=80=A2 rename its python3-cryptography binary package to<br>
=C2=A0 python3-cryptography-rustless or something<br>
=E2=80=A2 let that Provide python3-cryptography in the same version<br>
<br>
Making python3-cryptography-rustless available on all arches<br>
has the benefit that people can test that their code will work<br>
on ports arches without having to bother installing one of them.<br>
<br>
I=E2=80=99m not entirely sure that having python3-cryptography-rustless<br>
Provides python3-cryptography, then other packages B-D/Depends<br>
python3-cryptography will work; IIRC, there was something about<br>
the first alternative must not be virtual and buildds won=E2=80=99t use<br>
second+ alternatives. In that case, we=E2=80=99ll instead need the<br>
python3-cryptography-rustless source package to build a second<br>
binary package python3-cryptography either as arch:all but in a<br>
lower version than the python-cryptography=E2=80=99s (if that=E2=80=99s oka=
y),<br>
or as arch:any on just the affected architectures (which will<br>
end up being an annoying to maintain whitelist) that Depends<br>
python3-cryptography-rustless, to keep things installable on<br>
the buildds.<br>
<br>
With this in unstable proper, debian-ports will have a much<br>
easier job, and maintainers (both of the python3-cryptography<br>
ecosystem/packages and of software using it) can more easily<br>
test things work, and your team can apply whatever new policy<br>
changes, dh-* helpers, etc. to the 3.4.8-based package, and<br>
backport bugfixes, etc. (and perhaps there=E2=80=99s even an upstream<br>
fork?).<br>
<br>
The arches currently split as:<br>
<br>
=E2=80=A2 alpha=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03.4.8-2<br>
=E2=80=A2 hppa=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3.4.8-2<br>
=E2=80=A2 hurd-amd64=C2=A0 =C2=A0 3.4.8-2<br>
=E2=80=A2 hurd-arm64=C2=A0 =C2=A0 unknown, probably 3.x<br>
=E2=80=A2 hurd-i386=C2=A0 =C2=A0 =C2=A03.4.8-2<br>
=E2=80=A2 ia64=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3.4.8-2<br>
=E2=80=A2 loong64=C2=A0 =C2=A0 =C2=A0 =C2=A041.0.7-5<br>
=E2=80=A2 m68k=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3.4.8-2<br>
=E2=80=A2 powerpc=C2=A0 =C2=A0 =C2=A0 =C2=A041.0.7-3<br>
=E2=80=A2 ppc64=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A041.0.7-5<br>
=E2=80=A2 sh4=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03.4.8-2<br>
=E2=80=A2 sparc64=C2=A0 =C2=A0 =C2=A0 =C2=A041.0.7-5<br>
=E2=80=A2 x32=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A038.0.4-4<br>
<br>
(x32 seems to be lagging in the rust department, too=E2=80=A6)<br>
<br>
Since this exists mostly to help d-ports, it would be fine to<br>
open an RC bug against it early to prevent it from showing up<br>
in releases, if desired.<br>
<br>
Thanks for considering,<br>
//mirabilos, helping out m68k for the time_t transition again<br>
-- <br>
When he found out that the m68k port was in a pretty bad shape, he did<br>
not, like many before him, shrug and move on; instead, he took it upon<br>
himself to start compiling things, just so he could compile his shell.<br>
How&#39;s that for dedication. -- Wouter, about my Debian/m68k revival<br><=
/blockquote><div><br></div><div>While I&#39;m very much concerned about arc=
hitectures and compatibility,</div><div>it seems that for python-cryptograp=
hy, it&#39;s a sinking boat:</div><div>The end of a very discussion dates f=
rom february, 2021 - 3 years ago:</div><div><a href=3D"https://github.com/p=
yca/cryptography/issues/5771#issuecomment-775990406">https://github.com/pyc=
a/cryptography/issues/5771#issuecomment-775990406</a></div><div>=C2=A0</div=
></div></div>

--000000000000ac72200613686f01--