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:

• some ports are unlikely to meet the dependencies soon
• new ports won’t meet them at first even if they may meet
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’s 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:

• rename its python3-cryptography binary package to
python3-cryptography-rustless or something
• 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’m 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’t use
second+ alternatives. In that case, we’ll 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’s (if that’s okay),
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’s even an upstream
fork?).

The arches currently split as:

• alpha 3.4.8-2
• hppa 3.4.8-2
• hurd-amd64 3.4.8-2
• hurd-arm64 unknown, probably 3.x
• hurd-i386 3.4.8-2
• ia64 3.4.8-2
• loong64 41.0.7-5
• m68k 3.4.8-2
• powerpc 41.0.7-3
• ppc64 41.0.7-5
• sh4 3.4.8-2
• sparc64 41.0.7-5
• x32 38.0.4-4

(x32 seems to be lagging in the rust department, too…)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)