Re: python-cryptography vs. stainless steel ports
On 3/14/24 06:53, Thorsten Glaser wrote: Dixi quod… Is there a chance your team could fork the old python-cryptography source package (3.4.8-2) and do something like: Apparently, pyopenssl needs to also be forked as it wraps the above and, between 21.0.0-1 and 22.1.0-1, it began requiring the rust version of python-cryptography ☹ And gstreamer1.0 seems to depend on rust as well, which blocks glade and as such some gnome apps: https://buildd.debian.org/status/package.php?p=gstreamer1.0=sid Helge
Re: python-cryptography vs. stainless steel ports
Dixi quod… >Is there a chance your team could fork the old python-cryptography >source package (3.4.8-2) and do something like: Apparently, pyopenssl needs to also be forked as it wraps the above and, between 21.0.0-1 and 22.1.0-1, it began requiring the rust version of python-cryptography ☹ bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: python-cryptography vs. stainless steel ports
Jérémy Lal dixit: >Anyone had experience with the version 3.3 to 38.0 migration ? >Maybe the API didn't change that much. We cannot go past 3.4 because newer versions (starting at 38) have a hard dependency on rust stuff. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Re: python-cryptography vs. stainless steel ports
Le lun. 11 mars 2024 à 21:53, Thorsten Glaser a écrit : > Jérémy Lal dixit: > > >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 > > Ouch. > > cbmuser also has hopes for rustc_codegen_gcc, but I believe that > quite a way off for regular use in Debian yet and won’t hold my > breath. > > So, perhaps at least do palliative care for the 3.8-based package > in the meantime? Porters can help, but we don’t know the python ecosystem well. Anyone had experience with the version 3.3 to 38.0 migration ? Maybe the API didn't change that much.
Re: python-cryptography vs. stainless steel ports
Jérémy Lal dixit: >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 Ouch. cbmuser also has hopes for rustc_codegen_gcc, but I believe that quite a way off for regular use in Debian yet and won’t hold my breath. So, perhaps at least do palliative care for the 3.8-based package in the meantime? Porters can help, but we don’t know the python ecosystem well. bye, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“
Re: python-cryptography vs. stainless steel ports
Le lun. 11 mars 2024 à 20:17, Thorsten Glaser a é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: > > • 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-amd643.4.8-2 > • hurd-arm64unknown, 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 > 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
python-cryptography vs. stainless steel ports
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-amd643.4.8-2 • hurd-arm64unknown, 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
